DM8备份与还原学习笔记

---

一、备份与还原简介

备份的主要目的是数据容灾，保证数据的安全性，在数据库发生故障时，通过还原备份集，将数据恢复到可用状态

1.1 概述

• DM数据库中的数据存储在数据库的物理数据文件中，数据文件按照页、簇和段的方式进行管理，数据页是最小的数据存储单元
• 备份的本质就是从数据库文件中拷贝有效的数据页保存到备份集中，这里的有效数据页包括数据文件的描述页和被分配使用的数据页
• 在备份的过程中，如果数据库系统还在继续运行，这期间的数据库操作并不是都会立即体现到数据文件中，而是首先以日志的形式写到归档日志中，为了保证用户可以通过备份集将数据恢 复到备份结束时间点的状态，就需要将备份过程中产生的归档日志也保存到备份集中
• 还原与恢复是备份的逆过程
• 还原是将备份集中的有效数据页重新写入目标数据文件的过程。恢复则是指通过重做归档日志，将数据库状态恢复到备份结束时的状态，也可以恢复到指定时间点和指定LSN。
• 恢复结束以后，数据库中可能存在处于未提交状态的活动事务，这些活动事务在恢复结束后的第一次数据库系统启动时，会由DM数据库自动进行回滚
• 备份、还原与恢复的关系如下：
  

1.2 基本概念

1.2.1 表空间与数据文件

• DM数据库的表空间是一个逻辑概念，其目的主要是为了方便数据库的管理，数据库的所有对象在逻辑上都存放在某个表空间中，而物理上都存储在所属表空间的数据文件中
• 一个表空间由一个或多个数据文件组成数据文件是数据库中最重要的文件类型，是真实数据存储的地方。DM 中数据文件的扩展名为.DBF，分为系统默认生成的数据文件和用户自己创建的数据文件两类。需要注意的是，HUGE 数据文件不同于一般数据文件，其扩展名为.DTA
• DM数据库中的表空间可以分为普通表空间和混合表空间。普通表空间不能存储HUGE表，而混合表空间可以同时存储普通（非HUGE）表和HUGE表，其中HUGE数据文件存储在混合表空间定义中指定的HUGE数据文件路径下。可以通过为普通表空间添加 HUGE 数据文件路径将其升级为混合表空间
• 在创建DM数据库时，系统会自动创建4个表空间：SYSTEM表空间、ROLL表空间、MAIN表空间和TEMP表空间。DM自动为这几个自动创建的表空间分别生成默认的数据文件：SYSTEM.DBF、ROLL.DBF、MAIN.DBF 和 TEMP.DBF。另外，DM 还会自动创建一个HMAIN目录，并将其路径作为 MAIN 表空间的 HUGE 数据文件路径，因此 MAIN 表空间为混合表空间
• 用户也可以创建自己的表空间，由用户创建的表空间统称为用户自定义表空间，在创建自定义表空间时需要为表空间指定数据文件因此，DM 中的表空间有以下几类：
  SYSTEM 表空间
  存放了 DM 数据库全局字典信息和全局系统数据，是 DM 数据库能够正常运行的必要前提，默认对应数据文件 SYSTEM.DBF。CREATE TABLE 等 DDL 操作会修改 SYSTEM 表空间数据。
  ROLL 表空间
  存放 DM 数据库运行过程中产生的所有回滚记录。DM 中几乎所有的数据库修改操作都
  会生成回滚记录，并保存在 ROLL 表空间的数据文件中。ROLL 表空间是数据库全局对象，不论修改哪一个表空间，生成的回滚记录都是写入 ROLL 表空间，该表空间由系统自动维护，默认数据文件为 ROLL.DBF。
  TEMP 表空间
  存放临时表数据以及数据库运行过程中产生的临时数据。在数据库运行过程中，SORT、
  HASH JOIN 等操作都可能会生成临时结果集，它们作为临时数据存放在 TEMP 表空间中。TEMP 表空间是数据库全局对象，由系统自动维护。若数据库重启，保存在 TEMP 表空间中的所有数据都会丢失。TEMP表空间的默认数据文件为TEMP.DBF。DM 的物理备份还原不支持：TEMP 表空间。
  MAIN 表空间：混合表空间。在创建用户时，如果没有指定默认表空间，系统自动指定MAIN表空间为用户默认的表空间。MAIN表空间的默认数据文件为MAIN.DBF，默认HUGE数据文件路径为HMAIN目录所在路径
  用户自定义表空间：用户通过创建表空间相关操作生成的表空间

1.2.2 重做日志

• 重做日志，又叫 REDO 日志，记录所有物理页的修改，基本信息包括操作类型、表空间号、文件号、页号、页内偏移、实际数据等。数据库中 INSERT、DELETE、UPDATE等 DML 操作以及 CREATE TABLE 等 DDL 操作最终都会转化为对某些数据文件、 某些数据页的修改。因此，在系统故障重启时，通过重做 REDO 日志，可以将数据库恢复到故障时的状态
• DM数据库默认包含两个扩展名为log的日志文件来保存REDO日志，称为联机重做日志文件，两个文件循环使用。任何数据页从内存缓冲区写入磁盘之前，必须保证其对应的REDO日志已经写入到联机日志文件
• REDO日志包（RLOG_PKG）是DM数据库保存REDO日志的数据单元，一个日志包内可保存一个或多个PTX产生的REDO日志。日志包具有自描述的特性，日志包大小不固定，采用固定包头和可变包头结合的方式，包头记录日志的控制信息，包括类型、长度、包序号、LSN信息、产生日志的节点号、加密压缩信息、日志并行数等内容
• 日志包生成时按照序号连续递增，相邻日志包的LSN顺序是总体递增的，但是在DMDSC集群环境下不一定连续。如果未开启并行日志，RLOG_PKG 包内日志的 LSN 是递增的。如果开启并行日志，一个RLOG_PKG包内包含多路并行产生的日志，每一路并行日志的LSN是递增的，但是各路之间的LSN并不能保证LSN有序，因此并行日志包内LSN具有局部有序，整体无序的特点

1.2.3 归档日志

• DM数据库可以在归档和非归档两种模式下运行，DM支持多种归档方式
• 系统在归档模式下运行会更安全，当出现介质故障，如磁盘损坏导致数据文件丢失、异常时，利用归档日志，系统可以恢复至故障发生的前一刻。因此，为了保证归档日志文件和数据文件不同时出现问题，建议将归档目录与数据文件配置、保存到不同的物理磁盘上。除了表备份还原，其他的联机备份与还原必须运行在归档模式下
• DM数据库支持的归档方式包括：包括本地归档、实时归档、即时归档、异步归档和远程归档，其中本地归档和远程归档与备份还原密切相关
• 系统将 REDO 日志先写入联机日志文件后，根据归档的配置情况，异步地将 REDO 日志写入本地归档日志文件，或者通过 MAL 系统发送到远程归档的目标实例，写入目标实例的远程归档日志文件中
• Primary/Normal模式库归档日志文件命名规则：ARCH_NAME_DB_MAGIC[SEQNO]_日期时间.log。其中ARCH_NAME是在dmarch.ini中配置的LOCAL/REMOTE归档名称，DB_MAGIC是生成日志的数据库魔数，SEQNO代表DSC节点号，日期时间是归档日志文件的创建时间。比如：ARCHIVE_LOCAL1_0x567891[0]_2018-05-30_10-35-34.log
• Standby 模式库（备库）归档日志文件的命名规则是：
  STANDBY_ARCHIVE_DB_MAGIC[SEQNO]_日期时间.log 。其中，STANDBY_ARCHIVE表示备库生成的归档日志文件；DB_MAGIC 是生成日志的数据库（主库）魔数；SEQNO代表主库对应的 DSC 节点号；日期时间是归档日志文件的创建时间。比如：STANDBY_ARCHIVE_0x123456[0]_2018-05-30_10-35-34.log 。由于STANDBY_ARCHIVE用于表示备库生成的归档日志，因此，不允许将归档名称配置为STANDBY_ARCHIVE。

1.2.4 LSN介绍

• LSN（Log Sequence Number）是由系统自动维护的Bigint类型数值，具有自动递增、全局唯一特性，每一个LSN值代表着DM系统内部产生的一个物理事务。物理事务（Physical Transaction，简称 PTX）是数据库内部一系列修改物理数据页操作的集合，与数据库管理系统中事务（Transaction）概念相对应，具有原子性、有序性、无法撤销等特性

• DM数据库中与LSN相关的信息，可以通过查询V$RLOG和V$RAPPLY_PARALLEL_INFO表来获取
  

• DM主要包括以下几种类型的 LSN：

  • CUR_LSN：是系统已经分配的最大LSN值。物理事务提交时，系统会为其分配一个唯一的LSN值，大小等于CUR_LSN + 1，然后再修改CUR_LSN=CUR_LSN+1
  • FLUSH_LSN：是已经发起日志刷盘请求，但还没有真正写入联机REDO日志文件的最大LSN值
  • FILE_LSN：是已经写入联机REDO日志文件的最大LSN值。每次将REDO日志包RLOG_PKG写入联机REDO日志文件后，都要修改FILE_LSN值
  • CKPT_LSN：是检查点LSN，所有LSN<=CKPT_LSN的物理事务修改的数据页，都已经从Buffer缓冲区写入磁盘，CKPT_LSN由检查点线程负责调整，数据库故障重启时，CKPT_LSN之前的REDO日志不需要重做，只需要从CKPT_LSN+1开始重做REDO日志，就可以将系统恢复到故障前状态。并且，在联机重做日志文件中，LSN值<=CKPT_LSN的REDO日志都可以被覆盖
  • APPLY_LSN：是数据库还原恢复后已经写入联机REDO日志文件的日志包的原始最大LSN值，APPLY_LSN取自源库的原始日志包中的最大LSN值。DSC集群的每一个节点独立维护APPLY_LSN
  • RPKG_LSN：是数据库还原恢复后已经重演日志的最大LSN。DSC集群的每一个节点独立维护RPKG_LSN

1.2.5 包序列介绍

• 每个RLOG_PKG都有对应的序号属性，称之为包序号（PKG SEQNO），日志包生成时按照序号连续递增
• 包序号包括本地包序号（LSEQ）和全局包序号（GSEQ），本地包序号是节点内唯一、连续递增的值，用于校验联机日志连续性；全局包序号由数据守护集群的主备库共同维护，具有全局唯一、连续、递增的特性，用于校验归档日志的连续性。
• DM数据库中与全局包序号相关信息，可以查询V$RLOG和V$RAPPLY_PARALLEL_INFO表来获取
• 数据库端主要包括以下几种类型的全局包序号：
  • CUR_SEQ是系统已经分配的最大全局包序号。RLOG_PKG写入联机日志文件前，系统会为其分配一个唯一的全局包序号
  • FILE_SEQ是已经写入联机REDO日志文件的最大全局包序号。每次将REDO日志包RLOG_PKG写入联机REDO日志文件后，都要修改FILE_SEQ值。
  • APPLY_SEQ是数据库还原恢复后已经写入联机REDO日志文件的原始最大全局包序号，APPLY_SEQ取自源库的原始日志包的包序号。DSC集群的每一个节点独立维护APPLY_SEQ
  • RPKG_SEQ是数据库还原恢复后已经重演日志的最大全局包序号。DSC集群的每一个节点独立维护RPKG_SEQ

1.2.6 检查点

• DM数据库运行过程中，用户的所有操作都在内存中进行。每修改一条记录都必须先把记录所在的数据页加载到BUFFER缓冲区中，然后进行修改。事务运行时，会把生成的REDO日志保留在REDO日志包RLOG_PKG中，每条日志记录对应一个LSN，当事务提交或REDO日志包满或执行检查点时会进行日志刷盘
• 检查点（checkpoint）是一个数据库事件，它的功能是按照数据页的修改顺序，依次将BUFFER缓冲区中的脏页写入磁盘，并在这个过程中动态调整CKPT_LSN值，释放日志空间
• DM的检查点分为两种：完全检查点和部分检查点：
  • 完全检查点：会将内存缓冲区中的所有脏页写入磁盘，并调整 CKPT_LSN，在数据库正常关闭时会产生一个完全检查点
  • 部分检查点：根据dm.ini配置参数CKPT_FLUSH_RATE和CKPT_FLUSH_PAGES，确定每次检查点刷脏页的数量。执行部分检查点的过程中，DDL/DML操作都可以正常执行，DM系统中绝大多数情况下触发的都是部分检查点
• 数据库运行过程中产生的待写入日志首先写入 REDO 日志包 RLOG_PKG，当日志刷盘时一起写入联机日志文件中。在联机日志文件中，可以覆盖写入 REDO 日志的文件长度为可用日志空间；不能被覆盖的 REDO 日志，系统故障重启需要重做的 REDO 日志为有效日志，有效日志的 LSN 取值范围是(CKPT_LSN,FILE_LSN]
• 下图说明了联机日志文件、REDO日志包 RLOG_PKG 以及相关各 LSN 之间的关系
  

1.2.7 备份集

• 存放备份过程中产生的备份数据及备份信息
• 一个备份集对应了一次完整的备份
• 一般情况下，一个备份集就是一个目录，备份集包含一个或多个备份片文件，以及一
  个备份元数据文件。并行备份和非并行备份情况下，备份集里的内容略有不同

备份片：
存储备份数据的文件备份时，目标数据文件内容或归档日志内容经过处理后，都会存放到各自的备份片文件中。备份片文件后缀为.bak，用来存放备份数据，备份集中存放数据页的备份片称为数据备份片，存放REDO日志的备份片称为日志备份片，备份片的大小可以在备份时通过MAXPIECESIZE指定，一个备份集中可能生成多个备份片
元数据
元数据文件用来存放备份信息，元数据文件的后缀为.meta。通过元数据文件，可以了解整个备份集信息。元数据文件中包含的备份信息包括：
· 备份集本身相关的信息，如是否联机备份，备份的范围，备份的加密信息，以及备份的压缩信息等；
· 备份源库的建库参数信息，如DSC的节点数，是否大小写敏感，PAGE_CHECK属性等；
· 数据文件信息，如备份了哪些数据文件，文件大小，以及文件相关的表空间信息等；
· 备份片的信息，如包含哪些备份片文件、备份片大小等信息；
· 备份库的dm.ini参数信息和密钥文件（dm_service.prikey或者dm_external.config，若指定usbkey加密，则不备份）
备份集搜索目录
用于搜集目标备份集的文件路径，备份集搜索目录包括 4 类：
· 数据库的默认备份目录；
· WITH BACKUPDIR 子句指定的目录；
· 还原时备份集所在的上级目录；
· 增量备份时基备份集所在的上级目录。
如果使用第三方备份（介质为TAPE类型），则只搜索WITH BACKUPDIR子句指定的备份集目录，具体搜集方式由第三方备份程序决定WITH BACKUPDIR子句指定的目录列表，包含非法目录或目录不存在时，不会报错，只在日志中打印警告

1.2.8 备份

逻辑备份和物理备份

• 逻辑备份是指利用dexp导出工具，将指定对象（库级、模式级、表级）的数据导出到文件的备份方式。逻辑备份针对的是数据内容，并不关心这些数据物理存储在什么位置
• 物理备份则直接扫描数据库文件，找出那些已经分配、使用的数据页，拷贝并保存到备份集中。物理备份过程中，不关心数据页的具体内容是什么，也不关心数据页属于哪一张表，只是简单的根据数据库文件系统的描述，来挑选有效的数据页。

联机备份和脱机备份

• 数据库处于运行状态、并正常提供数据库服务情况下进行的备份操作，我们称为联机备份。
• 数据库处于关闭状态时进行的备份操作，被称为脱机备份
• DMRMAN工具进行脱机备份，并且支持对异常关闭的数据库进行脱机库备份。备份异常关闭的数据库，要求配置了本地归档，如果本地归档不完整，则需要先修复本地归档，再进行备份
• 联机备份则使用客户端工具连接到数据库实例后，通过执行 SQL 语句进行；也可以通过配置作业，定时完成自动备份。联机备份不影响数据库正常提供服务，是最常用的备份手段之一。
• 联机备份时，可能存在一些处于活动状态的事务正在执行，为确保备份数据的一致性，需要将备份期间产生的REDO日志一起备份。因此，只能在配置本地归档、并开启本地归档的数据库上执行联机备份。

数据备份和归档日志备份（备份内容不同）
· 数据备份主要针对数据文件内容，包括库备份、表空间备份和表备份。其中未指定
WITHOUT LOG参数执行的库备份和表空间备份还包含了REDO日志备份。
· 归档日志备份是专门针对归档日志文件进行操作，不涉及任何数据文件内容。归档日志
备份扫描归档目录收集归档日志文件，并将归档日志写入到备份集中。既可以在数据库运行
状态下，执行联机归档日志备份；也可以在数据库关闭状态下执行脱机归档日志备份。

归档日志备份范围
联机备份过程中，用户可以正常访问、修改数据库，为了准确记录备份过程中产生了哪些REDO日志，确定日志备份范围，我们特别定义了下述几个包序号和 LSN：
· 节点BEGIN_LSN
为了保证备份的完整性和有效性，必须包含的归档日志起始LSN值。BEGIN_LSN = 备份开始时检查点偏移前一个RLOG_PKG的max_lsn
· 节点BEGIN_SEQ
BEGIN_SEQ记录了BEGIN_LSN所在REDO日志包的序号。
· 节点END_LSN
为了保证备份的完整性和有效性，必须包含归档日志结束 LSN 值。END_LSN = 备份结束时 FILE_LSN。
· 节点END_SEQ
BEGIN_SEQ 记录了 END_LSN 所在 REDO 日志包的序号。
· BAK_END_LSN
备份结束时可以保证事务一致性的全局备份结束LSN。单节点BAK_END_LSN=END_LSN；DSC 集群环境中，每个节点的 END_LSN 都不相同，BAK_END_LSN 大于等于最大的 END_LSN。
如果BEGIN_SEQ等于END_SEQ，则表明备份过程中，该节点没有任何数据被修改。为了简化还原过程，增量备份时要求BEGIN_LSN必须大于等于基准备份的END_LSN，如果不满足条件，则强制生成检查点，直到BEGIN_LSN满足条件为止
一致性备份和非一致性备份（备份集中的数据是否满足一致性）
· 不指定WITHOUT LOG选项的备份生成的备份集就是一致性备份。一致性备份的备份集包含了完整的数据文件内容和 REDO 日志信息；利用一个一致性备份集就可以将数据库恢复到备份时状态。
· 指定WITHOUT LOG选项的备份生成的备份集都是非一致性备份集。非一致性备份的备份集只包含数据文件相关内容，没有 REDO 日志信息，利用非一致性备份集还原的数据库，无法直接启动，必须借助归档日志进行恢复之后才可以启动。但是有一种情况除外：数据库正常关闭时，会生成完全检查点，脱机备份生成的备份集中，不包含任何 REDO 日志。因此脱机备份一个正常关闭的数据库，既可以从归档日志恢复也可以从备份集恢复。
· 表空间备份生成的备份集是非一致性备份集。

完全备份和增量备份
按照备份数据完整性，可将备份分为完全备份和增量备份。库备份和表空间备份支持增量备份，表备份不支持增量备份。
· 完全备份生成的备份集包含了指定库（或者表空间）的全部有效数据页。当数据规模比较大的情况下，生成的完全备份集通常会比较大，而且备份时间也会比较长。
· 增量备份是在某个特定备份集基础上，收集数据库新修改的数据页进行备份，可以有效减少备份集的空间占用、提高备份速度。这个特定的、已经存在的备份集称为增量备份的基备份，根据对基备份的要求不同，DM 的增量备份分为以下两种：

1. 差异增量备份
   差异增量备份的基备份既可以是一个完全备份集，也可以是一个增量备份集。
   利用增量备份进行还原操作时，要求其基备份必须是完整的；如果差异增量备份的基备份本身也是一个增量备份，那么同样要求其基备份是完整的；任何一个增量备份，最终都是以一个完全备份作为其基备份。因此，完全备份是增量备份的基础。
2. 累积增量备份
   累积增量备份的基备份只能是完全备份集，而不能是增量备份集。
   增量备份的基备份集既可以是脱机备份生成的，也可以是联机备份生成的，脱机增量备份的基备份集可以是联机备份生成的，联机增量备份的基备份集也可以是脱机备份生成的。

1.2.9 还原

还原结束后目标库有可能处于非一致性状态，不能马上提供数据库服务；必须要进行数据库恢复操作后，才能正常启动。
逻辑还原和物理还原
· 逻辑还原是逻辑备份的逆过程，逻辑还原就是使用dimp工具，把dexp导出的备份数据重新导入到目标数据库
· 物理还原是物理备份的逆过程，物理还原一般通过 DMRMAN 工具（或者 SQL 语句），把备份集中的数据内容（数据文件、数据页、归档文件）重新拷贝、写入目标文件
联机还原和脱机还原
联机还原指数据库处于运行状态时，通过 SQL 语句执行还原操作。表还原可以在联机
状态下执行。
脱机还原指数据库处于关闭状态时执行的还原操作，脱机还原通过DMRMAN工具进行。
库备份、表空间备份和归档备份，可以执行脱机还原。脱机还原操作的目标库必须处于关闭
状态
数据还原和归档日志还原
根据备份集类型，数据还原可以分为库还原、表空间还原和表还原。库还原和表空间必
须脱机执行；表还原操作只能联机执行。
表空间还原的数据来源既可以是表空间备份集，也可以是库备份集。还原的目标表空间不能是 TEMP 表空间，只能是 MAIN、SYSTEM、ROLL 表空间，或者用户定义的表空间。
表还原从表备份集读取数据，重新恢复目标表数据，还会在目标表上重建索引、约束。
归档日志还原则将归档日志备份集中的归档日志内容，重新生成到指定目录中
完全还原和增量还原
完全还原是指直接利用完全备份集进行数据还原操作。增量还原指通过增量备份集进行数据还原操作。但是考虑到增量备份集的基础一定是一个完全备份集，因此增量还原过程中隐含了一个完全还原操作。如果增量备份集的基备份集被删除了，那么单独使用这个增量备份集是无法进行还原操作的。

1.3 备份还原过程

库备份还原：备份—还原—恢复。恢复又细分为恢复一致性、更新DB_MAGIC两步；
表空间备份还原：备份—还原—恢复。恢复只包括恢复一致性这一步；
表备份还原：备份—还原

1.4 介质管理层

• DM通过介质管理层MML，将备份、还原和恢复过程中备份片文件和元数据文件的读取写入动作进行抽象、隔离，备份还原过程中MML层会调用一组SBT接口来访问备份存储介质。SBT接口是DM定义的一组API函数，允许第三方厂商定制、管理备份存储介质；DM系统自带的备份还原功能也遵循了SBT规范如果备份、 还原时指定DEVICE TYPE为TAPE，且使用第三方提供的dmsbtex.dll(dmsbtex.so)来完成备份文件的存取功能，则DEVICE TYPE指定TAPE时还会提供PARMS关键字，用于传递第三方可识别的自定义字符串。使用第三方提供的动态库时，用户层应用不受影响。默认DEVICE TYPE为DISK，使用达梦自带SBT磁盘存储

1.5 备份方式

当前仅支持备份集方式的备份还原，不再支持其他备份方式。备份还原实现策略有两种：dmap辅助进程方式和无辅助进程方式。用户可通过dm.ini参数bak_use_ap来选择（dmrman使用参数use_ap），bak_use_ap可取值1、2。默认为1
bak_use_ap的两种取值的相应作用如下：
1. DMAP辅助进程方式，可支持第三方备份（指定DEVICE TYPE为TAPE）。DMAP插件执行，改造了备份还原任务子系统，允许指定并行度，大幅提升了备份还原的效率，特别是加密、压缩的处理效率。如果选择使用DMAP辅助进程，执行备份还原之前就必须启动DMAP服务。安装DM数据库以后，DMAP服务会自动启动。如果需要手动启动，有两种途径，一是启动DM服务查看器中的DmAPService。二是通过手动启动DMAP执行码实现，DMAP执行码位于DM安装目录的bin子目录下。除此之外，LINUX下，还可以调用bin目录下的DmAPService 脚本。
2：无辅助进程方式，不依赖DMAP，由主进程dmserver自身执行备份还原，但不支持第三方备份（指定 DEVICE TYPE 为 TAPE）

二、备份还原原理

2.1 归档技术

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

2.1.1 归档种类

备份还原相关的归档有本地归档和远程归档两种
本地归档
REDO 日志本地归档（LOCAL），就是将 REDO 日志写入到本地归档日志文件的过程。配置本地归档情况下，REDO 日志刷盘线程将 REDO 日志写入联机 REDO 日志文件后，对应的 RLOG_PKG 由专门的归档线程负责写入本地归档日志文件中。
与联机 REDO 日志文件可以被覆盖重用不同，本地归档日志文件不能被覆盖，写入其中的 REDO 日志信息会一直保留，直到用户主动删除；如果配置了归档日志空间上限，系统会自动删除最早生成的归档 REDO 日志文件，腾出空间。
为了最大限度地保护数据，当磁盘空间不足导致归档写入失败，系统将自动挂起等待，直到用户主动释放出足够的空间后继续运行。在设置多路本地归档的情况下，如果第一路本地归档若磁盘空间不足，则系统会被强制挂起，直到磁盘空间释放后继续运行。其它本地归档可以通过在 dmarch.ini 中设置 ARCH_HANG_FLAG 参数表示本地归档写入失败系统是否挂起，缺省值为 1 表示本地归档写入失败系统挂起。此外，系统会定期尝试恢复 INVALID的本地归档状态为 VALID。恢复 VALID 状态之后，如果正好剩余磁盘空间充足，那么可以继续归档。但是其它路（第一路归档之外的）本地归档中缺失的归档就需要人工手动进行修复了。当磁盘损坏导致归档日志写入失败时，系统会强制 HALT。
DM 提供了按指定的时间或指定的 LSN 删除归档日志的系统函数（SF_ARCHIVELOG_DELETE_BEFORE_TIME和SF_ARCHIVELOG_DELETE_BEFORE_LSN，具体请参考《DM8_SQL 语言使用手册》），但需谨慎使用。避免归档日志缺失，导致数据无法恢复。
远程归档
远程归档必须双向配置。否则，单向配置后远程归档会处于无效状态。
所谓远程归档（REMOTE ARCHIVE），顾名思义就是将归档目录配置在远程节点上。远程归档专门用于 DMDSC 环境中。远程归档采用双向配置的方式，双向配置远程归档就是两个节点将自己的远程归档相互配置在对方机器上。集群中所有的节点，都拥有一套包括所有节点的，完整的归档日志文件。
具体有两种配置方式：一是共享本地归档的远程归档，即将远程归档目录配置为另一节点的本地归档目录，以此来共享它的本地归档日志文件；二是通过 MAL 发送的远程归档，即将写入本地归档的 REDO 日志信息，通过 MAL 发送到远程节点，并写入远程节点的指定归档目录中，形成远程归档日志文件。
远程归档与本地归档的主要区别是 REDO 日志写入的位置不同，本地归档将 REDO 日志
写入数据库实例所在节点的磁盘，而远程归档则将 REDO 日志写入到其他数据库实例所在节
点的指定归档目录。
通过 MAL 发送的远程归档与本地归档的另外一个区别就是归档失败的处理策略不同：本地归档写入失败（比如磁盘空间不足），系统将会挂起；而远程归档失败则会直接将远程归档失效，不再发送 REDO 日志到指定数据库实例。当节点间网络恢复、或者远程节点重启成功后，系统会自动检测并恢复远程归档，继续发送新写入的 REDO 日志，但不会主动补齐故障期间的 REDO 日志。因此，在出现节点故障等情况下，通过 MAL 发送的远程归档的内容有可能是不完整的，而本地归档的内容肯定是完整的；如果备份还原恰好需要用到这段丢失的远程归档日志，那么可以从源端的本地归档拷贝、补齐这部分内容。而共享本地归档的远程归档，其本质就是本地归档，因而不存在远程归档日志丢失的问题，加上共享本地归档精省去了 MAL 发送的过程，因此更加可靠高效。综上所述，DM 推荐用户使用共享本地归档的远程归档。
共享本地归档的远程归档
共享本地归档的远程归档就是双向配置的两个节点都不再发送 REDO 日志到对方机器上生成远程归档日志文件，而是将对方的本地归档作为自己的远程归档。例如，节点 0 的本地归档配置在 ASM 共享存储或其他共享磁盘上。节点 1 可以通过将自己的远程归档目录设置为节点 0 的本地归档目录，将节点 0 的本地归档日志文件作为自己的远程归档日志文件。图展示了一个共享本地归档的远程归档的双向配置示意图

DMDSC 集群中，各个节点配置一个远程归档为其他节点的本地归档，通过这种共享本地归档的方式，可以在任意一个节点上，访问到 DMDSC 集群所有节点产生的、完整的归档日志文件。若节点出现故障，故障恢复后，因为该节点配置的远程归档为其他节点的本地归档，该节点的远程归档内容仍然是完整的，因此无需进行手动修复。
通过MAL发送的远程归档
通过 MAL 发送的远程归档就是将写入本地归档的 REDO 日志信息，发送到远程节点，并写入远程节点的指定归档目录中。远程归档的触发时机是，在 REDO 日志写入本地归档日志文件的同时，将 REDO 日志通过 MAL 系统发送给指定的数据库实例。
DMDSC 集群中，如果各个节点在配置本地归档之外，再双向配置一个远程归档，那么就可以在任意一个节点的本地磁盘中，找到一套 DMDSC 集群所有节点产生的、完整的归档日志文件。图展示了一个通过 MAL 发送的远程归档的双向配置示意图

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

2.1.2 归档修复

在数据库异常关闭后使用
DM 数据库实例正常退出时，会将所有 REDO 日志写入归档日志文件中；但是数据库实例异常关闭时，可能存在部分 REDO 日志未写入归档日志文件中，归档日志文件中的内容比实际可恢复的数据少一部分。这种情况下，将无法利用归档日志文件将数据恢复到最新状态，需要从联机日志文件拷贝该部分日志以补齐本地归档日志。
本地归档修复会扫描联机日志文件，将那些已经写入联机日志文件、但还没有写入到归档日志文件的 REDO 日志，重新写入到归档日志文件，流程如下：

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

2.1.3 归档备份还原

除了通常意义上的数据备份、还原之外，DM 还支持对本地归档日志文件进行备份和还原。
归档日志备份是数据库备份的一个有效补充。在使用非一致性备份集进行还原后，必须使用归档日志进行恢复之后，数据库才能启动。
因为归档日志文件中保存了所有数据库操作产生的 REDO 日志，所以只要在一个基准备份集的基础上，加上一个完整的归档日志，我们就可以将数据库恢复到任意时间点的状态。

2.1.3.1 归档备份

与联机备份收集备份过程中产生的 REDO 日志写入备份集不同，归档日志备份专门用来备份本地归档日志文件，将符合条件的本地归档日志文件拷贝到备份集中保存起来。
归档日志备份仅备份指定数据库生成的本地归档日志文件，要求归档日志文件的DB_MAGIC 与数据库的 DB_MAGIC 保持一致。如果本地归档目录中包含多个不同数据库的归档日志文件，也只会备份一个特定数据库的归档日志。由于经过还原后数据库的DB_MAGIC 会产生变化，因此即便 PERMANENT_MAGIC 相同，DB_MAGIC 不同的数据库产生的归档日志也不会备份。
与普通的数据库备份一样，归档日志备份也支持加密与压缩功能，可以联机执行归档日志备份，也可以在数据库关闭情况下使用 DMRMAN 工具进行脱机备份。归档日志备份时，可以指定是否删除已经备份的归档日志文件，在生成归档日志备份集的同时，删除本地归档日志文件，释放磁盘空间。

2.1.3.2 归档还原

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

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

2.2 数据备份还原

2.2.1 备份

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

2.2.1.1 数据备份

• 数据备份过程中，根据 DM 数据文件系统的描述信息，准确判断每一个数据页是否被分配、使用，将未使用的数据页剔除，仅保留有效数据页进行备份，这个过程我们称为智能抽取
• 与直接文件拷贝方式相比，DM 物理备份丢弃了那些没有使用的数据页，因此可以节省对存储空间的要求，并有效减少 IO 数量，提升备份、还原的效率
• 对处于 RES_OFFLINE 和 CORRUPT 状态的表空间，则只记录表空间相关信息和状态，不会真正拷贝数据页
• 数据备份过程中，会对数据进行校验，如果校验失败则会将相关信息写入到日志文件dm_BAKRES_xxx.log 中，但不会终止当前备份操作
  INI 参数 **page_check**，指定**页校验模式**，当指定值不为 0 时，在执行备份过程中会对数据页执行校验操作，校验结果会记录在备份集中，并在备份结束后给出警告信息，警告码为 609，告知用户此备份集中存在被破坏的数据页。该警告只是提示作用，并不影响备份集的有效性。在还原库上，备份集中备份的被破坏数据页在经过还原和恢复操作后，可以正常使用

2.2.1.1.1 库备份

DM 支持联机和脱机库级备份。
库备份分为完全备份和增量备份两种。

完全备份
备份程序扫描数据文件，拷贝所有被分配、使用的数据页，写入到备份片文件中。库备份会扫描整个数据库的所有数据文件。
参照如图 1.2，若执行库备份，则备份数据文件包括除 TEMP 表空间以外的其他表空间内的所有数据文件。数据文件备份结束后，BEGIN_LSN 之前修改的所有数据页都被备份下来。

增量备份
执行增量备份，备份程序会扫描数据文件，拷贝所有基备份结束以后被修改的数据页，写入到备份片文件中。
为了简化增量备份的还原过程，避免还原过程中重做基备份集对应的归档日志，DM 要求执行增量备份时，<=基备份 END_LSN 的所有数据页已经写入磁盘。由于基备份过程中，基备份BEGIN_LSN 与 END_LSN 之间的数据页可能被修改，导致数据库中的数据与备份文件中的数据不一致，所以增量备份会拷贝 LSN >基备份 BEGIN_LSN 的数据页写入备份片文件中，LSN <= 基备份 BEGIN_LSN 的数据页不需要写入到备份片文件中。
同样库增量备份会扫描整个数据库的所有数据文件。

2.2.1.1.2 表空间

DM 只支持联机表空间备份。但是不支持对 TEMP 表空间进行备份还原。
表空间备份也支持完全备份和增量备份。
表空间备份只拷贝指定表空间的数据页。
相对于数据库备份而言，表空间备份的速度会更快，生成的备份集会更小。对一些包含
关键数据的用户表空间，我们可以使用表空间备份功能，进一步保障数据安全。

2.2.1.1.3 表备份

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

2.2.1.2 备份附加选项

2.2.1.2.1 REDO日志备份

增量备份和完全备份的 REDO 日志备份流程完全相同。
只有库级和表空间级备份支持 REDO 日志备份。未指定 WITHOUT LOG 参数执行的库备份或表空间备份则包含了 REDO 日志备份。
REDO 日志备份就是将备份开始（BEGIN_LSN）之后产生的 REDO 日志拷贝到备份片文件中，用来在数据库还原结束后，将数据库恢复到一致性状态。如图 2.所示，在执行备份过程中，用户可能修改数据库中的数据，并产生对应的 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 日志的数量决定。跟源库中REDO 日志的数量无关。例如，源库中有 3 个 REDO 日志，目标库中只有 2 个，将源库还原到目标库后，目标库仍然只有 2 个 REDO 日志。

2.2.1.2.2 压缩与加密

DM 支持对备份数据进行压缩和加密处理，用户在执行备份时，可以指定不同的压缩级别，以获得不同的数据压缩比。默认情况下，备份是不进行压缩和加密处理的，详细使用方法参考 3 备份还原实战中的相关介绍。
DM 共支持 9 个级别（1~9 级）的压缩处理，级别越高压缩比越高，但相应的压缩速度
越慢、CPU 开销越大。
备份加密包括加密密码、加密类型和加密算法三个要素。加密密码通过使用IDENTIFIED BY<加密密码>来指定，使用备份集的时候必须输入对应密码。加密类型分为不加密、简单加密和完全加密。简单加密仅仅对部分数据进行加密，加密速度快；完全加密对所有数据执行加密，安全系数高。加密算法可参考《DM8 安全管理》加密章节。
加密类型和算法，用户均可手动指定。如果用户指定了加密密码，但没有指定加密类型和算法，则使用默认加密算法进行简单加密。用户也可以指定加密密码，但将加密类型指定为不加密。
如果同时指定加密和压缩，则备份过程中，会先进行压缩处理，再进行加密处理，备份的所有数据页和 REDO 日志都会进行压缩、加密处理。
如果基备份集没有指定加密类型，那么增量备份也不能指定加密类型；
如果基备份集指定了加密算法，那么增量备份的加密类型、加密算法和密码必须与基备份保持一致。

2.2.1.2.3 并行备份

库备份、表空间备份以及归档日志备份可以进行并行处理，用户通过关键字 PARALLEL指定是否执行并行备份，以及并行备份的并行数。如果指定了 PARALLEL 关键字，但不指定并行数，那么默认的并行数为 4，但实际的备份并行度由 DMAP 最终创建成功的并行子任务数决定。增量备份是否并行以及并行数与其基备份集无关。
目前的数据库并行备份还原都是以文件为单位，适用于待备份文件大小比较均匀的情况。若文件大小差别比较大，特别存在个别文件巨大时，并行备份还原基本没有优势。因此在进行数据库备份时，需要指定 READ SIZE <拆分块大小>，将巨大的数据文件先进行拆分之后再进行备份。
执行并行备份会生成一个主备份集和若干个子备份集，子备份集不能单独还原，也不能作为其他备份集的基备份。备份过程中产生的 REDO 日志保存在主备份集中，子备份集仅包含数据文件相关内容。
以下为一个并行数为 3 的脱机并行备份集（左）和非并行脱机备份集（右）比较截图：

2.2.2 还原

还原是备份的逆过程，具体包括数据还原和数据恢复两步。
数据还原的主要目的是将目标数据库还原到备份结束时刻的状态，数据还原的主要动作是将数据页从备份集中拷贝回数据库文件相应位置。数据恢复则是重做 REDO 日志将数据库恢复到一致性状态。
还原恢复时，若性能较差，则可以通过适当增大 dm.ini 文件中 BUFFER 的参数值或根据当前系统主机核数适当调整 REDOS_PARALLEL_NUM 的参数值来提升还原恢复性能。其中，BUFFER 的参数值建议为可用物理内存的 60%～80%。

2.2.2.1 数据还原

2.2.2.1.1 库还原

库还原就是根据库备份集中记录的文件信息重新创建数据库文件，并将数据页重新拷贝到目标数据库的过程。
DM 既可以将一个已存在的数据库作为还原目标库，也可以指定一个路径作为还原目标库的目录。库还原的主要步骤包括：清理目标库环境；重建数据库文件；拷贝数据页；重建联机日志文件；修改配置参数等。
清理目标库环境
如果指定已存在的数据库作为还原目标库，还原操作首先解析 dm.ini 配置文件，获取 dm.ctl 控制文件路径，删除控制文件中的数据文件，然后根据 OVERWRITE 选项
· 如指定OVERWRITE 选项，若待还原文件存在，则删除
· 如果未指定 OVERWRITE 选项，若待还原文件存在，则报错，但保留目标库的日志文件、控制文件等
需要注意的是，HUGE 数据文件未记录在 dm.ctl 控制文件中。如果指定还原到一个目录，则根据 OVERWRITE 参数选择策略，检查目标目录内的dm.ini文件、dm.ctl 文件、默认的日志文件 DBNAME01.log 和 DBNAME02.log（其中 DBNAME 为数据库名称）、待还原的数据文件等。

重建数据库文件
如果将一个已存在数据库作为还原目标，则需要将目标数据库的 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 个。
   拷贝数据页
   拷贝数据页是从备份集中读取数据页，并将数据页写入数据文件指定位置的过程。由于备份过程中，只将有效的数据页写入备份集中，因此，还原过程也只涉及这些被分配使用的数据页。
   修改配置参数
   还原到指定库时，默认会保留目标库的配置参数不变，也可以在还原时指定 REUSE DMINI 子句，使用备份集中的配置参数替换目标库 dm.ini 中的配置参数。还原到指定目录时，会重新建立一个 dm.ini 配置文件，并用备份集中的参数值来设置这些配置项。需要注意的是，一般与路径相关的配置参数，比如 SYSTEM_PATH 等并不会被替换，而是保留目标库 dm.ini 的原始值不变。
   服务器秘钥文件(dm_service.prikey或者 dm_external.config)仅在备份集中备份库非 usbkey 加密的情况下重建，并使用备份集中备份的秘钥内容进行还原。
   注意事项：
5. 指定的 dm.ini 必须存在且各项配置信息有效，其中 CTL_PATH 必须配置且路径必须有效；
6. 若指定目录还原，则指定目录作为数据库系统目录处理；
7. 由于还原是要确保数据库数据的完整性，因此，对于增量备份的还原，需要搜集完整的备份集链表，然后从前到后，逐个还原备份集中数据。鉴于增量备份 BEGIN_LSN 确定规则，增量备份的还原过程中，不需要重做任何归档日志。

2.2.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.2.2.1.3 表还原

表还原是表备份的逆过程，表还原从表备份集中读取数据替换目标表，将目标表还原成备份时刻的状态。表还原主要包括三部分内容：表结构还原、数据还原、以及重建索引和约束。
如果还原目标表不存在，则利用备份集中记录的建表语句重建目标表；如果还原目标表已经存在，则清除表中的数据、删除二级索引和约束；如果备份表存在附加列（通过 ALTER TABLE 语句快速增加的列），那么还原目标表必须存在、并且目标表所有列的物理存储格式必须与备份源表完全一致。
数据还原过程从表备份集拷贝数据页，重构数据页之间的逻辑关系，并重新形成一个完整的表对象。
在数据还原结束后，使用备份集中记录的信息，重新在表上创建二级索引，并建立各种约束。
表还原只支持在联机状态下执行，表还原过程中也不需要重做 REDO 日志。并且，表备份集允许跨库还原，但要求还原目标库与源库的数据页大小等建库参数相同。需要匹配的建库参数参考下表

2.2.2.2 数据恢复

数据恢复是指在还原执行结束后，重做 REDO 日志，将数据库恢复到一致性状态，并执行更新 DB_MAGIC 的过程。
重做 REDO 日志可以多次执行，直到恢复到目标状态。还原结束后，必须经过恢复操作，数据库才允许启动。即使备份过程中没有修改任何数据，备份集不包含任何 REDO 日志，在数据库还原结束后，也必须使用 DMRMAN 工具执行数据恢复操作后，才允许启动数据库。
数据恢复重做的 REDO 日志，既可以是那些在备份过程中产生的、包含在备份集中的 REDO 日志，也可以是备份数据库本地归档日志文件。在本地归档日志完整的情况下，数据还原结束后，可以利用本地归档日志，将数据库恢复到备份结束后任意时间点状态。
不管采用哪种数据恢复方法，REDO 日志的范围至少要覆盖备份过程中产生的 REDO 日志，也就是说必须完整包括备份集中记录的[BEGIN_LSN, END_LSN]之间的 REDO 日志，如果归档日志缺失将会导致数据库恢复失败。只有库备份和表空间备份还原后，需要执行数据恢复，表还原结束后，不需要执行数据恢复。
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 值。

2.2.2.2.1 数据库恢复

数据库恢复分为两步：一恢复一致性；二更新 DB_MAGIC。
恢复一致性
恢复一致性有两种途径：一是通过指定备份集恢复；二是通过指定归档恢复。用户需根据备份时是否选择WITHOUT LOG子句来决定选择何种恢复途径。

• 指定备份集恢复
  • 默认未指定 WITHOUT LOG 子句的联机库备份生成的备份集，包含了备份过程中产生的 REDO 日志，数据还原结束后，可以直接指定备份集，将数据库恢复到备份结束时的状态。
  • 由于执行增量备份时，要求<=基备份 END_LSN 的所有数据页已经写入磁盘；因此基备份集中包含的 REDO 日志不需要重做，只要重做指定执行还原操作的备份集中包含的 REDO日志，就可以将数据库恢复到一致性状态。
  • 指定备份集恢复的简要过程包括：
    1. 从备份集读取 REDO 日志，并生成一个临时的本地归档日志文件；
    2. 利用生成的临时归档日志文件，重做 REDO 日志，并将数据修改写入磁盘；
    3. 删除临时生成的归档日志文件；
    4. 更新数据库日志信息，设置 CKPT_LSN 为最后一个重做的 REDO 日志 LSN 值；
    5. 修改数据状态为 ACTIVE，标记数据库启动时需要进行相应的回滚活动事务、PURGE 已提交事务。
• 指定归档恢复
  • 如果备份时指定了 WITHOUT LOG 子句，那么产生的备份集不包含备份过程中产生的 REDO 日志。这种备份集还原后，必须利用本地归档日志，将数据库恢复到一致性状态。执行恢复前，会检查本地归档日志文件的完整性，要求必须包括[BEGIN_LSN, END_LSN]之间完整的 REDO 日志。
  • 利用本地归档日志进行恢复时，DMRMAN 工具会扫描指定的归档日志目录，收集与恢复数据库 PERMANENT_MAGIC 值相等的归档日志文件。与指定备份集恢复相比，利用本地归档日志恢复不需要生成、删除临时归档日志文件，其余的执行流程完全相同。
    指定归档恢复的执行场景主要包括：
    • 将还原后处于非一致性状态的数据库恢复到一致性状态
    • 将已经处于一致性状态的数据库尽可能地恢复到最新状态
    • 将数据库恢复到指定时间点状态
    • 将数据库恢复到指定 LSN 产生时的状态
  • DM 中的归档日志包含时间信息，重做归档日志过程中，一旦发现达到了指定时间点，就马上终止归档日志重做。在出现误操作的情况下，通过指定时间点恢复，可能帮助用户修复数据。比如：用户在下午 5 点做了一个误操作，删除了某些重要数据；我们可以将恢复时间设置为下午 4:59 分，在恢复完成后，重新找回被误删的数据。
  • 除了指定时间点，我们还可以通过指定 LSN 进行恢复。DM 中每条 REDO 日志记录都对
    应一个唯一的 LSN 值，指定 LSN 值以后，数据库将会精准的恢复到产生这个 LSN 时间点的
    状态。
    更新 DB_MAGIC
    若备份集满足 BEGIN_LSN 等于 END_LSN ，即在备份过程中未产生 REDO 日志，则使用此备份集还原后只需要更新 DB_MAGIC 即可完成恢复。更新 DB_MAGIC 不重做 REDO 日志，仅仅更新库的 DB_MAGIC 值和数据库状态。
    只能在还原后的数据库上执行更新DB_MAGIC操作

2.2.2.2.2 表空间恢复

考虑到用户表空间上的数据库对象定义是保存在SYSTEM 表空间的系统表内，而用户表空间仅保存这些数据库对象的数据，为了避免出现数据库对象的数据与定义不一致的情况，一般要求在表空间还原后，重做指定表空间所有 REDO 日志将这个表空间数据恢复到最新状态。与表空间还原类似，表空间恢复也只能在脱机状态下通过 DMRMAN 工具完成。
表空间恢复的 REDO 日志是从本地归档日志文件中提取。表空间恢复同样要求满足归档日志覆盖[BEGIN_LSN, END_LSN]的要求。
注：表空间恢复结束，并执行 ONLINE 表空间操作后，用户就可以访问这个表空间；但 ONLINE 操作并不会触发事务回滚，所以重做 REDO 日志产生的未 COMMIT 事务，也不会被回滚掉

2.2.2.2.1 DMDSC库恢复

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

2.2.2.3 还原与回复附加选项

2.2.2.3.1 解密与解压缩

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

1. 检查用户输入的密码和算法是否与备份集中记录的加密信息一致；
2. 从备份集读取数据之后，写到目标文件（包括目标数据文件和临时归档文件）之前执行解密操作。
   与解密不同，解压缩不需要用户干预，如果备份集指定了压缩，从备份集读取数据写到目标文件之前，会自动进行解压缩操作。
   如果备份时既指定了加密又指定了压缩，那么与备份过程处理相反，还原时会先进行解密，再进行解压缩，然后将处理后的数据写入到目标文件中。

2.2.2.3.2 并行还原

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