1. 项目概述归档日志为何非清不可做数据库运维的同行尤其是负责达梦数据库DM Database的朋友估计都遇到过磁盘空间告急的窘境。很多时候C盘或者数据盘突然“飘红”一查原因十有八九是归档日志文件Archive Log把空间给占满了。这可不是个小问题归档日志一旦写满磁盘数据库会直接挂起所有业务操作都会中断影响可大可小。所以“清理归档日志”这个操作看似简单实则是每个达梦DBA必须掌握的核心生存技能。归档日志是数据库恢复的“时光机”。达梦数据库在开启归档模式后会把重做日志文件Redo Log在切换时完整地保存下来形成归档日志。它的核心价值在于数据安全当发生介质故障比如磁盘损坏时你可以利用数据备份和这一连串的归档日志将数据库恢复到故障前的任意时间点实现零数据丢失。但是这个“安全卫士”有个特点它只生产不自动消费。只要数据库在运行归档日志就会源源不断地生成日积月累体积非常可观。因此清理归档日志的本质是在保障数据可恢复性的前提下对过期的、不再需要的日志文件进行安全移除释放宝贵的磁盘空间。这绝不是简单的rm -rf而是一个需要综合考虑备份策略、恢复窗口期RPO和存储管理的系统性操作。处理不当轻则浪费存储重则可能破坏恢复链导致关键时刻无法恢复数据。接下来我就结合多年的实战经验把达梦数据库清理归档日志的方法、背后的原理以及那些容易踩坑的细节给大家掰开揉碎了讲清楚。2. 核心思路与清理策略设计清理归档日志不能蛮干得先有策略。策略的核心围绕一个问题展开哪些日志可以删答案取决于你的数据备份和恢复计划。2.1 基于备份的清理最安全、最推荐的主流方法这是最经典、最安全的清理思路。它的逻辑非常直接一份归档日志在其所涵盖的所有数据变化都已经被至少一次有效的全量备份或增量备份所包含之后它就完成了历史使命可以被安全清理。为什么想象一下时间线你在T1时间点做了一个全量备份。从T1到T2时间段内数据库产生的所有变更都记录在归档日志里。如果在T2时间点又做了一个新的全量或增量备份那么这个新备份本身就包含了截至T2的所有数据状态。此时T1到T2之间的归档日志其“恢复价值”已经转移并固化到了T2的备份集中。即使删除这些日志你依然可以用T1的备份 T2的备份将数据库恢复到T2时刻。达梦数据库提供了强大的内置命令来支持这种策略即BACKUP ARCHIVELOG命令。这个命令的精髓在于它能在备份归档日志的同时自动删除那些已被备份的日志文件一举两得。策略制定的关键考量点恢复窗口目标RPO你的业务能容忍丢失多长时间的数据是一天还是一小时这决定了你需要保留多久的归档日志。例如RPO为24小时那么你至少需要保留最近24小时内产生的所有归档日志即使它们已被备份。备份频率全量备份和增量备份的频率直接影响归档日志的累积速度。备份越频繁单个备份周期内产生的日志量越少清理也就越及时。存储分层可以考虑将近期如一周内的归档日志放在高速磁盘如SSD上供快速恢复使用将更早的、已备份的日志迁移到廉价的大容量存储如对象存储或磁带库上长期归档然后从磁盘删除。这需要额外的脚本和工具支持。2.2 基于时间或序列的清理风险较高的应急手段在某些特定场景下比如磁盘空间即将耗尽急需释放空间或者测试环境不需要长期恢复能力时可能会采用更激进的策略直接删除指定时间点之前或指定序列号之前的归档日志。基于时间删除2023-10-01 00:00:00之前的所有归档日志。基于日志序列号LSN删除序列号小于12345的归档日志。警告这是一种破坏性操作直接删除会切断恢复链。如果你只有一份一个月前的全量备份然后删除了这一个月以来所有的归档日志那么你的数据库最多只能恢复到一个月前的状态这期间的所有数据变更将永久丢失。在生产环境中除非你完全清楚后果并有相应预案如已有更新的备份否则绝对不要轻易使用。这种方法通常作为空间紧急释放的“消防栓”但绝不是日常维护的“水龙头”。执行前务必确认后续的备份是否成功并且确保业务方了解潜在的数据丢失风险。2.3 工具选择命令行、管理工具与自制脚本达梦提供了多种操作入口disql命令行工具DBA的“手术刀”功能最全、最灵活适合编写自动化脚本。我们后续的实操将以disql命令为主。DM管理工具Manager图形化界面操作直观适合手动执行或初学者查看状态。在“归档管理”页面可以进行备份和删除操作。自制Shell/Python脚本结合操作系统命令和disql实现复杂的逻辑判断、日志清理、空间监控和报警是专业运维的终极形态。3. 实操准备与环境确认在动手清理之前必须做好以下准备工作摸清家底避免误操作。3.1 确认归档模式与归档状态首先连上数据库看看归档是不是真的开了以及当前状态如何。-- 使用disql连接数据库例如./disql SYSDBA/SYSDBAlocalhost:5236 SQL SELECT ARCH_MODE, ARCH_STATUS FROM V$DATABASE;如果ARCH_MODE是Y说明数据库处于归档模式。ARCH_STATUS显示当前归档状态如START表示正在归档。3.2 定位归档日志目录与空间占用知道日志在哪占了多大地方是清理的前提。SQL SELECT ARCH_DEST, ARCH_FILE_SIZE FROM V$ARCHIVED_LOG; -- 或者查看动态视图V$DM_ARCH_INI SQL SELECT PARA_NAME, PARA_VALUE FROM V$DM_ARCH_INI WHERE PARA_NAMEARCH_DEST;ARCH_DEST就是归档日志的存放路径。记下这个路径然后切换到操作系统层面去查看实际占用。# Linux/Unix示例 df -h # 查看磁盘整体使用情况 du -sh /dm8/arch_dest/* # 查看归档目录总大小 ls -lh /dm8/arch_dest/ | head -20 # 查看具体文件列表实操心得我习惯在操作系统层面用du和ls命令再确认一遍因为数据库视图显示的可能只是逻辑信息。有时会遇到视图显示有文件但磁盘上实际已被误删的情况会导致恢复时报错这时对比查看就非常必要。3.3 检查备份情况与恢复链完整性这是决定“哪些能删”的黄金标准。你需要知道最新的有效备份点在哪里。SQL SELECT BACKUP_TYPE, START_TIME, END_TIME, FILE_PATH FROM V$BACKUPSET ORDER BY START_TIME DESC;查看最近的备份记录尤其是全量备份。理论上在这个备份START_TIME之前产生的、并且已经被成功备份过的归档日志才是潜在的清理对象。更严谨的做法是使用BACKUP ARCHIVELOG ... DELETE INPUT命令让数据库自己来判断。4. 核心方法详解与步骤实操下面我们进入最关键的实操环节分别演示两种主要清理方法的具体命令和步骤。4.1 方法一备份后清理BACKUP ARCHIVELOG ... DELETE INPUT这是官方推荐、最安全的标准流程。它的原子操作是备份指定范围内的归档日志到备份集然后自动删除原日志文件。步骤1执行备份并删除-- 备份所有可用的归档日志并在备份成功后删除原文件 BACKUP ARCHIVELOG ALL DELETE INPUT TO BACKUP_DIR ‘/dm8/backup/arch_bak’;ARCHIVELOG ALL: 备份所有未被备份过的归档日志。DELETE INPUT: 关键参数表示备份成功后自动删除源归档日志文件。TO BACKUP_DIR ‘/dm8/backup/arch_bak’: 指定备份集的存放目录。更精细的控制-- 备份从序列号1000到2000的归档日志并删除 BACKUP ARCHIVELOG LSN BETWEEN 1000 AND 2000 DELETE INPUT TO ...; -- 备份2023年10月1日之前的归档日志并删除 BACKUP ARCHIVELOG BEFORE ‘2023-10-01 00:00:00’ DELETE INPUT TO ...;步骤2验证备份集与清理结果执行完成后务必进行双重验证验证备份集检查备份目录下是否生成了新的备份文件.bak。ls -l /dm8/backup/arch_bak/验证源文件再次查看归档目录确认对应的.arc文件是否已被删除。ls -l /dm8/arch_dest/数据库视图验证查询备份视图和归档日志视图确认记录已更新。SQL SELECT * FROM V$BACKUPSET WHERE BACKUP_TYPE‘ARCHIVELOG’ ORDER BY START_TIME DESC; SQL SELECT DEST_ID, NAME, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG WHERE DELETED‘YES’; -- 查看已被标记为删除的日志注意事项空间预估BACKUP ARCHIVELOG操作本身会在备份目录产生备份集文件需要确保目标磁盘有足够空间否则会失败。通常备份集会比原日志文件略大一点包含元数据。备份集管理备份出来的归档日志备份集本身也是需要管理的。长期积累也会占用空间。你需要为备份集制定独立的保留策略定期清理过期的备份集。这可以通过REMOVE BACKUPSET命令或图形化工具完成。DELETE INPUT 的威力这个参数非常高效但意味着操作不可逆。执行前请确保备份命令语法正确备份目录有效。4.2 方法二直接删除手动或脚本如前所述此方法风险高仅用于特定场景。核心原则先备份再删除或者确认删除范围绝对安全。步骤1确定删除范围至关重要通过查询精确找出你想要删除的日志文件。-- 查看所有归档日志信息重点关注序列号(FIRST_CHANGE#)、时间戳(FIRST_TIME)和路径(NAME) SQL SELECT DEST_ID, NAME, FIRST_TIME, NEXT_TIME, FIRST_CHANGE#, NEXT_CHANGE# FROM V$ARCHIVED_LOG ORDER BY FIRST_TIME; -- 例如找出2023年9月1日前所有的归档日志 SQL SELECT NAME FROM V$ARCHIVED_LOG WHERE FIRST_TIME TO_DATE(‘2023-09-01’, ‘YYYY-MM-DD’) AND DELETED‘NO’;将查询出的NAME文件完整路径记录下来这就是待删除列表。步骤2执行删除操作删除操作不在SQL内完成而是需要在操作系统层面进行。# Linux/Unix 示例假设上一步查出的一个文件是 /dm8/arch_dest/ARCHIVE_LOCAL1_20230901_123456.arc rm /dm8/arch_dest/ARCHIVE_LOCAL1_20230901_123456.arc # 更常见的做法是写一个脚本基于时间点批量删除 find /dm8/arch_dest -name “*.arc” -mtime 30 -exec rm {} \; # 删除30天前的归档文件谨慎步骤3更新数据库元数据关键步骤仅仅在操作系统上删除文件是不够的数据库的控制文件里还记录着这些日志的信息。需要用ALTER DATABASE命令来通知数据库这些文件已经没了。SQL ALTER DATABASE ARCHIVELOG DELETE UNTIL TIME ‘2023-09-01 00:00:00’; -- 删除指定时间点之前的日志记录 -- 或者 SQL ALTER DATABASE ARCHIVELOG DELETE SEQUENCE 12345; -- 删除指定序列号之前的日志记录这个命令并不会真的去删文件它只是更新数据库内部视图如V$ARCHIVED_LOG将对应日志标记为DELETED‘YES’。所以正确的顺序是先物理删除文件再执行此命令更新元数据。踩坑实录我曾经遇到过只执行了ALTER DATABASE ... DELETE但忘了物理删除文件的情况。这导致磁盘空间没释放但数据库认为日志已删除。后来做恢复测试时因为物理文件还在但元数据已标记删除恢复过程报了错排查了半天。所以顺序一定不能乱rm-ALTER DATABASE。4.3 自动化清理脚本示例Linux Shell对于生产环境手动操作既容易出错也无法持续。下面分享一个简单的自动化脚本框架可以集成到crontab中定时执行。#!/bin/bash # 文件名dm_archive_cleanup.sh # 功能自动备份并清理达梦数据库归档日志 # 使用前需配置以下变量 # 配置区 DB_USER“SYSDBA” DB_PASSWORD“SYSDBA” DB_PORT“5236” ARCH_DEST“/dm8/arch_dest” # 归档目录 BACKUP_BASE_DIR“/dm8/backup/arch” # 备份根目录 RETENTION_DAYS7 # 备份集保留天数 LOG_FILE“/var/log/dm_archive_clean.log” # TIMESTAMP$(date %Y%m%d_%H%M%S) BACKUP_DIR“${BACKUP_BASE_DIR}/${TIMESTAMP}” mkdir -p ${BACKUP_DIR} echo “$(date) — 开始归档日志清理任务” ${LOG_FILE} # 1. 使用disql执行备份并删除 ./disql ${DB_USER}/${DB_PASSWORD}localhost:${DB_PORT} EOF 21 | tee -a ${LOG_FILE} BACKUP ARCHIVELOG ALL DELETE INPUT TO BACKUP_DIR ‘${BACKUP_DIR}’; exit; EOF if [ $? -eq 0 ]; then echo “$(date) — 备份并清理命令执行成功。” ${LOG_FILE} else echo “$(date) — 错误备份清理命令执行失败” ${LOG_FILE} exit 1 fi # 2. 清理过期的备份集按保留策略 find ${BACKUP_BASE_DIR} -maxdepth 1 -type d -mtime ${RETENTION_DAYS} -exec rm -rf {} \; 2/dev/null echo “$(date) — 已清理超过${RETENTION_DAYS}天的备份集目录。” ${LOG_FILE} # 3. 检查归档目录磁盘使用率可选告警 ARCH_USAGE$(df -h ${ARCH_DEST} | awk ‘NR2 {print $5}’ | cut -d% -f1) if [ ${ARCH_USAGE} -gt 80 ]; then echo “$(date) — 警告归档目录 ${ARCH_DEST} 磁盘使用率 ${ARCH_USAGE}%” ${LOG_FILE} # 这里可以集成邮件或钉钉告警 fi echo “$(date) — 归档日志清理任务完成。” ${LOG_FILE}脚本使用要点将./disql路径替换为你环境中disql工具的实际路径。为脚本添加执行权限chmod x dm_archive_cleanup.sh。在crontab中添加定时任务例如每天凌晨2点执行0 2 * * * /path/to/dm_archive_cleanup.sh。务必先在测试环境充分验证脚本逻辑特别是rm -rf删除备份集的部分。5. 常见问题排查与实战技巧即使按照步骤操作也可能会遇到各种问题。这里汇总几个典型场景和解决方法。5.1 问题排查速查表问题现象可能原因排查步骤与解决方案BACKUP ARCHIVELOG执行失败报错“磁盘空间不足”备份目标目录空间不足。1. 使用df -h检查备份目录所在磁盘空间。2. 清理目标目录无用文件或更换更大磁盘。3. 临时可指定其他有空间的目录进行备份。归档目录磁盘使用率仍很高但V$ARCHIVED_LOG显示很多DELETED‘YES’操作系统层面文件未删除可能是手动删除文件后未更新元数据或进程占用。1.ls -l检查归档目录确认文件是否物理存在。2. 若文件存在尝试手动rm删除。3. 若rm提示“文件正忙”检查是否有dmap等达梦进程正在读写可尝试重启数据库服务后删除。数据库恢复RESTORE时报错提示缺少归档日志序列号XXX恢复链断裂所需的归档日志已被删除。1. 检查备份集是否完整确认用于恢复的备份点LSN。2. 核对被删除的归档日志序列号是否在恢复所需范围内。3.根本解决从归档日志备份集中还原缺失的日志文件或调整清理策略确保保留恢复窗口内所有日志。ALTER DATABASE ARCHIVELOG DELETE命令不生效语法错误或范围指定不对。1. 确认时间或序列号格式正确。2. 查询V$ARCHIVED_LOG确认指定的时间/序列点确实有对应的日志记录。3. 该命令只更新元数据不释放空间需结合物理删除。归档日志文件数量极多导致ls命令卡顿单目录下文件数量过多如超过数万影响文件系统性能。1. 考虑在达梦初始化参数中启用归档日志按日期分目录存放ARCH_DEST可配置多个或使用%d等格式符。2. 编写脚本定期将旧日志文件移动到其他存储并在数据库中更新位置较复杂需谨慎。5.2 关键技巧与经验分享“四眼原则”与变更窗口在生产环境执行任何删除操作前最好有两人核对命令和范围。并将清理操作安排在业务低峰期或预定的维护窗口进行。空间监控与预警前置不要等到磁盘100%满了才行动。建立监控当归档目录使用率超过70%或80%时就触发告警给你留出充足的反应时间。监控脚本可以简单到就是一个定时运行的df -h检查。测试环境的“练兵场”所有新的清理脚本或策略务必先在测试环境完整跑通并模拟恢复流程进行验证。测试环境可以故意制造磁盘满的场景练习紧急清理流程。归档路径的规划艺术初始化数据库时尽量将归档目录ARCH_DEST放在一个独立、大容量的分区或挂载点上避免与系统盘、数据库软件盘或备份盘混用。这样即使日志写满也不会影响系统运行或数据库核心功能。理解DELETE INPUT与DELETE ALL INPUT的区别在BACKUP ARCHIVELOG命令中DELETE INPUT只删除本次成功备份的那些日志文件。而DELETE ALL INPUT会删除备份目录中所有可用的归档日志文件无论本次是否备份。后者更激进使用时要绝对清楚备份目录里有什么。面对“文件正忙”无法删除如果遇到日志文件被进程锁定无法删除首先尝试用lsof \| grep filename找到是哪个进程在占用。通常是达梦的归档进程dmap。最稳妥的办法是关闭数据库实例然后进行删除。对于高可用环境这需要协调停机时间凸显了日常定期清理的重要性。清理归档日志是达梦数据库运维中一项看似枯燥但至关重要的日常工作。它平衡着数据安全与存储成本考验着DBA的规划能力和风险意识。掌握原理谨慎操作用好自动化才能让数据库这艘大船行稳致远。 达梦数据库归档日志清理：策略、实操与自动化运维指南
1. 项目概述归档日志为何非清不可做数据库运维的同行尤其是负责达梦数据库DM Database的朋友估计都遇到过磁盘空间告急的窘境。很多时候C盘或者数据盘突然“飘红”一查原因十有八九是归档日志文件Archive Log把空间给占满了。这可不是个小问题归档日志一旦写满磁盘数据库会直接挂起所有业务操作都会中断影响可大可小。所以“清理归档日志”这个操作看似简单实则是每个达梦DBA必须掌握的核心生存技能。归档日志是数据库恢复的“时光机”。达梦数据库在开启归档模式后会把重做日志文件Redo Log在切换时完整地保存下来形成归档日志。它的核心价值在于数据安全当发生介质故障比如磁盘损坏时你可以利用数据备份和这一连串的归档日志将数据库恢复到故障前的任意时间点实现零数据丢失。但是这个“安全卫士”有个特点它只生产不自动消费。只要数据库在运行归档日志就会源源不断地生成日积月累体积非常可观。因此清理归档日志的本质是在保障数据可恢复性的前提下对过期的、不再需要的日志文件进行安全移除释放宝贵的磁盘空间。这绝不是简单的rm -rf而是一个需要综合考虑备份策略、恢复窗口期RPO和存储管理的系统性操作。处理不当轻则浪费存储重则可能破坏恢复链导致关键时刻无法恢复数据。接下来我就结合多年的实战经验把达梦数据库清理归档日志的方法、背后的原理以及那些容易踩坑的细节给大家掰开揉碎了讲清楚。2. 核心思路与清理策略设计清理归档日志不能蛮干得先有策略。策略的核心围绕一个问题展开哪些日志可以删答案取决于你的数据备份和恢复计划。2.1 基于备份的清理最安全、最推荐的主流方法这是最经典、最安全的清理思路。它的逻辑非常直接一份归档日志在其所涵盖的所有数据变化都已经被至少一次有效的全量备份或增量备份所包含之后它就完成了历史使命可以被安全清理。为什么想象一下时间线你在T1时间点做了一个全量备份。从T1到T2时间段内数据库产生的所有变更都记录在归档日志里。如果在T2时间点又做了一个新的全量或增量备份那么这个新备份本身就包含了截至T2的所有数据状态。此时T1到T2之间的归档日志其“恢复价值”已经转移并固化到了T2的备份集中。即使删除这些日志你依然可以用T1的备份 T2的备份将数据库恢复到T2时刻。达梦数据库提供了强大的内置命令来支持这种策略即BACKUP ARCHIVELOG命令。这个命令的精髓在于它能在备份归档日志的同时自动删除那些已被备份的日志文件一举两得。策略制定的关键考量点恢复窗口目标RPO你的业务能容忍丢失多长时间的数据是一天还是一小时这决定了你需要保留多久的归档日志。例如RPO为24小时那么你至少需要保留最近24小时内产生的所有归档日志即使它们已被备份。备份频率全量备份和增量备份的频率直接影响归档日志的累积速度。备份越频繁单个备份周期内产生的日志量越少清理也就越及时。存储分层可以考虑将近期如一周内的归档日志放在高速磁盘如SSD上供快速恢复使用将更早的、已备份的日志迁移到廉价的大容量存储如对象存储或磁带库上长期归档然后从磁盘删除。这需要额外的脚本和工具支持。2.2 基于时间或序列的清理风险较高的应急手段在某些特定场景下比如磁盘空间即将耗尽急需释放空间或者测试环境不需要长期恢复能力时可能会采用更激进的策略直接删除指定时间点之前或指定序列号之前的归档日志。基于时间删除2023-10-01 00:00:00之前的所有归档日志。基于日志序列号LSN删除序列号小于12345的归档日志。警告这是一种破坏性操作直接删除会切断恢复链。如果你只有一份一个月前的全量备份然后删除了这一个月以来所有的归档日志那么你的数据库最多只能恢复到一个月前的状态这期间的所有数据变更将永久丢失。在生产环境中除非你完全清楚后果并有相应预案如已有更新的备份否则绝对不要轻易使用。这种方法通常作为空间紧急释放的“消防栓”但绝不是日常维护的“水龙头”。执行前务必确认后续的备份是否成功并且确保业务方了解潜在的数据丢失风险。2.3 工具选择命令行、管理工具与自制脚本达梦提供了多种操作入口disql命令行工具DBA的“手术刀”功能最全、最灵活适合编写自动化脚本。我们后续的实操将以disql命令为主。DM管理工具Manager图形化界面操作直观适合手动执行或初学者查看状态。在“归档管理”页面可以进行备份和删除操作。自制Shell/Python脚本结合操作系统命令和disql实现复杂的逻辑判断、日志清理、空间监控和报警是专业运维的终极形态。3. 实操准备与环境确认在动手清理之前必须做好以下准备工作摸清家底避免误操作。3.1 确认归档模式与归档状态首先连上数据库看看归档是不是真的开了以及当前状态如何。-- 使用disql连接数据库例如./disql SYSDBA/SYSDBAlocalhost:5236 SQL SELECT ARCH_MODE, ARCH_STATUS FROM V$DATABASE;如果ARCH_MODE是Y说明数据库处于归档模式。ARCH_STATUS显示当前归档状态如START表示正在归档。3.2 定位归档日志目录与空间占用知道日志在哪占了多大地方是清理的前提。SQL SELECT ARCH_DEST, ARCH_FILE_SIZE FROM V$ARCHIVED_LOG; -- 或者查看动态视图V$DM_ARCH_INI SQL SELECT PARA_NAME, PARA_VALUE FROM V$DM_ARCH_INI WHERE PARA_NAMEARCH_DEST;ARCH_DEST就是归档日志的存放路径。记下这个路径然后切换到操作系统层面去查看实际占用。# Linux/Unix示例 df -h # 查看磁盘整体使用情况 du -sh /dm8/arch_dest/* # 查看归档目录总大小 ls -lh /dm8/arch_dest/ | head -20 # 查看具体文件列表实操心得我习惯在操作系统层面用du和ls命令再确认一遍因为数据库视图显示的可能只是逻辑信息。有时会遇到视图显示有文件但磁盘上实际已被误删的情况会导致恢复时报错这时对比查看就非常必要。3.3 检查备份情况与恢复链完整性这是决定“哪些能删”的黄金标准。你需要知道最新的有效备份点在哪里。SQL SELECT BACKUP_TYPE, START_TIME, END_TIME, FILE_PATH FROM V$BACKUPSET ORDER BY START_TIME DESC;查看最近的备份记录尤其是全量备份。理论上在这个备份START_TIME之前产生的、并且已经被成功备份过的归档日志才是潜在的清理对象。更严谨的做法是使用BACKUP ARCHIVELOG ... DELETE INPUT命令让数据库自己来判断。4. 核心方法详解与步骤实操下面我们进入最关键的实操环节分别演示两种主要清理方法的具体命令和步骤。4.1 方法一备份后清理BACKUP ARCHIVELOG ... DELETE INPUT这是官方推荐、最安全的标准流程。它的原子操作是备份指定范围内的归档日志到备份集然后自动删除原日志文件。步骤1执行备份并删除-- 备份所有可用的归档日志并在备份成功后删除原文件 BACKUP ARCHIVELOG ALL DELETE INPUT TO BACKUP_DIR ‘/dm8/backup/arch_bak’;ARCHIVELOG ALL: 备份所有未被备份过的归档日志。DELETE INPUT: 关键参数表示备份成功后自动删除源归档日志文件。TO BACKUP_DIR ‘/dm8/backup/arch_bak’: 指定备份集的存放目录。更精细的控制-- 备份从序列号1000到2000的归档日志并删除 BACKUP ARCHIVELOG LSN BETWEEN 1000 AND 2000 DELETE INPUT TO ...; -- 备份2023年10月1日之前的归档日志并删除 BACKUP ARCHIVELOG BEFORE ‘2023-10-01 00:00:00’ DELETE INPUT TO ...;步骤2验证备份集与清理结果执行完成后务必进行双重验证验证备份集检查备份目录下是否生成了新的备份文件.bak。ls -l /dm8/backup/arch_bak/验证源文件再次查看归档目录确认对应的.arc文件是否已被删除。ls -l /dm8/arch_dest/数据库视图验证查询备份视图和归档日志视图确认记录已更新。SQL SELECT * FROM V$BACKUPSET WHERE BACKUP_TYPE‘ARCHIVELOG’ ORDER BY START_TIME DESC; SQL SELECT DEST_ID, NAME, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG WHERE DELETED‘YES’; -- 查看已被标记为删除的日志注意事项空间预估BACKUP ARCHIVELOG操作本身会在备份目录产生备份集文件需要确保目标磁盘有足够空间否则会失败。通常备份集会比原日志文件略大一点包含元数据。备份集管理备份出来的归档日志备份集本身也是需要管理的。长期积累也会占用空间。你需要为备份集制定独立的保留策略定期清理过期的备份集。这可以通过REMOVE BACKUPSET命令或图形化工具完成。DELETE INPUT 的威力这个参数非常高效但意味着操作不可逆。执行前请确保备份命令语法正确备份目录有效。4.2 方法二直接删除手动或脚本如前所述此方法风险高仅用于特定场景。核心原则先备份再删除或者确认删除范围绝对安全。步骤1确定删除范围至关重要通过查询精确找出你想要删除的日志文件。-- 查看所有归档日志信息重点关注序列号(FIRST_CHANGE#)、时间戳(FIRST_TIME)和路径(NAME) SQL SELECT DEST_ID, NAME, FIRST_TIME, NEXT_TIME, FIRST_CHANGE#, NEXT_CHANGE# FROM V$ARCHIVED_LOG ORDER BY FIRST_TIME; -- 例如找出2023年9月1日前所有的归档日志 SQL SELECT NAME FROM V$ARCHIVED_LOG WHERE FIRST_TIME TO_DATE(‘2023-09-01’, ‘YYYY-MM-DD’) AND DELETED‘NO’;将查询出的NAME文件完整路径记录下来这就是待删除列表。步骤2执行删除操作删除操作不在SQL内完成而是需要在操作系统层面进行。# Linux/Unix 示例假设上一步查出的一个文件是 /dm8/arch_dest/ARCHIVE_LOCAL1_20230901_123456.arc rm /dm8/arch_dest/ARCHIVE_LOCAL1_20230901_123456.arc # 更常见的做法是写一个脚本基于时间点批量删除 find /dm8/arch_dest -name “*.arc” -mtime 30 -exec rm {} \; # 删除30天前的归档文件谨慎步骤3更新数据库元数据关键步骤仅仅在操作系统上删除文件是不够的数据库的控制文件里还记录着这些日志的信息。需要用ALTER DATABASE命令来通知数据库这些文件已经没了。SQL ALTER DATABASE ARCHIVELOG DELETE UNTIL TIME ‘2023-09-01 00:00:00’; -- 删除指定时间点之前的日志记录 -- 或者 SQL ALTER DATABASE ARCHIVELOG DELETE SEQUENCE 12345; -- 删除指定序列号之前的日志记录这个命令并不会真的去删文件它只是更新数据库内部视图如V$ARCHIVED_LOG将对应日志标记为DELETED‘YES’。所以正确的顺序是先物理删除文件再执行此命令更新元数据。踩坑实录我曾经遇到过只执行了ALTER DATABASE ... DELETE但忘了物理删除文件的情况。这导致磁盘空间没释放但数据库认为日志已删除。后来做恢复测试时因为物理文件还在但元数据已标记删除恢复过程报了错排查了半天。所以顺序一定不能乱rm-ALTER DATABASE。4.3 自动化清理脚本示例Linux Shell对于生产环境手动操作既容易出错也无法持续。下面分享一个简单的自动化脚本框架可以集成到crontab中定时执行。#!/bin/bash # 文件名dm_archive_cleanup.sh # 功能自动备份并清理达梦数据库归档日志 # 使用前需配置以下变量 # 配置区 DB_USER“SYSDBA” DB_PASSWORD“SYSDBA” DB_PORT“5236” ARCH_DEST“/dm8/arch_dest” # 归档目录 BACKUP_BASE_DIR“/dm8/backup/arch” # 备份根目录 RETENTION_DAYS7 # 备份集保留天数 LOG_FILE“/var/log/dm_archive_clean.log” # TIMESTAMP$(date %Y%m%d_%H%M%S) BACKUP_DIR“${BACKUP_BASE_DIR}/${TIMESTAMP}” mkdir -p ${BACKUP_DIR} echo “$(date) — 开始归档日志清理任务” ${LOG_FILE} # 1. 使用disql执行备份并删除 ./disql ${DB_USER}/${DB_PASSWORD}localhost:${DB_PORT} EOF 21 | tee -a ${LOG_FILE} BACKUP ARCHIVELOG ALL DELETE INPUT TO BACKUP_DIR ‘${BACKUP_DIR}’; exit; EOF if [ $? -eq 0 ]; then echo “$(date) — 备份并清理命令执行成功。” ${LOG_FILE} else echo “$(date) — 错误备份清理命令执行失败” ${LOG_FILE} exit 1 fi # 2. 清理过期的备份集按保留策略 find ${BACKUP_BASE_DIR} -maxdepth 1 -type d -mtime ${RETENTION_DAYS} -exec rm -rf {} \; 2/dev/null echo “$(date) — 已清理超过${RETENTION_DAYS}天的备份集目录。” ${LOG_FILE} # 3. 检查归档目录磁盘使用率可选告警 ARCH_USAGE$(df -h ${ARCH_DEST} | awk ‘NR2 {print $5}’ | cut -d% -f1) if [ ${ARCH_USAGE} -gt 80 ]; then echo “$(date) — 警告归档目录 ${ARCH_DEST} 磁盘使用率 ${ARCH_USAGE}%” ${LOG_FILE} # 这里可以集成邮件或钉钉告警 fi echo “$(date) — 归档日志清理任务完成。” ${LOG_FILE}脚本使用要点将./disql路径替换为你环境中disql工具的实际路径。为脚本添加执行权限chmod x dm_archive_cleanup.sh。在crontab中添加定时任务例如每天凌晨2点执行0 2 * * * /path/to/dm_archive_cleanup.sh。务必先在测试环境充分验证脚本逻辑特别是rm -rf删除备份集的部分。5. 常见问题排查与实战技巧即使按照步骤操作也可能会遇到各种问题。这里汇总几个典型场景和解决方法。5.1 问题排查速查表问题现象可能原因排查步骤与解决方案BACKUP ARCHIVELOG执行失败报错“磁盘空间不足”备份目标目录空间不足。1. 使用df -h检查备份目录所在磁盘空间。2. 清理目标目录无用文件或更换更大磁盘。3. 临时可指定其他有空间的目录进行备份。归档目录磁盘使用率仍很高但V$ARCHIVED_LOG显示很多DELETED‘YES’操作系统层面文件未删除可能是手动删除文件后未更新元数据或进程占用。1.ls -l检查归档目录确认文件是否物理存在。2. 若文件存在尝试手动rm删除。3. 若rm提示“文件正忙”检查是否有dmap等达梦进程正在读写可尝试重启数据库服务后删除。数据库恢复RESTORE时报错提示缺少归档日志序列号XXX恢复链断裂所需的归档日志已被删除。1. 检查备份集是否完整确认用于恢复的备份点LSN。2. 核对被删除的归档日志序列号是否在恢复所需范围内。3.根本解决从归档日志备份集中还原缺失的日志文件或调整清理策略确保保留恢复窗口内所有日志。ALTER DATABASE ARCHIVELOG DELETE命令不生效语法错误或范围指定不对。1. 确认时间或序列号格式正确。2. 查询V$ARCHIVED_LOG确认指定的时间/序列点确实有对应的日志记录。3. 该命令只更新元数据不释放空间需结合物理删除。归档日志文件数量极多导致ls命令卡顿单目录下文件数量过多如超过数万影响文件系统性能。1. 考虑在达梦初始化参数中启用归档日志按日期分目录存放ARCH_DEST可配置多个或使用%d等格式符。2. 编写脚本定期将旧日志文件移动到其他存储并在数据库中更新位置较复杂需谨慎。5.2 关键技巧与经验分享“四眼原则”与变更窗口在生产环境执行任何删除操作前最好有两人核对命令和范围。并将清理操作安排在业务低峰期或预定的维护窗口进行。空间监控与预警前置不要等到磁盘100%满了才行动。建立监控当归档目录使用率超过70%或80%时就触发告警给你留出充足的反应时间。监控脚本可以简单到就是一个定时运行的df -h检查。测试环境的“练兵场”所有新的清理脚本或策略务必先在测试环境完整跑通并模拟恢复流程进行验证。测试环境可以故意制造磁盘满的场景练习紧急清理流程。归档路径的规划艺术初始化数据库时尽量将归档目录ARCH_DEST放在一个独立、大容量的分区或挂载点上避免与系统盘、数据库软件盘或备份盘混用。这样即使日志写满也不会影响系统运行或数据库核心功能。理解DELETE INPUT与DELETE ALL INPUT的区别在BACKUP ARCHIVELOG命令中DELETE INPUT只删除本次成功备份的那些日志文件。而DELETE ALL INPUT会删除备份目录中所有可用的归档日志文件无论本次是否备份。后者更激进使用时要绝对清楚备份目录里有什么。面对“文件正忙”无法删除如果遇到日志文件被进程锁定无法删除首先尝试用lsof \| grep filename找到是哪个进程在占用。通常是达梦的归档进程dmap。最稳妥的办法是关闭数据库实例然后进行删除。对于高可用环境这需要协调停机时间凸显了日常定期清理的重要性。清理归档日志是达梦数据库运维中一项看似枯燥但至关重要的日常工作。它平衡着数据安全与存储成本考验着DBA的规划能力和风险意识。掌握原理谨慎操作用好自动化才能让数据库这艘大船行稳致远。