达梦数据库未开启归档及备份作业的处理方法：配置实践与恢复策略

1. 问题背景与处理目标

数据库能够正常运行，并不代表已经具备完整的备份恢复能力。巡检时，如果发现数据库未开启归档，也未配置定时备份作业，就需要补充数据保护措施，并明确出现故障后可以恢复到什么时间、需要哪些文件，以及恢复过程需要多长时间。

本文结合 DM8 单实例测试环境，整理从状态检查、逻辑导出、开启归档，到首次物理全备、定时备份和验证的处理流程。同时说明每周全备、每日增备与归档保留之间的关系。

本文中的目录、归档大小、并行参数和保留时间用于测试与说明，尚未依据生产业务量完成容量评估。文中的容量计算和恢复场景均为假设示例，实际配置应结合业务要求和实测结果确定。

本文采用的测试配置如下：

项目	配置或说明
数据库	DM8 单实例测试环境
连接端口	5237
物理备份目录	/dm/backup/dmbak
本地归档目录	/dm/backup/dmarch
逻辑导出目录	/dm/backup/dexp
单个归档文件大小	2048MB
本地归档空间上限	10240MB，约 10GB
定时全备	每周六 22:00
定时增备	周日至周五，每天 22:00，采用累积增量备份
文件清理示例	删除 14 天前的数据库备份集；作业先禁用，核对恢复依赖后再启用

2. 先理解备份与归档各自解决什么问题

2.1 逻辑导出、物理备份与归档的区别

方式	主要用途	在本文中的作用
dexp 逻辑导出	导出对象定义和数据，配合 dimp 导入	配置变更前的补充保护手段
完全物理备份	保存数据库的全部有效数据页	提供恢复基线，并作为增备的基础
增量物理备份	保存相对于基备份发生变化的数据页	减少日常备份开销及恢复时需要重做的日志量
归档日志	保存历史 REDO 日志	支持联机备份的一致性恢复，以及向后续目标时间恢复

2.2 为什么采用每周全备、其余日期每日增备

全备和增备都应优先安排在业务量较小、数据库负载较低的时段，并与批处理、数据同步等任务错开，减少对正常业务的影响。

本文采用每周六 22:00 全备，其余六天每天 22:00 累积增备。全备用于建立恢复基线，每日增备用于减少日常备份开销和恢复时的日志重做量。上述时间属于测试配置，生产环境应结合业务规律和监控结果调整，并预留足够的备份窗口。。

2.3 本文为什么选择累积增量备份

差异增量备份可以以全备或增备为基础；累积增量备份只以全备为基础，保存自该全备以来发生变化的数据页。本文选择累积增备，主要是为了减少恢复时的备份依赖。例如，周六完成全备后，周日和周一的累积增备都以该全备为基础。恢复到周一增备状态，需要对应的周六全备和周一累积增备，无须再使用周日的增备。

这种方式的优势是恢复依赖较少、流程较简单，但距离全备时间越长，累积增备规模通常越大，因此需要定期生成新的全备。

我的理解是：每周全备建立恢复基线，每日累积增备减少恢复工作量，归档日志支持继续恢复到备份之后的目标时间。三者需要配合使用。

3. 操作前检查与准备

3.1 检查数据库版本、状态和归档情况

连接到数据库后执行：

-- 数据库版本
SELECT * FROM V$VERSION;

-- 实例和数据库状态
SELECT * FROM V$INSTANCE;
SELECT * FROM V$DATABASE;

-- 归档参数、归档配置和运行状态
SELECT * FROM V$DM_INI WHERE PARA_NAME = 'ARCH_INI';
SELECT * FROM V$DM_ARCH_INI;
SELECT * FROM V$ARCH_STATUS;

检查时，应同时确认归档开关、LOCAL 归档目标和归档运行状态，不能只看到一项配置就认定归档已正常工作。还需要确认归档路径存在、数据库服务账户可写，且存储空间足够。后文新增归档的 SQL 适用于尚未开启归档、且未配置对应 LOCAL 归档目标的场景。如果已经存在归档配置，应先核对并按需修改，避免重复添加。

3.2 检查业务活动并安排维护窗口

SELECT COUNT(*) AS ACTIVE_SESSION_COUNT
FROM V$SESSIONS
WHERE STATE = 'ACTIVE';

这个结果只能反映查询时刻的活动情况。即使结果为 1，也不能仅凭这个数值判定业务已经停止：当前查询本身可能计入活动会话，业务还可能稍后发起请求。

首次开启归档涉及切换到 MOUNT 状态，期间数据库不能正常提供业务对象的访问，因此应提前与业务方确认维护窗口，暂停应用访问并核对业务状态。后续的联机备份在归档模式和 OPEN 状态下进行，不需要每次停止业务，但仍应安排在负载较低的时段。

如需主动刷新检查点，可以执行：

SELECT CHECKPOINT(100);

说明：执行 checkpoint(100) 用于触发检查点，确保数据落盘；确认活跃会话数为 1，表示当前无业务压力，适合进行备份操作。

3.3 创建目录并核对存储

dmdba用户执行：

mkdir -p /dm/backup/dmbak
mkdir -p /dm/backup/dmarch
mkdir -p /dm/backup/dexp

ls -ld /dm/backup/dmbak /dm/backup/dmarch /dm/backup/dexp
df -h /dm/backup

确认目录权限、剩余容量及实际挂载位置。本文路径用于测试；不同目录并不代表位于不同物理存储上。生产环境应结合故障范围，把备份和必要日志保存到独立存储或其他服务器，避免源库与恢复材料因同一次存储故障同时丢失。

3.4 变更前进行全库逻辑导出

在达梦安装目录的 bin 下执行。将连接串中的 实际密码 替换为当前口令，文件名中的日期按实际操作日期修改：

./dexp USERID='SYSDBA/实际密码@localhost:5237' \
FILE=db_full_20261009.dmp \
LOG=db_full_20261009.log \
FULL=Y \
DIRECTORY=/dm/backup/dexp

FULL=Y 表示全库逻辑导出，LOG 指定导出过程的操作日志，这个 .log 文件也不同于数据库的 REDO 归档日志。逻辑导出可作为此次配置变更的补充保护措施。后续物理备份策略仍需要单独建立首次物理全备。

4. 开启本地归档

4.1 通过 SQL 配置归档

确认维护窗口及目录准备完成后，执行：

ALTER DATABASE MOUNT;

ALTER DATABASE ADD ARCHIVELOG
'DEST=/dm/backup/dmarch, TYPE=LOCAL, FILE_SIZE=2048, SPACE_LIMIT=10240';

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

每一步都应确认执行成功再继续。完成后，再次查询归档参数、配置和状态，并确认数据库已恢复到正常打开状态，配合业务方验证连接及关键功能。
也可以检查实例实际使用的 dm.ini 与 dmarch.ini。相关配置通常对应以下内容；这里用于理解和核对，已通过 SQL 配置后，无须再重复手工修改：

# dm.ini 中相关参数
ARCH_INI = 1

# dmarch.ini 中的本地归档配置示例
[ARCHIVE_LOCAL1]
ARCH_TYPE        = LOCAL
ARCH_DEST        = /dm/backup/dmarch
ARCH_FILE_SIZE   = 2048
ARCH_SPACE_LIMIT = 10240

完成配置后应尽快建立新的物理备份基线。

4.2 理解归档参数的含义

SQL 中的配置项	配置文件中的参数	本例取值及含义
FILE_SIZE	ARCH_FILE_SIZE	2048，单个归档文件大小，单位 MB
SPACE_LIMIT	ARCH_SPACE_LIMIT	10240，本地归档空间限制，单位 MB

达到本地归档空间限制时，系统会自动删除最早生成的归档文件。 SPACE_LIMIT=10240 表示容量限制。设置为 0 表示不限制归档空间，此时仍需对实际磁盘空间进行监控。

FILE_SIZE 主要影响归档文件的分卷粒度。较大文件通常减少文件数量，较小文件便于按更细粒度管理；这个参数本身不能保证日志保留时长，也不能单独决定 RPO。本文保留 2048MB 的测试取值，生产环境应结合归档增长、文件管理和归档备份方式确定。

5. 根据业务量设计归档空间与保留规则

5.1 容量规划示例

当本地目录承担所需日志的完整保留时，可以按下面的思路初步估算：

归档容量预算 ≈ 规划日归档产生量 × 所需日志保留天数 × 余量系数

这里的“所需日志保留天数”要结合恢复起点确定。如果要求恢复到最近 14 天内的指定时间，而窗口起点需要依赖更早的每周全备，则可能还要向前覆盖一个全备周期。

例如，假设日归档产出为 2048MB，按 21 天日志和 1.3 的余量系数做保守规划：

2048 × 21 × 1.3 = 55910.4MB

在这个假设条件下，可以将 61440MB，约 60GB，作为候选归档上限，并继续核对磁盘容量和高峰增长。21 天和 1.3 都是此例的规划假设，不是固定配置标准。如果保留了更接近窗口起点的有效增备，可以依据备份元数据和实际日志恢复起点进一步调整所需范围。

6. 建立首次物理全备并配置定时作业

6.1 首次部署先建立物理备份基线

开启归档并确认数据库处于 OPEN 状态后，先进行一次物理全备，避免等待下一次周六调度：

BACKUP DATABASE FULL
BACKUPSET '/dm/backup/dmbak/init_full_20261009';

备份集目录名按实际日期修改，每次执行使用新的目录名。确认这次全备完成并通过校验后，再进行增备测试。

6.2 检查并初始化作业系统

先检查作业系统表是否存在：

SELECT OWNER, TABLE_NAME
FROM DBA_TABLES
WHERE OWNER = 'SYSJOB'
  AND TABLE_NAME = 'SYSJOBS';

如果尚未建立作业环境，执行：

CALL SP_INIT_JOB_SYS(1);

如果已存在作业环境，应检查现有作业及名称，避免重复创建。这里使用的是创建作业环境的参数 1；参数 0 用于删除作业环境，不属于本次配置流程。

6.3 每周六 22:00 完全备份

CALL SP_CREATE_JOB('bakfull', 1, 0, '', 0, 0, '', 0, '每周六完全备份');
CALL SP_JOB_CONFIG_START('bakfull');
CALL SP_ADD_JOB_STEP(
    'bakfull', 'bak1', 6,
    '01020000/dm/backup/dmbak',
    1, 1, 0, 0, NULL, 0
);
CALL SP_ADD_JOB_SCHEDULE(
    'bakfull', 'std1', 1, 2, 1, 64, 0,
    '22:00:00', NULL, CURDATE, NULL, '每周六22点全备'
);
CALL SP_JOB_CONFIG_COMMIT('bakfull');

调度中的 TYPE=2 表示按周执行，FREQ_INTERVAL=1 表示每周，FREQ_SUB_INTERVAL=64 表示周六，分钟间隔为 0 表示选定日期只执行一次。

6.4 周日至周五 22:00 累积增量备份

CALL SP_CREATE_JOB('bakincr', 1, 0, '', 0, 0, '', 0, '每日累积增量备份');
CALL SP_JOB_CONFIG_START('bakincr');
CALL SP_ADD_JOB_STEP(
    'bakincr', 'bak2', 6,
    '41010000/dm/backup/dmbak|/dm/backup/dmbak',
    1, 1, 0, 0, NULL, 0
);
CALL SP_ADD_JOB_SCHEDULE(
    'bakincr', 'std2', 1, 2, 1, 63, 0,
    '22:00:00', NULL, CURDATE, NULL, '周日至周五22点累积增备'
);
CALL SP_JOB_CONFIG_COMMIT('bakincr');

按周调度的位掩码从最低位起依次对应周日、周一至周六：

日期	周日	周一	周二	周三	周四	周五	周六
对应数值	1	2	4	8	16	32	64

因此，63=1+2+4+8+16+32，表示周日至周五，恰好与周六全备互补。如果改成周日全备、周一至周六增备，则分别使用 1 和 126。

两个备份作业的成功和失败动作都设为 1，表示执行结束后记录结果，方便查看备份是否成功。配置好定时作业后，还要检查实际执行情况。备份失败时，应及时排查原因并补做。如果本周全备失败，还要确认后续增备是否仍以旧全备为基础，并关注增备文件是否变大、备份耗时是否变长。

6.5 理解备份命令编码

作业步骤类型 6 使用 V2.0 备份还原方式。本例命令前八位中的关键含义如下：

位置	全备 01020000	增备 41010000	含义
第 1 位	0	4	完全备份 / 累积增量备份；1 才表示差异增量
第 2 位	1	1	1 级压缩
第 3 位	0	0	备份日志；1 表示不备份日志
第 4 位	2	1	全备并行数为 2；增备采用默认并行数 4

增备路径中，| 左侧用于搜索基备份，右侧为增备输出目录。实际采用了哪个基备份，应通过备份集元数据确认。第 3 位的 0 用于保留恢复备份一致性所需的日志，并不表示每天的全部历史归档都已保存进数据库备份集。并行数也需要结合 CPU、存储吞吐和业务负载调整，本文沿用测试配置。

7. 配置备份清理示例，并保护恢复依赖

7.1 “删除 14 天前文件”的测试作业

以下作业演示每日 23:30 删除 14 天前的数据库备份集。因为它尚未根据生产恢复窗口完成依赖评估，创建时将作业设为禁用：

CALL SP_CREATE_JOB('delbak', 0, 0, '', 0, 0, '', 0, '测试清理规则，核对后启用');
CALL SP_JOB_CONFIG_START('delbak');
CALL SP_ADD_JOB_STEP(
    'delbak', 'del_step', 0,
    'SELECT SF_BAKSET_BACKUP_DIR_ADD(''DISK'', ''/dm/backup/dmbak'');
     CALL SP_DB_BAKSET_REMOVE_BATCH(''DISK'', SYSDATE - 14);',
    1, 1, 0, 0, NULL, 0
);
CALL SP_ADD_JOB_SCHEDULE(
    'delbak', 'del01', 1, 1, 1, 0, 0,
    '23:30:00', NULL, CURDATE, NULL, '每日检查清理'
);
CALL SP_JOB_CONFIG_COMMIT('delbak');

SF_BAKSET_BACKUP_DIR_ADD 添加待处理的备份搜索目录；SP_DB_BAKSET_REMOVE_BATCH 按截止时间批量删除数据库备份集。它不等同于清理原始归档目录，也不会按这个规则自动清理 dexp 导出文件。

7.2 为什么保留 14 天文件不等于可恢复最近 14 天

能否恢复数据，要看所需的全备、增备和归档日志是否齐全，不能只看文件保存了多少天。

例如，假设当前是周三，需要恢复到两周前的周三，就可能用到那个周三之前的周六全备。这份全备虽然已经超过 14 天，但仍然有用。如果把它删除，依赖它的增备也就无法正常用于恢复。

因此，清理时要注意两点：

• 按恢复需要保留文件。先确定需要恢复到多早，再保留对应的全备、增备和所需归档日志。实际需要保留的文件，可能超过 14 天。
• 清理前检查备份结果和依赖。23:30 只是计划清理时间，不代表当天备份已经成功。如果备份失败，应检查旧备份是否仍然需要，避免误删。

最后，要通过恢复测试确认保留下来的文件确实能够完成恢复。

8. 检查配置、执行结果与备份有效性

8.1 检查作业及调度

SELECT ID, NAME, ENABLE, VALID
FROM SYSJOB.SYSJOBS
WHERE UPPER(NAME) IN ('BAKFULL', 'BAKINCR', 'DELBAK');

SELECT J.NAME AS JOB_NAME,
       S.NAME AS SCHEDULE_NAME,
       S.ENABLE,
       S.TYPE,
       S.FREQ_INTERVAL,
       S.FREQ_SUB_INTERVAL,
       S.STARTTIME
FROM SYSJOB.SYSJOBS J
JOIN SYSJOB.SYSJOBSCHEDULES S ON S.JOBID = J.ID
WHERE UPPER(J.NAME) IN ('BAKFULL', 'BAKINCR', 'DELBAK');

8.2 检查实际执行历史

SELECT * FROM SYSJOB.SYSJOBHISTORIES2;
SELECT * FROM SYSJOB.SYSSTEPHISTORIES2;

作业已创建或启用，不代表备份已经成功。还要查看执行历史中的运行时间和错误信息，检查是否生成了备份集，以及校验是否通过。
首次配置后，建议按以下顺序验证：

1. 先手动执行全备。确认全备成功、备份集校验通过后，再进行下一步。
2. 再手动执行增备。检查执行记录、生成的备份集和校验结果，确认增备正常完成。
3. 检查定时调度。观察作业是否在设定时间自动执行，并确认备份成功。

手动执行用于验证备份能否完成，定时执行用于验证调度是否生效，两项都需要检查。

8.3 检查目录与归档状态

ls -lh /dm/backup/dmarch
ls -lh /dm/backup/dmbak
du -sh /dm/backup/dmarch /dm/backup/dmbak /dm/backup/dexp
df -h /dm/backup

结合 V$DM_ARCH_INI 和 V$ARCH_STATUS 确认归档配置及运行情况，并在正常业务或测试写入后观察日志变化。目录中存在文件不代表所有所需日志都完整，恢复可用性还应结合日志范围和演练验证。

8.4 校验备份集并确认基备份

以下路径需要替换为本次生成的具体备份集目录，而不是只填写 /dm/backup/dmbak 这个父目录：

SELECT SF_BAKSET_CHECK(
    'DISK',
    '/dm/backup/dmbak/实际备份集目录'
);

该函数用于备份集校验，执行失败时应检查原因。校验通过仍不能代替实际还原、恢复和业务数据核对。

还可以在 DMRMAN 中查看增备及其依赖。进入安装目录的 bin 后启动：

./dmrman

在 DMRMAN 提示符下执行，替换实际增备目录：

SHOW BACKUPSET '/dm/backup/dmbak/实际增备目录'
RECURSIVE WITH BACKUPDIR '/dm/backup/dmbak';

重点核对备份类型、基备份、日志相关信息及备份时间，确认备份链所需材料能够找到。

9. 全备、累积增备与归档如何共同恢复

假设本周六 22:30 完成全备，周二 22:10 完成最近一次累积增备，周三 10:00 发生故障：

可取得的恢复材料	可以据此评估的恢复范围
对应全备和周二累积增备完整	可恢复到所选增备的备份状态
同时有继续恢复至周三 10:00 所需的完整日志	可尝试恢复到该目标时间，并验证结果
周二增备之后所需日志缺失	无法仅凭上述备份保证恢复到周三 10:00
累积增备所依赖的全备缺失	不能只靠该累积增备完成恢复

备份完成时间要以备份集中的实际记录为准。22:00 是作业计划启动的时间，不能直接当作备份结束时间。每日增备主要用于减少恢复时需要重做的日志量。最终能恢复到哪个时间，要看日志是否完整、可用，以及故障影响了哪些文件。日志写入本地归档、复制到其他服务器也可能存在延迟。因此，不能仅凭每日增备，就认定最多丢失一天的数据；也不能仅凭开启归档，就保证零数据丢失。恢复到误操作之前，应先选择目标时间之前的可用备份，再利用完整日志恢复到指定时间。如果备份已经包含误操作后的数据，就不能靠日志重做退回到操作之前，因为日志重做只能向前推进，不能倒退。

10. 对本次配置方案的理解

本次配置主要是为数据库补齐归档和定时备份。我的理解是，配置完成后，还要确认备份实际执行成功、恢复所需的文件齐全。因此，开启归档后应及时完成首次全备，并检查后续备份的执行记录、生成的备份集和校验结果。

本文采用每周全备、每日累积增备，并配合归档日志：全备建立恢复基线，累积增备减少恢复所需的备份依赖和日志重做量，归档日志支持继续恢复到指定时间。如果本周全备失败，就要检查后续增备实际依赖哪次全备，同时关注增备大小和耗时，并保留仍有恢复用途的旧备份。归档上限和 14 天清理规则只是测试示例，需要根据实际业务调整。例如，业务写入量较大时，归档空间可能很快达到上限，触发旧日志删除；如果只按文件年龄清理，也可能删掉恢复窗口内仍需使用的全备。因此，容量和清理规则应结合实际日志产生量、备份依赖和恢复要求确定。