被视为是最麻烦的业务问题之一，数据库损坏常常在不知不觉中逐渐形成，给企业带来不利影响。简言之，可以将损坏 定义为数据库中的任何意外项。损坏问题可能会对系统造成严重的性能冲击。在某些情况下，它可能会导致频繁的系统崩溃，引发关键业务系统宕机。数据库损坏可发生在任何层面，从 DB2 到操作系统以及硬件层。因此，了解和排除故障很重要，即分析所有可能受影响的层，并收集可能尽快需要的任何可用的诊断数据。
在本文中，您将了解为何数据库会在遇到损坏问题时离线。您还将学习分析损坏症状，区分易于修复的故障和灾难性故障。本文将阐明使用 IBM DB2 时的损坏问题，并帮助 DB2 用户理解和选择处理这种关键的高影响问题的最佳方法。
本文首先讨论可能的损坏来源，然后解释以下任务：
识别和排除损坏故障，在使用 DB2 时识别数据库中的损坏问题并对其进行分类，辅以 db2diag.log 中出现的样例症状消息。损坏问题可以大体分为
五个类别：数据页面损坏（或表损坏）、索引损坏、CBIT 损坏、日志损坏和压缩描述符损坏。 使用 db2dart 和 INSPECT 识别损坏问题，洞悉有用的 DB2 命令，db2dart 和 INSPECT，来检查数据库损坏。 从损坏中恢复的方法，一旦识别到一个损坏问题，如何着手处理这些情况、要收集什么数据、如何从该状况中恢复过来，这些至关重要。学习可能的恢复方法以及如何选择可用方案。 避免可能的损坏的预防性战略，讨论最佳实践。
来源
数据库损坏可能在写入、读取、存储、传输或处理过程中发生，这会向原始数据引入非计划中的更改。损坏问题的一些常见原因：
损坏的文件系统是数据库中出现损坏的最常见原因之一。突然的系统关闭、电涌、文件系统双机挂载、迁移
磁盘、文件系统级活动，比如数据库上线运行时检查和修复文件系统（使用的实用程序包括 Linux® 上的 fsck），在文件打开时使用 Ctrl+Alt+">Delete 以及病毒，都可能在数据库中引入意外的变更。 硬件故障。 内存损坏。 DB2 缺陷。 I/O 和网络问题（如光纤适配器和交换机中的问题）。 不正确的应用程序编码。 缓冲池 (sqld
Page) 和文件系统中存储的页面的值不一致。 重写磁盘数据会导致损坏问题。 用户对数据库的重要配置文件、日志文件、日志控制文件等的干扰都会使数据库处于不一致的状态。
虽说损坏问题由各种原因而致，确切地查明是什么导致了数据损坏是极具挑战的。在大部分情况下，该问题是由文件系统问题和硬件问题引起的。
识别和排除故障
对于一个 DBMS，页面 是由操作系统为一个程序执行的内存分配的数据的最小单元，在主内存与任何其他辅助存储（比如硬盘驱动器）之间传输。因此所谓数据库损坏也就是说数据库中的某些页面被损坏了。
如果 DB2 有无法得体处理的错误情况，panic 是它会用来招致崩溃的一种方法。当 DB2 检测到一个页面损坏时，它通过一个受控崩溃 (panic) 停止所有处理，因为它无法确定数据库完整性。这也是为了阻止进一步的数据损害或丢失。
当 DB2 遇到数据库损坏时，db2diag.log 中转储很多错误消息。当出现意外中断且启用了自动的首次出现数据捕获 (FODC) 时，会基于症状来收集数据。当满足以下条件之一时，DB2 9.5 上会自动收集 FODC 数据：
FOCD_Trap，当发生一个实例范围内的陷阱时。 FODC_Panic，当一个 DB2 引擎检测到不连贯且决定不继续时。 FODC_BadPage，当检测到坏页面时。 FODC_DBMarkedBad，当数据库因一个错误而被标记为 “坏” 时。
要搜集必要的信息，比如 OS 诊断（例如，AIX® 上的 errpt –a、snap 和 fileplace 输出）以及任何硬件诊断（状态保存和错误日志等），关键是要包含 OS 和硬件支持。重要的是要确保关键的文件系统有足够的磁盘空间，比如转储空间和日志目录，从而确保完全捕获关键事件。
您可以查看 db2diag.log，确认 panic 是因为损坏还是另外的原因引起的。下面您会看到如何识别 DB2 中的损坏并对其进行分类。以下是识别损坏的最常见的一些 db2diag.log 错误消息。