使用logminer分析歸檔日誌案例

原因：
由於某生產系統db_sc使用者模式下t_sc表資料丟失，需要分析丟失的原因，下面是整個恢復步驟！

過程：
1、必須執行以下指令碼，建立相應的包和表

SQL> @$ORACLE_HOME/rdbms/admin/dbmslm.sql

Package created.

Grant succeeded.

Synonym created.

SQL> @$ORACLE_HOME/rdbms/admin/dbmslmd.sql

Package created.

Synonym created.

SQL> @$ORACLE_HOME/rdbms/admin/dbmslms.sql

Package created.

No errors.

Grant succeeded.

2、指出資料字典存放的位置（先建好目錄），並重啟資料庫

SQL> alter system set utl_file_dir='/tmp/hfsc' scope=spfile;

System altered.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  701485056 bytes
Fixed Size                  2216664 bytes
Variable Size             322964776 bytes
Database Buffers          373293056 bytes
Redo Buffers                3010560 bytes
Database mounted.
Database opened.

SQL> EXECUTE dbms_logmnr_d.build( 'mydictionary.ora', '/tmp/hfsc');

3、加入要分析的歸檔日誌

execute dbms_logmnr.add_logfile('/tmp/hfsc/arch/scdb/1_441401.dbf',dbms_logmnr.addfile);
execute dbms_logmnr.add_logfile('/tmp/hfsc/arch/scdb/1_441402.dbf',dbms_logmnr.addfile);
.......
execute dbms_logmnr.add_logfile('/tmp/hfsc/arch/scdb/1_441500.dbf',dbms_logmnr.addfile);

以上日誌是我們發現資訊丟失的歸檔日誌

4、分析歸檔日誌

執行日誌分析

EXECUTE dbms_logmnr.start_logmnr(dictfilename=>'/tmp/hfsc/mydictionary');

將臨時表的資料寫入到一個固定表中

create table logmnr.logmnrtab5 nologging as select * from v$logmnr_contents;

結束分析

SQL> exec sys.dbms_logmnr.end_logmnr;

5、根據表查詢所要找的物件和使用者
select * from logmnrtab5 where seg_owner = 'DB_SC' and seg_name = 'T_SC'

sql_redo：主要反映當時執行的sql語句
session_info：主要反映當時客戶端執行的情況資訊，包括ip\osname\machine\dbuser等重要資訊
timestamp：執行操作的具體時間。

6、分析結果：

客戶端session情況：
login_username=DB_SC client_info=192.168.1.101 OS_username=Administrator Machine_name=MSHOME\MARTSON OS_terminal=MARTSON OS_process_id=2388:2712 OS_program name=PlSqlDev.exe

執行語句：
-- Drop table
drop table T_SC cascade constraints;

執行時間：
201x-x-1x 10:xx:xx

經過分析，正好符合客戶提供資料丟失的時間段！