一個閃回區報警的資料恢復(r11筆記第63天)

    今天在火車上接到一個電話說，資料庫有個報警，讓我看看是怎麼回事。

看著報警資訊一直重複出現，看來是有些問題了。

    這是一個統計庫，出現了DG相關的報警（自定義配置的），看起來是備庫端接收歸檔的時候出現了問題。

Error 270 creating remote archivelog file 'sgstatdb3'

我們知道備庫端其實是有一個80%的閾值控制閃回區的，當時限於在火車上，網路，訊號不順暢，所以讓同事幫忙看了下，大體是說閃回區滿了，但是系統層面設定了crontab定期去刪除歸檔，每個小時會觸發一次。

     這樣聽起來閃回區依舊滿好像也沒有道理啊。我聯絡其之前碰到的類似問題，大體有幾個猜測，一個是發生了SQL的效能問題，導致產生了大量的歸檔，導致閃回區使用率暫時還恢復不過來。另外一種就是閃回區設定太小，一些例行操作可能短時間生成歸檔，閃回區還一時應付不過來。

     結果沒過一會，我發現自己的設想都不對，那是什麼問題呢。

      首先嚐試手工執行定時任務指令碼來刪除過期歸檔，竟然丟擲了警告。

RMAN-08120: WARNING: archived log not deleted, not yet applied by standby
archived log file name=+ARCH/sgstatdb3/archivelog/2017_01_31/thread_1_seq_176745.384.934727315 thread=1 sequence=176745

我們在RMAN中設定了歸檔的刪除策略是必須要應用到備庫之後才可以刪除。所以目前基本斷定應該是在之前出現了一個斷點。

      接著檢視資料庫日誌發現近期的歸檔接收都是沒有問題的，最新的歸檔都傳輸過來了，最後歸檔滿了，新的歸檔接收不了了。

      原本的ADG現在狀態是READ ONLY了。SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY      那麼我們就需要找到之前是在哪個時間點出現了斷點。

我讀到了下面的一段日誌內容,原來是在之前的一個時間點建立資料檔案的時候報錯了。

Datafile #872: '+DATA/sgstatdb3/datafile/tlbb_data.1197.933781165'
Fri xxx 15:41:40 2017
Errors in file /U01/app/oracle/diag/rdbms/sgstatdb3/statdb2/trace/statdb2_pr00_28125.trc:
ORA-01119: error in creating database file '+data'
ORA-17502: ksfdcre:4 Failed to create file +data
ORA-15041: diskgroup "DATA" space exhausted
File #873 added to control file as 'UNNAMED00873'.
Originally created as:
'/U01/app/oracle/oradata/statdb29/tlbb_data16.dbf'
Recovery was unable to create the file as a new OMF file.
MRP0: Background Media Recovery terminated with error 1274
Errors in file /U01/app/oracle/diag/rdbms/sgstatdb3/statdb2/trace/statdb2_pr00_28125.trc:
ORA-01274: cannot add datafile '/U01/app/oracle/oradata/statdb29/tlbb_data16.dbf' - file could not be created
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!

透過這段日誌可以看出，建立資料檔案其實是這樣一個動作，建立的時候空間慢了無法建立就會生成一個控制程式碼，會預設在$ORACLE_HOME/dbs下生成。

我在備庫端檢視的情況如下：

SQL> select name from v$datafile where file#=873;
/U01/app/oracle/product/11.2.3/db_1/dbs/UNNAMED00873

檔案管理的設定如下：

SQL> show parameter standby_file_management
NAME                                 TYPE        VALUE
------------------------------------ ----------- --------
standby_file_management              string      AUTO當然問題的原因到底是什麼呢，是磁碟組的裡出現了問題，備庫端使用了ASM,才兩個磁碟組，資料檔案的磁碟組剩餘16G左右，而歸檔所在的磁碟組剩餘56M,而問題的原因是在哪裡呢。是在資料檔案的磁碟組+DATA上。

NAME     TOTAL_MB    FREE_MB
----------------- ----------
ARCH       204800         56
DATA      6383104      16214

      這個問題該怎麼解釋呢，因為主庫建立一個資料檔案，大概是30G,這個操作會對映到備庫，也會在備庫建立一個30G的資料檔案，唯一的不同是資料檔名可以根據對映規則不同，但是在主庫中空間充足，建立沒有問題，在備庫資料檔案所在的磁碟組滿了，建立不了一個30G的檔案，所以這個操作就會生成一個斷點，導致MRP直接異常退出，而我們設定的歸檔刪除策略是保證歸檔應用到備庫才可以刪除，所以閃回區就會越放越滿，直到幾百GB的空間都滿了。

    問題原因已經說明清楚了，接下來該怎麼處理呢。這就是一個不太常規的思路了。我們就得做減法。備庫空間不足，目前還無法直接擴容，所以問題處理的空間就有一定的侷限性。

    我們知道主庫和備庫其實是有一些檔案是不同的，比如temp檔案，主庫為30G,備庫為1G也沒有問題，是一種外掛式的功能，而且不是必須的。所以要緊縮空間，temp就是一個首要考慮的選擇，如果空間還不夠怎麼辦，我們直接resize檔案是不行的，因為主庫resize的操作得等到之前的變更在備庫應用完成之後才可以。那麼還有哪些檔案是可以暫時可清理，來應急處理這個問題呢。還有就是standby logfile了。一般是建議2*n+1的公式，我們可以在這個情況下先刪掉幾組，把空間先省出來，後續再調整。簡單來說就是刪temp檔案，刪除部分備庫日誌檔案。

SQL> alter tablespace temp drop tempfile '+DATA/sgstatdb3/tempfile/temp.910.840550051';
Tablespace altered

.刪除備庫日誌檔案，如果報錯，可以使用如下的方式處理。

SQL> alter database drop logfile group 26;
alter database drop logfile group 26
*
ERROR at line 1:
ORA-01624: log 26 needed for crash recovery of instance statdb2 (thread 1)
ORA-00312: online log 26 thread 1: '+DATA/sgstatdb3/onlinelog/group_26.907.840501783'
ORA-00312: online log 26 thread 1: '+DATA/sgstatdb3/onlinelog/group_26.908.840501785'

這樣處理即可。

SQL> alter database clear unarchived logfile group 26;
Database altered.

SQL> alter database drop standby logfile group 26;
Database altered.

然後使用如下的方式重置資料檔案，比如下面的例子：

alter database create datafile '/U01/app/oracle/product/11.2.3/db_1/dbs/UNNAMED00874' as '+DATA/sgstatdb3/datafile/tlbb_data17.dbf';

然後重新開啟日誌應用，但是發現RMAN開始不聽話了。

$ rman target /
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04005: error from target database:
ORA-00604: error occurred at recursive SQL level 1
ORA-01219: database not open: queries allowed on fixed tables/views only
ORA-06508: PL/SQL: could not find program unit being called: "SYS.X$DBMS_BACKUP_RESTORE"
ORA-06512: at line 1
RMAN-04015: error setting target database character set to ZHS16GBK

    看錯誤是在x$的一個物件上過不去了。這個時候簡單想想x$是記憶體表，是在資料庫啟動的過程中初始化的，我們可以採用如下的策略來解決。

先讓MRP開啟歸檔日誌應用，應用一部分歸檔，然後重啟資料庫到Mount狀態，開啟RMAN清理。這樣閃回區的問題就解決了，都得算計著用空間。

   就這樣花了個把小時的時間，問題總算是順利解決了。

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

最後發起一個小活動，最近讀了一些書，也交了一些書友，如果有願意一起來參與讀書的小夥伴們，我們們一起來吧，不限職業年齡，要求只有一個，喜愛讀書即可。當然入群要推薦一本書。

    因為微信群掃碼已滿，需要加入的同學可以加我微信 jeanron100,說明來意和你推薦的一本書即可，我來加你入群。

    沒啥目的，沒啥動機，讀書的事情我就不強求了，豐富自己，也可以互相聊聊。