备份还原原理
本章介绍 DM 备份与还原的实现原理，读者通过阅读本章内容，可以了解 DM 备份、还原与恢复的实现原理。

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

2.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，具体请参考《DM8_SQL 语言使用手册》），但需谨慎使用。避免归档日志缺失，导致数据无法恢复。

注意
为了最大限度地保护数据，当磁盘空间不足导致归档写入失败时，系统会挂起等待，直到用户释放出足够的磁盘空间。

当磁盘损坏导致归档日志写入失败时，系统会强制 HALT。

2.1.2 远程归档
所谓远程归档（REMOTE ARCHIVE），顾名思义就是将归档目录配置在远程节点上。远程归档专门用于 DMDSC 环境中。远程归档采用双向配置的方式，双向配置远程归档就是两个节点将自己的远程归档相互配置在对方机器上。集群中所有的节点，都拥有一套包括所有节点的，完整的归档日志文件。

具体有两种配置方式：一是共享本地归档的远程归档，即将远程归档目录配置为另一节点的本地归档目录，以此来共享它的本地归档日志文件；二是通过 MAL 发送的远程归档，即将写入本地归档的 REDO 日志信息，通过 MAL 发送到远程节点，并写入远程节点的指定归档目录中，形成远程归档日志文件。

注意
远程归档必须双向配置。否则，单向配置后远程归档会处于无效状态。

远程归档与本地归档的主要区别是 REDO 日志写入的位置不同，本地归档将 REDO 日志写入数据库实例所在节点的磁盘，而远程归档则将 REDO 日志写入到其他数据库实例所在节点的指定归档目录。

通过 MAL 发送的远程归档与本地归档的另外一个区别就是归档失败的处理策略不同：本地归档写入失败（比如磁盘空间不足），系统将会挂起；而远程归档失败则会直接将远程归档失效，不再发送 REDO 日志到指定数据库实例。当节点间网络恢复、或者远程节点重启成功后，系统会自动检测并恢复远程归档，继续发送新写入的 REDO 日志，但不会主动补齐故障期间的 REDO 日志。因此，在出现节点故障等情况下，通过 MAL 发送的远程归档的内容有可能是不完整的，而本地归档的内容肯定是完整的；如果备份还原恰好需要用到这段丢失的远程归档日志，那么可以从源端的本地归档拷贝、补齐这部分内容。而共享本地归档的远程归档，其本质就是本地归档，因而不存在远程归档日志丢失的问题，加上共享本地归档精省去了 MAL 发送的过程，因此更加可靠高效。综上所述，DM 推荐用户使用共享本地归档的远程归档。

2.1.2.1 共享本地归档的远程归档
共享本地归档的远程归档就是双向配置的两个节点都不再发送 REDO 日志到对方机器上生成远程归档日志文件，而是将对方的本地归档作为自己的远程归档。例如，节点 0 的本地归档配置在 ASM 共享存储或其他共享磁盘上。节点 1 可以通过将自己的远程归档目录设置为节点 0 的本地归档目录，将节点 0 的本地归档日志文件作为自己的远程归档日志文件。图 2.1 展示了一个共享本地归档的远程归档的双向配置示意图。

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

2.1.2.2 通过 MAL 发送的远程归档
通过 MAL 发送的远程归档就是将写入本地归档的 REDO 日志信息，发送到远程节点，并写入远程节点的指定归档目录中。远程归档的触发时机是，在 REDO 日志写入本地归档日志文件的同时，将 REDO 日志通过 MAL 系统发送给指定的数据库实例。

DMDSC 集群中，如果各个节点在配置本地归档之外，再双向配置一个远程归档，那么就可以在任意一个节点的本地磁盘中，找到一套 DMDSC 集群所有节点产生的、完整的归档日志文件。图 2.2 展示了一个通过 MAL 发送的远程归档的双向配置示意图。

通过 MAL 发送的远程归档

图2.2 通过MAL发送的远程归档
若节点出现故障，故障恢复后，因为该节点配置的通过 MAL 发送的远程归档，该节点的远程归档内容可能不完整，可能缺少故障期间的 REDO 日志，因此需要进行手动修复。

2.1.3 归档切换
由于本地归档和远程归档是异步写入归档日志文件的，REDO 日志在写入联机日志文件后，再由专门的归档线程负责将这些 REDO 日志写入本地归档日志文件。通过归档切换功能，可以将这些已经写入联机日志文件，但还没有写入归档日志文件的 REDO 日志，写入到归档日志文件中。通过执行以下 SQL 命令，可以完成归档切换功能。三条语句功能一样，选择一条执行即可。

Copy
alter database archivelog current;

alter system archive log current;

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

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

收集本地归档日志文件；
扫描归档文件，获取最后一个有效 RLOG_PKG 偏移；
首先，根据偏移来截取最后一个本地归档日志文件中有效内容，删除掉 RLOG_PKG 偏移之后的多余内容，保留 RLOG_PKG 偏移之前的内容，并调整日志文件头信息。然后，再创建一个新的空的归档日志文件；
扫描联机日志文件，拷贝缺失的 REDO 日志并写入新创建的归档日志文件。
2.2 备份
任何一个对 DM 数据库的操作，归根结底都是对某个数据文件页的读写操作。物理备份就是把这些数据文件中的有效数据页备份起来，在出现故障时，用于恢复数据。DM 的物理备份一般包括数据备份和日志备份两部分，数据备份是拷贝数据页内容，日志备份则是拷贝备份过程中产生的 REDO 日志。

备份内容

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

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

注意
使用dminit建库时，通过设置INI参数page_check，指定页校验模式，当指定值不为0时，在执行备份过程中会对数据页执行校验操作，校验结果会记录在备份集中，并在备份结束后给出警告信息，警告码为609，告知用户此备份集中存在被破坏的数据页。该警告只是提示作用，并不影响备份集的有效性。在还原库上，备份集中备份的被破坏数据页在经过还原和恢复操作后，可以正常使用。

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

参照图 1.2，若执行库备份，则备份数据文件包括除 TEMP 表空间以外的其他表空间内的所有数据文件；若执行表空间备份，以用户表空间 BOOKSHOP 为例，那么只会扫描 BOOKSHOP 表空间的数据文件，包括 BOOKSHOP.DBF。数据文件备份结束后，BEGIN_LSN 之前修改的所有数据页都被备份下来。

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

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

同样库增量备份会扫描整个数据库的所有数据文件，表空间增量备份只扫描表空间内的数据文件。

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

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

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

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

在备份开始时，记录一个 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 日志。

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

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

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

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

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

注意
如果基备份集没有指定加密类型，那么增量备份也不能指定加密类型；

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

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

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

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

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

并行备份集目录结构示意图

2.3 还原与恢复
还原与恢复是备份的逆过程，还原与恢复的主要目的是将目标数据库恢复到备份结束时刻的状态。还原的主要动作是将数据页从备份集中拷贝回数据库文件相应位置，恢复则是重做 REDO 日志将数据库恢复到一致性状态。

还原恢复时，若性能较差，则可以通过适当增大 dm.ini 文件中 BUFFER 的参数值或根据当前系统主机核数适当调整 REDOS_PARALLEL_NUM 的参数值来提升还原恢复性能。其中，BUFFER 的参数值建议为可用物理内存的 60%～80%。关于 dm.ini 文件的具体配置信息请参考《DM8 系统管理员手册》。

2.3.1 数据还原
2.3.1.1 库还原
库还原就是根据库备份集中记录的文件信息重新创建数据库文件，并将数据页重新拷贝到目标数据库的过程。DM 既可以将一个已存在的数据库作为还原目标库，也可以指定一个路径作为还原目标库的目录。库还原的主要步骤包括：清理目标库环境；重建数据库文件；拷贝数据页；重建联机日志文件；修改配置参数等。

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

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

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

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

数据文件重建策略：

1）目标库和备份集中的 SYSTEM_PATH 路径相同，则按照备份集中记录的原始路径创建文件；

2）目标库和备份集中的 SYSTEM_PATH 路径不相同，默认在目标库的 SYSTEM_PATH 目录下创建文件；

3）目标库设置 REDOS_FILE_PATH_POLICY 参数为 1 时，用户创建的表空间（表空间 id 大于等于 5）按照数据文件在源库中的路径结构，在目标库 SYSTEM_PATH 下创建相同路径结构的文件；

4）使用 mapped file 指定源文件与目标文件的映射关系，定制数据库文件的物理分布情况，可以很好的满足用户关于数据文件分布的需求。

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

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

重置目标库
具体包括：

更新日志信息，设置当前 CKPT_LSN 为备份集中 BEGIN_LSN，并设置日志文件状态为 INACTIVE；
更新 DB_MAGIC，还原后，库中 PERMANENT_MAGIC 仍与备份集中相同；
设置还原标志，标识当前库为指定库要还原的库，不允许使用；
更新目标库的控制文件 dm.ctl，把当前库中的数据文件信息都记录到控制文件中，使用备份集中的服务器秘钥文件，重新生成新的秘钥文件。
修改配置参数
还原到指定库时，默认会保留目标库的配置参数不变，也可以在还原时指定 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.3.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 状态后，仍然允许再次执行还原恢复，CORRUPT 语法可参考《DM8_SQL 语言使用手册》。

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

如果还原目标表不存在，则利用备份集中记录的建表语句重建目标表；如果还原目标表已经存在，则清除表中的数据、删除二级索引和约束；如果备份表存在附加列（通过 ALTER TABLE 语句快速增加的列），那么还原目标表必须存在、并且目标表所有列的物理存储格式必须与备份源表完全一致。

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

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

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

表2.1还原库与备份库需匹配建库参数

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

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

不管采用哪种数据恢复方法，REDO 日志的范围至少要覆盖备份过程中产生的 REDO 日志，也就是说必须完整包括备份集中记录的[BEGIN_LSN,END_LSN]之间的 REDO 日志，如果归档日志缺失将会导致数据库恢复失败。只有库备份和表空间备份还原后，需要执行数据恢复，表还原结束后，不需要执行数据恢复。

为了让读者更好地了解恢复的过程，这里先介绍一下 DM 的 MAGIC。PERMANENT_MAGIC 和 DB_MAGIC 是用来标识数据库的 INTEGER 类型值。DM 在初始化数据库时生成 PERMANENT_MAGIC 和 DB_MAGIC 值，其中 PERMANENT_MAGIC 一经生成，永远不会改变（DDL_CLONE 还原库的 PERMANENT_MAGIC 除外），称为数据库永久魔数。只有 DDL_CLONE 还原库的 PERMANENT_MAGIC 会发生改变，当一个库使用 DDL_CLONE 备份集还原并恢复之后，在执行 RECOVER DATABASE …… UPDATE DB_MAGIC 时，PERMANENT_MAGIC 会发生改变。DB_MAGIC 称为数据库魔数，同样可以用来表示某一个数据库，但 DB_MAGIC 是可以变化的，每经过一次还原、恢复操作后，DB_MAGIC 就会产生变化，用来区分备份源库和还原目标库。

可以通过下列语句查看系统的 PERMANENT_MAGIC 和 DB_MAGIC 值。

Copy
SELECT PERMANENT_MAGIC;

SELECT DB_MAGIC FROM V$RLOG;
2.3.2.1 指定备份集恢复
默认未指定 WITHOUT LOG 子句的联机库备份生成的备份集，包含了备份过程中产生的 REDO 日志，数据还原结束后，可以直接指定备份集，将数据库恢复到备份结束时的状态。

由于执行增量备份时，要求<=基备份 END_LSN 的所有数据页已经写入磁盘；因此基备份集中包含的 REDO 日志不需要重做，只要重做指定执行还原操作的备份集中包含的 REDO 日志，就可以将数据库恢复到一致性状态。

指定备份集恢复的简要过程包括：

从备份集读取 REDO 日志，并生成一个临时的本地归档日志文件；
利用生成的临时归档日志文件，重做 REDO 日志，并将数据修改写入磁盘；
删除临时生成的归档日志文件；
更新数据库日志信息，设置 CKPT_LSN 为最后一个重做的 REDO 日志 LSN 值；
修改数据状态为 ACTIVE，标记数据库启动时需要进行相应的回滚活动事务、PURGE 已提交事务。
2.3.2.2 指定归档恢复
如果备份时指定了 WITHOUT LOG 子句，那么产生的备份集不包含备份过程中产生的 REDO 日志。这种备份集还原后，必须利用本地归档日志，将数据库恢复到一致性状态。执行恢复前，会检查本地归档日志文件的完整性，要求必须包括[BEGIN_LSN,END_LSN]之间完整的 REDO 日志。

利用本地归档日志进行恢复时，DMRMAN 工具会扫描指定的归档日志目录，收集与恢复数据库 PERMANENT_MAGIC 值相等的归档日志文件。与指定备份集恢复相比，利用本地归档日志恢复不需要生成、删除临时归档日志文件，其余的执行流程完全相同。

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

将还原后处于非一致性状态的数据库恢复到一致性状态
将已经处于一致性状态的数据库尽可能地恢复到最新状态
将数据库恢复到指定时间点状态
将数据库恢复到指定 LSN 产生时的状态
注意
使用DDL CLONE方式备份的数据库，不支持指定归档恢复。

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

DM 中的归档日志包含时间信息，重做归档日志过程中，一旦发现达到了指定时间点，就马上终止归档日志重做。在出现误操作的情况下，通过指定时间点恢复，可能帮助用户修复数据。比如：用户在下午 5 点做了一个误操作，删除了某些重要数据；我们可以将恢复时间设置为下午 4:59 分，在恢复完成后，重新找回被误删的数据。

除了指定时间点，我们还可以通过指定 LSN 进行恢复。DM 中每条 REDO 日志记录都对应一个唯一的 LSN 值，指定 LSN 值以后，数据库将会精准的恢复到产生这个 LSN 时间点的状态。

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

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

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

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

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

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

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

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

1.检查用户输入的密码和算法是否与备份集中记录的加密信息一致；

2.从备份集读取数据之后，写到目标文件（包括目标数据文件和临时归档文件）之前执行解密操作。

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

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

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

2.4 归档日志备份与还原
除了通常意义上的数据备份、还原之外，DM 还支持对本地归档日志文件进行备份和还原。归档日志备份是数据库备份的一个有效补充，我们知道归档日志文件中保存了所有数据库操作产生的 REDO 日志，因此，在理论上，只要有一个基准备份集，加上完整的归档日志，我们可以将数据库恢复到任意时间点的状态。

2.4.1 归档日志备份
与联机备份收集备份过程中产生的 REDO 日志写入备份集不同，归档日志备份专门用来备份本地归档日志文件，将符合条件的本地归档日志文件拷贝到备份集中保存起来。

归档日志备份仅备份指定数据库生成的本地归档日志文件，要求归档日志文件的 DB_MAGIC 与数据库的 DB_MAGIC 保持一致。如果本地归档目录中包含多个不同数据库的归档日志文件，也只会备份一个特定数据库的归档日志。由于经过还原后数据库的 DB_MAGIC 会产生变化，因此即便 PERMANENT_MAGIC 相同，DB_MAGIC 不同的数据库产生的归档日志也不会备份。

与普通的数据库备份一样，归档日志备份也支持加密与压缩功能，可以联机执行归档日志备份，也可以在数据库关闭情况下使用 DMRMAN 工具进行脱机备份。归档日志备份时，可以指定是否删除已经备份的归档日志文件，在生成归档日志备份集的同时，删除本地归档日志文件，释放磁盘空间。

由于本地归档的异步实现机制，为了确保归档日志备份的完整性，一般会在归档日志备份之前执行一个归档切换动作。

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

归档日志还原的过程包括：

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