三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

达梦数据库归档日志管理：安全清理方法与最佳实践

发布时间：2026/8/16 13:05:50 三亩地 编程学习日记
达梦数据库归档日志管理：安全清理方法与最佳实践

1. 归档日志：达梦数据库的“时光机”与“空间杀手”

如果你正在管理达梦数据库，并且发现服务器的磁盘空间像夏天的冰淇淋一样融化得飞快，那么“归档日志”很可能就是那个“甜蜜的负担”。这玩意儿，既是数据库的守护神，也是系统管理员的“心头大患”。简单来说，归档日志就是数据库将写满的重做日志文件（Redo Log）复制一份，永久保存到另一个地方的过程。你可以把它想象成数据库操作的“全程录像带”。当数据库正常运行时，所有数据变更都会先记录在内存的重做日志缓冲区，然后刷到磁盘上的联机重做日志文件里。这些联机日志文件是循环使用的，写满最后一个就会覆盖第一个。如果没有归档，那么被覆盖的旧日志就永远丢失了。而开启了归档模式后，数据库会在覆盖旧日志前，先把它复制一份到指定的归档目录，形成归档日志。

为什么说它既是“时光机”又是“空间杀手”？

  • “时光机”功能（核心价值）：这是达梦数据库高可用和数据安全的基石。有了完整的归档日志链，结合定期的数据备份，你可以将数据库恢复到历史上的任意一个时间点。无论是误删了重要数据，还是遭遇了逻辑错误，都能通过备份+归档日志进行恢复。对于生产系统，尤其是金融、政务等对数据一致性要求极高的场景，开启归档模式是标配。
  • “空间杀手”属性（管理痛点）：归档日志一旦开启，就会持续产生，只增不减（除非手动或自动清理）。一个业务繁忙的数据库，一天产生几十GB甚至上百GB的归档日志是家常便饭。如果不加管理，归档目录所在的磁盘很快就会爆满，导致数据库无法继续归档而挂起，进而影响整个业务的运行。这就是为什么“清理归档日志”成为了DBA（数据库管理员）的一项关键且日常的运维工作。

从你提供的热词来看，“c盘满了怎么清理”、“清理c盘空间”是普遍痛点，而“达梦数据库清理归档日志”正是这个痛点在其专业领域的具体体现。处理这个问题，不能像清理普通电脑垃圾那样直接删除，需要一套安全、规范的方法。接下来，我将结合达梦数据库（以常见的DM8版本为例）的特性，详细拆解几种主流的清理方法、它们的适用场景，以及我踩过的一些坑。

2. 清理前的绝对前提：备份与恢复策略确认

在动任何一条删除归档日志的命令之前，有一个步骤比清理本身重要一百倍：确认你的备份与恢复策略。这是一个严肃的“外科手术”前谈话，你必须清楚知道你在做什么，以及后果是什么。

归档日志的唯一作用，就是用于数据恢复。删除归档日志，等同于丢弃了某个时间点之后的“恢复能力”。因此，清理决策必须建立在完整的备份策略之上。

2.1 理解备份周期与归档日志的依赖关系

假设你制定了如下备份策略：

  • 每周日凌晨2点：执行一次全量备份（备份整个数据库）。
  • 每天凌晨1点：执行一次增量备份（备份自上次备份以来变化的数据）。

那么，你的归档日志需要保留多久？答案取决于你的“恢复点目标（RPO）”。例如，你的业务要求最多允许丢失一天的数据。那么，你最坏的情况可能是周六晚上11点59分发生故障。为了恢复到那个时间点，你需要：

  1. 上周日的全量备份。
  2. 本周一到周六所有的增量备份。
  3. 上周日全量备份之后，到周六晚上11点59分之间产生的所有归档日志。

结论：在下次全量备份（即下周日凌晨）成功完成之前，上周日之后产生的所有归档日志都不能删除。因为它们是恢复本周数据所必需的。

2.2 实操检查清单（动手前必看）

注意：永远不要在磁盘空间即将用尽的紧急情况下，才第一次思考如何清理。这应该是一个周期性的、有计划的工作。

  1. 确认备份是否成功：通过达梦管理工具或命令行检查最近的备份任务是否都已完成且有效。如果最后一次全量备份失败，那么清理归档日志的风险极高。
    # 使用达梦的备份查询工具（示例） ./dmrman CTLSTMT="SHOW BACKUPSET '备份文件路径'"
  2. 明确可清理的时间点：找出你的备份集中，最旧的那个有效全量备份的结束时间。理论上，这个时间点之前的归档日志就可以被安全清理了。但为了保险，通常会多保留一段时间（例如多保留24小时或一个备份周期）。
  3. 告知相关人员：如果是在生产环境操作，务必通知应用和业务团队，告知维护窗口和潜在风险（尽管规范操作风险极低）。

我个人的惨痛教训是，曾经在自动化脚本中设置“删除7天前的归档”，但未监控备份任务状态。结果某次全量备份因存储问题静默失败，脚本依旧删除了旧归档。后来需要恢复数据时，发现归档链断裂，最终只能恢复到更早的时间点，造成了数据损失。从此以后，“备份成功”是清理操作的绝对前提。

3. 方法一：使用达梦内置工具dmarch进行清理

这是达梦数据库官方推荐的、最安全的标准方法。dmarch工具是达梦数据库自带的归档管理命令行工具，它能够智能地识别出哪些归档日志已经不再被任何备份所需要，然后安全地删除它们。

3.1dmarch工具的工作原理

dmarch不是简单地按时间删除文件。它的核心逻辑是基于备份集进行清理。你需要告诉它你的备份集在哪里，它会分析这些备份集，计算出所有备份集都不再依赖的、最旧的归档日志序列号（LSN），然后删除该序列号之前的所有归档日志文件。这确保了你的删除操作绝不会破坏备份恢复链。

3.2 详细操作步骤与命令解析

假设你的归档日志存放在/dm8/arch目录，你的备份文件存放在/dm8/bak目录。

步骤1：连接到数据库（可选，部分操作需要）有些dmarch命令需要指定数据库实例名和服务名。

# 切换到达梦安装目录的bin文件夹 cd /dm8/bin # 设置环境变量（如果尚未设置） export DM_HOME=/dm8 export PATH=$DM_HOME/bin:$PATH # 使用SYSDBA用户连接（这里以本地实例DMSERVER为例） ./disql SYSDBA/SYSDBA@localhost:5236

步骤2：使用dmarch执行清理更常见的做法是直接在操作系统命令行下使用dmarch。

cd /dm8/bin ./dmarch ARCHIVE_DELETE BACKUPSET ‘/dm8/bak/full_bak_20231001’ ARCH_PATH=‘/dm8/arch’

命令参数拆解：

  • ARCHIVE_DELETE: 指定动作为删除归档。
  • BACKUPSET ‘/dm8/bak/full_bak_20231001’: 指定一个备份集文件或目录的路径。dmarch会读取这个备份集的信息。关键点：你可以指定多个备份集，或者指定备份集的根目录，工具会扫描分析所有备份集。为了安全，我通常指定包含最近一次成功全备和所有后续增备的父目录。
    # 指定备份根目录，让工具自动分析所有备份集 ./dmarch ARCHIVE_DELETE BACKUPSET ‘/dm8/bak’ ARCH_PATH=‘/dm8/arch’
  • ARCH_PATH=‘/dm8/arch’: 指定归档日志的存放路径。

步骤3：验证清理结果命令执行后，dmarch会输出类似以下信息：

开始计算可删除的归档... 分析备份集 [/dm8/bak/full_bak_20231001]... 最旧需保留的归档序列号: 1250 归档路径 [/dm8/arch] 中，序列号小于 1250 的归档文件将被删除。 即将删除文件列表： /dm8/arch/ARCHIVE_LOCAL1_0x0000000000000001_0x0000000000000123.log ... 确认删除吗？(Y/N):

务必仔细阅读输出信息！确认它找到的“最旧需保留的归档序列号”是否符合你的预期（应该晚于你最旧的有效备份时间点）。输入Y确认后，清理才会执行。

3.3 使用dmarch的优缺点与避坑指南

优点：

  • 绝对安全：基于备份集分析，杜绝了误删关键归档的可能。
  • 官方推荐：与达梦数据库内核兼容性最好，无副作用。
  • 灵活：可以针对特定备份集进行清理。

缺点与坑点：

  • 依赖备份集：如果备份集文件损坏或被移动，dmarch将无法工作。因此，备份文件的保管和管理本身就要规范。
  • 可能无法释放预期空间：如果备份策略非常保守（比如全备周期很长），或者很久没有成功的全量备份，dmarch可能计算后发现几乎没有归档可以删除。这时你需要审视你的备份策略，或者考虑结合方法二。
  • 命令行操作：对不熟悉命令行的DBA有一定门槛，但这也是基本功。

我的经验：将dmarch命令写入运维脚本，与备份任务结合。例如，在每周全量备份脚本成功运行后，紧接着调用dmarch清理上周全备之前的归档。这样形成了“备份-清理”的自动化闭环，既安全又高效。

4. 方法二：通过SF_ARCHIVELOG_DELETE系统函数按时间清理

有些时候，你的需求就是“简单粗暴”地保留最近N天的归档日志，超出的自动删除。比如，磁盘空间实在紧张，或者你的备份策略本身就是定期全备+短时间归档保留（适用于允许较长恢复时间或可接受部分数据丢失的测试、开发环境）。达梦提供了系统函数SF_ARCHIVELOG_DELETE来满足这个需求。

4.1 函数原理与风险再警示

这个函数的功能是：删除指定时间点之前的所有归档日志文件。它不检查这些归档是否被任何备份需要。这是一个“按时间刀切”的操作，风险高于dmarch。使用它的前提是：你非常确定在你要删除的时间点之前，已经存在一个成功的全量备份，并且你未来的恢复最多只需要回到那个时间点。

4.2 在 DISQL 中执行函数清理

以下操作需要在达梦的交互式查询工具DISQL中执行。

-- 连接到数据库 ./disql SYSDBA/SYSDBA@localhost:5236 -- 查询当前时间，确认时区 SELECT SYSDATE; -- 执行清理，删除3天前的归档日志（假设归档路径为默认或已设置） -- 下面的时间‘2023-10-01 00:00:00’需要替换为你计算出的实际时间点 SPOOL ‘/tmp/arch_delete.log’ -- 可选，将操作日志输出到文件 SELECT SF_ARCHIVELOG_DELETE(‘2023-10-01 00:00:00’); SPOOL OFF

关键解释：

  • SF_ARCHIVELOG_DELETE(‘指定时间点’)：删除该时间点之前生成的所有归档日志。
  • 如何计算时间点？通常用数据库系统时间减去一个间隔。但达梦的SQL函数中直接进行日期加减不如其他数据库方便，一个稳妥的做法是在操作系统层面或应用层面计算好具体时间字符串，再传入函数。

更常见的做法是在脚本中动态计算时间：

#!/bin/bash # 计算7天前的时间，格式化为达梦接受的格式 DELETE_BEFORE_DATE=$(date -d “-7 days” “+%Y-%m-%d %H:%M:%S”) echo “计划删除 ${DELETE_BEFORE_DATE} 之前的归档日志” # 使用echo和管道将SQL命令传递给disql执行 echo “SELECT SF_ARCHIVELOG_DELETE(‘${DELETE_BEFORE_DATE}’);” | ./disql SYSDBA/SYSDBA@localhost:5236 > /tmp/delete_result.log

4.3 配置dmarch.ini实现自动清理（推荐）

手动执行函数还是麻烦，达梦支持通过配置文件实现归档日志的自动过期删除。这是最常用、最省心的自动清理方式。

步骤1：找到并编辑dmarch.ini文件该文件通常位于数据库实例的配置目录下（/dm8/data/DAMENG/，实例名可能不同）。

vi /dm8/data/DAMENG/dmarch.ini

步骤2：修改归档配置项在对应的归档目的地配置中，添加ARCH_SPACE_LIMIT和ARCH_FILE_SIZE参数来控制归档空间，但更直接的是使用ARCH_EXPIRE_TIME参数。

[ARCHIVE_LOCAL1] ARCH_TYPE = LOCAL ARCH_DEST = /dm8/arch ARCH_FILE_SIZE = 1024 # 单个归档文件大小，单位MB ARCH_SPACE_LIMIT = 102400 # 归档目录总空间限制，单位MB，0表示不限制 ARCH_EXPIRE_TIME = 168 # ！！！关键参数：归档文件过期时间，单位小时。这里设置7天（168小时） ARCH_HANG_FLAG = 1

参数详解：

  • ARCH_EXPIRE_TIME：这是实现自动清理的核心。系统会自动检查归档文件的生成时间，删除超过设定小时数的文件。例如设置为168，意味着归档日志只会保留最近7天。
  • ARCH_SPACE_LIMIT：当归档目录总大小超过此限制时，系统会尝试删除最旧的归档文件，直到空间低于限制。注意：这个参数与ARCH_EXPIRE_TIME可能同时生效，实际保留时间以更严格的为准。

步骤3：重载归档配置修改dmarch.ini后，数据库不会立即生效。需要调用系统过程进行重载。

-- 在DISQL中执行 SP_INIT_ARCH_CFG(1);

执行成功后，新的归档清理策略就会生效。数据库会在生成新归档或定期任务中自动清理过期文件。

4.4 按时间清理的适用场景与严重警告

适用场景：

  • 开发、测试环境，数据重要性较低。
  • 磁盘资源极其紧张，且备份周期较短的生产环境（需经过严格评估）。
  • 作为dmarch清理的补充，设置一个“最后防线”式的过期时间（比如30天），防止因备份集异常导致dmarch失效，最终磁盘被撑爆。

严重警告：

绝对不要在未验证备份有效性的生产环境，仅依赖ARCH_EXPIRE_TIME进行激进（如少于全备周期）的清理。我曾见过一个案例，DBA将过期时间设为3天，而全备周期是7天。在第4天发生数据损坏时，发现唯一可用的全量备份是7天前的，但3天前的归档已被删除，导致中间4天的数据永久丢失。这成为了一个严重的生产事故。

5. 方法三：操作系统层面手动清理（应急与高阶管理）

在某些极端紧急情况下（如归档目录已满100%，数据库因无法归档而挂起），或者你需要进行非常精细化的归档文件管理时，可能会直接操作操作系统层面的文件。这是一把需要极高技巧和风险意识的“手术刀”。

5.1 极端应急处理：当数据库因归档满而挂起

症状：应用报错数据库连接失败或操作超时，检查数据库日志发现大量“归档目录空间不足”的错误，数据库状态可能变为“挂起”。

应急步骤：

  1. 立即扩容或转移（首选）：如果能最快速度给归档目录所在磁盘扩容，或者挂载一个新磁盘并将归档目录软链接过去，这是最安全的方式，无需动数据库。
  2. 手动移动部分归档文件（次选）：如果无法立即扩容，可以临时手动将一部分最早的归档文件移动到其他有空间的磁盘上。
    # 1. 停止数据库（如果允许停机） systemctl stop DmServiceDMSERVER # 2. 在归档目录中，按时间排序，将一部分旧文件移走 cd /dm8/arch mkdir -p /tmp/old_arch_backup ls -lt ARCHIVE_LOCAL1*.log | tail -50 | awk ‘{print $9}’ | xargs -I {} mv {} /tmp/old_arch_backup/ # 3. 启动数据库 systemctl start DmServiceDMSERVER
    关键：移动后，务必记录下移动了哪些文件（序列号范围）。未来如果需要恢复，必须将这些文件放回原处。
  3. 使用dmarch紧急清理（如果备份集可用）：如果数据库还能勉强连接，且你有可用的备份集，立即使用dmarch进行清理（见方法一），这是最规范的做法。
  4. 风险最高的操作：直接删除（最后手段）：如果上述都不可行，且业务完全中断，在得到上级明确授权并告知业务方数据丢失风险后，可以考虑删除最旧的、确定不再需要的归档文件。
    # 强烈建议先重命名而非直接rm，给自己一个后悔的机会 cd /dm8/arch ls ARCHIVE_LOCAL1*.log | sort | head -100 | xargs -I {} mv {} {}.to_be_deleted # 观察数据库是否恢复，确认无误后，再删除.to_be_deleted文件 rm -f *.to_be_deleted

5.2 手动清理的精细化管理脚本示例

对于超大型数据库，你可能需要更复杂的归档管理策略，比如按表空间或按日期分目录存放归档，并编写脚本进行生命周期管理。

假设你按周分目录存放归档：/dm8/arch/2023_W40,/dm8/arch/2023_W41... 以下是一个简单的保留最近4周归档的清理脚本：

#!/bin/bash ARCH_BASE=“/dm8/arch” # 计算4周前的年份和周数 TARGET_WEEK=$(date -d “-4 weeks” “+%Y_W%W”) # 遍历归档根目录下的所有子目录 for dir in $(ls -d ${ARCH_BASE}/*/ 2>/dev/null); do dir_name=$(basename ${dir}) # 如果目录名是“年份_W周数”的格式，且比目标周旧 if [[ “${dir_name}” =~ ^[0-9]{4}_W[0-9]{2}$ ]]; then if [[ “${dir_name}” < “${TARGET_WEEK}” ]]; then echo “删除过期归档目录: ${dir}” # ！！！再次强调，删除前请确保这些归档对应的备份已存在且有效！ # rm -rf “${dir}” # 实际执行时请取消注释 fi fi done

5.3 手动操作的“铁律”

  1. 删前必备份：即使是删除，也先mv到其他位置观察，而非直接rm。
  2. 记录归档序列号：删除或移动文件时，务必记录文件的起始和结束序列号（通常包含在文件名中），并与备份时间点进行核对。
  3. 操作期间停库或只读：大规模移动或删除归档文件时，最好将数据库置于MOUNT状态或只读模式，防止产生新的归档导致文件列表变化。
  4. 测试！测试！测试！：所有手动脚本，必须在测试环境充分验证后再上生产。

6. 归档日志管理的进阶思考与最佳实践

清理只是亡羊补牢，优秀的管理者更注重未雨绸缪。结合多年的运维经验，我总结出以下关于达梦数据库归档日志管理的最佳实践，希望能帮你从根本上减少“清理”的烦恼和风险。

6.1 规划：给归档日志一个“专属大房子”

很多问题源于初期的规划不当。归档日志应该存放在哪里？

  • 独立磁盘或分区：绝对不要将归档目录放在操作系统盘（如C盘）或数据库数据文件所在的盘。它的快速增长会挤爆系统盘，影响OS运行。从你的热词“c盘满了怎么清理”就能看出这是常见误区。应该为归档日志单独挂载一块大容量、高IOPS的磁盘。
  • 充足的容量预估：根据业务峰值期的日增数据量，估算归档日志的产生速度。预留至少“全备周期 + RPO要求天数 + 至少30%”的冗余空间。例如，每周全备，RPO为1天，则至少预留8天的归档空间，再加30%缓冲。
  • 清晰的目录结构：使用子目录按时间（年-月、年-周）组织归档文件，便于查找、管理和清理。可以在dmarch.ini的ARCH_DEST中使用变量，但更简单的做法是在操作系统中用脚本或软链接管理。

6.2 监控：建立空间预警机制

不能等到磁盘100%满了才行动。建立多层预警：

  • 操作系统级监控：使用Zabbix、Prometheus等监控工具，对归档目录所在磁盘的空间使用率设置告警，例如>80%发警告，>90%发严重告警。
  • 数据库级监控：达梦数据库本身也提供系统视图查询归档信息。
    -- 查询归档日志信息 SELECT NAME, ARCH_LSN, CLSN, PATH, CREATE_TIME FROM V$ARCHIVED_LOG; -- 查询归档目的地状态 SELECT * FROM V$ARCH_DEST;
    可以定期运行脚本，计算归档日志的日增长量和预计充满时间。

6.3 整合：构建备份-清理-监控闭环

将清理动作嵌入到你的备份流程中，实现自动化、安全化的闭环管理。

一个理想的自动化脚本流程：

  1. 触发：每周日凌晨，定时任务启动。
  2. 备份：执行达梦数据库全量备份，备份到网络存储或对象存储。
  3. 验证：脚本检查备份作业是否成功完成（通过返回值或解析日志）。
  4. 清理：如果备份成功，调用dmarch工具，以本次备份集为基准，清理旧的归档日志。
    # 伪代码逻辑 if [ $BACKUP_EXIT_CODE -eq 0 ]; then ./dmarch ARCHIVE_DELETE BACKUPSET ‘/backup/latest_full’ ARCH_PATH=‘/dm8/arch’ LOG “归档清理完成。” else ALERT “全量备份失败！跳过本次归档清理，请立即检查！” # 可以触发更高级别的告警，甚至尝试清理更早的备份集以释放空间 fi
  5. 报告：脚本发送执行报告邮件，包含备份大小、耗时、清理释放空间等信息。

6.4 特殊场景：与第三方工具（如Navicat, DBeaver）的协作

从热词“navicat连接达梦数据库”、“dbeaver 达梦数据库”可以看出，很多开发者使用图形化工具管理达梦。这些工具通常不提供直接的归档日志管理功能。

  • Navicat：你需要通过Navicat的“命令列界面”或“服务器监控”功能，连接到数据库服务器执行上述的SQL命令（如SF_ARCHIVELOG_DELETE）或调用系统过程。
  • DBeaver：同样，在SQL编辑器中执行相关管理SQL。
  • 通用建议：对于生产环境的归档管理，强烈建议使用操作系统层面的脚本或作业调度工具（如cron, systemd timer, 或专业的运维平台）来实现。图形化工具更适合执行一次性的、临时的检查或操作。

归档日志管理，看似是简单的“删除文件”，实则贯穿了数据库运维的备份、恢复、容量规划、监控告警等多个核心领域。它考验的不仅是技术，更是流程规范和风险意识。最理想的境界，是让清理工作变成一种按部就班、无声无息的自动化流程，而你只需要偶尔看一眼监控图表和运行报告。记住，每一次对归档日志的删除，都应该是经过备份验证的、有据可依的“外科手术”，而不是一场慌不择路的“大扫除”。

编程学习 学习日记 实战经验
← 返回列表