一. 在测试之前讲一点理论知识
1.1. 补充日志（supplemental logging）
先看一下补充日志都包含哪些信息和特性：
（1）索引簇、链行和迁移行；
（2）直接路径插入；
（3）摘取LogMiner字典到重做日志；
（4）跟踪DDL；
（5）生成键列的SQL_REDO和SQL_UNDO信息；
（6）LONG和LOB数据类型。
这里我们重点看一下：track DDL 和 generate sql_redo and sql_undo.
因为我们可以根据归档和online redo 去恢复数据，所以这些DDL 的内容，即使不启动 supplemental log，对与Oracle 内部来说肯定是可以识别的，只是我们不能Mining出来。 只有启动supplemental log之后，我们也就可以Mining出来了。
默认情况下Oracle 并没有启动supplemental log。因为记录太多的内容会增加写log的压力。
SQL_REDO 和 SQL_UNDO 是我们操作的SQL（DDL和DML）和用于回滚的SQL。 我们的恢复就是使用SQL_UNDO 来进行的。
在我们的DML 和DDL操作之前，需要先启动supplemental log。 不然生成的SQL_REDO 和 SQL_UNDO 是没有经过数据字典转换过的，这样不具可读性。 都是Oracle 内部的ID。
启动supplemental log：
SQL>alter database add supplemental log data;
关闭supplemental log：
SQL>alter database drop supplemental log data;
查看 supplemental log：
SQL>select supplemental_log_data_min from v$database;
1.2 Logminer 的三种模式
LogMiner dictionary ：
The LogMiner dictionary allows LogMiner to provide table and column names, instead of internal object IDs, when it presents the redo log data that you request.
LogMiner uses the dictionary to translate internal object identifiers and datatypes to object names and external data formats. Without a dictionary, LogMiner returns internal object IDs and presents data as binary data.
LogMiner字典用于将内部对象ID号和数据类型转换为对象名和外部数据格式。使用LogMiner分析重做日志和归档日志时，应该生成LogMiner字典，否则将无法读懂分析结果。
INSERT INTO HR.JOBS(JOB_ID, JOB_TITLE, MIN_SALARY, MAX_SALARY) VALUES('IT_WT','Technical Writer', 4000, 11000);
如果没有数据字典进行转换，解析之后的结果是：
insert into "UNKNOWN"."OBJ# 45522"("COL 1","COL 2","COL 3","COL 4") values (HEXTORAW('45465f4748'),HEXTORAW('546563686e6963616c20577269746572'),HEXTORAW('c229'),HEXTORAW('c3020b'));
这个就没有什么可读性了。 现在我们来看三种模式。
1.2.1 Online Catalog
直接用DB的数据字典在线进行转换。 要求DB必须处于open 状态，只能Mining DML。 只能反应当前版本表中的信息。 即表没有没有进行DDL 修改。 只能Mining到表自修改之后到现在的数据。 之前的不能Mining。
这是效率最高的。 但是缺点也摆在这。 系统表是关键表，用这种方法会增加DB的压力。
1.2.2 Extracting a LogMiner Dictionary to the Redo Log Files
The process of extracting the dictionary to the redo log files does consume database resources, but if you limit the extraction to off-peak hours, then this should not be a problem, and it is faster than extracting to a flat file. Depending on the size of the dictionary, it may be contained in multiple redo log files. If the relevant redo log files have been archived, then you can find out which redo log files contain the start and end of an extracted dictionary.
To do so, query the V$ARCHIVED_LOG view, as follows:
SQL>SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN='YES';
SQL>SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_END='YES';
使用这种方法必须启动supplemental log。 进程会讲database dictionary的信息extract到online redo log里去，从而减少对在Mining时对数据库资源的消耗。 如果database dictionary 非常大， 这时候在写online redo的时候发生了归档的操作。 那么可以通过上面的两个SQL 来查看。 因为dictionary信息写入了这些log文件，所以在Mining时，这些文件是必须包含在Mining里的，不然会报ORA-1371的错误。
To extract a LogMiner dictionary to the redo log files, the database must be open and in ARCHIVELOG mode and archiving must be enabled. While the dictionary is being extracted to the redo log stream, no DDL statements can be executed. Therefore, the dictionary extracted to the redo log files is guaranteed to be consistent (whereas the dictionary extracted to a flat file is not).
这个还有一个很大的问题在这。 就是在进行