Dm8故障恢复

数据库系统在运行过程中可能会发生一些故障。造成故障的原因多种多样，包括磁盘崩 溃、电源故障、软件错误，甚至人为破坏。这些情况一旦发生，就可能会丢失数据，数据库 系统将无法正常运行。因此，故障恢复是数据库系统必不可少的组成部分，即数据库系统必 须保证即使发生故障，也可以保障数据的完整性和一致性。 支持故障恢复的技术主要是日志，日志以一种安全的方式记录数据库系统变更的历史信 息，一旦系统出现故障，数据库系统可以根据日志将系统恢复至故障发生前的某个时刻。数 据库系统的日志分为两种类型：一是 REDO 日志，在数据被修改后记录它的新值；另一种是 UNDO 日志，在数据被修改前记录它的旧值。 另外，当服务器处于归档模式时，如果数据库发生故障，通过备份文件和归档日志可以 恢复到指定时间点。

2 REDO 日志

在恢复操作中最重要的结构是联机 REDO 日志。REDO 日志存放在日志表空间文件中，

这些文件存储数据库所做的所有物理更改信息。达梦数据库每一个实例都有一个相关联的联

机重做日志，通过重做日志可以保证数据库的完整性和一致性。

DM SERVER 的 REDO 日志用于存储被修改数据的新值，包括事务对数据文件和回滚段

的修改。REDO 日志每次被修改以后，都会自动生成一个新的日志序列值 LSN（Log Sequence

Number）。LSN 取值范围 0~正无穷大，新建的库 LSN 为 0，以后日志每被写入一次，LSN

值增加 1。

REDO 日志里包含有一种特殊的记录，叫 PWR（Page Written Record）日志。PWR

包括（ts_id, fil_id, page_no, page_lsn）信息。每个数据页刷盘时，都会生成一

条对应的 PWR 日志。PWR 日志的 lsn 与上一个日志的 lsn 相同。在以下情况下可以利用 PWR

日志：

1. DSC 故障恢复时：利用 PWR 日志减少加载磁盘数据页的次数；

2. 故障恢复时：利用 PWR 日志提升 redo 速度；

3. 增量备份时：利用 PWR 日志提升备份速度。

在第 2 章中提到过，系统采用了单独的日志文件来存储 REDO 日志，即联机日志文件。

DM 至少有两个日志文件，日志文件是循环利用的。日志文件由日志表空间管理。DM 支持增

加日志文件和扩展日志文件大小。

例１增加大小为 80M 的日志文件 dameng_003.log

 ALTER DATABASE ADD LOGFILE 'dameng_003.log' size 80;

例 2 将日志文件 dameng_003.log 大小更改为 100M

ALTER DATABASE RESIZE LOGFILE 'dameng_003.log' to 100;

在 MOUNT 状态下，支持对日志文件的重命名操作。

例 3 将日志文件 dameng_003.log 重命名为 dameng_004.log

ALTER DATABASE RENAME LOGFILE 'dameng_003.log' to 'dameng_004.log'

3 重做日志归档

DM 服务器可以运行在两种模式下，即归档模式和非归档模式，这两种模式可以由用户进

行设置，系统在归档模式下运行时，会产生归档日志文件，此时系统管理员应该事先预留出

足够的磁盘空间以便存储归档日志文件。通过 dm.ini 和 dmarch.ini 可以配置归档。

归档日志包括以下五种类型：

24.3.1 本地归档

写入 REDO 日志到本地归档文件，在 REDO 日志写入日志文件后触发，由归档线程完成

本地归档动作，最多可以设置 8 个本地归档。若磁盘空间不足，所有本地归档一旦失效，系

统会被强制挂起，直到磁盘空间释放，本地归档成功后，再继续执行。

24.3.2 实时归档

在写入 REDO 日志到日志文件之前，通过 MAL 系统发送 REDO 日志到远程服务器，远程

服务器收到 REDO 日志后，返回确认消息。收到确认消息后，执行后续操作，发送 REDO 日

志失败，或从备库返回的数据库模式不是 STANDBY，将数据库切换为 SUSPEND 状态，阻塞

所有 REDO 日志的写入操作。只能配置 1 个实时归档。

24.3.3 即时归档

即时归档在主库将 Redo 日志写入联机 Redo 日志文件后，再通过 MAL 系统将 Redo 日

志发送到备库。即时归档是读写分离集群的实现基础，与实时归档的主要区别是发送 Redo

日志的时机不同。一个主库可以配置 1~8 个即时备库。

24.3.4 异步归档

在设定的时间点或者每隔设定时间，启动归档 REDO 日志发送。设置定时归档，必须确

保至少有一个本地归档。系统调度线程根据设定，触发归档 REDO 日志发送事件。通过 MAL

系统，获取远程服务器的当前 LSN，生成发送归档 REDO 日志任务，加入任务队列。归档任

务线程获取任务，通过 MAL 系统，发送到远程服务器。最多可以设置 8 个异步归档。

24.3.5 远程归档

远程归档就是将写入本地归档的 REDO 日志信息，发送到远程节点，并写入远程节点的

指定归档目录中。远程归档与本地归档的主要区别是 REDO 日志写入的位置不同，本地归档

将 REDO 日志写入数据库实例所在节点的磁盘，而远程归档则将 REDO 日志写入到其他数据

库实例所在节点的指定归档目录。远程归档日志文件的命名规范和本地归档日志文件保持一

致，都是以归档名+归档文件的创建时间进行组合命名。最多可以配置 8 个远程归档。

4 检查点

创建数据库时，联机日志文件通常被扩展至一定长度，其内容则被初始化为空，当系统

运行时，该文件逐渐被产生的日志所填充。为了达到循环利用日志系统空间的目的，必须在

所有日志文件空间将被占满时，系统能够自动清空一部分日志，以便重用日志文件的空间，

为了保证被清空的日志所―保护‖的数据在磁盘上是安全的，需要引入一个关键的数据库概念

——检查点。当系统产生检查点时，将系统缓冲区中被修改过的数据页写入磁盘，以保证当前

日志所―保护‖的数据页都已安全写入磁盘，这样日志文件即可被安全重用。

当服务器启动和关闭时，系统都会产生检查点。服务器运行过程中，系统会自动判断是

否需要执行检查点；当空闲日志空间不足时，系统自动产生一个检查点；系统调度线程也会

定时产生检查点；还可以通过调用系统函数 CHECKPOINT 主动生成检查点。

系统调度线程根据 dm.ini 的参数配置，产生检查点，下面给出具体的例子和说明。

CKPT_INTERVAL = 1800 #每间隔 1800 秒，产生检查点间隔

CKPT_FLUSH_RATE = 5 #检查点的刷盘比例为 5%，将系统中所有脏页的 5%写入磁盘

CKPT_FLUSH_PAGES = 1000 #一个检查点最少写入 1000 个脏页

检查点系统函数 CHECKPOINT（FLUSH_RATE），其参数 FLUSH_RATE 为 INTEGER 类

型或 DOUBLE 类型，指示刷盘比例，替代 dm.ini 中的 CKPT_FLUSH_RATE，同时

CKPT_FLUSH_PAGES 参数同时生效。例如，执行 SELECT CHECKPOINT(10);会将系统中

10%脏页写入磁盘。

5 回滚段与回滚记录

DM SERVER 采用回滚段机制来处理 UNDO 日志。回滚段由一定数量的回滚页组成，回

滚页存放的是一批回滚记录。回滚记录存放被修改数据的旧值，并有专属的格式，与物理记

录格式不同。回滚段的管理同一般数据文件一样，其回滚数据页的分配、淘汰和释放也交由

数据缓冲区完成。回滚文件属于回滚表空间。回滚段的数据并不会永久保留, 事务结束后，

由系统的 PURGE 模块释放回滚页。

REDO 日志记录了所有对数据库数据进行修改的数据，当然也包括回滚段的修改数据。

因此，REDO 日志同样也会保护回滚数据。当使用重做日志恢复数据库时，系统将重做回滚

段中修改了的数据，并将这些修改写回到回滚段中，从而形成回滚记录。回滚记录与重做记

录类似，只不过回滚记录记录被修改数据的旧值，以达到数据回滚到原来状态的目的。

另外，回滚表空间不允许修改和删除操作。

6 系统故障恢复

系统故障也就是我们通常所说的系统崩溃。系统崩溃的原因比较复杂，有硬件故障，或者是数据库软件或操作系统的漏洞等。它导致整个系统停止运行，内存中的数据全部丢失，但磁盘上存储的数据仍然有效。

当系统故障发生时，系统管理员可以通过查看系统日志文件以了解系统故障发生的原因或故障发生之前系统的运行状况。多数情况下，系统在故障发生之前会自动记录产生故障的原因，但也不全是这样，如系统掉电时，发生故障的原因可能来不及记录。总之，在处理系统故障之前，系统管理员需要完全了解系统故障发生的原因，并采取相应的措施，如更换硬件，升级操作系统或数据库软件等，必要时还可以联系达梦公司的技术支持工程师，以获得

必要的支持。系统故障恢复的最后一步则是重新启动 DM 服务器。此时，系统将从最近一个检查点处开始扫描联机日志，并重做日志记录的内容，这样系统即恢复到了故障发生前的某个很近的 时刻，然后将系统中仍然活动的事务再依次利用回滚段进行回滚。由此可以看出，系统故障 恢复可以保证事务的原子性和持久性，即系统故障发生时，仍然活动的事务可以被安全回滚， 而已经提交的事务则保证其所修改数据的持久性。

7 介质故障恢复

介质故障指的是由于各种原因导致数据库系统存储在磁盘上的数据被损坏，如磁盘损坏 等。介质故障是数据库系统最为严重的故障，此时系统已经无法重新启动，磁盘上的数据也 无法复原。 出现介质故障后，系统管理员首先需要分析介质故障发生的原因，并采取措施，如磁盘 损坏则更换磁盘等。由于系统的数据已经全部或部分丢失，此时只能依赖以前建立的备份和 系统产生的归档日志文件进行恢复。由于涉及到备份，具体的介质恢复策略将在《DM8 备份 与还原.docx》中详细介绍。 需要说明的是，为了避免系统在出现故障时丢失数据，应关闭磁盘缓存（若存在的话）， 具体事项请咨询操作系统管理员。

更多资讯 请访问 https://eco.dameng.com/