LogMiner是Oracle从8i开始引入、在9i中得到显著增强的日志分析工具。它能够对联机重做日志和归档日志进行解析，将其中记录的二进制变更数据翻译成带有SQL语句的可读形式。对于审计追踪、误操作恢复、增量数据抽取等场景，LogMiner几乎是DBA必备的技能之一。本文将以Oracle 9i环境为基础，完整演示LogMiner的配置与分析过程。
一、LogMiner的基本原理与适用场景
Oracle数据库的所有变更操作都会先写入重做日志缓冲区，再由LGWR进程写入联机重做日志文件，最终归档为归档日志。这些日志以二进制格式存储，直接打开根本无法阅读。LogMiner的作用就是把这些二进制记录逆向解析，还原出操作发生时的SQL语句，同时还可以生成对应的反向SQL，也就是UNDO语句，方便做数据回滚。
在9i版本中，LogMiner有以下几个典型的使用场景：第一是审计分析，比如某张表的数据被不明原因修改，可以通过挖掘日志定位操作时间、操作用户和客户端主机；第二是误操作恢复，利用反向SQL撤销错误的UPDATE或DELETE；第三是辅助增量数据同步，一些第三方同步工具底层就是调用LogMiner来捕获变更；第四是分析数据库的负载特征，统计各类DML操作的比例。
需要注意的是，LogMiner只能解析DML语句和部分DDL语句，对于SELECT查询是无能为力的，因为查询操作本身不产生redo日志。另外，挖掘过程中支持的字符集、数据类型也有一定限制，比如LONG、LOB等大对象类型在9i中只能看到操作记录，无法还原完整内容。
二、使用前的准备：补充日志与归档模式
在正式开始挖掘之前，数据库需要满足两个基本条件。首先是数据库必须运行在归档模式下，否则联机日志被覆盖后就无法追溯历史变更。可以通过以下命令检查并调整归档模式：
-- 检查是否处于归档模式 SQL> archive log list; -- 如果是NOARCHIVELOG模式，需要重启到mount状态再切换 SQL> shutdown immediate; SQL> startup mount; SQL> alter database archivelog; SQL> alter database open;
第二个条件是建议开启补充日志。默认情况下，redo日志只记录被修改列的信息，如果UPDATE语句只改了一个字段，挖掘出来的SQL中将无法看到其他字段的旧值，定位具体行会变得困难。开启最小补充日志后，Oracle会在日志中额外记录行的唯一标识信息，让还原出的SQL语句可以精确定位到具体数据行。
-- 开启最小补充日志 SQL> alter database add supplemental log data; -- 查看补充日志状态 SQL> select supplemental_log_data_min from v$database;
此外还需要确认当前用户拥有执行DBMS_LOGMNR包的权限，一般使用SYS用户即可，普通用户需要被授予EXECUTE_CATALOG_ROLE角色。相关角色权限授予语句如下：
GRANT EXECUTE_CATALOG_ROLE TO myuser;
三、挖掘实战：字典文件与DBMS_LOGMNR的完整流程
LogMiner的使用分三步走：添加日志文件、启动挖掘、查询结果。其中最关键的环节是字典信息的处理。日志中的对象编号、列编号都是内部标识，必须借助数据字典才能翻译成表名和列名。9i提供了三种字典来源方式，这里重点介绍最常用的提取字典文件方式。
第一步是生成字典文件。字典文件需要在源数据库上生成，并且要提前配置UTL_FILE_DIR参数指定输出目录：
-- 配置字典文件输出目录（需要重启生效）
SQL> alter system set utl_file_dir='/oracle/logmnr' scope=spfile;
-- 生成字典文件
SQL> execute dbms_logmnr_d.build( -
dictionary_filename => 'dict.ora', -
dictionary_location => '/oracle/logmnr');
第二步是添加待分析的日志文件。可以添加联机日志，也可以添加归档日志，建议把时间范围内的归档日志一次性全部加入：
-- 添加归档日志，new选项表示新建立日志列表
SQL> execute dbms_logmnr.add_logfile( -
logfilename => '/oracle/archive/1_100.arc', -
options => dbms_logmnr.new);
-- 追加更多日志文件用addfile选项
SQL> execute dbms_logmnr.add_logfile( -
logfilename => '/oracle/archive/1_101.arc', -
options => dbms_logmnr.addfile);
第三步是启动挖掘并查询结果。启动时通过dictfromonlinedcatalog或指定字典文件的方式加载字典信息：
-- 使用字典文件启动挖掘
SQL> execute dbms_logmnr.start_logmnr( -
dictfilename => '/oracle/logmnr/dict.ora');
-- 查询挖掘结果
SQL> select to_char(timestamp,'yyyy-mm-dd hh24:mi:ss') op_time,
username, table_name, operation,
sql_redo, sql_undo
from v$logmnr_contents
where table_name = 'EMP';
查询结果中，SQL_REDO列记录了原始执行的SQL语句，SQL_UNDO列则是可以用来撤销该操作的回滚语句，这两个字段是日志分析中最核心的输出。v$logmnr_contents视图中还包含SESSION_INFO列，可以看到操作发起的客户端程序和登录用户，OPERATION列区分INSERT、UPDATE、DELETE、DDL等操作类型。
四、字典模式选择与常见问题处理
关于字典来源，三种方式各有优劣。使用字典文件方式的优点是挖掘环境可以独立于源数据库，适合分析从其他服务器拷贝过来的归档日志，缺点是字典文件生成之后如果表结构发生变更，挖掘结果会出现偏差。使用在线数据字典方式操作最简单，直接指定dictfromonlinedcatalog选项即可，但要求挖掘会话连接的就是源数据库本身。第三种是9i新增强的从redo日志中提取字典，通过dbms_logmnr_d.build的store_in_redo_logs选项把字典写入日志，适合源库与挖掘库版本字符集不一致的复杂场景。
实际操作中常见的报错有几个。第一个是ORA-01291表示找不到字典文件或字典文件与日志版本不匹配，此时应确认字典文件路径正确，且是在日志产生期间生成的。第二个是挖掘结果的SQL_REDO中出现十六进制数据或bin$开头的对象名，多半是字典没有正确加载，或者被挖掘对象在字典生成之后发生过结构变更。第三个是v$logmnr_contents查询报错ORA-01306表示在from子句之外引用了挖掘视图字段，这是因为该视图只允许在特定会话中查询。
还要特别提醒一点，v$logmnr_contents是一个会话级视图，挖掘结果只存在于执行start_logmnr的当前会话中，一旦会话断开或执行了end_logmnr，数据就会消失。因此查询到有价值的信息后要及时插入到普通表中留存，分析结束后记得调用dbms_logmnr.end_logmnr释放资源：
-- 将挖掘结果保存到普通表
SQL> create table logmnr_result as
select * from v$logmnr_contents;
-- 结束挖掘会话
SQL> execute dbms_logmnr.end_logmnr;
掌握LogMiner之后，面对突发的数据误删、可疑的权限变更等审计需求，你就多了一件趁手的排查利器。建议在日常运维中定期归档日志并妥善保存，同时保持补充日志处于开启状态，这样在事故发生时才能有完整的日志可供挖掘。
Oracle LogMiner日志挖掘redo日志分析修改时间：2026-08-31 08:22:53