logminer 基本操作
概念
logminer可以干什么
实例恢复时要用到online redo log。介质恢复时要用到archived redo log。除此以外，ORACLE的重做记录流可以用于下面三个目的：
⊙ ORACLE的重做记录流可以指出逻辑错误,比如误删除数据、是谁删除的。如果我们误删除，或者更新了数据，除了闪回等技术。还可以挖掘日志，来还原操作，救出误操作的数据
⊙ 可以纠正用户错误，如删除了错误的行、修改了错误的值、删除了错误的索引，可以用重做记录流来还原。可以用于审计某用户什么时候做了什么操作
⊙ 可以分析表的DML语句，对过于活动的语句优先进行优化
我们要实现上面的功能，可以通过ORACLE提供的工具来实现，那就是LOGMNR。
v$logmnr_contents
LOGMINER是ORACLE一个功能强大的工具。可以用它将在线日志或者归档日志的重做记录流转换成SQL文本保存(vlogmnr_contents)，并可以用LOGMINER来恢复部分丢失的数据。vlogmnr_contents 这个很重要的视图。我们先来看一下视图里的这几个列 :
⊙ operation
Number of the operation code:
• 0 - INTERNAL
• 1 - INSERT
• 2 - DELETE
• 3 - UPDATE
• 5 - DDL
• 6 - START
• 7 - COMMIT
• 9 - SELECT_LOB_LOCATOR
• 10 - LOB_WRITE
• 11 - LOB_TRIM
• 25 - SELECT_FOR_UPDATE
• 28 - LOB_ERASE
• 34 - MISSING_SCN
• 68 - XML DOC BEGIN
• 70 = XML DOC WRITE
• 71 = XML DOC END
• 36 - ROLLBACK
• 255 - UNSUPPORTED
⊙ SQL_REDO 重构原始语句需要的SQL语句
⊙ SQL_UNDO 重构原始语句UNDO改变需要的SQL语句
后面两个就是我们抽取出来的SQL代码，我们就是要获取这些数据来还原数据，我们就是要获取这些数据来还原数据，特别是SQL_UNDO。
⊙ SCN 系统改变号
⊙ CSCN commit scn 事务提交时的系统改变号
logminer 限制条件
对于logminer来说，它需要以下几个组件
⊙ source database 源库，也就是我们要分析的redo log的来源库
⊙ mining database 执行库，也就是我们要用来挖掘日志的库。当然，源库和挖掘库也可以是一个
⊙ logminer 字典
⊙ redo log files
以下是对LogMiner将要挖掘的源数据库、挖掘数据库、数据字典和重做日志文件的要求：
- 源和挖掘数据库
1、源数据库和挖掘数据库都必须在相同的硬件平台上运行。
2、挖掘数据库可以与源数据库相同或完全独立。
3、挖掘数据库必须与源数据库一样运行Oracle数据库软件的相同版本或更高版本。就像我们的exp出来的文件，低的可以imp到高版本，反之不行。因为LOGMNR是在mining database上运行，高级工具才可以处理低级的数据
4、挖掘数据库必须使用源数据库使用的相同字符集（或字符集的超集）。 - LogMiner字典
字典必须由生成LogMiner将分析的重做日志文件的相同源数据库生成。 - 所有重做日志文件：
1、必须由相同的源数据库生成。
2、必须与相同的数据库相关联RESETLOGS SCN。
3、必须来自8.0或更高版本的Oracle数据库。但是，从版本9.0.1开始引入的一些LogMiner功能仅适用于在Oracle9 i或更高版本的数据库上生成的重做日志文件。
logminer 数据字典选项
LOGMNR的数据字典选项
1、使用源数据库的联机数据字典
2、抽取字典信息到在线日志中
3、外部字典文件
LogMiner三种方式生成数据字典：
这三种方式先介绍一下 ：
⊙ Extracting the Dictionary to a Flat File
flat 文件，比如txt文件等。就是一个外部文件
我们把表名、列名、类型名等对应关系用LOGMNR BUILD字典保存到一个外部文件上
注意，必须BUILD主库的字典，否则对应关系就不一致了，张冠李戴了
成为外部字典文件，将来要用LOGMINER分析时，将读取该文件，才能转换成想要的SQL
⊙ Extracting a Dictionary to the Redo Logs
从数据字典抽取，然后保存到redo logfile中，那我们要去抽取SQL时，要用到LOGFILE中的字典
⊙ Using the Online Catalog
这里数据字典就是row cache中，不需要再另存为了，直接使用在线的数据字典，使用online的字典。直接使用数据库的数据字典，但是该方法只能在线操作，数据库必须OPEN，而且必须在source database（源数据库）上做。因为mining database上做也必须保证有数据字典信息，所以mining database和source database是同一个库。这三种方式里，推荐的是第二种。第一种是不建议的，容易形成数据的不一致，第三种有局限性
logminer 大概步骤
一个典型的logminer的操作包含如下步骤：
- 进行初始化设置；
- 提取一个字典
- 指定需要分析的redo日志文件
- 开始logminer
- 查询v$logmnr_contents视图
- 结束logminer
总的步骤是：设置字典模式、增加日志文件、启动logminer。
1.先要设置数据字典模式
2.增加日志文件。
exec sys.dbms_lgmnr.add_logfile(’’,dbms_logmr.new);
注意，如果是第一个要解析的日志文件，后面需要加NEW。第二个之后，选项将改变，LOGMINER可以同时分析多个在线或归档日志，这时候要使用dbms_logmnr.addfile
3.启动日志管理器。根据字典方式不同，启动语句也有差别
具体说明
以下是logmnr对应的视图
v$logmnr_dictionary 因logmnr可以有多个字典文件，该视图用于显示这方面信息。
v$logmnr_parameters 它用于显示logmnr的参数。
v$logmnr_logs 它用于显示用于分析的日志列表信息。
下面对其中步骤做一个特殊说明：
1、创建要分析的日志文件列表
Oracle的重作日志分为两种，在线（online）和离线（offline）归档日志文件，下面就分别来讨论这两种不同日志文件的列表创建。
（1）分析在线重作日志文件
A. 创建列表
SQL> EXECUTE dbms_logmnr.add_logfile(
LogFileName=>’ e:\Oracle\oradata\sxf\redo01.log’,
Options=>dbms_logmnr.new);
B. 添加其他日志文件到列表
SQL> EXECUTE dbms_logmnr.add_logfile(
LogFileName=>’ e:\Oracle\oradata\sxf\redo02.log’,
Options=>dbms_logmnr.addfile);
（2）分析离线日志文件
A.创建列表
SQL> EXECUTE dbms_logmnr.add_logfile(
LogFileName=>’ E:\Oracle\oradata\sxf\archive\ARCARC09108.001’,
Options=>dbms_logmnr.new);
B.添加另外的日志文件到列表
SQL> EXECUTE dbms_logmnr.add_logfile(
LogFileName=>’ E:\Oracle\oradata\sxf\archive\ARCARC09109.001’,
Options=>dbms_logmnr.addfile);
关于这个日志文件列表中需要分析日志文件的个数完全由你自己决定，但这里建议最好是每次只添加一个需要分析的日志文件，在对该文件分析完毕后，再添加另外的文件。
和添加日志分析列表相对应，使用过程 ‘dbms_logmnr.removefile’ 也可以从列表中移去一个日志文件。下面的例子移去上面添加的日志文件e:\Oracle\oradata\sxf\redo02.log。
SQL> EXECUTE dbms_logmnr.add_logfile(
LogFileName=>’ e:\Oracle\oradata\sxf\redo02.log’,
Options=>dbms_logmnr. REMOVEFILE);
可以通过动态性能视图v$logmnr_logs查看日志分析列表中有哪些待分析的日志文件。
创建了要分析的日志文件列表，下面就可以对其进行分析了。
2、使用LogMiner进行日志分析
（1）无限制条件
SQL> EXECUTE dbms_logmnr.start_logmnr(
DictFileName=>’ e:\oracle\logs\ v816dict.ora ');
（2）有限制条件
通过对过程DBMS_ LOGMNR.START_LOGMNR中几个不同参数的设置（参数含义见表1），可以缩小要分析日志文件的范围。通过设置起始时间和终止时间参数我们可以限制只分析某一时间范围的日志。如下面的例子，我们仅仅分析2001年9月18日的日志：
SQL> EXECUTE dbms_logmnr.start_logmnr(
DictFileName => ’ e:\oracle\logs\ v816dict.ora ‘,
StartTime => to_date(‘2001-9-18 00:00:00’,‘YYYY-MM-DD HH24:MI:SS’)
EndTime => to_date(’‘2001-9-18 23:59:59’,'YYYY-MM-DD HH24:MI:SS '));
注意：此过程能否执行成功的关键是给出的starttime（起始时间）和endtime（终止时
间）应在一个有效的范围内。特别是终止时间，应小于或等于归档日志的建立时间；如果大于
归档日志的建立时间，则不能执行分析过程。分析多个归档日志时，这些归档日志最好是连续
也可以通过设置起始SCN和截至SCN来限制要分析日志的范围：
SQL> EXECUTE dbms_logmnr.start_logmnr(
DictFileName => ’ e:\oracle\logs\ v816dict.ora ',
StartScn => 20,
EndScn => 50);
表1 DBMS_LOGMNR.START__LOGMNR过程参数含义
参数 参数类型 默认值 含义
StartScn 数字型（Number） 0 分析重作日志中SCN≥StartScn日志文件部分
EndScn 数字型（Number） 0 分析重作日志中SCN≤EndScn日志文件部分
StartTime 日期型(Date) 1998-01-01 分析重作日志中时间戳≥StartTime的日志文件部分
EndTime 日期型(Date) 2988-01-01 分析重作日志中时间戳≤EndTime的日志文件部分
DictFileName 字符型(VARCHAR2) 字典文件，该文件包含一个数据库目录的快照。使用该文件可以使得到的分析结果是可以理解的文本形式，而非系统内部的16进制
Options BINARY_INTEGER 0 系统调试参数，实际很少使用
在执行分析的时候如果提示无效的月份，可以按照下面的步骤去尝试：
alter session set nls_date_language=‘AMERICAN’;
alter session set nls_date_format=‘DD-MON-YYYY HH:MI:SS’;
执行包(exec dbms_logmnr.start_logmnr(dictfilename=>’’);
一定要指名参数dictfilename，因为这个包有五个默认的参数，不指名会默认为第一个。
Extracting a Dictionary to the Redo Logs–抽取数据字典到在线日志中
Extracting a Dictionary to the Redo Logs：把字典数据保存在redo log file里。这是推荐的，但造成log file 变大。但是必须启用归档。
抽取字典信息到在线日志中的实验，必须在归档模式下才行，需要知道数据字典放在哪个日志里，在v$archived_log里的dictionary_begin=yes，可以看出build的日志文件是哪个，在分析logminer时，必须把有字典的logfile也加进去，才能转换sql出来，对于要美化sql语句，我们需要用到PRINT_PRETTY_SQL 。DICT_FROM_REDO_LOGS。
使用这种方式，必须保证数据库打开并在归档模式下，并且archiving被激活。在解析到重做日志的过程中，所有的DDL语句都不能执行。所以这种方式能保证数据字典的快照与当前的数据字典一致
1、必须在归档模式下运行。
SQL> archive log list;
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch
Oldest online log sequence 63
Current log sequence 65
SQL> execute dbms_logmnr_d.build(options=>dbms_logmnr_d.store_in_redo_logs);
BEGIN dbms_logmnr_d.build(options=>dbms_logmnr_d.store_in_redo_logs); END;
*
ERROR at line 1:
ORA-01325: archive log mode must be enabled to build into the logstream
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 3419
ORA-00258: manual archiving in NOARCHIVELOG mode must identify log
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 6110
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 6208
ORA-06512: at "SYS.DBMS_LOGMNR_D", line 12
ORA-06512: at line 1
- 在线日志里BUILD数据字典 --相当于在此刻，备份了此刻的数据字典到redo log中
execute dbms_logmnr_d.build(options=>dbms_logmnr_d.store_in_redo_logs);
SQL> execute dbms_logmnr_d.build(options=>dbms_logmnr_d.store_in_redo_logs);
PL/SQL procedure successfully completed.
２．可以通过下面的sql来确认redo log中包含了数据字典的信息：
select SEQUENCE#,name from v$archived_log where dictionary_begin=‘YES’;
下面模拟挖掘的一个过程：
基础环境准备
1、我们创建了一张表，里面的数据如下：
conn scott/tiger;
create table t1 (id int primary key,name varchar2(10),key number);
insert into t1 values(1,‘aaa’,10);
insert into t1 values(2,‘bbb’,11);
insert into t1 values(3,‘ccc’,12);
insert into t1 values(4,‘ddd’,13);
commit;
SQL> alter database archivelog;
Database altered.
SQL> alter database open;
Database altered.
SQL> conn scott/tiger;
Connected.
SQL> select * from t1;
ID NAME KEY
---------- ---------------------------------------------------------------------- ----------
1 aaa 10
2 bbb 11
3 ccc 12
4 ddd 13
2、我们做了一个update，为了避免相互影响，做之前和做之后都会做一个切换日志。保证这个归档日志只有这一个事务。
SQL> alter system switch logfile;
System altered.
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------ ------------ ------------
1 1 52 52428800 512 1 YES INACTIVE 752562 21-NOV-19 753214 21-NOV-19
2 1 53 52428800 512 1 YES ACTIVE 753214 21-NOV-19 764652 22-MAR-22
3 1 54 52428800 512 1 NO CURRENT 764652 22-MAR-22 2.8147E+14
SQL> update scott.t1 set name='eee' where key=10;
1 row updated.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
System altered.
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------ ------------ ------------
1 1 55 52428800 512 1 NO CURRENT 764665 22-MAR-22 2.8147E+14
2 1 53 52428800 512 1 YES ACTIVE 753214 21-NOV-19 764652 22-MAR-22
3 1 54 52428800 512 1 YES ACTIVE 764652 22-MAR-22 764665 22-MAR-22
同上如上操作，我们能看到，UPDATE的REDO应该记录在日志序列号54文件里。
查看54号日志对应的归档日志：
SQL> select name from v$archived_log where SEQUENCE#=54;
NAME
----------------------------------------------------------------------
/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_54_1024919054.dbf
将数据字典解析到重做日志里。
SQL> execute dbms_logmnr_d.build(options=>dbms_logmnr_d.store_in_redo_logs);
BEGIN dbms_logmnr_d.build(options=>dbms_logmnr_d.store_in_redo_logs); END;
*
ERROR at line 1:
ORA-01354: Supplemental log data must be added to run this command
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 6110
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 6208
ORA-06512: at "SYS.DBMS_LOGMNR_D", line 12
ORA-06512: at line 1
SQL> conn / as sysdba
Connected.
SQL> execute dbms_logmnr_d.build(options=>dbms_logmnr_d.store_in_redo_logs);
BEGIN dbms_logmnr_d.build(options=>dbms_logmnr_d.store_in_redo_logs); END;
*
ERROR at line 1:
ORA-01354: Supplemental log data must be added to run this command
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 6110
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 6208
ORA-06512: at "SYS.DBMS_LOGMNR_D", line 12
ORA-06512: at line 1
SQL> alter database add supplemental log data;
Database altered.
SQL> execute dbms_logmnr_d.build(options=>dbms_logmnr_d.store_in_redo_logs);
PL/SQL procedure successfully completed.
我们必须打开最小追加日志模式，才能运用logmnr查询到DML操作的日志信息。
普通的redo日志记录的东西不足以用logminer还原出sql来。还需要额外的信息才行。所以，这里就需要另一种日志，辅助日志，启动辅助日志后才可以更好的利用LOGMNR功能。比如辅助日志，可以增加更多的列到日志文件中，而不是只记录X列的变化，或者辅助日志可以记录KEY，KEY是主键，可以唯一标识一行
查询数据字典所在日志文件的头和尾
SQL> col name for a70
SQL> select SEQUENCE#,name from v$archived_log where dictionary_begin='YES';
SEQUENCE# NAME
---------- ----------------------------------------------------------------------
56 /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_56_1024919054.dbf
57 /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_57_1024919054.dbf
58 /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_58_1024919054.dbf
可以看到，我们build完后，oracle 会自动切换日志，build一次就会保存一次数据字典，虽然报错了2次，现在我们的字典信息是保存在58号日志文件中的，为最新的，所以我们就要用58号日志。为了分析之前或者之后的日志，我们必须要先有数据字典，所以必须先加载58号日志文件。
我们可以看到，包含了数据字典的归档日志会很大，比其他的要大，具体大小取决于你的数据库元数据大小。
[oracle@oracle11g dbs]$ ls -ltrh arch*
[oracle@oracle11g dbs]$ ls -ltrh arch*
-rw-r-----. 1 oracle oinstall 42M Mar 22 23:51 arch1_53_1024919054.dbf
-rw-r-----. 1 oracle oinstall 3.0K Mar 22 23:51 arch1_54_1024919054.dbf
-rw-r-----. 1 oracle oinstall 5.0K Mar 22 23:53 arch1_55_1024919054.dbf
-rw-r-----. 1 oracle oinstall 120K Mar 22 23:53 arch1_56_1024919054.dbf
-rw-r-----. 1 oracle oinstall 121K Mar 22 23:53 arch1_57_1024919054.dbf
-rw-r-----. 1 oracle oinstall 15M Mar 22 23:53 arch1_58_1024919054.dbf
58号日志文件就特别大。
把58和54号归档日志，拷贝到我们的测试库，进行分析。
[oracle@oracle11g dbs]$ scp arch1_58_1024919054.dbf 10.1.11.12:/home/oracle/ The authenticity of host '10.1.11.12 (10.1.11.12)' can't be established. RSA key fingerprint is 11:1b:05:8d:81:24:b3:b1:68:26:47:78:76:ae:a1:5c. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.1.11.12' (RSA) to the list of known hosts. oracle@10.1.11.12's password: arch1_58_1024919054.dbf 100% 14MB 14.4MB/s 00:00 [oracle@oracle11g dbs]$ scp arch1_54_1024919054.dbf 10.1.11.12:/home/oracle/ oracle@10.1.11.12's password: arch1_54_1024919054.dbf
测试库添加归档日志文件，先添加58号文件，所以是new，在添加54号文件，所以是addfile。
SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME => '/home/oracle/arch1_58_1024919054.dbf', OPTIONS => DBMS_LOGMNR.NEW);
PL/SQL procedure successfully completed.
SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME => '/home/oracle/arch1_54_1024919054.dbf',OPTIONS => DBMS_LOGMNR.ADDFILE);
PL/SQL procedure successfully completed.
测试库开启logminer
EXECUTE DBMS_LOGMNR.START_LOGMNR(-
OPTIONS => DBMS_LOGMNR.DICT_FROM_REDO_LOGS + -
DBMS_LOGMNR.PRINT_PRETTY_SQL);
查询
SQL> set linesize 200
set pagesize 200
SQL> SQL> col USR for a10
SQL> col sql_redo for a50
SQL> col SQL_UNDO for a50
SQL> SELECT USERNAME AS usr,SQL_REDO,SQL_UNDO FROM
2 V$LOGMNR_CONTENTS
3 WHERE SEG_OWNER ='SCOTT';
no rows selected
明明修改的是scott用户下的表，但是查询不到任何结果。
即使更新的是主键，也不会挖掘到。SQL> update t1 set id=5 where id=1;
可能与附加日志有关，我们在update的时候，没开启附加日志，而是update完后，准备挖的时候，才开了附加日志，所以有可能redo没记录到，所以我们再做一遍测试，这次是附加日志已经开启，再update，过程同上面，最后结果为：
SQL> set linesize 200
SQL> set pagesize 200
SQL> col USR for a10
SQL> col sql_redo for a50
SQL> col SQL_UNDO for a50
SQL> SELECT USERNAME AS usr,SQL_REDO,SQL_UNDO FROM
2 V$LOGMNR_CONTENTS
3 WHERE SEG_OWNER ='SCOTT';
USR SQL_REDO SQL_UNDO
---------- -------------------------------------------------- --------------------------------------------------
SCOTT update "SCOTT"."T1" update "SCOTT"."T1"
set set
"NAME" = 'fff' "NAME" = 'bbb'
where where
"NAME" = 'bbb' and "NAME" = 'fff' and
ROWID = 'AAATr3AAEAAAACvAAB'; ROWID = 'AAATr3AAEAAAACvAAB';
经测试：insert和delete都按照如上方法，可以挖到。
SQL> SELECT USERNAME AS usr,SQL_REDO,SQL_UNDO FROM
2 V$LOGMNR_CONTENTS
3 WHERE SEG_OWNER ='SCOTT';
USR SQL_REDO SQL_UNDO
---------- -------------------------------------------------- --------------------------------------------------
SCOTT delete from "SCOTT"."T1" insert into "SCOTT"."T1"
where values
"ID" = 5 and "ID" = 5,
"NAME" = 'yyy' and "NAME" = 'yyy',
"KEY" = 20 and "KEY" = 20;
ROWID = 'AAATr3AAEAAAACvAAE';
SQL> SELECT USERNAME AS usr,SQL_REDO,SQL_UNDO FROM
2 V$LOGMNR_CONTENTS
3 WHERE SEG_OWNER ='SCOTT';
USR SQL_REDO SQL_UNDO
---------- -------------------------------------------------- --------------------------------------------------
SCOTT insert into "SCOTT"."T1" delete from "SCOTT"."T1"
values where
"ID" = 6, "ID" = 6 and
"NAME" = 'zzz', "NAME" = 'zzz' and
"KEY" = 30; "KEY" = 30 and
ROWID = 'AAATr3AAEAAAACvAAF';
所以要能挖到DML操作，必须在事前就开启附加日志，事后临时开启，没有用，虽然logminer可以用，但是挖不倒数据。而且一般生产都不会开启附加日志，往redo日志里面存储数据字典的时候，就会报错ORA-01354。此时可以临时开启，但是如上，挖不倒数据。所以这是相互矛盾的。所以在线日志的数据字典就有缺陷。
结束logminer
EXECUTE DBMS_LOGMNR.END_LOGMNR();
总结
总结以上过程，抽取数据字典到在线日志中这种方法的步骤如下：
源端（必须开归档）：
1、打开数据库归档
alter database archivelog;
2、打开数据库最小附加日志
SQL> alter database add supplemental log data;
3、做DML操作
SQL> update scott.t1 set name=‘eee’ where key=10
4、日志保存到online redo日志里面
SQL> execute dbms_logmnr_d.build(options=>dbms_logmnr_d.store_in_redo_logs);
SQL> select SEQUENCE#,name from v$archived_log where dictionary_begin=‘YES’;
挖掘端（可以不开归档）：
5、添加日志文件
SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME => ‘/home/oracle/arch1_58_1024919054.dbf’, OPTIONS => DBMS_LOGMNR.NEW);
SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME => ‘/home/oracle/arch1_54_1024919054.dbf’,OPTIONS => DBMS_LOGMNR.ADDFILE);
6、开启logminer
EXECUTE DBMS_LOGMNR.START_LOGMNR(-
OPTIONS => DBMS_LOGMNR.DICT_FROM_REDO_LOGS + -
DBMS_LOGMNR.PRINT_PRETTY_SQL);
注意：行尾的 － 表示后面还有内容
7、查询视图
SQL> set linesize 200
SQL> set pagesize 200
SQL> col USR for a10
SQL> col sql_redo for a50
SQL> col SQL_UNDO for a50
SQL> SELECT USERNAME AS usr,SQL_REDO,SQL_UNDO FROM
2 V$LOGMNR_CONTENTS
3 WHERE SEG_OWNER =‘SCOTT’;
8、结束
EXECUTE DBMS_LOGMNR.END_LOGMNR();
使用场景：Oracle建议您在不希望访问创建了重做日志文件的源数据库的情况下使用此选项。
