在IBM DBA 小荷的blog上看到一個用Logminer 做資料恢復的例子。 雖然對Logminer 也瞭解一點，但是用Logminer 做恢復還真沒用過，所以也測試一下。 原文連結地址如下：

一. 在測試之前講一點理論知識

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.

Oracle 的online redo 會記錄DB的所有操作，包括DDL 和 DML。 supplemental log支援track DDL。 也就是說，我們可以直接去Mining DML的內容。 但是如果要去Mining DDL 內容，就必須先啟動supplemental log，oracle 收集有關更多的DDL 資訊之後，我們才可以去Mining它的資訊。

因為我們可以根據歸檔和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.2Logminer 的三種模式

在我之前整理過的Blog裡有詳細說明：

Oracle 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).

這個還有一個很大的問題在這。就是在進行extract的時候，所以的DDL 都會被掛住。即不能執行，只有當extract 結束以後，DDL 才能執行。如果extract 的時間很長，那麼DDL 被掛的時間也就很長。

雖然講生產庫上DDL 操作很少，但是這個extract directory to redo 操作也還是有風險的。 所以可行性最高的還是我們的第三種方法。

1.2.3 Extracting the LogMiner Dictionary to a Flat File

When the LogMiner dictionary is in a flat file, fewer system resources are used than when it is contained in the redo log files. Oracle recommends that you regularly back up the dictionary extract to ensure correct analysis of older redo log files.

Be sure that no DDL operations occur while the dictionary is being built.

同樣需要啟動supplemental log。 在extract to online redo的時候，Oracle會限制DDL 執行，直到directory extract 結束。 而extract to flat file的話，就需要使用者來保證這個一致性了。 而且每次進行挖掘的時候都需要extract一次，從而保證一致性。

這種方法的致命傷是需要設定 UTL_FILE_DIR引數，而該引數的生效必須重啟DB。

我們這裡就是用extract to flat file來來演示資料恢復。

三. 用Logminer恢復的示例

一般生產環境不會啟動supplemental log。 所以用Logminer 方法來做資料恢復不是一種常用的方法。 對於DML 操作，還是有一定的可行性。 DDL 就不行。

而且在沒有啟動supplemental log的情況下，Mining出來的SQL_REDO和SQL_UNDO資料是沒有進過資料字典進行轉換的，可讀性很差。如：

deletefrom"UNKNOWN"."OBJ# 54173"where"COL 1"=HEXTORAW('53434f5454')and"COL 2"=HEXTORAW('504b5f44455054')and"COL 3"ISNULLand"COL 4"=HEXTORAW('c3060c30')and"COL 5"=HEXTORAW('c3060c30')and"COL 6"=HEXTORAW('494e444558')and"COL 7"=HEXTORAW('7869061e14303a')and"COL 8"=HEXTORAW('7869061e14303a')and"COL 9"=HEXTORAW('323030352d30362d33303a31393a34373a3537')and"COL 10"=HEXTORAW('56414c4944')and"COL 11"=HEXTORAW('4e')and"COL 12"=HEXTORAW('4e')and"COL 13"=HEXTORAW('4e')andROWID='AAANOdAABAAATEmAAc';

insertinto"UNKNOWN"."OBJ# 54173"("COL 1","COL 2","COL 3","COL 4","COL 5","COL 6","COL 7","COL 8","COL 9","COL 10","COL 11","COL 12","COL 13")values(HEXTORAW('53434f5454'),HEXTORAW('504b5f44455054'),NULL,HEXTORAW('c3060c30'),HEXTORAW('c3060c30'),HEXTORAW('494e444558'),HEXTORAW('7869061e14303a'),HEXTORAW('7869061e14303a'),HEXTORAW('323030352d30362d33303a31393a34373a3537'),HEXTORAW('56414c4944'),HEXTORAW('4e'),HEXTORAW('4e'),HEXTORAW('4e'));

Logminer 可以作為Flashback 的一種補充。 關於Flashback 參考我的Blog：

Oracle Flashback 技術總結

3.1 啟動supplemental log

[email protected](rac2)> alter database add supplemental log data;

Database altered.

[email protected](rac2)> select supplemental_log_data_min from v$database;

SUPPLEME

--------

YES

這個引數可以動態修改，不需要重啟DB。

3.2 建立測試表

[email protected](rac2)> create table huaining as select * from dba_objects;

Table created.

[email protected](rac2)> select count(*) from huaining;

COUNT(*)

----------

50253

-- 檢視一下時間

[email protected](rac2)> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

Session altered.

[email protected](rac2)> select sysdate from dual;

SYSDATE

-------------------

這個時間之前的是我們的原始資料。 下面我們做一些DML 操作，做完操作之後，我們可以使用Flashback 去進行rollback。 這裡我們使用Logminer去Mining 這些DML，然後用sql語句去進行rollback。

3.3. 一些DML 操作

[email protected](rac2)> select distinct owner from huaining;

OWNER

------------------------------

MDSYS

TSMSYS

DMSYS

PUBLIC

OUTLN

CTXSYS

OLAPSYS

SYSTEM

EXFSYS

SCOTT

ORACLE_OCM

DBSNMP

ORDSYS

ORDPLUGINS

SYSMAN

XDB

SYS

WMSYS

SI_INFORMTN_SCHEMA

19 rows selected.

[email protected](rac2)> delete from huaining where owner='SCOTT';

6 rows deleted.

[email protected](rac2)> commit;

Commit complete.

[email protected](rac2)> update huaining set owner='DAVE' where object_id<20;

18 rows updated.

[email protected](rac2)> commit;

Commit complete.

假設N長時間過去了，已經超過了UNDO retention的時間，沒辦法進行Flashback，這時候就可以用Logminer來把這段時間內的DML操作給挖出來，然後用SQL_UNDO的sql執行一下，就恢復出來。

3.4 設定資料字典目錄

[email protected](rac2)> show parameter utl

NAMETYPEVALUE

----------------------------- ----------------------- ----------

create_stored_outlinesstring

utl_file_dirstring

現在為空，沒有值

[email protected](rac2)> alter system set utl_file_dir='/u01/backup' scope=both;

alter system set utl_file_dir='/u01/backup' scope=both

*

ERROR at line 1:

ORA-02095: specified initialization parameter cannot be modified

--必須重啟才能生效

[email protected](rac2)> alter system set utl_file_dir='/u01/backup' scope=spfile;

System altered.

3.5 重啟例項

[[email protected] u01]$ sh crs_stat.sh

NameTargetStateHost

------------------------------ ---------- ----------------

ora.anqing.anqing1.instONLINEONLINErac1

ora.anqing.anqing2.instONLINEONLINErac2

ora.anqing.dbONLINEONLINErac1

ora.rac1.ASM1.asmONLINEONLINErac1

ora.rac1.LISTENER_RAC1.lsnrONLINEONLINErac1

ora.rac1.gsdONLINEONLINErac1

ora.rac1.onsONLINEONLINErac1

ora.rac1.vipONLINEONLINErac1

ora.rac2.ASM2.asmONLINEONLINErac2

ora.rac2.LISTENER_RAC2.lsnrONLINEONLINErac2

ora.rac2.gsdONLINEONLINErac2

ora.rac2.onsONLINEONLINErac2

ora.rac2.vipONLINEONLINErac2

[

相關推薦