当前位置:Gxlcms > mysql > 使用IBMDB2时如何识别最常见的损坏问题

使用IBMDB2时如何识别最常见的损坏问题

时间:2021-07-01 10:21:17 帮助过:153人阅读

了解在使用 IBM DB2 时如何识别最常见的损坏问题,并对这些问题进行分类。在本文中,将了解一些纠正和预防技术,您可以用它们来解决讨厌的损坏问题。

被视为是最麻烦的业务问题之一,损坏常常在不知不觉中逐渐形成,给企业带来不利影响。简言之,可以将损坏 定义为中的任何意外项。损坏问题可能会对系统造成严重的性能冲击。在某些情况下,它可能会导致频繁的系统崩溃,引发关键业务系统宕机。数据库损坏可发生在任何层面,从 DB2 到操作系统以及硬件层。因此,了解和排除故障很重要,即分析所有可能受影响的层,并收集可能尽快需要的任何可用的诊断数据。

在本文中,您将了解为何数据库会在遇到损坏问题时离线。您还将学习分析损坏症状,区分易于修复的故障和灾难性故障。本文将阐明使用 IBM DB2 时的损坏问题,并帮助 DB2 用户理解和选择处理这种关键的高影响问题的最佳方法。

本文首先讨论可能的损坏来源,然后解释以下任务:

  1. 识别和排除损坏故障,在使用 DB2 时识别数据库中的损坏问题并对其进行分类,辅以 db2diag.log 中出现的样例症状消息。损坏问题可以大体分为五个类别:数据页面损坏(或表损坏)、索引损坏、CBIT 损坏、日志损坏和压缩描述符损坏。
  2. 使用 db2dart 和 INSPECT 识别损坏问题,洞悉有用的 DB2 命令,db2dart 和 INSPECT,来检查数据库损坏。
  3. 从损坏中恢复的方法,一旦识别到一个损坏问题,如何着手处理这些情况、要收集什么数据、如何从该状况中恢复过来,这些至关重要。学习可能的恢复方法以及如何选择可用方案。
  4. 避免可能的损坏的预防性战略,讨论最佳实践。

来源

数据库损坏可能在写入、读取、存储、传输或处理过程中发生,这会向原始数据引入非计划中的更改。损坏问题的一些常见原因:

  1. 损坏的文件系统是数据库中出现损坏的最常见原因之一。突然的系统关闭、电涌、文件系统双机挂载、迁移磁盘、文件系统级活动,比如数据库上线运行时检查和修复文件系统(使用的实用程序包括 Linux® 上的 fsck),在文件打开时使用 Ctrl+Alt+Delete 以及病毒,都可能在数据库中引入意外的变更。
  2. 硬件故障。
  3. 内存损坏。
  4. DB2 缺陷。
  5. I/O 和网络问题(如光纤适配器和交换机中的问题)。
  6. 不正确的应用程序编码。
  7. 缓冲池 (sqldPage) 和文件系统中存储的页面的值不一致。
  8. 重写磁盘数据会导致损坏问题。
  9. 用户对数据库的重要配置文件、日志文件、日志控制文件等的干扰都会使数据库处于不一致的状态。

虽说损坏问题由各种原因而致,确切地查明是什么导致了数据损坏是极具挑战的。在大部分情况下,该问题是由文件系统问题和硬件问题引起的。

识别和排除故障

对于一个 DBMS,页面 是由操作系统为一个程序执行的内存分配的数据的最小单元,在主内存与任何其他辅助存储(比如硬盘驱动器)之间传输。因此所谓数据库损坏也就是说数据库中的某些页面被损坏了。

如果 DB2 有无法得体处理的错误情况,panic 是它会用来招致崩溃的一种方法。当 DB2 检测到一个页面损坏时,它通过一个受控崩溃 (panic) 停止所有处理,因为它无法确定数据库完整性。这也是为了阻止进一步的数据损害或丢失。

当 DB2 遇到数据库损坏时,db2diag.log 中转储很多错误消息。当出现意外中断且启用了自动的首次出现数据捕获 (FODC) 时,会基于症状来收集数据。当满足以下条件之一时,DB2 9.5 上会自动收集 FODC 数据:

  1. FOCD_Trap,当发生一个实例范围内的陷阱时。
  2. FODC_Panic,当一个 DB2 引擎检测到不连贯且决定不继续时。
  3. FODC_BadPage,当检测到坏页面时。
  4. FODC_DBMarkedBad,当数据库因一个错误而被标记为 “坏” 时。

要搜集必要的信息,比如 OS 诊断(例如,AIX® 上的 errpt –a、snap 和 fileplace 输出)以及任何硬件诊断(状态保存和错误日志等),关键是要包含 OS 和硬件支持。重要的是要确保关键的文件系统有足够的磁盘空间,比如转储空间和日志目录,从而确保完全捕获关键事件。

您可以查看 db2diag.log,确认 panic 是因为损坏还是另外的原因引起的。下面您会看到如何识别 DB2 中的损坏并对其进行分类。以下是识别损坏的最常见的一些 db2diag.log 错误消息。

人气教程排行