LogMiner配置使用手册
参考：
http://blog.csdn.net/zq9017197/article/details/7074641
http://www.cnblogs.com/shishanyuan/p/3140440.html
http://www.qiuyb.com/archives/171
一、LogMiner功能
日志文件中存放着所有进行数据库恢复的数据，记录了针对数据库结构的每一个变化，也就是对数据库操作的所有DML语句。
在Oracle 8i之前，Oracle没有提供任何协助数据库管理员来读取和解释重作日志文件内容的工具。系统出现问题，对于一个普通的数据管理员来讲，唯一可以作的工作就是将所有的日志文件打包，然后发给Oracle公司的技术支持，然后静静地等待Oracle 公司技术支持给我们最后的答案。然而从8i以后，Oracle提供了这样一个强有力的工具-LogMiner。
LogMiner工具的主要用途有：
1． 跟踪数据库的变化：可以离线的跟踪数据库的变化，而不会影响在线系统的性能。
2． 回退数据库的变化：回退特定的变化数据，减少point-in-time recovery的执行。
3． 优化和扩容计划：可通过分析日志文件中的数据以分析数据增长模式。
二、LogMiner安装
一般默认安装，如要安装LogMiner工具，必须以sys用户运行下面这样两个脚本，
l $ORACLE_HOME/rdbms/admin/dbmslm.sql
2 $ORACLE_HOME/rdbms/admin/dbmslmd.sql
其中第一个脚本用来创建DBMS_LOGMNR包，该包用来分析日志文件。第二个脚本用来创建DBMS_LOGMNR_D包，该包用来创建数据字典文件。
创建完毕后将包括如下过程和视图：
过程 Dbms_logmnr_d.build 创建一个数据字典文件
过程 Dbms_logmnr.add_logfile 在类表中增加日志文件以供分析
过程 Dbms_logmnr.start_logmnr 使用一个可选的字典文件和前面确定要分析日志文件来启动LogMiner
过程 Dbms_logmnr.end_logmnr 停止LogMiner分析
视图 V$logmnr_dictionary 显示用来决定对象ID名称的字典文件的信息
视图 V$logmnr_logs 在LogMiner启动时显示分析的日志列表
视图 V$logmnr_contents LogMiner启动后，可以使用该视图在SQL提示符下输入SQL语句来查询重做日志的内容
使用logminer的一些说明:
1.分析日志所在的数据库平台必须跟产生日志的数据库平台保持一致;
2.分析日志所在的数据库可以跟产生日志的数据库完全独立,或者是两者是同一个数据库;
3.分析日志所在的数据库的版本比如高于产生日志的数据库的版本;
4.分析日志所在的数据库的字符集必须跟产生日志的数据库的字符集保持一致;
5.logminer数据字典文件必须在产生日志的数据库生成.
三、LogMiner使用
首先在init.ora初始化参数文件中，指定数据字典文件的位置，也就是添加一个参数UTL_FILE_DIR，该参数值为服务器中放置数据字典文件的目录。如：
SQL>alter system set utl_file_dir='/orasoft/logminer' scope=spfile;
SQL>shutdown immediate
SQL>startup
第一步：
生成数据字典文件
exec dbms_logmnr_d.build(dictionary_filename => 'dict.ora',dictionary_location => '/orasoft/logminer');
该字典文件是可选的，但是如果没有它，logminer解释出来的语句中关于数据字典中的部分（如表名、列名等）和数值都将是16进制的形式，我们是无法直接理解的。
如果我们要分析的数据库中的表有变化，影响到库的数据字典也发生变化，这时就需要重新创建该字典文件。另外一种情况是在分析另外一个数据库文件的重作日志时，也必须要重新生成一遍被分析数据库的数据字典文件。
把字典放到在线日志文件,适用于源库与目标库不同这样的方式
EXECUTE DBMS_LOGMNR_D.BUILD( OPTIONS=> DBMS_LOGMNR_D.STORE_IN_REDO_LOGS);
看字典存放到了哪个归档日志：
SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN='YES';
SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_END='YES';
设置扩充日志：
SQL> show user
USER 为 "SYS"
SQL> select SUPPLEMENTAL_LOG_DATA_MIN from v$database;
SUPPLEME
--------
NO
SQL> alter database add supplemental log data;
supplemental logging（扩充日志）：在通常情况下，redo log 只记录的进行恢复所必需的信息，但是这些信息对于我们使用redo log进行一些其他应用时是不够的，例如在 redo log中使用rowid唯一标识一行而不是通过Primary key，如果我们在另外的数据库分析这些日志并想重新执行某些dml时就可能会有问题，因为不同的数据库其rowid代表的内容是不同的。在这时候就需要一些额外的信息（columns）加入redo log，这就是supplemental logging。supplemental logging分为两个级别database_level and table_level，其中database_level级别分为两种，minimal supplemental logging and identification key logging，其中minimal supplemental logging不会显著增加系统的负担，但是identification key logging对系统负担比较大，在默认情况下oracle不会设置任何supplemental logging，但是如果要使用logminer，oracle建议至少设置minimal supplemental logging。我在使用logminer是，不设置minimal supplemental logging，从v$logmnr_contents中几乎得不到任何信息。
第二步：可以分析在线（online）和归档（offline）两种日志文件，加入分析日志文件使用dbms_logmnr.add_logfile过程，第一个文件使用dbms_logmnr.NEW参数，后面文件使用dbms_logmnr.ADDFILE参数。按日志文件的先后顺序依次加入：
exec dbms_logmnr.add_logfile(LogFileName => '/oracle/app/oracle/fast_recovery_area/ORCL/archivelog/2016_04_14/o1_mf_1_16_cjyh6hf7_.arc',Options => dbms_logmnr.NEW);
exec dbms_logmnr.add_logfile(LogFileName => '/oracle/app/oracle/oradata/orcl/redo01.log',Options => dbms_logmnr.ADDFILE);
删除列表中的日志文件：exec dbms_logmnr.add_logfile('/u01/app/oracle/oradata/orcl/redo03.log', dbms_logmnr.removefile);
查看归档日志列表；
select sequence#, FIRST_CHANGE#, NEXT_CHANGE#,name from v$archived_log order by sequence# desc;
查看redo日志列表；
select * from v$log;
select * from v$logfile;
从磁带库恢复出所需的日志
run
{
ALLOCATE channel t1 type 'SBT_TAPE' parms 'ENV=(NSR_SERVER=linuxbak,NSR_CLIENT=jfdb1,NSR_DATA_VOLUME_POOL=jfdb)';
set archivelog destination to '/jfdb_arch/yang';
restore archivelog from logseq 247761 until logseq 247763 thread 1;
release channel t1;
}
第三步：查看当前分析列表
select filename from v$logmnr_logs;
第四步：进行分析
Oracle的LogMiner分析时分为无限制条件和限制条件两种，无限制条件中分析所有加入到分析列表日志文件，限制条件根据限制条件分析指定范围日志文件。
源库上分析推荐方式：
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.COMMITTED_DATA_ONLY+DBMS_LOGMNR.PRINT_PRETTY_SQL);
1、无限制条件
EXECUTE dbms_logmnr.start_logmnr(dictfilename=>'/orasoft/logminer/dict.ora');
2、有限制条件
通过对过程DBMS_ LOGMNR.START_LOGMNR中几个不同参数的设置（参数含义见表1），可以缩小要分析日志文件的范围。通过设置起始时间和终止时间参数我们可以限制只分析某一时间范围的日志。
参数 参数类型 默认值 含义
StartScn 数字型 0 分析重作日志中SCN≥StartScn日志文件部分
EndScn 数字型 0 分析重作日志中SCN≤EndScn日志文件部分
StartTime 日期型 1998-01-01 分析重作日志中时间戳≥StartTime的日志文件部分
EndTime 日期型 2988-01-01 分析重作日志中时间戳≤EndTime的日志文件部分
DictFileName 字符型 字典文件该文件包含一个数据库目录的快照。
如下面的例子，我们仅仅分析2013年6月8日的日志：
exec dbms_logmnr.start_logmnr(DictFileName => '/orasoft/logminer/dict.ora',startTime => to_date('2016-04-14 14:20:00','yyyy-mm-dd hh24:mi:ss'),endTime => to_date('2016-04-14 14:49:00','yyyy-mm-dd hh24:mi:ss'));
也可以通过设置起始SCN和截至SCN来限制要分析日志的范围：
EXECUTE dbms_logmnr.start_logmnr(DictFileName =>'D:\..\practice\LOGMNR\dictionary.ora',StartScn =>20,EndScn =>50);
使用指定的数据字典文件，在跟新表字段时不能实时解析；
oracle推荐的方式，在源库上做分析，用源库在线字典；
exec dbms_logmnr.start_logmnr(Options => dbms_logmnr.DICT_FROM_ONLINE_CATALOG);
第五步：查询分析结果
到现在为止，我们已经分析得到了重作日志文件中的内容。动态性能视图v$logmnr_contents包含LogMiner分析得到的所有的信息。
SELECT USERNAME, SEG_OWNER, SEG_NAME, SQL_REDO, SQL_UNDO FROM v$LOGMNR_CONTENTS;
需要强调一点的是，视图v$logmnr_contents中的分析结果仅在我们运行过程'dbms_logmrn.start_logmnr'这个会话的生命期中存在。这是因为所有的LogMiner存储都在PGA内存中，所有其他的进程是看不到它的，同时随着进程的结束，分析结果也随之消失。
create table log14 as select * from v$logmnr_contents;
v$logmnr_contents部分列介绍
序号 名称 含义
1 SCN 特定数据变化的系统更改号
2 TIMESTAM 数据改变发生的时间
3 COMMIT_TIMESTAMP 数据改变提交的时间
4 SEG_OWNER 段的所有者名称
5 SEG_NAME 数据发生改变的段名称
6 SEG_TYPE 数据发生改变的段类型
7 SEG_TYPE_NAME 数据发生改变的段类型名称
8 TABLE_SPACE 变化段的表空间
9 ROW_ID 特定数据变化行的ID
10 SESSION_INFO 数据发生变化时用户进程信息
11 OPERATION 重做记录中记录的操作(如INSERT)
12 SQL_REDO 可以为重做记录重做指定行变化的SQL语句(正向操作)
13 SQL_UNDO 可以为重做记录回退或恢复指定行变化的SQL语句(反向操作)
第六步：结束分析
最后，使用过程DBMS_LOGMNR.END_LOGMNR终止日志分析事务，此时PGA内存区域被清除，分析结果也随之不再存在。
execute dbms_logmnr.end_logmnr
附录：一些常用选项
1. COMMITTED_DATA_ONLY
顾名思义就是只显示已经提交了的，那些正在进行中的及Oracle内部操作都忽略掉了;
2.PRINT_PRETTY_SQL
SQL_REDO和SQL_UNDO中SQL以易读的方式显示;
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.COMMITTED_DATA_ONLY+DBMS_LOGMNR.PRINT_PRETTY_SQL);
SELECT USERNAME, SEG_OWNER, SEG_NAME, SQL_REDO, SQL_UNDO
FROM v$LOGMNR_CONTENTS;
WHERE SEG_OWNER NOT IN ('SYS', 'SYSTEM')
AND SEG_NAME = 'T2'
3.DDL_DICT_TRACKING
适用于在线日志存放LogMiner字典的情况，当表发生了添加字段等情况，字典自动更新。
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DDL_DICT_TRACKING + DBMS_LOGMNR.DICT_FROM_REDO_LOGS);
4. NO_SQL_DELIMITER
去掉SQL_REDO及SQL_UNDO中SQL语句最后的分号，以CURSOR方式循环执行解析出的SQL会很方便和快捷。
举例：
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.NO_SQL_DELIMITER + DBMS_LOGMNR.DICT_FROM_REDO_LOGS);
5. NO_ROWID_IN_STMT
在SQL_REDO和SQL_UNDO列语句中去掉ROWID。举例：
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS =>DBMS_LOGMNR.NO_ROWID_IN_STMT + DBMS_LOGMNR.DICT_FROM_REDO_LOGS);
适用于在源库以外的其它库重新执行解析出的SQL,因为相应的ROWID在目标库是不存在的。
参考：
http://blog.csdn.net/zq9017197/article/details/7074641
http://www.cnblogs.com/shishanyuan/p/3140440.html
http://www.qiuyb.com/archives/171
一、LogMiner功能
日志文件中存放着所有进行数据库恢复的数据，记录了针对数据库结构的每一个变化，也就是对数据库操作的所有DML语句。
在Oracle 8i之前，Oracle没有提供任何协助数据库管理员来读取和解释重作日志文件内容的工具。系统出现问题，对于一个普通的数据管理员来讲，唯一可以作的工作就是将所有的日志文件打包，然后发给Oracle公司的技术支持，然后静静地等待Oracle 公司技术支持给我们最后的答案。然而从8i以后，Oracle提供了这样一个强有力的工具-LogMiner。
LogMiner工具的主要用途有：
1． 跟踪数据库的变化：可以离线的跟踪数据库的变化，而不会影响在线系统的性能。
2． 回退数据库的变化：回退特定的变化数据，减少point-in-time recovery的执行。
3． 优化和扩容计划：可通过分析日志文件中的数据以分析数据增长模式。
二、LogMiner安装
一般默认安装，如要安装LogMiner工具，必须以sys用户运行下面这样两个脚本，
l $ORACLE_HOME/rdbms/admin/dbmslm.sql
2 $ORACLE_HOME/rdbms/admin/dbmslmd.sql
其中第一个脚本用来创建DBMS_LOGMNR包，该包用来分析日志文件。第二个脚本用来创建DBMS_LOGMNR_D包，该包用来创建数据字典文件。
创建完毕后将包括如下过程和视图：
过程 Dbms_logmnr_d.build 创建一个数据字典文件
过程 Dbms_logmnr.add_logfile 在类表中增加日志文件以供分析
过程 Dbms_logmnr.start_logmnr 使用一个可选的字典文件和前面确定要分析日志文件来启动LogMiner
过程 Dbms_logmnr.end_logmnr 停止LogMiner分析
视图 V$logmnr_dictionary 显示用来决定对象ID名称的字典文件的信息
视图 V$logmnr_logs 在LogMiner启动时显示分析的日志列表
视图 V$logmnr_contents LogMiner启动后，可以使用该视图在SQL提示符下输入SQL语句来查询重做日志的内容
使用logminer的一些说明:
1.分析日志所在的数据库平台必须跟产生日志的数据库平台保持一致;
2.分析日志所在的数据库可以跟产生日志的数据库完全独立,或者是两者是同一个数据库;
3.分析日志所在的数据库的版本比如高于产生日志的数据库的版本;
4.分析日志所在的数据库的字符集必须跟产生日志的数据库的字符集保持一致;
5.logminer数据字典文件必须在产生日志的数据库生成.
三、LogMiner使用
首先在init.ora初始化参数文件中，指定数据字典文件的位置，也就是添加一个参数UTL_FILE_DIR，该参数值为服务器中放置数据字典文件的目录。如：
SQL>alter system set utl_file_dir='/orasoft/logminer' scope=spfile;
SQL>shutdown immediate
SQL>startup
第一步：
生成数据字典文件
exec dbms_logmnr_d.build(dictionary_filename => 'dict.ora',dictionary_location => '/orasoft/logminer');
该字典文件是可选的，但是如果没有它，logminer解释出来的语句中关于数据字典中的部分（如表名、列名等）和数值都将是16进制的形式，我们是无法直接理解的。
如果我们要分析的数据库中的表有变化，影响到库的数据字典也发生变化，这时就需要重新创建该字典文件。另外一种情况是在分析另外一个数据库文件的重作日志时，也必须要重新生成一遍被分析数据库的数据字典文件。
把字典放到在线日志文件,适用于源库与目标库不同这样的方式
EXECUTE DBMS_LOGMNR_D.BUILD( OPTIONS=> DBMS_LOGMNR_D.STORE_IN_REDO_LOGS);
看字典存放到了哪个归档日志：
SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN='YES';
SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_END='YES';
设置扩充日志：
SQL> show user
USER 为 "SYS"
SQL> select SUPPLEMENTAL_LOG_DATA_MIN from v$database;
SUPPLEME
--------
NO
SQL> alter database add supplemental log data;
supplemental logging（扩充日志）：在通常情况下，redo log 只记录的进行恢复所必需的信息，但是这些信息对于我们使用redo log进行一些其他应用时是不够的，例如在 redo log中使用rowid唯一标识一行而不是通过Primary key，如果我们在另外的数据库分析这些日志并想重新执行某些dml时就可能会有问题，因为不同的数据库其rowid代表的内容是不同的。在这时候就需要一些额外的信息（columns）加入redo log，这就是supplemental logging。supplemental logging分为两个级别database_level and table_level，其中database_level级别分为两种，minimal supplemental logging and identification key logging，其中minimal supplemental logging不会显著增加系统的负担，但是identification key logging对系统负担比较大，在默认情况下oracle不会设置任何supplemental logging，但是如果要使用logminer，oracle建议至少设置minimal supplemental logging。我在使用logminer是，不设置minimal supplemental logging，从v$logmnr_contents中几乎得不到任何信息。
第二步：可以分析在线（online）和归档（offline）两种日志文件，加入分析日志文件使用dbms_logmnr.add_logfile过程，第一个文件使用dbms_logmnr.NEW参数，后面文件使用dbms_logmnr.ADDFILE参数。按日志文件的先后顺序依次加入：
exec dbms_logmnr.add_logfile(LogFileName => '/oracle/app/oracle/fast_recovery_area/ORCL/archivelog/2016_04_14/o1_mf_1_16_cjyh6hf7_.arc',Options => dbms_logmnr.NEW);
exec dbms_logmnr.add_logfile(LogFileName => '/oracle/app/oracle/oradata/orcl/redo01.log',Options => dbms_logmnr.ADDFILE);
删除列表中的日志文件：exec dbms_logmnr.add_logfile('/u01/app/oracle/oradata/orcl/redo03.log', dbms_logmnr.removefile);
查看归档日志列表；
select sequence#, FIRST_CHANGE#, NEXT_CHANGE#,name from v$archived_log order by sequence# desc;
查看redo日志列表；
select * from v$log;
select * from v$logfile;
从磁带库恢复出所需的日志
run
{
ALLOCATE channel t1 type 'SBT_TAPE' parms 'ENV=(NSR_SERVER=linuxbak,NSR_CLIENT=jfdb1,NSR_DATA_VOLUME_POOL=jfdb)';
set archivelog destination to '/jfdb_arch/yang';
restore archivelog from logseq 247761 until logseq 247763 thread 1;
release channel t1;
}
第三步：查看当前分析列表
select filename from v$logmnr_logs;
第四步：进行分析
Oracle的LogMiner分析时分为无限制条件和限制条件两种，无限制条件中分析所有加入到分析列表日志文件，限制条件根据限制条件分析指定范围日志文件。
源库上分析推荐方式：
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.COMMITTED_DATA_ONLY+DBMS_LOGMNR.PRINT_PRETTY_SQL);
1、无限制条件
EXECUTE dbms_logmnr.start_logmnr(dictfilename=>'/orasoft/logminer/dict.ora');
2、有限制条件
通过对过程DBMS_ LOGMNR.START_LOGMNR中几个不同参数的设置（参数含义见表1），可以缩小要分析日志文件的范围。通过设置起始时间和终止时间参数我们可以限制只分析某一时间范围的日志。
参数 参数类型 默认值 含义
StartScn 数字型 0 分析重作日志中SCN≥StartScn日志文件部分
EndScn 数字型 0 分析重作日志中SCN≤EndScn日志文件部分
StartTime 日期型 1998-01-01 分析重作日志中时间戳≥StartTime的日志文件部分
EndTime 日期型 2988-01-01 分析重作日志中时间戳≤EndTime的日志文件部分
DictFileName 字符型 字典文件该文件包含一个数据库目录的快照。
如下面的例子，我们仅仅分析2013年6月8日的日志：
exec dbms_logmnr.start_logmnr(DictFileName => '/orasoft/logminer/dict.ora',startTime => to_date('2016-04-14 14:20:00','yyyy-mm-dd hh24:mi:ss'),endTime => to_date('2016-04-14 14:49:00','yyyy-mm-dd hh24:mi:ss'));
也可以通过设置起始SCN和截至SCN来限制要分析日志的范围：
EXECUTE dbms_logmnr.start_logmnr(DictFileName =>'D:\..\practice\LOGMNR\dictionary.ora',StartScn =>20,EndScn =>50);
使用指定的数据字典文件，在跟新表字段时不能实时解析；
oracle推荐的方式，在源库上做分析，用源库在线字典；
exec dbms_logmnr.start_logmnr(Options => dbms_logmnr.DICT_FROM_ONLINE_CATALOG);
第五步：查询分析结果
到现在为止，我们已经分析得到了重作日志文件中的内容。动态性能视图v$logmnr_contents包含LogMiner分析得到的所有的信息。
SELECT USERNAME, SEG_OWNER, SEG_NAME, SQL_REDO, SQL_UNDO FROM v$LOGMNR_CONTENTS;
需要强调一点的是，视图v$logmnr_contents中的分析结果仅在我们运行过程'dbms_logmrn.start_logmnr'这个会话的生命期中存在。这是因为所有的LogMiner存储都在PGA内存中，所有其他的进程是看不到它的，同时随着进程的结束，分析结果也随之消失。
create table log14 as select * from v$logmnr_contents;
v$logmnr_contents部分列介绍
序号 名称 含义
1 SCN 特定数据变化的系统更改号
2 TIMESTAM 数据改变发生的时间
3 COMMIT_TIMESTAMP 数据改变提交的时间
4 SEG_OWNER 段的所有者名称
5 SEG_NAME 数据发生改变的段名称
6 SEG_TYPE 数据发生改变的段类型
7 SEG_TYPE_NAME 数据发生改变的段类型名称
8 TABLE_SPACE 变化段的表空间
9 ROW_ID 特定数据变化行的ID
10 SESSION_INFO 数据发生变化时用户进程信息
11 OPERATION 重做记录中记录的操作(如INSERT)
12 SQL_REDO 可以为重做记录重做指定行变化的SQL语句(正向操作)
13 SQL_UNDO 可以为重做记录回退或恢复指定行变化的SQL语句(反向操作)
第六步：结束分析
最后，使用过程DBMS_LOGMNR.END_LOGMNR终止日志分析事务，此时PGA内存区域被清除，分析结果也随之不再存在。
execute dbms_logmnr.end_logmnr
附录：一些常用选项
1. COMMITTED_DATA_ONLY
顾名思义就是只显示已经提交了的，那些正在进行中的及Oracle内部操作都忽略掉了;
2.PRINT_PRETTY_SQL
SQL_REDO和SQL_UNDO中SQL以易读的方式显示;
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.COMMITTED_DATA_ONLY+DBMS_LOGMNR.PRINT_PRETTY_SQL);
SELECT USERNAME, SEG_OWNER, SEG_NAME, SQL_REDO, SQL_UNDO
FROM v$LOGMNR_CONTENTS;
WHERE SEG_OWNER NOT IN ('SYS', 'SYSTEM')
AND SEG_NAME = 'T2'
3.DDL_DICT_TRACKING
适用于在线日志存放LogMiner字典的情况，当表发生了添加字段等情况，字典自动更新。
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DDL_DICT_TRACKING + DBMS_LOGMNR.DICT_FROM_REDO_LOGS);
4. NO_SQL_DELIMITER
去掉SQL_REDO及SQL_UNDO中SQL语句最后的分号，以CURSOR方式循环执行解析出的SQL会很方便和快捷。
举例：
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.NO_SQL_DELIMITER + DBMS_LOGMNR.DICT_FROM_REDO_LOGS);
5. NO_ROWID_IN_STMT
在SQL_REDO和SQL_UNDO列语句中去掉ROWID。举例：
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS =>DBMS_LOGMNR.NO_ROWID_IN_STMT + DBMS_LOGMNR.DICT_FROM_REDO_LOGS);
适用于在源库以外的其它库重新执行解析出的SQL,因为相应的ROWID在目标库是不存在的。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29519108/viewspace-2081811/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
