凌晨一点手机告警铃声把值班的同事从椅子上弹了起来某生产系统的达梦数据库连接数直接被占满业务服务大面积超时。等我们登录服务器一看归档日志目录早已被写满实例处于一种近乎假死的状态——联机日志切不出去所有写事务都堵在门口排队。这种场景就是达梦数据库故障处理里最典型的一类表面上看是数据库卡死了实际上是一整条链路从磁盘、归档到事务提交被依次挤爆。这篇文章我想把这一年多在生产环境里处理达梦数据库故障的完整经验梳理出来重点讲实例启动失败、归档空间写满、主备切换异常、慢SQL拖垮实例这几类最高频也最要命的故障每一类都按照“现象 → 排查链路 → 处理顺序 → 事后预防”来讲。无论你是刚接手达梦数据库的运维新人还是在跑DM8主备集群的DBA都可以把下文里的排查思路和命令直接拿去当手册用。1. 故障处理前先搞清楚达梦的“病历本”藏在哪里1.1 日志入口与现场取证处理任何数据库故障第一步都不是动手重启而是搞清楚系统当前处在什么状态、日志里到底说了什么。达梦数据库的日志大致可以分成四类实例服务日志也就是dmserver和后台服务进程输出的运行日志记录了启动过程、状态切换、SQL报错和后台任务消息告警日志记录比较严重的系统级信号比如内存不足、磁盘IO异常、归档写入失败审计日志默认不一定开启开启后会记录登录行为和敏感操作最后是归档日志它是联机日志redo的副本用来支撑恢复和主备同步。故障处理时我习惯按时间窗过滤日志把故障发生前十分钟到处理结束这一整段的日志全部抓出来按时间先后排列你会发现很多因果链是清清楚楚的。比如日志里先出现“内存分配失败”后面必然跟着实例退出先出现“归档文件创建失败”后面大概率会跟出一大串事务挂起。把这些线索串起来故障的根因往往就浮现了。除了日志动态性能视图就是数据库自己的体检报告。用disql连进去后V$INSTANCE能看实例状态V$SESSIONS能看当前会话V$LOCK能看锁等待关系V$ARCHIVED_LOG能看归档进度。图形管理工具用不了的时候命令行就是唯一能依靠的入口。1.2 动手前先花五分钟记录现场我见过不少同事一上来就执行重启把原本可以保留的崩溃现场直接冲掉了事后连原因是什么都无从查起这是处理数据库故障最大的忌讳。在动任何命令之前先花几分钟把下面这些信息记录下来故障发生的时间点、告警原文、几个关键进程的状态dmserver是否还在、守护进程是否存活、磁盘空间和内存的使用快照、最近一次成功备份的时间和备份集位置。这组信息看着不起眼但关键时刻能救命。它决定了你后续能不能做数据恢复以及恢复时能回到哪个时间点。还要顺手确认一下影响范围是只有一个实例连接不上还是整个集群都不健康是写事务受阻还是读请求也一起挂掉这个判断决定你该走“就地修复”还是“直接切换”的路线。数据库故障处理最怕的不是故障本身而是在信息不全的情况下盲目操作越急越容易把小事搞成大事。2. 实例起不来三类启动故障的逐层排查2.1 端口冲突服务日志里的第一个线索有一次现场报障应用连不上达梦数据库我登上去一看dmserver进程都没了。手动执行启动脚本进程刚起来几秒又消失反复几次都是这样。折腾了一会儿才在实例日志里发现关键信息——端口注册失败。再查了一圈原来是另一个中间件程序占用了达梦默认监听的5236端口实例启动到监听这一步自动退出。这类问题的排查非常简单先用netstat -lnp | grep 5236看看端口被谁占用再用ps -ef | grep dmserver确认是不是还有残留进程。如果端口确实被其他程序占了要么停掉占用程序要么修改dm.ini里的PORT_NUM参数后重启实例。这里要特别提醒改完端口之后所有连接字符串、主备守护配置、备份脚本里的端口号都得同步改漏掉一个就会出现“库明明好的却怎么也连不上”的后续故障我在这上面吃过亏。2.2 内存相关参数配置不当导致反复闪退比端口冲突更隐蔽的是内存问题。某个模拟环境里达梦库在旧机器上一直很稳迁移到新环境后实例频繁崩溃日志里反复出现内存相关的报错。一开始怀疑硬件有问题后来把系统资源限制和数据库内存参数放一起看了才发现新环境对单个进程的文件描述符上限和内存锁定限制比旧机器紧而实例初始化时内存类参数又配得过于激进两边叠加实例启动时一次性申请内存失败进程起来就闪退。处理这个问题的思路分两步先用ulimit -a看系统当前的资源限制必要时在/etc/security/limits.conf里调高对应值重新登录会话生效同时检查dm.ini里的内存、连接数等参数按物理内存实际大小合理下调。我的经验是调整这类参数时一次只动一个改完启动实例观察十分钟以上确认稳定了再动下一个。如果同时改三四个参数后面真要出问题你根本不知道是哪个改动起了反作用。2.3 数据页不一致离线校验与最小损失恢复第三类启动故障最让人头疼通常发生在异常断电、实例被强制kill或者磁盘出现坏道之后。现象是实例能到mount状态但一执行open就报数据文件校验失败管理工具里看得清清楚楚数据库就是打不开。处理这种问题要死死记住一条顺序任何校验和修复操作之前先把整个数据目录完整备份一份。哪怕只是复制一份到另一块磁盘也比什么都不做就冲上去修复强。备份之后再用达梦自带的离线备份恢复工具dmrman对数据文件做校验和恢复。如果只是部分数据页损坏、备份链路又完整可以基于最近一次备份集做增量恢复把实例拉回到故障前一个可用的时间点。如果备份缺失那只能在能打开的最小范围内抢救数据这时候你之前记录的“最近成功备份时间”就派上大用场了。这里必须说实话恢复能力从来不是靠临场发挥而是靠平时备份攒出来的底气没有备份支撑的修复方案操作者等于在钢丝上走路。3. 归档占满磁盘存储故障的现场救援与事后布防3.1 故障链路归档写满如何拖垮整个实例磁盘是数据库服务器上最容易被低估的资源尤其是开归档的生产库。达梦开启归档模式后联机日志切换时先要写出一份归档日志归档写成功了联机日志才能被覆盖复用新事务才继续往前走。一旦归档目录所在的分区满了整条链路就堵死了联机日志切不动事务一提交就进入等待数据库进程看着还活着业务却已经“假死”。等你通过告警发现的时候系统盘剩余空间可能已经是0了。这种故障最迷惑人的地方在于表面上看是数据库响应慢本质却是磁盘空间耗尽表面上是IO性能问题实际是文件写不进去。所以我处理达梦数据库卡顿类告警时第一件事永远是执行df -h看空间这个操作成本几乎为零却能一次性排除掉一大半存储类故障。如果你的故障复盘里发现大多数卡顿都发生在磁盘使用率90%以上之后那就更说明问题出在存储侧而不是数据库参数。3.2 紧急救援的先后顺序当磁盘确实满了先不要慌按下面这个顺序操作先清理绝对安全、可删除的临时文件比如/tmp下的安装包残留、历史备份产生的临时分片。再看归档目录里有没有可以被安全清理的旧归档。但注意归档的删除必须配合备份保留策略不能为了腾空间把早于最近全量备份的归档一股脑全删了否则恢复点会直接断层。如果空间实在不够优先方案是给归档目录换更大的分区存储侧挂新磁盘把归档目标路径指到新分区再让数据库把新归档写到新目录。这样业务能较快恢复又不破坏归档的连续性。最后一个手段才是临时关闭归档或降低归档写入频率。这是救火性质的让步只能在业务低谷期操作而且要评估它对主备同步的影响。整体思路就是先止血让业务恢复可用再处理根因最后补预防措施顺序反了就会踩坑。3.3 归档策略怎么配才合理事后布防层面有几条配置经验可以分享。归档目录不要和数据库文件、系统盘放在同一个分区否则任何一个写满都会拖累其他两个。归档文件的大小和空间上限要设置合理不要放任它无限膨胀。每日备份脚本执行成功后再用定时任务把超过保留周期的归档统一转储或清理清理动作一定要绑在“备份成功”之后执行顺序不能乱。监控上要给归档目录单独设置磁盘使用率告警我的习惯是70%预警、85%告警留足处理时间。容量估算按“每日归档量 × 保留天数 × 1.5冗余”来算并且至少要在测试环境模拟过一次“归档满”的演练把一键清理脚本真正跑一遍。演练过和没演练过在真实故障现场的临场反应完全不一样。4. 主备切换失败数据守护集群的一次实战复盘4.1 备库状态与同步积压的定位主备集群是为高可用上的保险但它本身也可能成为故障源。有一次主库所在服务器宕机业务侧等自动切换结果五分钟过去备库也没有接管最后只能人工介入。从主库故障后的现场日志看守护进程配置的切换策略没有正常触发备库一直停留在STANDBY状态。排查时先确认主备两侧的实例状态再确认守护进程和监视器是否还活着最后对比主备最近的归档日志时间戳判断备库数据到底追平没有。很多自动切换失败的场景根因并不是切换机制坏了而是备库的归档链在主库宕机之前就已经中断备库数据滞后太多守护进程为了避免把一个数据不完整的实例提升为主库直接拒绝切换。换句话说主备同步的“健康检查”平时没做好故障时才暴露出来。4.2 手动切换的完整步骤确认备库数据基本追平之后就可以手动执行切换。如果主库已经完全不可用就要在监视器中对备库执行接管操作让备库以主库身份对外提供服务。这里有个细节很容易被忽略切换之前要把应用侧的连接串指向备库地址的准备工作做好最好由应用方值班人员确认连接信息能改。否则数据库切换再顺利应用还是连旧地址故障时间根本没有缩短。切换完成后第一件事不是庆祝而是以新主库身份做一个快速的写测试插入一条记录再查回来确认写入链路真的通了第二件事是检查归档是否恢复到正常状态第三件事是记录新主库当前的日志时间点为后续老主库回归作为新备库加入集群做准备。回归时通常需要基于全量备份把老主库重置成新备库这个过程必须在业务低峰做因为数据量越大耗时越长。4.3 两个在演练中才暴露的问题这里要分享两个只有通过演练才会暴露的坑。第一个是自动切换的超时参数设置得太长导致主库宕机后业务侧干等了好几分钟切换才被确认失败。参数不能照抄文档默认值必须根据业务能容忍的RTO来调宁可把超时设短一点触发告警也不要让业务在故障里多熬几分钟。第二个坑是主备两台机器的系统时间没有严格同步。切换后新主库的日志时间戳出现乱序后续排查和同步重建都变得非常别扭。数据库集群里的时间同步不是可选项而是必选项。手动切换的流程必须每隔一段时间实际演练一次平时都是自动切换就不验证真到故障时你会发现人对命令的熟悉程度远没有想象中那么高。5. 一条慢SQL引发的“假死”性能故障的定位与急救5.1 从会话视图和锁等待还原现场性能类故障和崩溃类故障的处理思路完全不同崩溃故障要把数据保住性能故障要把响应时间保住。典型场景是某个业务系统在特定时段CPU被打满数据库连接数持续飙升新请求根本进不来整个库看起来像是死了。实际上库没死而是某个会话占着关键资源一直不释放把后面的请求全堵住了。我在现场的处理链路是固定的先查V$SESSIONS里那些长时间处于活动状态、始终没有进展的会话按执行时长排序再看V$LOCK找出有没有会话在被阻塞以及阻塞者是谁最后把阻塞者正在执行的SQL抓出来元凶基本就浮出水面了。这套“会话 → 锁 → SQL”的定位方法从登录到得出初步结论通常只需要几分钟比去看一堆应用报错日志高效得多。5.2 慢SQL执行计划怎么抓、怎么看定位到具体SQL之后先不要急着优化把执行计划抓出来分析一遍。在disql里给目标SQL加上EXPLAIN关键字就能看到达梦生成的执行计划。看执行计划的重点有三个表访问方式是不是全表扫描、表连接顺序是否合理、有没有做超出预期的大范围排序或哈希操作。我在实践中发现最常见的性能拐点不是SQL写得多烂而是统计信息过期导致优化器选了一个错误的执行方案。如果手头没有测试库可以在生产环境的低峰期对涉及的表主动更新统计信息再重新看执行计划是否变化。这也是为什么日常运维里要把统计信息更新纳入周期任务很多“昨天还正常、今天突然变慢”的诡异故障本质上就是统计信息长期不更新造成的。5.3 临时止血与长期优化如果阻塞会话已经让业务无法容忍最直接的止血手段是关闭那个阻塞会话让排队事务继续跑下去。但关会话一定要谨慎先确认它不是正在执行一个长事务批量任务否则强行中断可能引发回滚风暴反而把实例拖得更惨。我的判断标准是优先杀掉那些已经空闲很久、只持有锁不干活的会话而不是杀正在全力运行的SQL。长期优化则有三条路径可以走一是优化SQL写法或者加合适的索引把全表扫描改成索引查找二是调整数据库参数比如增大排序区或缓冲池让常用表尽量留在内存里三是从应用架构上做拆解把高峰期的大查询挪到只读备库上去跑。前两条是DBA能直接落地的第三条需要和应用开发团队一起设计但往往是收益最大的一条。6. 从救火到防火达梦数据库的日常巡检与应急准备6.1 每天花十分钟做一遍的检查项故障处理能力再强也比不上不发生故障。我现在带团队每天到岗第一件事就是花十分钟做一遍基础巡检用df -h看系统盘、数据盘、归档盘的使用率用top看CPU和内存占用留意有没有进程异常吃资源通过disql连接实例检查实例状态是否正常、主备状态是否健康、昨晚的备份任务有没有失败记录扫一眼告警日志只看ERROR级别以上的内容普通INFO直接忽略。这十分钟能完成的巡检胜过故障之后通宵达旦的排查。绝大多数严重故障在发生前都会在巡检指标里露出马脚问题是你有没有每天去看。6.2 监控阈值、归档清理和备份恢复验证监控阈值要根据业务峰值动态调整不能一个阈值用一整年。连接数的告警阈值应该在业务高峰期正常连接数的基础上乘1.5到2倍磁盘使用率的预警线设在70%、告警线设在85%归档目录可以用更严格的标准。如果阈值设得太低告警会天天轰炸最后大家麻木到连真告警都忽略设得太高又等于没有监控。归档清理任务要绑定在备份任务成功之后执行保证任何一个时间点的恢复能力都不依赖已经被删除的归档文件。另外每月的备份恢复演练绝对不能省挑一台测试机从最近的备份集恢复出一个完整实例验证数据能读、应用能连。我见过太多团队以为“备份每天都在跑”就等于“恢复没问题”但备份和恢复是两码事备份只是恢复的必要条件不是充分条件。只有真正从备份里恢复出可用实例的那一天你才敢说自己的备份体系是合格的。6.3 故障速查卡让下一次处理更快最后分享一个坚持了很久的习惯每次处理完一次达梦数据库故障我会用半小时的时间把故障现象、日志关键词、排查命令、处理步骤按固定模板整理成一张速查卡按故障类型归档到团队文档库。速查卡不需要写很长控制在能在一屏看完的篇幅重点是记录每一步操作和下一步判断的依据比如“归档满时先看哪个目录写了多少”“主备切换失败时先查哪个视图”。故障类型首要命令/动作常见根因处理原则实例启动失败ps -efgrep dmserver查日志端口冲突、内存不足、数据页损坏数据库假死df -h看磁盘空间归档目录写满先清临时文件再扩归档路径主备切换失败检查守护进程与备库日志时间戳归档链路中断、参数不合适数据追平后再手动切换性能类故障查V$SESSIONS和V$LOCK慢SQL、统计信息过期先止血再优化执行计划这个习惯坚持下来之后团队处理同类故障的耗时基本缩短了一半。数据库故障处理的深度最终来自一次次的复盘和沉淀而不是一次次疲惫的重启。