在实际开发过程中，有时我们很有可能需要某个表的操作痕迹，或通过记录的SQL语句进行有目的性的数据恢复（此时POINT-IN-TIME恢复已经满足不了更细的粒度）、或仅仅是查看；
据说Oracle8i之后，就提供了Logminer日志分析工具，虽然没有GUI图形化的界面，但也阻挡不了使用他的决心。
Oracle11g下使用的情况：
(1)、数据库开启归档模式
在安装Logminer之前，我们先讲数据库设置为归档模式：
注意：如果开启日志分析功能，仅仅是分析系统默认的Redo01.log、Redo02.log、Redo03.log是不够的，因为重做日志是循环填充的方式，下一个循环周期开启就是丢失上一个周期的日志信息，势必需要将重做日志进行归档保存。
windows下利用cmd下sqlplus命令登录oracle，并查看归档模式，如果未归档，需要在mount状态下，开启归档模式，最好打开数据库：
1 //cmd下连接数据库 2 C:\Users\Administrator>sqlplus sys/123456@orcl as sysdba 3 4 //连接成功后，查看归档模式 5 SQL> archive log list; 6 Database log mode No Archive Mode //非归档模式 7 ... 9 //关闭数据库 10 SQL> shutdown immediate; 11 ... 13 //以mount状态启动数据库 14 SQL> startup mount; 15 ... 16 SQL> alter database archivelog;//启动归档模式 17 Database altered. 19 SQL> archive log list; 20 Database log mode Archive Mode //此时已是归档模式 22 //打开数据库 23 SQL> alter database open;
(2)、安装Logminer
首先，需要确定您安装的oracle版本的数据库是否具备Logminer，在安装目录下查看，即$ORACLE_HOME/rdbms/admin下是否有dbmslm.sql、dbmslmd.sql，我安装目录下的两个文件：
1 D:\app\admin\product\11.2.0\dbhome_1\RDBMS\ADMIN\dbmslm.sql 2 D:\app\admin\product\11.2.0\dbhome_1\RDBMS\ADMIN\dbmslmd.sql
执行安装命令（使用具有dba的权限来执行安装，可以用sys用户登录，然后执行SQL>grant dba to SCOTT;，这样scott用户就具有dab的权限）
安装成功后，可以在PL/SQL Developer 的左边对象Objects导航中的Packages包下会找到DBMS_LOGMNR、DBMS_LOGMNR_D包，其中：
DBMS_LOGMNR：用来分析日志文件
DBMS_LOGMNR_D：用来创建数据字典文件
(3)、创建数据字典文件
数据字典文件中会包括数据库的DB_ID，以及编码格式，如果不创建数据字典文件，默认解析的日志信息均以16进制编码格式进行展示，无法直观理解，下面我们使用命令创建数据字典文件：
需要创建数据字典目录和数据字典文件
首先，创建数据字典目录
CREATE DIRECTORY utlfile AS ‘D:\app\admin\oradata\orcl\LOGMNR‘; alter system set utl_file_dir=‘D:\\app\admin\oradata\orcl\LOGMNR‘ scope=spfile;
同时，开启附加日志模式，关于附加日志supplemental log的解释：可以指示数据库在日志中添加额外信息到日志流中，以支持基于日志的工具，如逻辑standby、streams、GoldenGate、LogMiner。
alter database add supplemental log data;
进行到此时，需要重启下数据库，因为在添加字段目录的时候，我们使用的是‘scope=spfile‘，即下次启动时生效。
//关闭数据库 SHUTDOWN IMMEDIATE; //启动数据库 STARTUP;
如果想验证数据字典是否设置成功，可以在命令行输入以下命令，查看：(出现下面截图所示可表示设置目录成功)
SHOW PARAMETER utl_file_dir;
创建好目录后，继续使用具有dba权限的SCOOT用户，创建数据字典文件：
EXECUTE dbms_logmnr_d.build(dictionary_filename => ‘dictionary.ora‘, dictionary_location =>‘D:\app\admin\oradata\orcl\LOGMNR‘);
(4)、分析日志文件
SCOTT用户下，对数据进行一些操作
-- 创建简单表 create table WY_TEST(ID NUMBER(10,0),USERNAME VARCHAR2(10)); SELECT * FROM WY_TEST; -- 此时查询内容为空 -- 插入两条数据 INSERT INTO WY_TEST(ID,USERNAME) VALUES(1,‘WY01‘); INSERT INTO WY_TEST(ID,USERNAME) VALUES(2,‘WY02‘); COMMIT; SELECT * FROM WY_TEST; -- 查询验证插入是否成功 -- 修改内容 UPDATE WY_TEST SET USERNAME=‘WY03‘ WHERE ID=2; COMMIT; SELECT * FROM WY_TEST; -- 查询验证修改是否成功 --删除内容 DELETE FROM WY_TEST WHERE ID=2; COMMIT; SELECT * FROM WY_TEST; -- 此时表中内容：ID=1，USERNAME=‘WY01‘
据介绍，当表数据发生变化后，需要重新创建数据字典文件，所以，此时，我们需要重新执行下创建数据文件的语句：
EXECUTE dbms_logmnr_d.build(dictionary_filename => ‘dictionary.ora‘, dictionary_location =>‘D:\app\admin\oradata\orcl\LOGMNR‘);
此时，开始加载日志文件进行分析，您可以加载当前正在使用的日志文件，也可以像我这样，把三个重做日志文件均加载进去；
SQL> begin 2 dbms_logmnr.add_logfile(LogFileName=>‘D:\app\admin\oradata\orcl\REDO01.LOG‘,Options=>dbms_logmnr.NEW); 3 END; 4 / SQL> BEGIN 2 dbms_logmnr.add_logfile(LogFileName=>‘D:\app\admin\oradata\orcl\REDO02.LOG‘,Options=>dbms_logmnr.ADDFILE); 3 dbms_logmnr.add_logfile(LogFileName=>‘D:\app\admin\oradata\orcl\REDO03.LOG‘,Options=>dbms_logmnr.ADDFILE); 4 END; 5 /
接下来，使用Logminer对日志文件进行分析
SQL> Execute dbms_logmnr.start_logmnr(DictFileName=>‘D:\app\admin\oradata\orcl\LOGMNR\dictionary.ora‘);
执行命令成功后，我们可以在v$logmnr_contents视图中进行查看到操作的日志内容
SQL> SELECT sql_redo, sql_undo from v$logmnr_contents where seg_name=‘WY_TEST‘;
从截图中，可以看到所有执行的痕迹，以及撤销此步骤的UNDO SQL，从这点看出，日志分析还是非常有用的。
上面提到过，如果可以‘分析’当前正在使用的Redo Log，通过下面的语句查询
SELECT GROUP#,SequencE#,status,first_change# from v$LOG ORDER BY FIRST_CHANGE#;
从运行的截图中可以看到，当前使用的是Redo03.Log，所以在上面使用Logminer进行分析的时候，仅需要加载Redo03.Log日志文件进行分析即可
(5)、分析归档日志文件
我们知道，只有到Redo Log写满后进行自动切换时，如果数据库开启归档模式，会将已满的Redo Log写入到归档日志中，我们也可以手动进行切换（通常，多执行几次）
ALTER SYSTEM SWITCH LOGFILE;
我们执行后，会发现，flash_recovery_area目录下会出现orcl\ArchiveLog目录(没有设置归档的目录，默认是在flash_recovery_area下面)
注：可以通过以下方式，查询到归档日志目录
select sequence#, FIRST_CHANGE#, NEXT_CHANGE#,name from v$archived_log order by sequence# desc
此时，我只要选择将最新的归档日志进行分析，即可
SQL> begin 2 dbms_logmnr.add_logfile(LogFileName=>‘D:\app\admin\flash_recovery_area\orcl\ARCHIVELOG\2017_08_19\O1_MF_1_18_DSH8OJF9_.ARC‘,options=>dbms_logmnr.new); 3 end; 4 /
从截图中可以看到，执行的效果和分析Redo Log的结果相同
欢迎大家补充指导，共同学习！