Oracle LogMiner是数据库自带的日志分析工具，它能直接读取重做日志文件，把内部二进制格式的变更记录还原成可执行的SQL语句。比如有人误删了一张表里的几百行数据，只要相关的重做日志或归档日志还在，就能通过LogMiner找到删除操作对应的SQL_UNDO，再执行撤销语句把数据找回来。这个工具不依赖闪回查询，也不要求事先创建闪回恢复区，在数据恢复、审计追踪、变更比对等场景下都能派上用场。
LogMiner的工作原理与核心概念
重做日志记录的是数据库内部所有数据块变更，这些内容以二进制形式保存，直接打开日志文件看到的是一堆无法阅读的符号。LogMiner在分析日志时，会借助一个字典来翻译这些二进制信息。字典记录了表名、列名、数据类型以及对象编号之间的映射关系。没有字典，LogMiner只能输出一堆十六进制片段，无法还原出有意义的SQL语句。字典可以来自在线数据字典，也可以提前提取成平面文件或放入重做日志。
LogMiner的分析过程并不修改任何日志内容，它只是把日志中的变更按照事务顺序展开，并填充到V$LOGMNR_CONTENTS这个动态性能视图里。每条记录对应一个操作，常见的OPERATION值包括INSERT、UPDATE、DELETE、DDL等。SQL_REDO列显示的是重做操作对应的正向SQL，SQL_UNDO列则是撤销该操作所需的逆向SQL。比如一条UPDATE语句将工资从5000改成6000，SQL_REDO会显示UPDATE语句，SQL_UNDO则显示将6000改回5000的语句。这种设计让数据恢复变得非常直观。
适用LogMiner的场景比较广。最常见的是误操作恢复，其次是审计某些敏感表的变更历史，还可以用来分析应用程序在特定时间段内到底执行了哪些DML语句。与数据库闪回相比，LogMiner不需要开启Flashback功能，也不受undo保留时间的限制，只要日志文件存在就能分析。不过它也有局限，比如无法直接还原LOB列的完整内容，分析大量日志时耗时较长。
安装与基础配置
LogMiner从Oracle 8i开始就是数据库内置组件，无需单独安装可执行文件。使用前需要确保当前用户具有执行DBMS_LOGMNR包的权限，通常授予EXECUTE_CATALOG_ROLE角色或者直接赋予EXECUTE ON DBMS_LOGMNR权限即可。如果是普通开发账号，建议由DBA统一授权。
要让LogMiner准确还原SQL语句，必须开启补充日志。默认情况下，Oracle只记录变更后行的部分信息，不一定会记录所有列的值，这会导致SQL_UNDO无法完整构造出撤销语句。执行下面的命令可以开启数据库级补充日志：
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
第一条命令记录所有列的完整值，第二条命令在更新时额外记录主键列信息。开启补充日志会对数据库产生一定的日志量增长，但通常影响很小。如果只是临时分析某几张表，也可以使用表级补充日志，例如ALTER TABLE employees ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;，这样只对目标表生效，避免全库日志膨胀。
字典文件方面，早期Oracle版本常使用平面文件字典，通过DBMS_LOGMNR_D.BUILD过程生成。现在更推荐直接使用在线数据字典，在启动LogMiner时指定DICT_FROM_ONLINE_CATALOG选项即可，这样省去维护字典文件的麻烦。如果分析的是很久以前的归档日志，而表结构已经发生了变化，则需要使用当时提取的字典文件，否则翻译出来的SQL可能与当前表结构不匹配。
使用LogMiner分析日志的完整步骤
分析流程可以概括为四步：添加日志文件、启动LogMiner、查询结果、结束会话。先通过DBMS_LOGMNR.ADD_LOGFILE过程把需要分析的日志文件加入列表。第一个日志文件使用DBMS_LOGMNR.NEW参数，后续文件使用ADDFILE参数。日志文件可以是当前在线重做日志，也可以是归档日志，路径必须写完整的操作系统路径。
-- 添加第一个日志文件
EXECUTE DBMS_LOGMNR.ADD_LOGFILE('/u01/app/oracle/oradata/ORCL/redo03.log', DBMS_LOGMNR.NEW);
-- 添加归档日志
EXECUTE DBMS_LOGMNR.ADD_LOGFILE('/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2024_01_15/o1_mf_1_123_abc.arc', DBMS_LOGMNR.ADDFILE);
日志文件添加完成后，调用START_LOGMNR过程启动分析。OPTIONS参数可以组合多个选项，常用的有DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG表示使用在线数据字典，DBMS_LOGMNR.COMMITTED_DATA_ONLY表示只显示已提交事务的数据。如果不加COMMITTED_DATA_ONLY，查询结果会包含未提交的事务，虽然信息更全但噪音也更多。对于大多数恢复场景，只关注已提交数据就够了。
EXECUTE DBMS_LOGMNR.START_LOGMNR(
OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.COMMITTED_DATA_ONLY
);
启动后就可以像查询普通视图一样访问V$LOGMNR_CONTENTS。这个视图只在当前会话有效，不同会话之间互不干扰。查询时可以加上SEG_NAME、OPERATION、TIMESTAMP等条件缩小范围。例如想查看employees表在某个时间段的删除操作，可以这样写：
SELECT SCN, TIMESTAMP, OPERATION, SQL_REDO, SQL_UNDO
FROM V$LOGMNR_CONTENTS
WHERE SEG_NAME = 'EMPLOYEES'
AND OPERATION = 'DELETE'
AND TIMESTAMP > TO_DATE('2024-01-15 14:00:00', 'YYYY-MM-DD HH24:MI:SS')
ORDER BY SCN;
查询结果中，SQL_UNDO列就是恢复数据的核心。拿到SQL_UNDO后需要人工审核，确认无误后再执行。执行完成后调用END_LOGMNR过程结束分析会话，释放相关资源。如果不主动结束，会话退出时LogMiner也会自动清理，但显式调用更规范。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
结果解读与误删恢复案例
V$LOGMNR_CONTENTS视图里有很多列，最常用的包括SCN、TIMESTAMP、OPERATION、SQL_REDO、SQL_UNDO、USERNAME、SEG_NAME、TABLE_NAME等。OPERATION列告诉用户这次变更的类型，SQL_REDO是数据库实际执行的正向语句，SQL_UNDO是反向撤销语句。例如一条INSERT操作，SQL_REDO显示插入语句，SQL_UNDO显示删除该行的语句。对于UPDATE，SQL_REDO和SQL_UNDO是成对的正反更新语句。
假设某开发人员在下午误删除了employees表中department_id等于50的所有员工记录，并且已经提交。这时候可以先找到包含该时间段的归档日志，将其加入LogMiner分析列表。启动分析后执行查询：
SELECT SQL_UNDO
FROM V$LOGMNR_CONTENTS
WHERE SEG_NAME = 'EMPLOYEES'
AND OPERATION = 'DELETE'
AND TIMESTAMP > TO_DATE('2024-01-15 14:00:00', 'YYYY-MM-DD HH24:MI:SS')
AND TIMESTAMP < TO_DATE('2024-01-15 15:00:00', 'YYYY-MM-DD HH24:MI:SS');
查询结果会返回若干条DELETE对应的SQL_UNDO，每条SQL_UNDO都是一个INSERT语句，包含了被删除行的完整列值。把这些INSERT语句复制出来，核对一下数据内容，然后在业务低峰期执行，数据就能恢复。如果删除的行数很多，手工复制SQL_UNDO不太现实，可以写一个PL/SQL块遍历游标动态执行SQL_UNDO，但执行前务必在测试环境验证。
需要注意的是，SQL_UNDO中如果涉及LOB列、LONG列或者某些特殊类型，LogMiner可能无法完整还原，这时需要结合其他备份手段。另外，如果删除操作之后又发生过其他DML操作，直接执行SQL_UNDO可能会覆盖后续变更，恢复前要仔细检查时间线。
注意事项与性能优化建议
LogMiner分析大量日志时会消耗不少CPU和内存资源，尤其是在对几十GB的归档日志做全量扫描时，会话可能会运行很长时间。为了减少资源占用，建议在分析时尽量使用过滤条件，比如通过START_LOGMNR的STARTTIME和ENDTIME参数限定时间范围，或者在查询V$LOGMNR_CONTENTS时只选取需要的列和条件。不要在没有过滤条件的情况下直接SELECT *，那样会返回海量数据。
补充日志虽然能提高SQL还原的完整性，但也会增加日志写入量。对于高并发写入的生产库，开启全列补充日志前最好评估一下磁盘空间和日志切换频率。如果只是偶尔分析，可以在分析完成后关闭不必要的补充日志，例如使用ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;来降低长期开销。
另外，LogMiner会话是会话级的，分析结果不会持久化保存。如果需要在多个会话中查看分析结果，可以把V$LOGMNR_CONTENTS的数据插入到一张普通表里保存起来。还有一点，在线重做日志在切换后可能被覆盖，如果怀疑有人误操作，应尽快将相关日志文件复制出来或确保归档日志存在，否则日志一旦被覆盖，LogMiner就无能为力了。日常运维中建议开启归档模式，并保留足够的归档日志，这样误操作发生后才有足够的分析素材。
Oracle LogMiner日志分析数据恢复修改时间：2026-10-02 12:23:21