归档日志挖掘

一、引言

在数据库日常运行过程中，偶尔会产生一些异常，这些异常通常由业务sql触发。其中一些异常为偶发性，同时转瞬即逝，大大增加了排查难度。
重做日志中记录了数据库中添加、删除、修改对象，或者改变数据等操作的执行结果，因为重做日志大小有限，会进行覆写，当数据库开启归档模式时，会将重做日志中的内容转储至归档日志文件中进行持久化保存，保存时间根据实际情况通过dmarch.ini中的配置进行控制，归档日志为数据库异常排查提供了溯源手段。
下面将通过描述一次故障排查过程介绍如何使用归档日志进行挖掘。

二、故障排查过程（DM7）

问题现象：
2025-05-15 20:53:05 监控发现：达梦数据库当前待PURGE事务量182785大于限值100000。告警发生后几分钟，待PURGE事务量恢复正常，期间数据库运行未受到影响。
问题分析：PURGE为回滚段清理过程，用于清理回滚段已提交的事务。待PURGE对象堆积，通常由大事务回滚或PURGE线程被阻塞导致。选择通过归档日志进行回溯，排查具体原因。
排查步骤：
1、经过用户同意后，从生产环境中拷贝出告警产生时刻及前几分钟的归档文件并上传至相同大版本测试库服务器上用于日志挖掘。（禁止在生产系统中进行归档挖掘操作）

2、获取测试库dbmagic，获取正式库dbmagic，批量修改归档日志文件的dbmagic


备注：DB_MAGIC_SRC参数填写正式库DB_MAGIC,DB_MAGIC_DST参数填写测试库DB_MAGIC。TYPE=7为批量修改归档文件。TYPE=2为修改指定文件的DB_MAGIC.直接执行./dmmdf 可以查看帮助信息
3、调用存储过程创建系统包
SP_CREATE_SYSTEM_PACKAGES(1,'DBMS_LOGMNR');

4、指定归档日志文件
DBMS_LOGMNR.ADD_LOGFILE('/dbarch/dmarch/ARCH/ARCHIVE_LOCAL1_20250515205132386_0.log');

备注：可以通过打开多个数据库会话加载多个归档日志。系统包只需要加载一次
5、加载归档日志文件

备注：归档日志的大小及测试库服务器规格不同，加载时间可能稍长。START_LOGMNR可以根据需要填写OPTIONS参数：如DBMS_LOGMNR.START_LOGMNR(OPTIONS=>2128)其中2128=16+64+2048即不包含COMMITTED_DATA_ONLY选项
对应的配置项见下表：
Options 对应值 说明
COMMITTED_DATA_ONLY 2 仅从已提交的事务的日志中挖掘信息
DICT_FROM_ONLINE_CATALOG 16 使用在线字典
NO_SQL_DELIMITER 64 拼写的 SQL 语句最后不添加分隔符
NO_ROWID_IN_STMT 2048 拼写的 SQL 语句中不包含 ROWID

6、寻找大事务
select xid,count(*) from V$LOGMNR_CONTENTS group by xid;

可以观察到有两个40W条的操作记录的大事务。
备注：XID为事务号。V$LOGMNR_CONTENTS视图是由归档日志文件中二进制数据解析成的视图，不同会话加载不同的归档日志文件，通过该视图查询的内容不同，即只会显示各自会话加载归档日志文件的内容。
7、分析大事务中的SQL操作类型
select count(*),operation from V$LOGMNR_CONTENTS where xid='0x0000001F8C5BDFB8' group by OPERATION;

备注：OPERATION中记录了事务中的操作类型。这次运气比较好，在一个归档文件中记录了大事务中的完整的操作，后续根据需要可以考虑多个归档文件联合分析。
8、分析大事务中的执行SQL的明细
select scn,operation,sql_redo from V$LOGMNR_CONTENTS where xid='0x0000001F8C5BDFB8' ORDER by scn desc;

备注：SCN为事务中对应记录的LSN号，可以理解为操作执行的先后顺序。同样是运气很好，很快就能分析出这个事务的操作过程是执行了40W+条插入语句后进行了回滚，然后又进行了删除、插入提交操作。由于是测试库，日志中显示的是模式的对象ID和表ID。
9、结束
此时只需要将事务对应的模式名和表名反馈给用户，让用户侧找业务应用方进行核实，并进行整改。异常处理确认结束后，清理拷贝出来的归档日志文件。
至此，本次异常分析处置过程已结束，完成闭环。
V$LOGMNR_CONTENTS其他相关内容见《DM7/DM8系统管理员手册》。
LOGMNR系统包相关内容见《DM系统包使用手册》