今天本來下班快要走了，結果開發人員說他們有個測試表的資料突然不見了，而且說應該是沒有人delete，問我是不是Oracle的Bug（這個有點搞吧，這都想得出來，哈哈），讓我幫看一下，沒法只能使用logminer來分析日誌了：
1、 修改utl_file_dir參數為一個特定目錄，或者修改為*（建議，這樣就可以訪問所有oracle使用者可以訪問的目錄，修改這個參數需要重啟生效！）
2、 執行一下指令碼初始化logminer環境
- @$ORACLE_HOME/rdbms/admin/dbmslm.sql
- @$ORACLE_HOME/rdbms/admin/dbmslmd.sq
3、 產生資料字典檔案，如：
- EXECUTE dbms_logmnr_d.build(dictionary_filename => 'logminer.ora',dictionary_location => '/arclog/logminer');
4、 添加記錄檔，可以使歸檔日誌也可以使線上redo日誌，由於這個資料庫沒有起歸檔，所有就使用online redo日誌來分析，還好他們沒有做壓力，日誌沒被切換掉：
- EXECUTE dbms_logmnr.add_logfile(LogFileName=>'/soft/oracle/oradata/newpay/redo02a.dbf', Options=>dbms_logmnr.new);
- EXECUTE dbms_logmnr.add_logfile(LogFileName=>'/soft/oracle/oradata/newpay/redo03a.dbf', Options=>dbms_logmnr.addfile);
5、 使用第三步中產生的資料字典開始分析日誌，可以使用scn參數分析從多少scn號至多少scn號之間的日誌
EXECUTE dbms_logmnr.start_logmnr(DictFileName=>'/arclog/logminer/logminer.ora');
6、 可以查詢v$logmnr_contents視圖中的sql_redo欄位，擷取操作內容，如：
- SELECT distinct sql_redo FROM v$logmnr_contents WHERE SEG_OWNER='PMTS' ;
經查看sql_redo，發現他們在2012-02-22 19:52:22時對那個表做了663個delete操作，虧他還還想得起來。呵呵。
7、 使用以後可以使用EXECUTE DBMS_LOGMNR.END_LOGMNR 清空v$logmnr_logs及v$logmnr_contents的內容
8、 附加：
當使用logminer挖掘日誌時，可能出現sql_redo值為UNSUPPORTED的內容資訊，這時可以開啟資料庫的追加日誌選項：
查詢資料庫層級的日誌追加選項是否已經開啟：
- SELECT SUPPLEMENTAL_LOG_DATA_MIN,SUPPLEMENTAL_LOG_DATA_PK,SUPPLEMENTAL_LOG_DATA_UI,
- SUPPLEMENTAL_LOG_DATA_FK,SUPPLEMENTAL_LOG_DATA_ALL FROM V$DATABASE;
啟用Supplemental Logging：
- ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
這裡啟用minimal logging，一般做到這一步，logminer就擁有足夠的資訊分析所有所做過的操作。
其他層級的日誌追加：
- ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL,PRIMARY KEY,UNIQUE INDEX) COLUMNS;
禁用Supplemental Logging：
如果存在ALL、PRIMARY KEY、UNIQUE INDEX的追加日誌選項，則需要先禁用這些內容的日誌追加後才能禁用minimal logging，否則會有如下錯誤：
ORA-32589: unable to drop minimal supplemental logging
- ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE, FOREIGN KEY,ALL) COLUMNS;
- ALTER DATABASE DROP SUPPLEMENTAL LOG DATA;
啟用表層級的追加日誌，如：
- ALTER TABLE HR.EMPLOYEES ADD SUPPLEMENTAL LOG GROUP emp_parttime (EMPLOYEE_ID, LAST_NAME, DEPARTMENT_ID) ALWAYS;
