DM 达梦数据库备份与还原实战

目录

• 1. DM 备份与还原机制概述
  • 1.1. 核心概念
  • 1.2. 本文实践内容
• 2. 核心配置：归档与参数详解
  • 2.1. 开启归档（ARCHIVE）
    • 2.1.1. 控制归档的核心 INI 参数
    • 2.1.2. 归档策略文件 (dmarch.ini) 详解
  • 2.2. 备份与还原核心参数
    • 2.2.1. 备份（Backup）参数
    • 2.2.2. 还原（Restore）参数
• 3. 备份还原实战演练
  • 3.1. 场景一：联机表备份与还原（应对误操作）
  • 3.2. 场景二：联机库备份与脱机还原（全库灾难恢复）
  • 3.3. 场景三：结合归档日志的精确时间点恢复 (PITR)
  • 3.4. 场景四：脱机备份与还原

1. DM 备份与还原机制概述

1.1. 核心概念

DM 数据库的备份还原机制是保障数据安全的核心。其设计思路主要围绕两种状态和两种操作进行组合：

• 联机备份 (Online Backup)：在数据库正常运行、对外提供服务时执行的备份。这是生产环境中最常用的备份方式。DM 通过归档日志来保证联机备份数据的一致性。
• 脱机备份 (Offline Backup)：在数据库关闭后执行的备份。由于不存在数据变更，脱机备份天然就是一致的，但需要业务中断。
• 脱机还原 (Offline Restore)：所有数据库级别的还原（灾难恢复）都必须在数据库关闭状态下，通过 DMRMAN 工具进行。这是一个物理文件覆盖的过程。
• 联机还原 (Online Restore)：仅限于表对象的还原。当误删或误操作某张表时，可以在不中断服务的情况下，将其恢复到指定备份集的状态。

基本流程是：通过联机或脱机方式创建备份集，当灾难发生时，关闭数据库，使用 DMRMAN 工具将备份集恢复到指定位置，并通过归档日志进行精准恢复，最终使数据库恢复至可用状态。

1.2. 本文实践内容

本博客将通过具体的实操案例，覆盖以下核心场景：

• 联机备份还原：包括联机备份库、联机备份表，以及如何联机还原被误删除的表。
• 脱机备份还原：包括脱机备份整个数据库，以及如何进行完整的脱机还原。

更完整和深入的内容可以查阅官方的《DM 备份与还原手册》。

2. 核心配置：归档与参数详解

2.1. 开启归档（ARCHIVE）

归档是联机备份的基石。当数据库启用归档模式后，所有已提交事务的 REDO 日志会被保存为独立的归档日志文件。这使得数据库可以在任何时间点进行一致性备份，并且能够在灾难发生后恢复到任意时间点（PITR, Point-In-Time Recovery）。

1.控制归档的INI参数：

• ARCH_INI (dm.ini 参数)
  • 作用：归档功能的总开关。0 表示不启用（默认），1 表示启用。
  • 属性：动态参数，系统级。只有在MOUNT状态下才可修改。可通过系统过程 SP_SET_PARA_VALUE 进行修改，或 ALETR 修改。
  • 说明：当 ARCH_INI 设置为 1 后，数据库实例会根据 dmarch.ini 文件中的配置来执行具体的归档操作。
• DMARCH.INI (归档配置文件)
  • 作用：定义具体的归档策略，如归档类型、目标路径、文件大小等。
  • 路径：DM 数据库会根据 dm.ini 中 CONFIG_PATH 参数指定的路径去寻找 dmarch.ini 文件。CONFIG_PATH 默认为 SYSTEM_PATH（即数据库实例所在目录）。
  • 重要提示：如果开启了归档 (ARCH_INI=1)，但没有在指定目录下创建有效配置的 dmarch.ini 文件，数据库虽然可以正常启动，但无法执行任何归档动作。一旦联机日志写满，系统会因无法归档而挂起，导致业务中断。

2. 归档策略文件默认值（位于 dmarch.ini）

当将 ARCH_INI 设置为 1 启用归档后，数据库会读取 dmarch.ini 文件来获取具体的归档策略。该文件中各项参数的默认值如下（以本地归档为例）：

• ARCH_WAIT_APPLY
  • 默认值：配置为即时归档(TIMELY)时，缺省值为 1（事务一致模式）；配置为实时归档(REALTIME)时，缺省值为 0（高性能模式） 。
• ARCH_RESERVE_TIME
  • 默认值：0
  • 说明：单位为分钟。0 表示不自动删除归档 。
• ARCH_SEND_POLICY
  • 默认值：0
  • 说明：主库发送 REALTIME 归档的策略。0 表示发送后立即等待备库响应 。
• ARCH_FILE_SIZE (本地归档)
  • 默认值：1024
  • 说明：单个归档文件的大小，单位 MB（即 1G） 。
• ARCH_SPACE_LIMIT (本地归档)
  • 默认值：0
  • 说明：本地归档文件空间限制，单位 MB。0 表示无空间限制 。
• ARCH_FLUSH_BUF_SIZE (本地归档)
  • 默认值：2
  • 说明：归档合并刷盘缓存大小，单位 MB 。
• ARCH_HANG_FLAG (本地归档)
  • 默认值：1
  • 说明：本地归档写入失败时系统是否挂起。1 表示写入失败后挂起，反复尝试

相关SQL命令：

 -- 1. 查看当前归档状态
SELECT ARCH_MODE FROM V$DATABASE;

-- 2. 切换到配置模式 (也可在管理工具中修改)
ALTER DATABASE MOUNT;

-- 3. 开启归档模式
ALTER DATABASE ARCHIVELOG;

-- 4. 添加一个本地归档配置
-- 说明：可以联机使用SQL配置，也可以手动在指定目录下创建DMARCH.INI文件。
-- DM支持配置多个归档路径。在生产环境中，归档路径必须与数据文件位于不同的物理磁盘。
ALTER DATABASE ADD ARCHIVELOG 'DEST = /home/dmdba/dmdbms/data/DAMENG/arch, TYPE = local, FILE_SIZE = 1024, SPACE_LIMIT = 2048';

-- 5. 重新打开数据库，使配置生效
ALTER DATABASE OPEN;

2.2. 备份与还原核心参数

1. 备份（Backup）参数

1.1 INI 文件参数 (全局默认行为)

• BAK_PATH (在 dm.ini 中)
  • 作用： 指定默认的备份根目录。
  • 默认值： 如果不配置，DM会使用 SYSTEM_PATH 下的 bak 目录。
  • 建议手动配置。将其设置为一个与数据文件物理磁盘隔离的绝对路径，这是灾备的底线。
• bak_use_ap (在 dm.ini 中)
  • 作用： 选择备份执行策略，是使用dmap辅助进程还是dmserver主进程。
  • 默认值： 1 (使用 dmap 辅助进程)。
  • 保持默认值1可获得更高性能，支持并行、压缩、加密和第三方磁带备份。如果客户环境（如某些轻量级容器）没有dmap服务，才需要手动设为2，但这会丧失第三方磁带备份功能。
• ARCH_INI (在 dm.ini 中)
  • 作用： 启用归档配置，使其去读取 dmarch.ini 文件。
  • 默认值： 0 (不启用)。
  • 这是所有联机库/表空间备份的开关。必须手动将其设为 1，并正确配置 dmarch.ini，否则联机备份会失败。
• page_check (在 dm.ini 中)
  • 作用： 设置数据页的校验模式。
  • 默认值： 0 (不校验)。
  • 建议在生产库中设置为非0值（如1）。这样，备份进程在读取数据页时会进行校验，能提前发现磁盘“静默损坏”导致的数据页损坏问题。
• RLOG_GEN_FOR_HUGE (在 dm.ini 中)
  • 作用： 决定是否为HUGE表生成REDO日志。
  • 如需备份HUGE表的数据，这个参数应在建库时设置为1。

1.2命令参数 (SQL / DMRMAN)

这些参数定义了备份任务的具体内容。它们是**“一次性”的，并且优先级高于** .ini 中的默认设置。

• BACKUPSET '<path>'
  • 作用： 明确指定本次备份的存放路径和名称。
  • 如果你在命令中指定了 BACKUPSET，那么 dm.ini 中的 BAK_PATH 将被忽略。
• FULL / INCREMENT
  • 作用： 指定备份类型是“全量”还是“增量”。
  • 默认值： FULL (全量)。
  • 在备份策略脚本中，必须手动指定 INCREMENT 来执行增量备份。
• WITHOUT LOG (仅联机SQL)
  • 作用： 强制本次联机备份成为“非一致性备份”，即备份集中不包含REDO日志。
  • 默认值： 不指定 (即默认包含日志，是一致性备份)。
  • 仅在你追求备份速度，且100%确认外部归档完整时才使用。
• COMPRESSED [LEVEL <n>]
  • 作用： 对本次备份启用压缩，级别0-9。
  • 默认值： 不压缩。
• IDENTIFIED BY "<password>"
  • 作用： 对本次备份启用加密。
  • 默认值： 不加密。
• PARALLEL [<n>]
  • 作用： 对本次备份启用并行，极大提升大库备份速度。
  • 默认值： 不并行（串行）

2. 还原（Restore）参数

还原操作（尤其是DMRMAN）的参数大部分没有“默认值”，需要手动指定。

• RESTORE DATABASE '<ini_path>' 或 TO '<dir_path>'
  • 作用： (必须) 指定还原的目标。'<ini_path>' 是还原到已存在的库结构；TO '<dir_path>' 是还原到全新的目录。
  • 没有默认值。
• FROM BACKUPSET '<path>'
  • 作用： (必须) 指定还原的数据源（备份集路径）。
  • 没有默认值。
• MAPPED FILE '<path>'
  • 作用： (按需) 指定一个路径映射文件，用于解决源库和目标机磁盘路径不一致的问题。
  • 没有默认值。
• OVERWRITE
  • 作用： (高危) 允许 DMRMAN 覆盖目标路径下已存在的同名文件。
  • 默认值： 不指定（即默认不覆盖，如果文件已存在会报错）。
• REUSE DMINI
  • 作用： (按需) 还原时，使用备份集中的 .ini 参数来覆盖目标库的 .ini 参数（路径相关参数除外）。
  • 默认值： 不指定（即默认使用目标库自己的 .ini 参数）。
• RECOVER ... WITH ARCHIVEDIR '<path>'
  • 作用： (必须，如果是非一致性备份) 指定恢复时使用的外部归档日志目录。
  • 没有默认值。
• RECOVER ... UNTIL TIME '...' / UNTIL LSN ...
  • 作用： (按需) 执行按时间点恢复。
  • 默认值： 不指定（即默认恢复到所有归档的末尾）。
• RECOVER ... UPDATE DB_MAGIC
  • 作用： (必须) 恢复流程的最后一步，使数据库变为可启动状态。
  • 没有默认值。

3. 备份还原实战

以下案例均基于 DM 官方手册中的 BOOKSHOP 示例库。

3.1. 场景一：联机表备份与还原（应对误操作）

模拟研发人员误删一张重要表的常见场景，要求在不停止服务的情况下快速恢复。

步骤 1：联机备份表 (SQL)

-- 目标表：PRODUCTION.PRODUCT_REVIEW
-- 为备份集指定一个清晰的绝对路径和名称
BACKUP TABLE PRODUCTION.PRODUCT_REVIEW
BACKUPSET '/home/dmdba/dmdbms/data/DAMENG/bak/bookshop_review_bak';

步骤 2：模拟灾难 (DROP TABLE)

-- 研发的“手抖”操作
DROP TABLE PRODUCTION.PRODUCT_REVIEW;

-- 验证表已不存在，查询将报错：-2106:无效的表或视图名[PRODUCT_REVIEW]
SELECT COUNT(*) FROM PRODUCTION.PRODUCT_REVIEW;
  

步骤 3：联机还原表 (SQL)

由于表已被 DROP，DM 要求分两步进行还原，否则会报错。

-- 第1步：仅还原表结构
-- 使用 STRUCT 关键字重建表的定义
RESTORE TABLE STRUCT 
FROM BACKUPSET '/home/dmdba/dmdbms/data/DAMENG/bak/bookshop_review_bak';

-- 第2步：还原表数据
RESTORE TABLE PRODUCTION.PRODUCT_REVIEW
FROM BACKUPSET '/home/dmdba/dmdbms/data/DAMENG/bak/bookshop_review_bak';
  

步骤 4：验证恢复结果

-- 再次查询，应能返回正确的行数
SELECT COUNT(*) FROM PRODUCTION.PRODUCT_REVIEW;

-- 期望结果: 20
  

结论：PRODUCT_REVIEW 表已成功恢复，整个过程数据库服务未中断。

3.2. 场景二：联机库增量备份与脱机还原（全库灾难恢复）

模拟数据文件全部损坏的“全库灾难”场景。注意：数据库级别的还原 (RESTORE DATABASE) 只能脱机执行！

步骤 1：联机全量库备份 (SQL)

-- 创建一个一致性的全量备份（默认包含日志）
BACKUP DATABASE FULL 
BACKUPSET '/home/dmdba/dmdbms/data/DAMENG/bak/bookshop_full_bak';
  
[执行语句1]:
BACKUP DATABASE FULL 
BACKUPSET 'bookshop_full_bak';
执行成功, 执行耗时6秒 399毫秒. 执行号:1860
影响了0条记录

1条语句执行成功

步骤 2：第一次业务变更 (创建 test 模式)

CREATE SCHEMA test;
CREATE TABLE test.t1 (id int);
INSERT INTO test.t1 VALUES (1);
COMMIT;

步骤 3：联机增量库备份 (SQL)

-- 创建一个增量备份，它依赖于之前的全量备份
-- WITH BACKUPDIR 指明基备份的搜索路径
BACKUP DATABASE INCREMENT 
WITH BACKUPDIR '/home/dmdba/dmdbms/data/DAMENG/bak' 
BACKUPSET '/home/dmdba/dmdbms/data/DAMENG/bak/bookshop_inc1_bak';
  
[执行语句1]:
BACKUP DATABASE INCREMENT 
WITH BACKUPDIR '/home/dmdba/dmdbms/data/DAMENG/bak' 
BACKUPSET 'bookshop_inc1_bak';
执行成功, 执行耗时5秒 541毫秒. 执行号:1865
影响了0条记录

1条语句执行成功

步骤 4：第二次业务变更 (创建 test2 模式)

CREATE SCHEMA test2;
CREATE TABLE test2.t2 (id int);
INSERT INTO test2.t2 VALUES (1);
COMMIT;

步骤 5：模拟全库灾难

-- 模拟毁灭性操作，删除所有业务模式
DROP SCHEMA PERSON CASCADE;
DROP SCHEMA RESOURCES CASCADE;
DROP SCHEMA SALES CASCADE;
DROP SCHEMA PRODUCTION CASCADE;
DROP SCHEMA PURCHASING CASCADE;
DROP SCHEMA OTHER CASCADE;
DROP SCHEMA test CASCADE;
DROP SCHEMA test2 CASCADE;

-- 结果：8条语句执行成功
  

步骤 6：准备脱机还原

-- 立即关闭数据库
SHUTDOWN IMMEDIATE;
  

步骤 7：执行脱机还原 (DMRMAN)

打开服务器命令行，进入 DM 安装目录的 bin 文件夹下，执行标准的三步恢复流程。

# 启动 DMRMAN 工具
./dmrman

# 第 1 步: 还原 (Restore)
# 指向最新的增量备份集，DMRMAN 会智能地先应用基备份，再应用增量备份。
RMAN> RESTORE DATABASE '/home/dmdba/dmdbms/data/DAMENG/dm.ini' 
FROM BACKUPSET '/home/dmdba/dmdbms/data/DAMENG/bak/bookshop_inc1_bak' 
WITH BACKUPDIR '/home/dmdba/dmdbms/data/DAMENG/bak';

[Percent:100.00%][Speed:0.00M/s][Cost:00:00:03][Remaining:00:00:00]                       
restore successfully.
time used: 00:00:03.264


# 第 2 步: 恢复 (Recover)
# 应用备份集中包含的 REDO 日志，将数据库恢复到备份结束的那个时间点。
RMAN> RECOVER DATABASE '/home/dmdba/dmdbms/data/DAMENG/dm.ini' 
FROM BACKUPSET '/home/dmdba/dmdbms/data/DAMENG/bak/bookshop_inc1_bak';

[Percent:100.00%][Speed:8.85PKG/s][Cost:00:00:00][Remaining:00:00:00]                      recover successfully!
time used: 00:00:03.268         


# 第 3 步: 更新魔数 (Update DB_MAGIC)
# 这是最后一步，使数据库变为可启动状态。
RMAN> RECOVER DATABASE '/home/dmdba/dmdbms/data/DAMENG/dm.ini' UPDATE DB_MAGIC;

recover successfully!
time used: 00:00:01.282

# 退出 DMRMAN
RMAN> exit
  

步骤 8：验证恢复结果

启动数据库服务后，登录 DIsql 进行验证：

-- 1. 验证核心数据（成功）
SELECT COUNT(*) FROM PRODUCTION.PRODUCT_REVIEW;
-- 结果: 20

-- 2. 验证第一次变更（成功）
SELECT COUNT(*) FROM test.t1;
-- 结果: 1

-- 3. 验证第二次变更（失败）
SELECT COUNT(*) FROM test2.t2;
-- 结果: -2103: 无效的模式名[TEST2]

结论：test2 模式没有被恢复。因为灾难恢复是基于最后一次备份集 (inc1_bak) 进行的。test2 模式是在该备份之后创建的，其变更信息不存在于任何备份集中。要恢复这部分数据，必须借助归档日志。

3.3. 场景三：结合归档日志的精确时间点恢复 (PITR)

承接上文，我们的目标是恢复包含 test2 模式在内的所有数据，即恢复到 DROP 命令执行前的最后一刻。

步骤 1：重新还原数据库

数据库需保持关闭。由于上一步已启动过数据库，数据文件状态已改变，必须重新执行 RESTORE 并覆盖现有文件，设置带待恢复标志才能在RMAN中进行归档恢复。

# 启动 DMRMAN
./dmrman

# 使用 OVERWRITE 关键字覆盖现有文件，并重新设置“待恢复”标志
RMAN> RESTORE DATABASE '/home/dmdba/dmdbms/data/DAMENG/dm.ini' OVERWRITE 
FROM BACKUPSET '/home/dmdba/dmdbms/data/DAMENG/bak/bookshop_inc1_bak' 
WITH BACKUPDIR '/home/dmdba/dmdbms/data/DAMENG/bak';
  

步骤 2：执行时间点恢复 (Recover)

DROP 命令的执行时间是 2025-11-18 14:49:23。我们需要恢复到此时间点的前一秒。

# 使用 WITH ARCHIVEDIR 指定归档日志目录
# 使用 UNTIL TIME 指定恢复的精确时间点
RMAN> RECOVER DATABASE '/home/dmdba/dmdbms/data/DAMENG/dm.ini' 
WITH ARCHIVEDIR '/home/dmdba/dmdbms/data/DAMENG/arch' 
UNTIL TIME '2025-11-18 14:49:22';
  

步骤 3：更新魔数并完成

# 移除“待恢复”标志，使数据库可启动
RMAN> RECOVER DATABASE '/home/dmdba/dmdbms/data/DAMENG/dm.ini' UPDATE DB_MAGIC;

RMAN> exit

步骤 4：最终验证

启动数据库服务后，再次验证 test2 模式。

SELECT COUNT(*) FROM test2.t2;
-- 期望结果: 1 (test2 模式已成功恢复)
  

3.4. 场景四：脱机备份与还原

适用于计划内停机维护窗口的备份场景。

步骤 1：正常关闭数据库

-- 正常关闭会执行一个完整的检查点，确保数据文件完全一致
SHUTDOWN NORMAL;
  

步骤 2：执行脱机备份 (DMRMAN)

# 启动 DMRMAN
./dmrman

# 执行脱机备份
RMAN> BACKUP DATABASE '/home/dmdba/dmdbms/data/DAMENG/dm.ini' FULL 
BACKUPSET '/home/dmdba/dmdbms/data/DAMENG/bak/bookshop_offline_full';
  

说明：由于数据库已正常关闭，这个备份集是 100% 一致的，因此不包含 REDO 日志。

步骤 3：执行脱机还原 (DMRMAN)

模拟灾难后，进行还原。

# 启动 DMRMAN
./dmrman

# 第 1 步: 还原 (Restore)
RMAN> RESTORE DATABASE '/home/dmdba/dmdbms/data/DAMENG/dm.ini' OVERWRITE 
FROM BACKUPSET '/home/dmdba/dmdbms/data/DAMENG/bak/bookshop_offline_full';

# 第 2 步: 更新魔数 (Update DB_MAGIC)
# 注意：因为脱机备份是完全一致的，所以不需要 RECOVER日志步骤，直接更新魔数
RMAN> RECOVER DATABASE '/home/dmdba/dmdbms/data/DAMENG/dm.ini' UPDATE DB_MAGIC;

RMAN> exit
  

步骤 4：验证恢复结果

启动数据库服务并登录查询，数据已完全恢复到备份时的状态。