使用場景：工作中如果誤刪除了一張表，又沒有對這張表做備份（即使做了備份也只能恢復到備份時的狀態），只要開了歸檔，做了備份，就可以通過時間或者LSN來做還原，把資料庫狀態還原到某個時間點或某個LSN，是的，只能做全庫還原，不支援單獨還原某個表。如果不清楚具體時間點或者LSN的值，可以通過DBMS_LOGMNR來定位。
　　DBMS_LOGMNR包對歸檔日誌進行挖掘，重構出 DDL 和 DML 等操作，並通過獲取的資訊進行更深入的分析。找到你刪除表的語句，定位到自己到底是什麼時候刪除的那張表，就可以操作還原了。
　　DBMS_LOGMNR包使用方式參考《DM8系統包使用手冊.pdf》，分析結果在動態檢視 V$LOGMNR_CONTENTS中，該動態檢視欄位說明等可以參考《DM8系統管理員手冊.pdf》。

一、檢視當前資料庫是否開啟歸檔

　　select arch_mode from v$database;

　　我當前資料庫開啟了歸檔。如果沒有開啟歸檔，有許多方式可以開啟，一般是用disql開啟，如下：

　　　　1)修改資料庫為 MOUNT 狀態。
　　　　　　ALTER DATABASE MOUNT;
　　　　2)配置本地歸檔。
　　　　　　ALTER DATABASE ADD ARCHIVELOG 'DEST = E:\dmdbms\data\DAMENG\arch, TYPE = local,FILE_SIZE = 1024, SPACE_LIMIT = 2048';
　　　　3)開啟歸檔模式。
　　　　　　ALTER DATABASE ARCHIVELOG;
　　　　4)修改資料庫為 OPEN 狀態。
　　　　　　ALTER DATABASE OPEN;

　　　　注意：arch資料夾需要提前建立好。

二、查詢有哪些歸檔日誌

　　SELECT NAME , FIRST_TIME , NEXT_TIME , FIRST_CHANGE# , NEXT_CHANGE# FROM V$ARCHIVED_LOG;　

三、檢視RLOG_APPEND_LOGIC引數值

　　目前 DBMS_LOGMNR 只支援對歸檔日誌進行分析，配置歸檔後，還需要將 dm.ini 中的RLOG_APPEND_LOGIC 選項置為 1 或 2。

　　select * from v$dm_ini where para_name ='RLOG_APPEND_LOGIC';

　　我當前引數值是0，所以需要修改一下。

四、修改RLOG_APPEND_LOGIC引數為1　　

　　alter system set 'RLOG_APPEND_LOGIC'=1 both;
　　select * from v$dm_ini where para_name ='RLOG_APPEND_LOGIC';

五、重啟資料庫服務

六、再次檢視歸檔日誌

　　SELECT NAME , FIRST_TIME , NEXT_TIME , FIRST_CHANGE# , NEXT_CHANGE# FROM V$ARCHIVED_LOG;

　　重啟後會建立一個新的歸檔日誌，用新的歸檔日誌去分析才有效。RLOG_APPEND_LOGIC引數預設值是0，這就意味著，想利用DBMS_LOGMNR包分析歸檔日誌去定位誤刪除的表，前提是已經提前設定RLOG_APPEND_LOGIC=1。

　　這個時候如果再設定RLOG_APPEND_LOGIC=0，重啟資料庫服務，發現也會再重新建立一個歸檔日誌。現在先不做這個測試。

七、新增測試資料　

　　drop table test;
　　create table test(id int,name varchar);
　　insert into test values(1,'test1');
　　insert into test values(2,'test2');
　　commit;
　　select * from test;

八、分析歸檔日誌　

　　1) 查詢有哪些歸檔日誌
　　　　SELECT NAME , FIRST_TIME , NEXT_TIME , FIRST_CHANGE# , NEXT_CHANGE# FROM V$ARCHIVED_LOG;
　　2) 新增一個或多個需要分析的歸檔日誌檔案
　　　　DBMS_LOGMNR.ADD_LOGFILE('E:\dmdbms\data\DAMENG3\arch\ARCHIVE_LOCAL1_0x606C7ADA[0]_2021-07-20_18-18-14.log')
　　　　如要 看通過ADD_LOGFILE新增的歸檔日誌檔案，可以通過動態檢視V$LOGMNR_LOGS 進行查詢，如下：
　　　　SELECT LOW_SCN, NEXT_SCN, LOW_TIME, HIGH_TIME, LOG_ID, FILENAME FROM V$LOGMNR_LOGS;
　　3）啟動歸檔日誌檔案分析
　　　　DBMS_LOGMNR.START_LOGMNR(OPTIONS=>2128 , STARTTIME=>TO_DATE('2021-03-04 17:36:00','YYYY-MM-DD HH24:MI:SS') , 　　　　ENDTIME=>TO_DATE('2021-07-21 17:36:02','YYYY-MM-DD HH24:MI:SS'));
　　　　如要檢視歸檔日誌檔案的分析結果，可以通過動態檢視 V$LOGMNR_CONTENTS 進行查詢，如下：
　　　　SELECT OPERATION_CODE , SCN, SQL_REDO , TIMESTAMP ,SEG_OWNER, TABLE_NAME FROM V$LOGMNR_CONTENTS ;
　　4）終止歸檔日誌檔案分析
　　　　DBMS_LOGMNR.END_LOGMNR();

九、附加測試

　　1)再次重啟資料庫服務，發現沒有新建歸檔日誌。

　　2）終止歸檔日誌檔案分析，執行第八步，重新執行歸檔日誌分析，發現有時候會再建立了一條歸檔日誌。這種時候需要改為分析最新的歸檔日誌檔案。也又時候不會建立新的歸檔日誌檔案，沒找到具體規律。

　　3）如果RLOG_APPEND_LOGIC=0的話，無論啟動多少次歸檔日誌檔案分析，都不會建立新的歸檔日誌。

　　十、總結

　　　　1）只有當RLOG_APPEND_LOGIC=1時，生成的歸檔日誌檔案才能用來分析。

　　　　2）狀態值為1，執行歸檔日誌檔案分析，只能分析執行歸檔日誌這個操作時間點之前的歸檔日誌，如果有新的增刪改查操作，需要把新的歸檔日誌檔案加入再重新執行才能分析到最新的操作。

　　　　3）我本地資料庫版本教老，試了下最新版的達夢資料庫，發現多次“終止歸檔日誌檔案分析”再“啟動歸檔日誌檔案分析”不會再建立多個歸檔日誌檔案了。

　　　　比如我先開啟歸檔，這個時候會建立一個歸檔日誌檔案，這時RLOG_APPEND_LOGIC=0。接著我把RLOG_APPEND_LOGIC設定為1，然後重啟資料庫服務，這個時候又建立了一個歸檔日誌檔案，也就是當前有兩個歸檔日誌檔案。如果我再把RLOG_APPEND_LOGIC設為0，然後重啟資料庫服務，這時也建立了一個歸檔日誌檔案，也就是當前有三個歸檔日誌檔案。我再次把RLOG_APPEND_LOGIC設定為1，然後重啟資料庫服務，這個時候又建立了一個歸檔日誌檔案，也就是最後實際上有四個歸檔日誌檔案。我隨便測試下增刪改查操作，然後執行第八步，啟動歸檔日誌檔案分析，這個時候可以查出我剛剛的增刪改查操作。接著我又執行新的增刪改查操作，這時查不到，只能“終止歸檔日誌檔案分析”後再“啟動歸檔日誌檔案分析”，這樣就可以查到我最新的增刪改查操作了。這個過程中，始終只有四個歸檔日誌檔案，也就是最終最近的操作都儲存在第四個歸檔日誌檔案中。