备份还原原理

备份还原原理

前言

根据官网文档进行整理

一、（归档日志）备份还原原理

备份与恢复过程都依赖归档日志，归档日志是保证数据一致性和完整性的重要保障。配有归档日志的数据库系统在出现故障时丢失数据的可能性更小，这是因为一旦出现介质故障如磁盘损坏时，利用归档日志，系统可被恢复至故障发生的前一刻，也可以还原到指定的时间点。

1、归档种类

1.1 本地归档

REDO 日志本地归档（LOCAL），就是将 REDO 日志写入到本地归档日志文件的过程。配置本地归档情况下，由两个线程分别执行任务。

• REDO 日志刷盘线程将 REDO 日志写入联机 REDO 日志文件。
• 上述日志写完后，对应的 RLOG_PKG 由专门的归档线程负责写入本地归档日志文件中。

与联机 REDO 日志文件可以被覆盖重用不同，本地归档日志文件不能被覆盖，写入其中的 REDO 日志信息会一直保留，直到用户主动删除；如果配置了归档日志空间上限，系统会自动删除最早生成的归档 REDO 日志文件，腾出空间。

DM 提供了按指定的时间或指定的 LSN 删除归档日志的系统函数（SF_ARCHIVELOG_DELETE_BEFORE_TIME 和 SF_ARCHIVELOG_DELETE_BEFORE_LSN，但需谨慎使用。避免归档日志缺失，导致数据无法恢复。

1.2 远程归档

远程归档（REMOTE ARCHIVE）专门用于 DMDSC 环境中，是将当前节点的远程归档目录配置为另一节点的本地归档目录，以此来共享它的本地归档日志文件。远程归档必须双向配置，即两个节点将自己的远程归档相互配置在对方机器上。

DMDSC 集群中，各个节点配置一个远程归档为其他节点的本地归档，通过这种共享本地归档的方式，可以在任意一个节点上，访问到 DMDSC 集群所有节点产生的、完整的归档日志文件。若节点出现故障，故障恢复后，因为该节点配置的远程归档为其他节点的本地归档，该节点的远程归档内容仍然是完整的，因此无需进行手动修复。

---

2、归档日志修复

实例状态	归档文件情况
实例正常退出	所有 REDO 日志写入本地归档日志文件中
实例异常关闭	可能存在部分 REDO 日志未写入本地归档日志文件中，归档日志文件中的内容比实际可恢复的数据少一部分。这种情况下，将无法利用归档日志文件将数据恢复到最新状态，需要从联机日志文件拷贝该部分日志以补齐归档日志。

如何修复本地归档日志？

本地归档修复会扫描联机日志文件，将那些已经写入联机日志文件、但还没有写入到归档日志文件的 REDO 日志，重新写入到归档日志文件。

2.1 归档日志修复流程

1. 收集本地归档日志文件；
2. 扫描归档文件，获取最后一个有效 RLOG_PKG 偏移；
3. 首先，根据偏移来截取最后一个本地归档日志文件中有效内容，删除掉 RLOG_PKG 偏移之后的多余内容，保留 RLOG_PKG 偏移之前的内容，并调整日志文件头信息。然后，再创建一个新的空的归档日志文件；
4. 扫描联机日志文件，拷贝缺失的 REDO 日志并写入新创建的归档日志文件。

---

3、归档日志文件的备份与还原

除了通常意义上的数据备份、还原之外，DM 还支持对本地归档日志文件进行备份和还原。

为什么在使用非一致性备份集进行还原后，必须使用归档日志进行恢复之后，数据库才能启动？

因为归档日志文件中保存了所有数据库操作产生的 REDO 日志，而使用非一致性备份集还原后，数据是不完整的。利用归档日志文件，我们可以补录重演缺失的数据。

所以只要在一个基准备份集的基础上，加上一个完整的归档日志，我们就可以将数据库恢复到任意时间点的状态。

3.1 归档日志文件备份

归档日志备份专门用来备份本地归档日志文件，将符合条件的本地归档日志文件拷贝到备份集中保存起来。

归档日志备份**仅备份指定数据库生成的本地归档日志文件**，要求归档日志文件的 DB_MAGIC 与数据库的 DB_MAGIC 保持一致。如果本地归档目录中包含多个不同数据库的归档日志文件，也只会备份一个特定数据库的归档日志。

我的理解：

这个就是说，先确认当前实例的DB_MAGIC是多少，然后归档目录下面（多个实例归档目录都配置在这路径下面），如果有别的实例产生的归档文件（DB_MAGIC肯定与当前实例不同），由于别的实例产生的归档文件中的DB_MAGIC与当前实例的DB_MAGIC不一致，这部分归档日志是不备份的，只会备份当前实例产生的归档文件。

由于经过还原后数据库的 DB_MAGIC 会产生变化，因此即便 PERMANENT_MAGIC 相同，DB_MAGIC 不同的数据库产生的归档日志也不会备份。

我的理解：

这个是说，A机器的数据库备份以后，传输到B机器进行还原。进行还原操作时候，会执行update DB_MAGIC操作，更新了B机器的DB_MAGIC，导致A和B机器数据库实例的DB_MAGIC会不一致。但是因为是使用A的备份集还原的，所以两台机器的永久魔数 PERMANENT_MAGIC是会一致的。

根据上一段话的结论，当前实例只备份当前实例产生的归档文件。所以，B机器上，其实只会备份B实例产生的归档日志文件。

综上所述：

数据库只会备份当前运行实例产生的归档日志文件，即使本机上配置了多个实例，归档路径都一样。全备份归档日志文件，其实本质也只是不同实例各管各的，各自备份自己产生的归档日志文件，这样完成了一次归档目录的全备份。是由多个实例共同作用的结果，而不是靠单一实例实现的。

后面还涉及到利用归档文件进行数据恢复，利用指定的归档日志进行恢复。它的流程是，系统扫描指定的归档日志目录，收集与恢复数据库 PERMANENT_MAGIC 值相等的归档日志文件。

3.2 归档日志文件还原

归档日志还原就是将备份集中的归档日志文件重新拷贝到指定归档目录中。使用归档日志备份集，既可以将归档日志文件还原到指定数据（还原时指定目标库的 dm.ini）的归档目录，也可以还原到用户指定的任意归档目录中。

3.2.1 归档日志还原过程

1. 根据过滤条件，从归档日志备份集收集需要还原的归档日志文件。
2. 在指定的归档目录创建归档文件。如果目标归档文件已经存在，默认采用认为该归档完好，生成一条日志记录，不再还原策略。也可以使用 OVERWRITE 指定策略。OVERWRITE 参数为：1 表示认为归档文件完好，不再还原该归档文件，添加一条日志记录；2 表示存在同名归档立即报错返回，终止还原；3 表示强制删除归档，重新还原同名归档。
3. 从备份集拷贝 REDO 日志，写入目标归档日志文件。

如果备份时指定了加密或压缩，还原过程中会先经过解密和解压缩处理，再写回到目标归档日志文件中。

---

二、（数据）备份还原原理

任何一个对 DM 数据库的操作，归根结底都是对某个数据文件页的读写操作。物理备份就是把这些数据文件中的有效数据页备份起来，在出现故障时，用于恢复数据。一份完整的物理备份包括数据备份和 REDO 日志备份两部分。数据备份是拷贝数据页内容，REDO 日志备份则是拷贝备份过程中产生的 REDO 日志。

1、数据备份

数据备份过程中，根据 DM 数据文件系统的描述信息，准确判断每一个数据页是否被分配、使用，将未使用的数据页剔除，仅保留有效数据页进行备份，这个过程我们称为智能抽取。与直接文件拷贝方式相比，DM 物理备份丢弃了那些没有使用的数据页，因此可以节省对存储空间的要求，并有效减少 IO 数量，提升备份、还原的效率。

对处于 RES_OFFLINE（还原） 和 CORRUPT（损坏） 状态的表空间，则**只记录表空间相关信息和状态，不会真正拷贝数据页**。数据备份过程中，会对数据进行校验，如果校验失败则会将相关信息写入到日志文件 dm_BAKRES_xxx.log 中，但不会终止当前备份操作。

1.1 库备份

粒度	说明	数据来源	联机备份	脱机备份	全量备份	增量备份
库备份	库备份会拷贝数据库中所有数据文件的有效数据页。	扫描数据文件	√	√	√	√

1.1.1 完全备份

执行完全备份，备份程序会扫描数据文件，拷贝所有被分配、使用的数据页，写入到备份片文件中（如图第二根横轴所示）。库备份会扫描整个数据库的所有数据文件。

1.1.2 增量备份

执行增量备份，备份程序会扫描数据文件，拷贝所有基备份结束以后被修改的数据页，写入到备份片文件中。

为了简化增量备份的还原过程，避免还原过程中重做基备份集对应的归档日志，DM 要求执行增量备份时，<=基备份 END_LSN 的所有数据页已经写入磁盘。由于基备份过程中，基备份 BEGIN_LSN 与 END_LSN 之间的数据页可能被修改，导致数据库中的数据与备份文件中的数据不一致，所以增量备份会拷贝 LSN > 基备份 BEGIN_LSN 的数据页写入备份片文件中（如图第三根横轴所示），LSN <= 基备份 BEGIN_LSN 的数据页不需要写入到备份片文件中。

同样库增量备份会扫描整个数据库的所有数据文件。

1.2 表空间备份

表空间备份只拷贝指定表空间的数据页，因此，相对于数据库备份而言，表空间备份的速度会更快，生成的备份集会更小。对一些包含关键数据的用户表空间，我们可以使用表空间备份功能，进一步保障数据安全。

表空间备份支持完全备份和增量备份，但只能在联机状态下执行。不支持 TEMP 表空间备份还原。

粒度	说明	数据来源	联机备份	脱机备份	全量备份	增量备份
表空间备份	针对特定表空间的备份，只能在联机状态下执行。	扫描数据文件	√	X	√	√

1.3 表备份

表备份主要包括数据备份和元信息备份两部分。与库备份和表空间备份不同，表备份不是直接扫描数据文件，而是从 BUFFER 中加载数据页，拷贝到备份片文件中。表备份的元信息则包括建表语句、重建约束语句、重建索引语句，以及其他相关属性信息。表备份不需要配置归档就可以执行，并且不支持增量表备份。

粒度	说明	数据来源	联机备份	脱机备份	全量备份	增量备份
表备份	拷贝指定表的所有数据页到备份集中，并会记录各个数 据页之间的逻辑关系用以恢复。 1️⃣表备份只能在联机状态下执行 2️⃣一次表备份操作只能备份一张用户表 3️⃣不支持增量表备份。	BUFFER加载	√	X	√	X

1.4 REDO日志备份

日志备份就是将**联机备份过程中产生的 REDO 日志拷贝到备份片文件中**，用来在数据库还原结束后，将数据库恢复到一致性状态。在执行备份过程中，用户可能修改数据库中的数据，并产生对应的 REDO 日志。增量备份和完全备份的日志备份流程完全相同。

只有库级和表空间级备份支持联机日志备份。未指定 WITHOUT LOG 参数执行的库备份或表空间备份则包含了联机日志备份。

在备份开始时，记录一个 BEGIN_LSN，在备份结束后记录一个 END_LSN，那么 [BEGIN_LSN,END_LSN] 之间的 REDO 日志，就对应备份过程中用户对数据的修改。其中 BEGIN_LSN=CKPT_LSN，作为日志备份的起点，END_LSN = 数据备份结束时的 FILE_LSN，作为日志备份的终点。

联机库备份默认开启日志备份，将备份过程中产生的 REDO 日志单独写入备份片作为备份集的一部分。也可以通过 WITHOUT LOG 子句取消这部分 REDO 日志的拷贝，这种情况下生成的备份本身是不完整的，数据库还原后，还要依赖备份库的本地归档日志来进行恢复操作后，才能将数据恢复到一致性状态；否则，还原后的数据库将无法正常启动。

还原后目标库中 REDO 日志的数量，由目标库本身 REDO 日志的数量决定。跟源库中 REDO 日志的数量无关。例如，源库中有 3 个 REDO 日志，目标库中只有 2 个，将源库还原到目标库后，目标库仍然只有 2 个 REDO 日志。

---

1.5 备份附加选项

1.5.1 压缩与加密

DM 支持对备份数据进行压缩和加密处理，用户在执行备份时，可以指定不同的压缩级别，以获得不同的数据压缩比。默认情况下，备份是不进行压缩和加密处理的。

DM 共支持 9 个级别（1~9 级）的压缩处理，级别越高压缩比越高，但相应的压缩速度越慢、CPU 开销越大。

备份加密包括加密密码、加密类型和加密算法三个要素。加密密码通过使用 IDENTIFIED BY<加密密码>来指定，使用备份集的时候必须输入对应密码。加密类型分为不加密、简单加密和完全加密。简单加密仅仅对部分数据进行加密，加密速度快；完全加密对所有数据执行加密，安全系数高。加密算法可参考《DM8 安全管理》加密章节。

加密类型和算法，用户均可手动指定。如果用户指定了加密密码，但没有指定加密类型和算法，则使用默认加密算法进行简单加密。用户也可以指定加密密码，但将加密类型指定为不加密。

如果同时指定加密和压缩，则备份过程中，会先进行压缩处理，再进行加密处理，备份的所有数据页和 REDO 日志都会进行压缩、加密处理。

注意

• 如果基备份集没有指定加密类型，那么增量备份也不能指定加密类型；
• 如果基备份集指定了加密算法，那么增量备份的加密类型、加密算法和密码必须与基备份保持一致。

1.5.2 并行备份

库备份、表空间备份以及归档日志备份可以进行并行处理，用户通过关键字 PARALLEL 指定是否执行并行备份，以及并行备份的并行数。如果指定了 PARALLEL 关键字，但不指定并行数，那么默认的并行数为 4，但实际的备份并行度由 DMAP 最终创建成功的并行子任务数决定。增量备份是否并行以及并行数与其基备份集无关。

目前的数据库并行备份还原都是以文件为单位，适用于待备份文件大小比较均匀的情况。若文件大小差别比较大，特别存在个别文件巨大时，并行备份还原基本没有优势。因此在进行数据库备份时，需要指定 READ SIZE <拆分块大小>，将巨大的数据文件先进行拆分之后再进行备份。

执行并行备份会生成一个主备份集和若干个子备份集，子备份集不能单独还原，也不能作为其他备份集的基备份。备份过程中产生的 REDO 日志保存在主备份集中，子备份集仅包含数据文件相关内容。

以下为一个并行数为 3 的脱机并行备份集（左）和非并行脱机备份集（右）比较截图：

---

2、数据还原

还原是备份的逆过程，具体包括数据还原和数据恢复两步。

• 数据还原

  主要目的是将目标数据库还原到备份结束时刻的状态，数据还原的主要动作是将数据页从备份集中拷贝回数据库文件相应位置。

• 数据恢复

  重做 REDO 日志将数据库恢复到一致性状态。

还原恢复时，若性能较差，则可以通过适当增大 dm.ini 文件中 BUFFER 的参数值或根据当前系统主机核数适当调整 REDOS_PARALLEL_NUM 的参数值来提升还原恢复性能。其中，BUFFER 的参数值建议为可用物理内存的 60%～80%。

2.1 数据还原

2.1.1 库还原

DM 既可以将一个已存在的数据库作为还原目标库，也可以指定一个路径作为还原目标库的目录。

库还原的主要步骤包括：清理目标库环境；重建数据库文件；拷贝数据页；重建联机日志文件；修改配置参数等。

2.1.1.1 清理目标库环境

如果指定已存在的数据库作为还原目标库，还原操作首先解析 dm.ini 配置文件，获取 dm.ctl 控制文件路径，删除控制文件中的数据文件，然后根据 OVERWRITE 选项，如果指定 OVERWRITE 选项，若待还原文件存在，则删除；如果未指定 OVERWRITE 选项，若待还原文件存在，则报错，但保留目标库的日志文件、控制文件等。需要注意的是，HUGE 数据文件未记录在 dm.ctl 控制文件中。

如果指定还原到一个目录，则根据 OVERWRITE 参数选择策略，检查目标目录内的 dm.ini 文件、dm.ctl 文件、默认的日志文件 DBNAME01.log 和 DBNAME02.log（其中 DBNAME 为数据库名称）、待还原的数据文件等。如果用户指定 OVERWRITE 参数，并且存在相关文件情况下，还原过程中会自动删除这些已经存在的文件；如果没有指定 OVERWRITE 参数，并且存在相关文件，则会报错。

2.1.1.2 重建数据库文件

如果将一个已存在数据库作为还原目标，则需要将目标数据库的 dm.ini 路径作为还原参数。还原过程中，会重新创建数据文件，并将相关信息写入 dm.ctl 控制文件中。

如果将数据库还原到指定目录，则会在这个目录创建一个 dm.ini 配置文件，设置 CTL_PATH、SYSTEM_PATH 配置项指向这个目录，并在这个目录下创建 dm.ctl 控制文件。DMDSC 不支持指定目录还原数据库。

• 数据文件重建策略
  • 目标库和备份集中的 SYSTEM_PATH 路径相同，则按照备份集中记录的原始路径创建文件；
  • 目标库和备份集中的 SYSTEM_PATH 路径不相同，默认在目标库的 SYSTEM_PATH 目录下创建文件；
  • 目标库设置 REDOS_FILE_PATH_POLICY 参数为 1 时，用户创建的表空间（表空间 id 大于等于 5）按照数据文件在源库中的路径结构，在目标库 SYSTEM_PATH 下创建相同路径结构的文件；
  • 使用 mapped file 指定源文件与目标文件的映射关系，定制数据库文件的物理分布情况，可以很好的满足用户关于数据文件分布的需求。

2.1.1.3 重建联机日志文件

指定目录还原，系统目录使用指定还原目录，所有库配置文件均认为在指定还原目录下。联机日志文件命名规则，单机环境为 db_name+ 文件编号.log，其中 db_name 取自备份集备份库的名称，文件编号从 1 开始，如 DAMENG01.log、DAMENG02.log。联机日志文件至少 2 个。

2.1.1.4 拷贝数据页

拷贝数据页是从备份集中读取数据页，并将数据页写入数据文件指定位置的过程。由于备份过程中，只将有效的数据页写入备份集中，因此，还原过程也只涉及这些被分配使用的数据页。

2.1.1.5 重置目标库

具体包括：

1. 更新日志信息，设置当前 CKPT_LSN 为备份集中 BEGIN_LSN，并设置日志文件状态为 INACTIVE；
2. 更新 DB_MAGIC，还原后，库中 PERMANENT_MAGIC 仍与备份集中相同；
3. 设置还原标志，标识当前库为指定库要还原的库，不允许使用；
4. 更新目标库的控制文件 dm.ctl，把当前库中的数据文件信息都记录到控制文件中，使用备份集中的服务器秘钥文件，重新生成新的秘钥文件。

2.1.1.6 修改配置参数

还原到指定库时，默认会保留目标库的配置参数不变，也可以在还原时指定 REUSE DMINI 子句，使用备份集中的配置参数替换目标库 dm.ini 中的配置参数。还原到指定目录时，会重新建立一个 dm.ini 配置文件，并用备份集中的参数值来设置这些配置项。需要注意的是，一般与路径相关的配置参数，比如 SYSTEM_PATH 等并不会被替换，而是保留目标库 dm.ini 的原始值不变。

服务器秘钥文件(dm_service.prikey 或者 dm_external.config)仅在备份集中备份库非 usbkey 加密的情况下重建，并使用备份集中备份的秘钥内容进行还原。

注意事项：

1）指定的 dm.ini 必须存在且各项配置信息有效，其中 CTL_PATH 必须配置且路径必须有效；

2）若指定目录还原，则指定目录作为数据库系统目录处理；

3）由于还原是要确保数据库数据的完整性，因此，对于增量备份的还原，需要搜集完整的备份集链表，然后从前到后，逐个还原备份集中数据。鉴于增量备份 BEGIN_LSN 确定规则，增量备份的还原过程中，不需要重做任何归档日志。

---

2.1.2 表空间还原

表空间还原是根据**库备份集或表空间备份集**中记录的数据信息，重建目标表空间数据文件并拷贝数据页的过程，该过程不涉及日志操作。

表空间还原只可以在脱机状态下执行。脱机时通过 DMRMAN 工具执行，对表空间状态没有限制。

表空间还原后如果表空间状态为 RES_OFFLINE（还原状态），表明目标表空间已进行还原操作，但数据不完整。

在部分数据文件损坏，或者部分物理磁盘损坏情况下，我们可以指定还原数据文件，跳过那些不正常的数据文件，以提升还原速度。

表空间还原也支持使用 mapped file 进行数据文件映射，如果不指定 mapped file，则默认当前系统目录与备份集中一致。实际创建过程中，若发现已经存在或者创建失败后，处理方式与数据库还原中数据重建策略处理一致。

说明

表空间状态包括：ONLINE（联机状态）、OFFLINE（脱机状态）、RES_OFFLINE（还原状态）、CORRUPT（损坏状态）。V$TABLESPACE表的 STATUS$列值表示表空间状态，0/1/2/3分别代表ONLINE状态/OFFLINE状态/RES_OFFLINE状态/CORRUPT状态。
表空间发生故障，比如还原失败（处于RES_OFFLINE状态）、表空间文件损坏或缺失（处于OFFLINE状态），这两种故障情况下如果想直接删除表空间，不考虑还原恢复的方式，则可以手动将表空间切换到CORRUPT状态，再执行删除操作，否则无法删除。已经切换到CORRUPT状态后，仍然允许再次执行还原恢复。

---

2.1.3 表还原

表还原是表备份的逆过程，表还原从**表备份集**中读取数据替换目标表，将目标表还原成备份时刻的状态。表还原主要包括三部分内容：表结构还原、数据还原、以及重建索引和约束。

• 如果还原目标表不存在，则利用备份集中记录的建表语句重建目标表；

• 如果还原目标表已经存在，则清除表中的数据、删除二级索引和约束；

• 如果备份表存在附加列（通过 ALTER TABLE 语句快速增加的列），那么还原目标表必须存在、并且目标表所有列的物理存储格式必须与备份源表完全一致。

数据还原过程从表备份集拷贝数据页，重构数据页之间的逻辑关系，并重新形成一个完整的表对象。

在数据还原结束后，使用备份集中记录的信息，重新在表上创建二级索引，并建立各种约束。

表还原只支持在联机状态下执行，表还原过程中也不需要重做 REDO 日志。并且，表备份集允许跨库还原，但要求还原目标库与源库的数据页大小等建库参数相同。需要匹配的建库参数参考下表。

名称	描述
PAGE_SIZE	数据页大小
BLANK_PAD_MODE	空格填充模式，可选值：0/1
CASE_SENSITIVE	字符大小写是否敏感
CHARSET/UNICODE_FLAG	字符集(0)，可选值：0[GB18030]，1[UTF-8]，2[EUC-KR]
USE_NEW_HASH	是否使用新的 HASH 算法
LENGTH_IN_CHAR	VARCHAR 类型长度是否以字符为单位(N)
PAGE_ENC_SLICE_SIZE	数据页加密分片大小

可以使用 DMRMAN 工具的 SHOW 功能查看备份的数据页大小等建库参数。

---

2.2 数据恢复

数据恢复是指在还原执行结束后，重做 REDO 日志，将数据库恢复到一致性状态，并执行更新 DB_MAGIC 的过程。其中重做 REDO 日志可以多次执行，直到恢复到目标状态。还原结束后，必须经过恢复操作，数据库才允许启动。即使备份过程中没有修改任何数据，备份集不包含任何 REDO 日志，在数据库还原结束后，也必须使用 DMRMAN 工具执行数据恢复操作后，才允许启动数据库。

数据恢复重做的 REDO 日志，既可以是那些在备份过程中产生的、包含在备份集中的 REDO 日志，也可以是备份数据库本地归档日志文件。在本地归档日志完整的情况下，数据还原结束后，可以利用本地归档日志，将数据库恢复到备份结束后任意时间点状态。

2.2.1 数据库恢复

数据库恢复分为两步：恢复一致性、更新 DB_MAGIC。

2.2.1.1 恢复一致性

恢复一致性有两种途径：

• 通过指定备份集恢复；

• 通过指定归档恢复。

  • 指定时间点恢复：归档日志包含时间信息，重做归档日志过程中，一旦发现达到了指定时间点，就马上终止归档日志重做。比如：用户在下午 5 点做了一个误操作，删除了某些重要数据；我们可以将恢复时间设置为下午 4:59 分，在恢复完成后，重新找回被误删的数据。
  • 指定 LSN 进行恢复：DM 中每条 REDO 日志记录都对应一个唯一的 LSN 值，指定 LSN 值以后，数据库将会精准的恢复到产生这个 LSN 时间点的状态。

用户需根据备份时是否选择 WITHOUT LOG 子句来决定选择何种恢复途径。

恢复途径	恢复流程
指定备份集恢复	1️⃣从备份集读取 REDO 日志，并生成一个临时的本地归档日志文件； 2️⃣利用生成的临时归档日志文件，重做 REDO 日志，并将数据修改写入磁盘； 3️⃣删除临时生成的归档日志文件； 4️⃣更新数据库日志信息，设置 CKPT_LSN 为最后一个重做的 REDO 日志 LSN 值； 5️⃣修改数据状态为 ACTIVE，标记数据库启动时需要进行相应的回滚活动事务、PURGE 已提交事务。
指定归档恢复	1️⃣扫描指定的归档日志目录，收集与恢复数据库 PERMANENT_MAGIC 值相等的归档日志文件。 2️⃣更新数据库日志信息，设置 CKPT_LSN 为最后一个重做的 REDO 日志 LSN 值； 3️⃣修改数据状态为 ACTIVE，标记数据库启动时需要进行相应的回滚活动事务、PURGE 已提交事务。

与指定备份集恢复相比，利用本地归档日志恢复不需要生成、删除临时归档日志文件，其余的执行流程完全相同。

指定归档恢复的执行场景主要包括：

• 将还原后处于非一致性状态的数据库恢复到一致性状态
• 将已经处于一致性状态的数据库尽可能地恢复到最新状态
• 将数据库恢复到指定时间点状态
• 将数据库恢复到指定 LSN 产生时的状态

注意

使用DDL CLONE方式备份的数据库，不支持指定归档恢复。

指定归档恢复时，不建议使用联机状态下源库的归档，此时无法保证归档的完整性。

2.2.1.2 更新DB_MAGIC

若备份集满足 BEGIN_LSN 等于 END_LSN，即在备份过程中未产生 REDO 日志，则使用此备份集还原后只需要更新 DB_MAGIC 即可完成恢复。更新 DB_MAGIC 不重做 REDO 日志，仅仅更新库的 DB_MAGIC 值和数据库状态。

注意

只能在还原后的数据库上执行更新DB_MAGIC操作。

---

2.2.2 表空间恢复

考虑到用户表空间上的数据库对象定义是保存在 SYSTEM 表空间的系统表内，而用户表空间仅保存这些数据库对象的数据，为了避免出现数据库对象的数据与定义不一致的情况，一般要求在表空间还原后，重做指定表空间所有 REDO 日志将这个表空间数据恢复到最新状态。与表空间还原类似，表空间恢复也只能在脱机状态下通过 DMRMAN 工具完成。

表空间恢复的 REDO 日志是从本地归档日志文件中提取。表空间恢复同样要求满足归档日志覆盖 [BEGIN_LSN,END_LSN] 的要求。

注意：

表空间恢复结束，并执行 ONLINE 表空间操作后，用户就可以访问这个表空间；但 ONLINE 操作并不会触发事务回滚，所以重做 REDO 日志产生的未 COMMIT 事务，也不会被回滚掉。

2.2.3 DMDSC库恢复

DMDSC 库与普通单节点数据库的区别在于 DMDSC 库的多个节点共同维护一份库数据，每个节点上都有独立的联机日志和本地归档日志。重做 REDO 日志恢复时，需要重做所有节点上的 REDO 日志，因此需要提供各个节点的归档日志。

---

2.3 还原与恢复附加选项

2.3.1 解密与解压缩

解密和解压缩是备份过程中加密和压缩的逆操作，如果备份时未指定加密或压缩，还原和恢复过程中也不需要执行解密或者解压缩操作。

如果备份时进行了加密，那么还原时用户必须指定与备份时一致的加密密码和加密算法，否则还原会报错。如果备份时没有加密，那么还原时用户不需要指定加密密码和加密算法，如果指定了，也不起作用。DM 还原时的解密过程主要包括：

1. 检查用户输入的密码和算法是否与备份集中记录的加密信息一致；
2. 从备份集读取数据之后，写到目标文件（包括目标数据文件和临时归档文件）之前执行解密操作。

与解密不同，解压缩不需要用户干预，如果备份集指定了压缩，从备份集读取数据写到目标文件之前，会自动进行解压缩操作。

如果备份时既指定了加密又指定了压缩，那么与备份过程处理相反，还原时会先进行解密，再进行解压缩，然后将处理后的数据写入到目标文件中。

2.3.2 并行还原

指定并行备份生成的备份集，在还原时默认采用并行方式还原，并行度上限为备份时指定的并行数，实际并行度由 DMAP 最终创建成功的并行子任务数决定。目前，非并行备份生成的备份集，不支持以并行方式还原。

达梦社区：https://eco.dameng.com