凌晨两点被电话叫醒的经历我不知道你经历过几次。那次是某单位生产库突然卡死所有业务连接全部堆积应用日志疯狂报无法获取连接。远程上去一看不是连接池的问题不是SQL的问题是达梦数据库的redo日志相关目录满了归档写不进去整个实例直接hang住。从那以后我就养成了一个习惯凡是接手一套达梦数据库第一件事就是看redo日志和归档的配置再看业务增长量。这篇就把达梦redo日志管理这套东西从头到尾梳理一遍涵盖日常操作、故障排查、参数规划以及一些在官方文档里不太容易被注意到的细节希望对正在用达梦或者正在从其他数据库迁到达梦的朋友有帮助。1. redo日志在达梦里到底是干什么的1.1 从崩溃恢复说起redo日志解决的核心问题数据库做了修改之后数据并不会立刻写进数据文件而是先写一份改动记录到日志缓冲区再从缓冲区刷到redo日志文件里。这个先日志后数据的顺序是所有主流关系型数据库保证崩溃后数据不丢的基本手段达梦也不例外。我从这几个层面理解redo日志的职责前滚恢复的素材实例异常崩溃后内存里那些已经提交但还没落盘的数据要靠redo日志在实例启动时重放一遍把数据文件恢复到崩溃前的状态。这个过程在达梦中叫实例恢复和Oracle的crash recovery是一个思路。检查点的基础系统在做检查点时会把脏页刷到数据文件里同时推进检查点位置。检查点之前的redo日志就可以被覆盖复用了。日志文件是循环写入的一个日志写满之后如果没有开启归档就开始覆盖最老的那个日志。恢复的边界如果连redo日志本身都丢了或者坏了数据库基本只能恢复到上一次完整备份的状态中间所有已提交事务都可能丢失。这就是为什么redo日志管理在DBA眼里是保命级别的工作。1.2 达梦redo日志和Oracle redo log的异同达梦数据库的体系结构和Oracle高度相似。redo日志以日志组的形式存在每个组里可以有多个日志文件同一组内的文件内容是完全一样的镜像关系。达梦默认会创建两组日志交替使用。两者的相似点主要体现在三个方面都是循环复用的模式写满一组切到另一组都可以通过动态视图查看当前日志状态和切换历史都支持归档模式归档模式下日志在复用之前会被完整保存下来。差异点也有最直观的是管理命令存在差异。达梦中增加日志文件使用的是ALTER DATABASE ADD LOGFILE调整大小可以用ALTER DATABASE RESIZE LOGFILE部分版本支持这些语法和Oracle不完全一样。另外达梦在图形化工具DM管理工具里提供了非常直观的日志管理界面生产环境完全可以在图形界面里完成日志组的增删改这一点比Oracle的命令行方式更友好。2. 日常管理redo日志的四类操作2.1 查看redo日志状态别等出事才想起来日常巡检时我一般会执行下面这条SQL看全局日志信息SELECT * FROM V$RLOG;V$RLOG返回的信息里我最关注的是当前正在使用的日志文件、日志序列号和检查点位置。再看文件级别的明细SELECT * FROM V$RLOGFILE;V$RLOGFILE会列出所有redo日志文件路径、大小、状态。状态字段里如果出现INACTIVE表示该日志可以安全覆盖CURRENT表示当前正在写入ACTIVE表示日志对应的检查点还没有完成数据还在内存里这个日志暂时不能删除。在DM管理工具的图形界面里选中数据库实例往下展开可以直接看到重做日志标签页所有日志文件一览无余双击日志文件还能查看路径、大小、状态等信息。形象地说图形界面适合看一眼命令行适合写脚本巡检两者结合是生产环境的标准姿势。2.2 增加/删除/调整redo日志文件的标准做法先明确一个原则所有日志文件操作必须在数据库的配置允许范围内进行且至少保留两个日志文件。如果只剩一个日志文件达梦会直接报错拒绝删除这是防止你把自己锁死。增加日志文件可以用下面这种方式ALTER DATABASE ADD LOGFILE /dm/data/DAMENG/redo03.log SIZE 2048;这条命令执行成功后新日志文件会加入日志循环队列中后续日志切换时可能被使用。调整大小的需求一般出现在业务增长之后。如果达梦版本支持RESIZE可以直接执行ALTER DATABASE RESIZE LOGFILE /dm/data/DAMENG/redo01.log TO 4096;如果不支持或者想更保险我习惯用三步法先添加一个新的大日志文件手动触发几次日志切换让业务写入自然流转到新文件上确认旧文件状态变成INACTIVE后再删除旧文件。这种做法的好处是全程不中断业务风险最低。删除日志文件的命令是ALTER DATABASE DELETE LOGFILE /dm/data/DAMENG/redo01.log;删除前务必确认该文件状态不是CURRENT或ACTIVE。至于判断方法可以通过v$rlogfile查看状态也可以先执行日志切换让当前文件脱离写入状态。2.3 日志切换和归档的触发方式日志切换有两种触发方式一是当前日志写满自动切换二是手动切换。手动切换命令通常采用这种方式ALTER DATABASE SWITCH LOGFILE;在达梦的某些版本中也可以使用ALTER SYSTEM ARCHIVE LOG CURRENT;它会先将当前日志归档再切换日志适合准备做备份前主动触发一次确保所有已提交事务都进入归档。开启归档模式的标准流程是这样的-- 先将数据库切换到MOUNT状态 ALTER DATABASE MOUNT; -- 打开归档模式 ALTER DATABASE ARCHIVELOG; -- 添加一个本地归档目录 ALTER DATABASE ADD ARCHIVELOG DEST/dm/arch TYPELOCAL; -- 回到OPEN状态 ALTER DATABASE OPEN;生产环境设置归档时一定要预留足够的磁盘空间否则会出现开头说的归档目录写满实例hang住的情况。3. 三个真实故障场景的完整排查链路3.1 归档日志目录写满导致数据库hang住这是我遇到的最多的redo日志相关问题没有之一。现象是应用连接全部超时数据库日志里持续报错大量日志写入失败整个实例拒绝服务。排查链路如下第一步先确认是不是磁盘满了。执行df -h如果发现归档目录所在文件系统使用率100%基本可以锁定原因。第二步确认是不是归档进程卡死。查看V$ARCH_STATUSSELECT * FROM V$ARCH_STATUS;如果归档状态异常且归档目录里文件没有持续增加说明归档线程可能已经停止工作。第三步解决当前阻塞。我通常先清理掉一部分无用归档文件让实例先恢复运行再排查为什么归档会积压。根因上归档积压大概率是以下三个原因之一业务高峰期产生日志量远超预期归档目录空间规划不足备份脚本没有及时清理过期归档文件归档目录所在磁盘性能太差或者网络存储挂载方式有问题导致归档写入速度跟不上日志生成速度。第四步就是完善机制写一个带保留天数的归档清理脚本加入crontab同时给归档目录加磁盘空间监控告警。3.2 redo日志文件损坏后的恢复过程物理损坏比空间写满麻烦得多。一次迁移项目里客户因为磁盘坏道导致redo日志文件读到一半就读不下去数据库启动时反复报日志校验错误。这个时候我的处理路径是这样的第一步不要急着动数据文件先把所有物理文件备份一份防止后续操作引入二次损坏。第二步把数据库启动到MOUNT状态。如果当前日志文件损坏导致无法正常启动达梦通常允许以ALTER DATABASE OPEN RESETLOGS方式强制打开让数据库重建日志内容。这个操作在达梦中是可行的但必须先确认数据文件本身没有丢失。第三步尝试删除损坏的日志文件再重新添加。这里一定要记住一点日志损坏后最后一个日志文件里的已提交事务可能无法全部恢复所以操作前务必和业务方确认可接受的数据丢失范围通常依赖上一次物理备份和归档日志。经历过这次之后我再也不在单块磁盘上放redo日志了。如果你的环境允许把日志文件分散到不同物理磁盘或者至少保证有多路冗余故障半径会小很多。3.3 日志频繁切换引起的性能抖动还有一种现象不是宕机但是比宕机更隐蔽——业务高峰期数据库CPU不高、IO也不高但是应用就是偶尔慢几秒。看告警日志后发现日志切换非常频繁几乎每几分钟就切一次。日志切换本身不算重操作但如果切换过快且检查点没有跟上就会触发数据库的日志覆盖等待所有写事务都被迫停顿。排查时一般看两个指标单个日志文件的写满时间。如果几分钟就写满说明日志太小了。检查点完成时间和日志切换时间的关系。如果每次切换时都需要额外等待很久说明日志数量和大小都不够。这种场景下对应的解决方法是调整日志大小和数量具体怎么调下一节细说。4. redo日志大小和数量规划4.1 先理解日志配置的关键逻辑redo日志规划的核心目标只有一条让日志切换的频率和检查点的频率保持在一个合理节奏上既不能切太快导致频繁覆盖等待也不能让日志文件过大导致恢复时间过长。具体来说日志太小检查点无法及时把脏页刷下去系统会频繁触发日志覆盖等待影响写入性能日志太大一旦实例崩溃前滚恢复时需要重放大量日志恢复时间变长日志组太少一组在写、另一组还在等检查点完成就容易出现写不动的情况。对于日志数量和大小我给出一版自己在项目中常用的经验配置表适合大多数常见的OLTP业务不绝对但参考价值比较大。业务场景日志组数量单日志文件大小说明小型应用/测试库3组1GB业务量小配置太大会浪费空间中型OLTP系统4组2GB常规生产配置兼顾切换频率和恢复时间大型高频交易系统4至6组4GB以上写入量大需结合归档速度和检查点频繁程度综合评估分析型/批量作业为主3至4组4GB至8GB批量场景写入集中单次事务量大日志需要更大的缓冲空间拿中型OLTP系统举例如果一套数据库中单日产生50GB的redo日志业务高峰集中在8小时峰值时段每小时产生约10GB每20分钟切换一组2GB的日志。四组日志能让循环队列覆盖80分钟左右检查点不需要和日志切换抢时间这种节奏基本是平稳的。4.2 判断当前日志配置是否合理的方法如果你不确定当前配置是否合理可以按下面的步骤验证一下第一步在业务高峰期执行多次日志切换查询记录两次切换之间的间隔时间。如果间隔不足10分钟大概率日志偏小。第二步查看v$rlog里的检查点位置和当前日志位置的差距。如果检查点落后太多说明检查点刷盘速度跟不上日志生成速度。第三步观察告警日志里有没有类似checkpoint not complete的信息。即使不频繁出现只要有记录就说明配置到了临界状态。调整验证的时候要注意一点调大日志文件后系统可能要等到所有日志组都用过一轮之后才真正生效所以不要急着几分钟后看结果至少运行一个业务高峰周期再评估。5. redo日志与备份恢复、集群同步的联动5.1 归档模式的选择RTO和RPO的取舍redo日志在非归档模式下日志写满就会被覆盖一旦覆盖该段日志对应的历史数据就再也找不回来。所以生产环境我几乎从不推荐非归档模式。归档模式的代价是额外的磁盘空间和维护成本但换来的是可以做到任意时点恢复。简单说开启归档后你的恢复窗口取决你保留了多少归档日志你可以恢复到昨天下午三点也可以恢复到前天上午十点只要对应的归档还在。如果你所在企业对数据丢失极度敏感建议至少满足以下三者之一每天全量备份同时保留最近三天的归档日志每周全量备份保留最近一周的归档日志接入带实时同步的灾备环境备库实时应用归档日志。我见过不少从其他数据库迁移到达梦的项目迁移工具把表结构、数据、视图都搬过去了但归档参数沿用默认结果第一次真实故障演练时就发现恢复点达不到预期。这属于典型的底层配置被忽略。5.2 redo日志在集群和主备环境中的特殊角色达梦的两地三中心、主备集群、DSC共享集群这些高可用方案底层都离不开日志同步。主备集群DataWatch的同步原理是主库产生的redo日志通过归档或实时传送方式发送到备库备库接收后持续重放保持和主库一致。主库日志完整、备库日志完整切换时就不会丢数据。如果主库的redo日志文件设置过小主库日志切换非常频繁日志传送的频率也会跟着加快。在跨机房同步的场景下网络延迟和带宽往往成为瓶颈极端情况下备库会一直追赶主库进度延迟越拉越大。我经历过的几个两地三中心项目里备库延迟的根因一半以上都出在主库redo日志配置过于小气上。所以高可用环境的日志规划不仅要考虑本机性能还要把同步链路的网络带宽和延迟算进去。日志大一点切换频率低一点同步压力会明显下降。在一套生产环境中想要快速判断备库能不能跟上主库的节奏可以在备库执行查看同步状态的相关SQL观察主备日志序号差距。如果差距持续增长先检查主库日志切换频率和同步网络状态再检查备库重放能力。6. 巡检清单和最容易翻车的小细节6.1 我落到文档里的日常巡检项以下是我在项目上使用的re do日志巡检清单直接抄到你的巡检脚本里就行检查redo日志文件数量是否小于3组小于3组需要警惕检查单个redo日志大小是否低于1GB低于1GB需要结合业务评估是否扩容检查归档目录空间使用率是否高于75%高于75%需要准备清理或扩容查看v$rlogfile中是否存在状态异常的日志文件查看数据库告警日志里是否有checkpoint相关告警或者归档相关报错确认归档日志清理脚本是否正常运行清理策略是否还能满足恢复要求。每次巡检后把结果发到群里或归档到本地持续关注趋势比单看一次结果更重要。6.2 几个常见误操作汇总使用达梦这么久我见过不少操作失误造成二次故障的案例集中记录一下第一删除日志文件前不做状态检查。这个错误最致命一句话总结永远不要在没确认日志状态的情况下执行DELETE LOGFILE。第二在非归档模式下长时间运行生产库。一旦日志覆盖任何恢复手段都无法找回覆盖前的已提交事务。如果不确定自己的生产库是否处于归档模式现在就查一下不要等出问题。第三多个日志文件放在同一块磁盘上。虽然日志文件是多组的但物理上都在一块盘上磁盘坏了所有日志一起没。有条件的话至少把日志组分散到不同物理存储上。第四调整日志大小时直接RESIZE没有预留足够的磁盘空间导致过程中磁盘写满。执行任何扩容操作之前先确认磁盘剩余空间是否大于目标文件大小的两倍以上。第五迁移完成后直接沿用源库的日志规划。不同数据库对日志的使用机制有差别迁移后必须重新评估日志大小和归档策略。上面这些坑我在项目实施中都真实踩过或帮客户擦过屁股。这里没有哪个是技术难题全都是提前想一步就能避免的事。最后再分享一个经验接手任何一套达梦环境第一周就把日志配置、归档路径、备份策略、清理脚本四个东西全部过一遍后面能帮你省下很多凌晨的紧急电话。