Oracle 11gR2資料庫閃回功能--預防人為邏輯錯誤

標籤：des   style   color   strong   檔案   資料   

Oracle 11gR2資料庫閃回功能--預防人為邏輯錯誤

 

1.Flashback對於DJI ERP系統的作用？

對於一些人為操作的錯誤，比如大量刪除了資料，我們可以通過Flashback功能來恢複。缺點是，此段時間內其他使用者的正確操作也會丟失。

a.設立一個閃回視窗，例如60分鐘。當出現人為錯誤時，可以恢複到過去60分鐘內的任何一個時間點。

b.以某個時刻設定一個復原點，以後出問題了，那怕過了幾個月，都可以恢複到這個時刻上來。而且，只能恢複到這個時刻，而不能是這幾個月內的任何一個時間點。

 

我們的需求只落在閃回方案b上。

 

我們可以在生產庫或災備庫上開啟flashback。

A.利用災備庫做完閃回操作後，我們可以查詢相應時刻的表資料，也可以利用這個時刻的待用資料庫，複製出一個新的環境。如果複製到正式環境，能起到恢複生產的作用。但此時生產停機時間可能就得半天左右了。

B.如果是生產開啟flashback，當出現需要全庫閃回時，直接就可以在生產閃回了，停機時間會在1小時內。

 

 

2.閃回理論參考

理論上，我們都可以閃回到這時間視窗內的任何一個時間點。開了閃回日誌，每間隔10分鐘，會將有變化data block的變化前影像寫到flashback log中（沒變化的data block就不會記）。此時能回退的點，取決於FRA中的閃回日誌視窗，視窗是隨著空間的壓力而向後滾動的。鑒於閃回日誌是一段時間採樣一次，那麼我們是否只能閃回到以10分鐘為單位的時間點上呢？如果想要10分鐘內的時刻怎麼辦呢？所以flshback database時也是需要用redo log來做精確恢複的。回退的機制是這樣的，根據想恢複到的target time，將該target time之前的最接近的一次閃回日誌採樣資料取出，然後將每個資料區塊利用redo log向後走到精確地走到target scn。當然，我們有了1440這個保證的時間窗，時間窗中的日誌與歸檔日誌都不會被刪除、就算它符合歸檔日誌刪除策略。

 

 

 

3.方案A的實踐指導參考

包括開啟閃回功能、以及如何閃回。

在生產庫與災備庫上開啟閃回都是可以的，方法大同小異，下面介紹在災備庫上開啟flashback功能。

 

1）.通過這個查詢，可以知道，我們的ERP生產庫、災備庫的閃回功能都是沒有開啟的。

SQL> select flashback_on from v$database;

FLASHBACK_ON

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

NO

 

2）.開啟flashback功能。當我在DG庫想開啟閃回功能時，會提示必須先啟動閃回恢複區，指定閃回日誌應該放到哪裡。

SQL> alter database flashback on;

alter database flashback on

*

ERROR at line 1:

ORA-38706: Cannot turn on FLASHBACK DATABASE logging.

ORA-38709: Recovery Area is not enabled.

SQL>

 

3）.指定flash recovery area（fra,閃回恢複區）。我們設定其size為80G（也就是flashback log、以及存放在fra區的其他檔案如歸檔日誌、備份等，不能超過80G），並且把“/u01/erpdg/db/apps_st/fra”這兩個路徑作為閃回恢複區。

SQL> alter system set db_recovery_file_dest_size=80g;

System altered.

SQL> alter system set db_recovery_file_dest=‘/u01/erpp1/db/apps_st/fra‘;

System altered.

SQL> 

 

4）.再次開啟flashback功能，因為我們的災備庫在即時恢複生產庫的日誌，所以會報錯。我們必須先停下恢複日誌的進程、即MRP進程，使得災備庫處於一個靜止時間點。

5）.停掉MRP進程：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

6）.再次開啟閃回特性，成功了。

 

7）.此時我們的閃回時間視窗多大呢？通過查看參數db_flashback_retention_target的值，是1440分鐘。這個值是可以調整的。這個視窗是隨著空間的壓力而向後滾動的。也就是說，1440分鐘（一天）以內的資料，系統是必須要保證可以閃回到的，假如空間不足以保證1440分鐘的閃回，系統寧願宕下來不運作，也不會讓我們不能閃回到。那是不是1440分鐘以外的人為錯誤，我們就一定不能閃回呢？也不一定，假如空間是否足夠，兩天、三天前的閃回日誌，系統依然會保留的。觸發系統刪除閃回日誌的，一般是系統空間壓力（比如設定為達到fra的90%就觸發刪除，刪除到60%為止）。

 

 

8）.此時我們要將dg庫的mrp進程重新啟起來，再即時應用生產庫傳過來的日誌。

 

SQL> alter database recover managed standby database using current logfile disconnect from session parallel 8;

 

Database altered.

 

SQL>

 

此時，整個DG庫的flashback功能開啟完畢。

 

9）.閃回查詢。當有一天，有使用者在資料庫裡面誤操作，比如人為地刪除了資料。如果是一個表的資料，其實這裡我們首先是可以考慮利用undo的閃回查詢。

select * from dept as of timestamp to_timestamp(‘2012-03-09 21:55:06‘,‘yyyy-mm-dd hh24:mi:ss‘);--閃回查詢，利用復原段。 

select * from dept as of timestamp to_timestamp(‘2012-03-09 21:55:06‘,‘yyyy-mm-dd hh24:mi:ss‘) minus select * from dept;--得到被刪除的記錄

execute SYS.dbms_flashback.enable_at_time(to_timestamp(‘2012-03-09 21:55:06‘,‘yyyy-mm-dd hh24:mi:ss‘));

--讓當前會話回到指定時間點，會看到一個凍結版的資料庫，只能select，不能DML。

備忘：表結構不能被更改過。即閃回不能跨越DDL。

對於閃回查詢，就是查詢某個表過去的資料。這裡，我們先討論需要整庫閃回的情況，比如做了一些錯誤操作，涉及到很多關聯的表，我們也很難理清究竟要閃回什麼的時候，就可以用統一的整庫閃回操作。

 

 

10）.全庫flashback前，同樣需要停掉MRP進程：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

 

Database altered.

 

11）.全庫Flash back操作

SQL> flashback database to timestamp to_timestamp(‘2014-07-22 14:22:24‘,‘yyyy-mm-dd hh24:mi:ss‘);

Flashback complete.

SQL> 

 

 

12）.驗證。此時我們已經閃回到了所需要的時間點。

SQL> alter session set nls_date_format=‘yyyy-mm-dd hh24:mi:ss‘;

Session altered.

SQL> col max(first_time) for a30

SQL> select CONTROLFILE_TIME from v$database;

CONTROLFILE_TIME

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

2014-07-22 14:22:25

SQL> 

13）.反覆閃回，以取得錯誤剛好發生前的時間點。

alter database open read only;

以唯讀模式開啟，看是否找到了被誤刪除的內容，不斷從shutdown abort開始，重新flashback，不斷採用二分法，以逼近被刪除模式那一刻之前的點。