閃回資料庫不是“萬金油”(r11筆記第73天)

    閃回資料庫這個特性在很多Oracle DBA眼裡就是雞肋特性，因為誰會因為恢復資料而需要在主庫閃回，最後可能丟掉更多的資料，這個觀點沒錯。

    但是如果是備庫呢，這個特性就順利成章的滿足了絕大多數的恢復需求，無論你是truncate，還是一些drop table的操作都是可以輕而易舉的恢復。所以更多的時候我們其實更偏愛於Data Guard基礎上的這種資料恢復方式，而原本的邏輯備份exp,expdp，物理備份RMAN就顯得有些臃腫了。

     拿一個真實的小案例來說明，有一次因為資料查詢的SQL有問題，結果查出的資料結果有問題，但是發現的時候這個時間已經過去了好幾天，要追溯到那天那個時間點的資料狀態，使用備份是完全不可能的。這個時候因為備庫開啟了閃回，我們可以很輕鬆的恢復到幾天前的任意一個時間點，就這樣這個問題就引刃而解了。這也算是閃回資料庫嚐到了一些甜頭。所以在後來這個特性我也會逐步放開手腳去使用。

     但是對於閃回資料庫，很多場景雖然恢復起來全然沒有問題，但是它可能不是罪完美的，如果讓你說出個一二三，可能也會不是很肯定。

    其實閃回資料庫不是資料恢復的“萬金油”，有一些場景它是無法實現閃回的。我們要清楚的這個這個邊界才能在資料恢復的時候更加充滿信心。這個資訊還是從官方文件中能夠得到要合適一些。（）

    大體來說，有下面的幾個場景是無法實現閃回的。

     1.透過閃回資料庫來修復介質問題或者是資料檔案丟失

     2.如果對資料檔案做了收縮操作，比如資料檔案為200M,我們收縮為190M,那麼這個我們是無法閃回到收縮前的狀態的。

     3.如果drop datafile這樣的操作，本身也是無法支援閃回的，而且在10g的子版本中，這個操作直接會導致MRP異常終止。

      4.一些特殊的NOLOGGING操作是不支援閃回的，比如做一個direct path的資料匯入，比如持續時間是9:00~9:15，啟用了Nologging,如果你要閃回到9:07的這個狀態是不可以的。

     總體來看上面的幾個場景，也算是極為罕見了。而且放開所有的許可權，開發同學是全然沒有這些許可權去破壞和操作的。

我們來簡單做一個例子來強化理解一下。

SQL> select file_id,file_name ,bytes/1024/1024 from dba_data_files;
   FILE_ID FILE_NAME                                          BYTES/1024/1024
---------- -------------------------------------------------- ----
         4 /home/oracle/users01.dbf                                       935
         3 /U01/app/oracle/oradata/dataguru/undotbs01.dbf                 295
         2 /U01/app/oracle/oradata/dataguru/sysaux01.dbf                 1250
         1 /U01/app/oracle/oradata/dataguru/system01.dbf                  750
         5 /U01/app/oracle/oradata/dataguru/test_new01.dbf                200
         6 /U01/app/oracle/oradata/dataguru/test/test02.dbf                10
我們記下一個時間戳。然後在主庫端把5號檔案從200M收縮到190M.

alter database datafile '/U01/app/oracle/oradata/dataguru/test_new01.dbf'  resize 190M;這個時候檢視資料檔案的大小是明顯發生了變化，收縮到了190M.

那麼我們在備庫端取消日誌應用，準備開始閃回。

SQL> recover managed standby database cancel;
Media recovery complete.
SQL> alter database close;
Database altered.開始閃回資料庫到收縮前的狀態。

SQL> flashback database to timestamp to_timestamp('2017-02-12 22:32:15','yyyy-mm-dd hh24:mi:ss');
flashback database to timestamp to_timestamp('2017-02-12 22:32:15','yyyy-mm-dd hh24:mi:ss')
*
ERROR at line 1:
ORA-38766: cannot flashback data file 5; file resized smaller
ORA-01110: data file 5: '/U01/app/oracle/oradata/dataguru/test_new01.dbf'     由此可以看出這個操作是支援不了的，所以對於閃回資料庫這些場景就是一些底線，我們需要了解閃回資料庫能夠做什麼，哪些是不支援的。

     明確了這些問題，其實閃回資料庫還是大有可為。