Document #: 2897544G19000
Body: [标题] 什么是崩溃恢复 (Crash Recovery)
内容提要:
在DB2的诊断日志中，有时候会看到 "Crash Recovery (崩溃恢复) is needed."。
例如：
“
2004-07-03-22.50.45.863184 Instance: xxxxxxxx 高速公路免费几天Node:000
PID:5004(db2agent ( XXXXXX ) 0) TID:1 Appid:*N0. xxxxxxxx .012CA3145037
base sys utilities sqledint Probe:30
Crash Recovery is needed.
”
那么，什么是崩溃恢复呢？
说明: 对数据库执行的事务（也称工作单元）可能被意外中断。若在作为工作单元一部分的所有更改完成和落实之前 发生故障，则该数据库就会处于不一致和不可用的状态。 崩溃恢复 是将数据库移动回一致并可用状态的进程。为此，回滚未完成的事务， 并完成当发生崩溃时仍在内存中的已落实事务（ 图 1 ）。当数据库处于一致和可用状态时，它处于一种称为"一致点"的状态。
图 1. 回滚工作单元（崩溃恢复）
事务处理失败 是由于出现了严重错误或导致数据库或数据库管理器异常结束的情况。部分完成的工作单元或发生故障时未清仓至磁盘中的 UOW 使数据库处于不一致状态。在事务处理故障之后必须恢复数据库。导致事务处理故障的情况有：
· 机器上的掉电故障，它会导致使用该机器的数据库管理器和数据库分区崩溃
· 导致 DB2(R) 崩溃的严重操作系统错误
· 硬件故障，例如内存毁坏、磁盘、CPU 或网络故障。 如果您希望不完整工作单元的回滚是由数据库管理器自动完成的，则应将 autorestart 数据库配置参数设置为 ON，以启用该自动重新启动参数。（这是缺省值。）如果不想要重新启动，则将 autorestart 数据库配置参数设置为 OFF。这样，将需要在数据库故障发生时发出 RESTART DATABASE 命令。如果数据库 I/O 在发生崩溃之前已处于暂挂状态，则必须指定 RESTART DATABASE 命令的 WRITE RESUME 选项才能使崩溃恢复继续进行。管理通知日志记录数据库重新启动操作开始的时间。 如果对允许正向恢复的数据库应用崩溃恢复（即，将 logretain 配置参数设置为 RECOVERY，或启用 userexit 配置参数），且在崩溃恢复期间因个别表空间而导致发生错误，则将会让该表空间脱机，直到修复后才能访问它。崩溃恢复继续进行。在崩溃恢复完成时，该数据库中的其它表空间将是可存取的，并且可以与该数据库建立连接。但是，如果脱机的表空间包含系统目录，则必须先修复它才允许进行所有连接。 一 降低媒体故障的影响 要降低媒体故障的可能性，并简化从此类型的故障的恢复： · 镜像或复制保存重要数据库的数据和日志的磁盘。
· 使用"冗余独立磁盘阵列"(RAID) 配置，例如 RAID 级别 5。
· 在分区数据库环境中，要设置一个严格的过程，来处理该目录节点上的数据和日志。因为此节点是维护数据库的关键：
o 确保它驻留在可靠的磁盘上
o 复制它
o 频繁地进行备份
o 不要在此节点上存放用户数据。 1 防止磁盘故障 若您担心由于磁盘故障而使数据或日志损坏的可能性，则请考虑使用 某种形式磁盘故障容错。通常，这是通过使用 磁盘阵列 （一组磁盘）来完成的。 磁盘阵列有时只是指 RAID数据库恢复（冗余独立磁盘阵列）。磁盘阵列也可以通过处于操作系统级或应用程序级的 软件来提供。硬件磁盘阵列和软件磁盘阵列的不同点在于处理输入／输出（I/O）请求的 CPU 处理的方式。对于硬件磁盘阵列，I/O 活动由磁盘控制器管理，对于软件磁盘阵列，由操作系统或应用程序完成。 2 硬件磁盘阵列 在硬件磁盘阵列中，一个磁盘控制器可使用和管理多个磁盘，且使用它自己的 CPU 来完成。管理构成此阵列的磁盘所需的所有逻辑都包含在磁盘控制器中；因此，此实现与操作系统无关。 618购物攻略 有几种类型的 RAID 体系结构，在功能和性能上有所不同，但只有 RAID 级别 1 和级别 5 是现在常用的。 RAID 级别 1 也称为磁盘镜像和双工技术。 磁盘镜像技术 使用单个磁盘控制器将数据（一个完整的文件）从一个磁盘复制到另一个磁盘。 磁盘双工技术 类行政助理工作内容 似于磁盘镜像技术，但磁盘是与另一个磁盘控制器连接的（与两个 SCSI 适配器相似）。因此可较好地保护数据：任何一个磁盘发生故障时，仍可从另一 个磁盘访问数据。使用磁盘双工技术时虽然磁盘控制器可能会发生故障，但不会影响可提供的数据保护。它的性能很好，但实现它需要的磁盘数是通常磁 盘数的两倍。 RAID 级别 5 涉及到跨所有磁盘，按扇区进行的数据和奇偶性校验分割。奇偶性校验与数据交错，而不是存储在专用的驱动器上。数据保护性能很好：如 果有任何磁盘发生故障，仍然可以使用其它磁盘上的信息以及已分割的奇偶性校验信息访问数据。读性能良好，但写性能较差。RAID 级别 5 配置需要最 少三个相同的磁盘。开销所需的磁盘空间量随阵列中磁盘的数量而变化。如果 RAID 级别 5 配置了 5 个磁盘，空间开销将是百分之二十。 使用 RAID（但不是 RAID 级别 0）磁盘阵列时，有故障的磁盘不会影响您访问阵列上的数据。当在该阵列中使用可热插入的或可热交换的磁盘时，可以在该阵列正在使用时将 替换磁盘与故障磁盘交换。使用 RAID 级别 5 时，如果有两个磁盘同时发生故障，所有数据都会丢失（但同时发生磁盘故障的可能性非常小）。 您可能会考虑对日志使用 RAID 级别 1 硬件磁盘阵列或软件磁盘阵列，因为这可以使故障点具有恢复能力并提供良好的写性能（这对日志来说很重要）。如果（由于不能将时间花在磁盘故障后的数据恢复上）可靠性很关键，而写性能不是，则可以考虑使用 RAID 级别 5 硬件磁盘阵列。另外，如果写性能很重要，而不太关心所需的附加磁盘空间量，则可以考虑对您的数据以及日志使用 RAID 级别 1 硬件磁盘阵列。 有关可用的 RAID 级别的详细信息，访问以下 Web 站点： www.acnc/04_01_00.html 3 软件磁盘阵列 软件磁盘阵列在许多方面与硬件磁盘阵列相同，但是磁盘流量是由操作系统或在服务器上运行的应用程序来管理的。软件阵列象其它程序一样，必须争用 CPU 和系统资源。对于 CPU 受约束的系统，它不是一个好的选项，同时要记住磁盘阵列的总体性能取决于服务器的 CPU 负载和能力。 典型的软件磁盘阵列提供磁盘镜像。虽然冗余磁盘是必需的，但是由于不需要高成本的磁盘控制器，所以软件磁盘阵列的实现相对便宜。 注意: 如果操作系统引导驱动器在磁盘阵列中，则当该驱动器发生故障时， 系统将无法启动。若在磁盘阵列运行之前该驱动器发生故障，则磁盘阵列就不允许 访问该驱动器。引导驱动器应与磁盘阵列分开。 二 降低事务故障的影响 要降低事务故障的影响，应尽量确保： · 不间断电源
· 有足够的磁盘空间用于存储数据库日志
· 在分区数据库环境中的数据库分区服务器之间有可靠的通信链路
· 分区数据库环境中的系统时钟的同步。 三 从分区数据库环境中的事务处理故障中恢复 如果事务处理失败发生在分区数据库环境中，通常需要对发生了故障的数据库分区服务器和参予了该事务的任何其它数据库分区服务器都进行数据库恢复： · 对发生了故障的数据库分区服务器的崩溃恢复发生在更正了先前的错误情况后。
· 对其它（仍活动的）数据库分区服务器的 数据库分区故障恢复 紧接在检测到故障后发生。 水浒人物评价在分区数据库环境中，提交应用程序的数据库分区服务器是协调程序节点， 而为该应用程序工作的第一个代理进程是协调代理进程。 协调代理进程负责将工作分发至其它数据库分区服务器上， 并跟踪哪些服务器参与了该事务。当应用程序对一个事务发出 COMMIT 语句时，该协调代理进程使用两阶段落实协议来落实该事务。在第一阶段期间，协调程序节点将 PREPARE 请求分发至参与该事务的所有其它的数据库分区服务器。然后，这些服务器用下列其中一项应答： READ-ONLY 在此服务器中未发生任何数据更改 YES 在此服务器中发生了数据更改 NO 由于错误，服务器未准备落实 若其中一个服务器应答 NO，则回滚该事务。否则，协调程序节点开始第二个阶段。 在第二阶段期间，协调程序节点写入一条 COMMIT 日志记录，然后将 COMMIT 请求分发至应答了 YES 的所有服务器。在所有其它数据库分区服务器都已落实后，它们会将 COMMIT 的确认发送至协调程序节点。当协调代理进程从所有参与的服务器接收到所有 COMMIT 确认时，该事务完成。在此时间点，协调代理进程会写入一条 FORGET 日志记录。 1 活动数据库分区服务器上的事务处理故障恢复
若任何数据库分区服务器检测到另一个服务器当机，则与该发生故障的数据库分区服务器相关的所有工作都会停止：
· 若仍为活动的数据库分区服务器是一个应用程序的协调程序节点，且该应用程序是在发生故障的数据库分区服务器上运行（尚未准备 COMMIT），则会中断该协调代理进程，以便执行故障恢复。如果该协调代理进程处于 COMMIT 处理的第二个阶段，会将 SQL0279N 返回给应用程序，应用程序随之会丢失它的数据库连接。否则，协调代理进程将一个 ROLLBACK 请求分发至所有其它参与该事务的服务器，并将 SQL1229N 返回至该应用程序。
· 若发生故障的数据库分区服务器是该应用程序的协调程序节点，仍在活动服务器上为该应用程序工作的代理进程会被中断，以便执行故障恢复。除非当前事务已准备就绪且正在等待事务结果，否则在每个服务器上以本地方式回滚当前事务。在这种情况下， 该事务在活动的数据库分区服务器上处于未确定状态，而协调程序节点未意识到这个情况（因为它不可用）。
· 若该应用程序与发生故障的数据库分区服务器连接（在它发生故障之前），但是本地数据库分区服务器和发生故障的数据库分区服务器都不是协调程序节点，则会中断为此应用程序工作的代理进程。协调程序节点将向其它数据库分区服务器发送 ROLLBACK 或断开连接消息。若协调程序节点返回 SQL0279，则事务将只在仍然活动的数据库分区服务器上是未确定的。
试图向该发生故障的服务器发送请求的任何进程（如，代理进程或死锁检测器）都会得到通知：它不能发送该请求。
2 有故障的数据库分区服务器上的事务处理失败恢复
如果事务失败导致数据库管理器异常结束，则可以发出带有 RESTART 选项的 db2start 缘份五月命令以在重新启动数据库分区后立即重新启动数据库管理器。如果不能重新启动数据库分区，则可以发出 db2start 以在另一分区上重新启动数据库管理器。
如果数据库管理器异常结束，则服务器上的数据库分区可能会处于不一致状态。要使它们可用，可以在数据库分区服务器上触发崩溃恢复：
· 通过 RESTART DATABASE 命令显式触发
· 在 autorestart 数据库配置参数已设置为 ON 后，通过 CONNECT 请求隐式触发
崩溃恢复将重新应用活动日志文件中的日志记录，以确保所有已完成的事务的结果都在数据库中。重新应用了这些更改后， 除 不确定事务外的所有未落实的事务都将本地回滚。分区数据库环境中有两种类型的不确定事务：
· 在不是协调程序节点的数据库分区服务器上，已就绪但未落实的事务就是未确定的。
· 在协调程序节点上，已落实但还未被记录为完成（即，还未写入 FORGET 记录）的事务是未确定的。当协调代理进程未从为该应用程序工作的所有服务器接收到全部 COMMIT 确认时，会发生此情况。
崩溃恢复试图通过下列其中一项操作解决所有未确定的事务。要执行的操作取决于数据库分区服务器是否为应用程序的协调程序节点：
· 若重新启动的服务器不是该应用程序的协调程序节点，它会将一个查询消息发送至该协调代理进程，以发现该事务的结果。
· 若重新启动的服务器 是 该应用程序的协调程序节点，它会将一个消息发送至协调代理进程仍在等待它们的 COMMIT 确认的所有其它代理进程（从属代理进程）。
有可能崩溃恢复不能解决所有不确定事务（例如，某些数据库分区服务器可能会不可用）。在这种情况中，会返回 SQL 警告消息 SQL1061W。由于不确定事务占用了资源（例如锁和活动日志空间）， 有可能会导致不能对数据库进行任何更改，因为不确定事务占用了活动日志空间。因此，应确定在崩溃恢复之后是否还有不确定事务，并尽快恢复解决这些不确定事务所需的所有数据库分区服务器。 若解决不确定事务所需的一个或多个服务器不能及时恢复，且需要访问其它服务器上的数据库分区，可以通过作出试探性决策来手工解决这些不确定事务。可以使用 LIST INDOUBT TRANSACTIONS 命令来查询、落实和回滚服务器上的不确定事务。
注意:
LIST INDOUBT TRANSACTIONS 命令还可用于分布式事务环境中。要区分这两种类型的不确定事务，LIST INDOUBT TRANSACTIONS 命令所返回的输出中的 originator 字段显示下列其中一项： · DB2 通用数据库扩充企业版，它指示该事务始发于分区数据库环境中。
· XA，它指示该事物始发于分布式环境中。 3 标识有故障的数据库分区服务器
当一个数据库分区服务器发生故障时，应用程序通常会接收到下列其中一个 SQLCODE。检测哪个数据库管理器发生故障的方法取决于接收到的 SQLCODE：
SQL0279N
当在 COMMIT 处理期间终止的事务中涉及了数据库分区服务器时，会接收到此 SQLCODE。
SQL1224N
当发生故障的数据库分区服务器是该事务的协调程序节点时，会接收到此 SQLCODE。
SQL1229N
当发生故障的数据库分区服务器不是该事务的协调程序节点时，会接收到此 SQLCODE。
确定哪个发生了故障的数据库分区服务器是一个两阶段进程。与 SQLCODE SQL1229N 相关的 SQLCA 在 sqlerrd 字段的第六个数组位置包含检测到错误的服务器的节点号。（为服务器写入的节点号与 db2nodes.cfg 文件中的节点号对应。）在检测到错误的数据库分区服务器上，会将指示故障服务器的节点号的消息写至管理通知日志。 注意:
若正在一个处理器上使用多个逻辑节点，则一个逻辑节点发生故障可能导致同一个处理器上的其它逻辑节点发生故障。
| 
发表评论