DG 歸檔管理
搭建過dg的同窗確定很是清楚歸檔日誌和備份的重要性，這些歸檔日誌從主庫傳輸到備庫，在備庫被apply。linux
思考一個問題：主庫的歸檔日誌是怎麼管理呢，備庫的歸檔又該怎麼管理呢？數據庫
在11g裏面，隨着ASM、RAC、Data Guard（包括Active Data Guard）的成熟，使用RAC+ASM+Data Guard愈來愈成爲一種可靠的、維護簡單、穩定的高可用性和容災保護方案。這篇文章談談如何管理Oracle 11g Data Guard環境中的歸檔日誌。app
歸檔日誌是重要的，否則就沒必要提到這篇文章，備份恢復須要它，而Data Guard也須要它。在早期版本的Data Guard環境中，經常面臨着歸檔日誌管理問題。在Data Guard環境裏面，對歸檔日誌管理須要達到如下幾個方面的要求或者說是需求：測試
- 不可以隨意刪除掉歸檔日誌，歸檔日誌丟失會致使Data Guard須要從新搭建。
- 不能隨意使用RMAN刪除歸檔日誌，不然一樣會致使Data Guard須要從新搭建。
- 在使用RMAN備份後，若是歸檔沒有被傳送或應用到備庫上，那麼RMAN不該該刪除歸檔日誌，不然Data Guard須要的歸檔就必須從備份裏面還原出來，增長了維護工做量。
- 對RMAN的備份腳本沒有特別的要求，不然腳本意外改動，可能會致使Data Guard須要的歸檔日誌被刪除。
- 歸檔應儘可能保存在磁盤上，以免Data Guard長時間維護時歸檔被刪除。
- 備庫的歸檔日誌不須要花精力去維護，自動刪除已經應用過的歸檔日誌。
幸運的是，在11g環境裏面，上述的幾點很容易就知足，那就是隻須要作到如下幾點。spa
- 使用快速恢復區(fast recovery area)，在10g版本的文檔中稱爲閃回恢復區（flash recovery area），老實說，一直不太明白爲何取名叫閃回恢復區，難道是由於10g有了數據庫閃回功能？在RAC中，毫無疑問快速恢復區最好是置放在ASM上。
- 爲快速恢復區指定合適的空間。首先咱們須要預估一個合理的歸檔保留時間長。好比因爲備份系統問題或Data Guard備庫問題、維護等，須要歸檔保留的時間長度。假設是24小時，再評估一下在歸檔量最大的24小時以內，會有多少許的歸檔？通常來講是在批量數據處理的時候歸檔量最大，假設這24小時以內歸檔最大爲200G。注意對於RAC來講是全部節點在這24小時的歸檔量之和。最後爲快速恢復區指定須要的空間量，比經過參數db_recovery_file_dest_size指定快速恢復區的大小。這裏一樣假設快速恢復區們存放歸檔日誌。
- 在備庫上指定快速恢復區以及爲快速恢復區指定合適的大小，在備庫上指定快速恢復區的大小主要考慮的是：切換成爲主庫後歸檔日誌容量；若是主庫歸檔容量壓力大，備庫可否存儲更多的歸檔日誌以即可以經過備庫來備份歸檔日誌。
- 對主庫和備份使用RMAN配置歸檔刪除策略：CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
- 在主備庫 須要指定歸檔路徑爲快速恢復區，這樣纔好讓rman來管理閃回區，log_archive_dest_size_1='location=USE_DB_RECOVERY_FILE_DEST'
完成了上述幾個步驟，那麼歸檔管理的要求基本上就達到了。經過這樣的設置，實現的效果以下：日誌
- 歸檔日誌若是沒有應用到備庫，那麼在RMAN中使用backup .... delete inputs all和delete archivelog all不會將歸檔日誌刪除。但可是請注意若是是使用delete force命令則會刪除掉歸檔，無論歸檔有沒有被應用到備庫。
- 若是歸檔日誌已經應用到了備庫，那麼在RMAN中使用backup .... delete inputs all和delete archivelog all能夠刪除歸檔日誌，在正常狀況下，因爲歸檔日誌可能很快應用到Data Guard，因此在RMAN備份以後能夠正常刪除歸檔日誌。RMAN也不須要使用特別的備份腳本，也沒必要擔憂人爲不當心使用。delete archivelog all命令刪除了歸檔。
- 備庫的歸檔日誌存儲到快速恢復區中，備庫的快速恢復區空間緊張時，會自動刪除已經應用過的較早的歸檔日誌以釋放空間，這樣即可以實現備庫的歸檔日誌徹底自動管理。
- 若是因爲備份異常或Data Guard異常，在快速恢復區空間緊張時，Oracle在切換日誌時，會自動刪除掉已經應用過的歸檔日誌，以釋放空間。可是若是歸檔日誌沒有應用到Data Guard，那麼歸檔日誌不會被刪除。這種狀況下，快速恢復區的歸檔可能會增長到空間耗盡，最後就會出現數據庫不能歸檔，數據庫掛起的問題。
注意上面最後一點，當快速恢復區空間緊張時，Oracle開始刪除歸檔日誌，刪除的條件還包括歸檔日誌已經應用到備庫，這種狀況下若是歸檔日誌尚未備份，也會被刪除掉。這裏的問題是，文檔中描述的快速恢復區空間緊張，具體是指什麼時間？也就是快速恢復區的空間消耗多少百分比的時候纔算是空間緊張？在MOS文章《Files being deleted in the flash recovery area, messages in the alert log Deleted Oracle managed file <filename> (Doc ID 1369341.1)》裏面有提到，空間使用率達到80%之後就開始刪除文件（歸檔日誌）。code
Oracle在往快速恢復區存儲文件時，其步驟大概是這樣的：Oracle估計須要的空間大小（切換日誌時就是歸檔日誌大小），而後將這個大小與當前的佔用空間大小相加，看是否超過了80%，若是超過了，那麼就回收空間（回收的空間應大於等於新建文件須要的空間大小，也就是回收的空間以夠用爲原則）。若是不能回收空間（好比歸檔日誌沒有被應用到備庫），那就只能繼續佔用新的空間，直到空間耗盡。事件
這裏的問題是，假設快速恢復區設定了200G空間，那麼在使用到80%，也就是160G的時候就開始回收空間。那麼咱們在估算空間時，就應該上浮20%。好比咱們要求保留24小時歸檔，這24小時以內歸檔量最大是200G，那麼咱們應該爲快速恢復區設置240G左右的容量。文檔
那麼，這個80%的比率可以更改嗎以便延遲Oracle刪除歸檔日誌的時間嗎？答案是確定的。沒有相應的數據庫參數來設定，可是能夠經過事件來設置，事件號是19823：get
- oerr ora 19823
- 19823, 00000, "soft limit recovery area space pressure percentage"
- // *Document: NO
- // *Cause: Set on all instances to alter recovery area space pressure
- // trigger percentage.
- // *Action: level 1 to 100 indicates the percentage when the space
- // pressure has to be triggered.
下在是一個測試：
測試環境：主庫是Oracle 11.2.0.3 for Linux兩節點RAC，備庫是Oracle 11.2.0.3 for linux單實例庫。測試是在主庫的節點1上進行的，其在線日誌大小爲512MB，快速恢復區指定的大小爲16GB。
當前主庫的FRA（快速恢復區）的使用率已經接近於80%：
select * from V$RECOVERY_AREA_USAGE; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES -------------------- ------------------ ------------------------- --------------- CONTROL FILE 0 0 0 REDO LOG 15.33 0 13 ARCHIVED LOG 64.04 63.81 45 BACKUP PIECE .24 0 1 IMAGE COPY 0 0 0 FLASHBACK LOG 0 0 0 FOREIGN ARCHIVED LOG 0 0 0
發現FRA（快速恢復區）的空間使用率基本上在80%左右。alert日誌也有相應的刪除較早的歸檔日誌的信息：
- Thu Jan 02 12:28:50 2014
- Thread 1 advanced to log sequence 981 (LGWR switch)
- Current log# 12 seq# 981 mem# 0: +DATA1/ractest/onlinelog/group_12.299.835542549
- Current log# 12 seq# 981 mem# 1: +DG_FLA/ractest/onlinelog/group_12.298.835542551
- Thu Jan 02 12:28:50 2014
- LNS: Standby redo logfile selected for thread 1 sequence 981 for destination LOG_ARCHIVE_DEST_2
- Thu Jan 02 12:28:50 2014
- Deleted Oracle managed file +DG_FLA/ractest/archivelog/2014_01_02/thread_2_seq_309.424.835783855
- Deleted Oracle managed file +DG_FLA/ractest/archivelog/2014_01_02/thread_1_seq_947.426.835783855
- Deleted Oracle managed file +DG_FLA/ractest/archivelog/2014_01_02/thread_1_seq_948.437.835784237
- Archived Log entry 2645 added for thread 1 sequence 980 ID 0xc8804744 dest 1:
上面的日誌也能夠看到其過程是：切換日誌；刪除不須要的最老的歸檔日誌；生成新的歸檔日誌。
如今咱們利用事件19823將這個比率調到95%看看會是什麼樣子：
SQL> alter system set event='19823 trace name context forever,level 95' scope=spfile sid='*';
而後重啓主庫。再運行上面的測試代碼，發現Oracle再也不刪除歸檔日誌，而是到接近95%的空間使用率時再開始刪除歸檔日誌：
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES -------------------- ------------------ ------------------------- --------------- CONTROL FILE 0 0 0 REDO LOG 15.33 0 13 ARCHIVED LOG 68.99 65.72 49 BACKUP PIECE .24 0 1 IMAGE COPY 0 0 0 FLASHBACK LOG 0 0 0 FOREIGN ARCHIVED LOG 0 0 0 ............. FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES -------------------- ------------------ ------------------------- --------------- CONTROL FILE 0 0 0 REDO LOG 15.33 0 13 ARCHIVED LOG 78.62 59.9 55 BACKUP PIECE .24 0 1 IMAGE COPY 0 0 0 FLASHBACK LOG 0 0 0 FOREIGN ARCHIVED LOG 0 0 0
從上面的最後一次對v$recovery_area_usage的查詢數據能夠看到，此時空間利用率達到了94.19%，離95%已經很接近（在線日誌的大小是512MB，佔快速恢復區的3.1%，若是在快速恢復區裏面多一個文件就會超過95%）。
接下來咱們將這個比率調整到50%，看看是什麼結果：
SQL> alter system set event='19823 trace name context forever,level 50' scope=spfile sid='*';
而後重啓主庫。再運行上面的測試代碼，發現Oracle在刪除歸檔日誌，可是每次均刪除的日誌只須要容納要新增的文件便可，不會一會兒刪除到使利用率到50%如下：
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES -------------------- ------------------ ------------------------- --------------- CONTROL FILE 0 0 0 REDO LOG 15.33 0 13 ARCHIVED LOG 72.47 48.57 54 BACKUP PIECE .24 0 1 IMAGE COPY 0 0 0 FLASHBACK LOG 0 0 0 FOREIGN ARCHIVED LOG 0 0 0
而後一直使用alter system switch logfile命令，每執行一次，Oracle會刪除一個歸檔日誌，到最後快速恢復區的空間利用率到接近於50%。
- Thu Jan 02 12:56:29 2014
- Thread 1 advanced to log sequence 1004 (LGWR switch)
- Current log# 12 seq# 1004 mem# 0: +DATA1/ractest/onlinelog/group_12.299.835542549
- Current log# 12 seq# 1004 mem# 1: +DG_FLA/ractest/onlinelog/group_12.298.835542551
- Thu Jan 02 12:56:30 2014
- Deleted Oracle managed file +DG_FLA/ractest/archivelog/2014_01_02/thread_1_seq_963.317.835788195
- Thu Jan 02 12:56:30 2014
- LNS: Standby redo logfile selected for thread 1 sequence 1004 for destination LOG_ARCHIVE_DEST_2
- Archived Log entry 2703 added for thread 1 sequence 1003 ID 0xc8804744 dest 1:
- FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
- -------------------- ------------------ ------------------------- ---------------
- CONTROL FILE 0 0 0
- REDO LOG 15.33 0 13
- ARCHIVED LOG 33.29 28.86 65
- BACKUP PIECE .24 0 1
- IMAGE COPY 0 0 0
- FLASHBACK LOG 0 0 0
- FOREIGN ARCHIVED LOG 0 0 0
所以，咱們能夠了解event 19823的用途。對於空間容量比較小的主機，可是但願歸檔可以儘可能保留在快速恢復區，以便留有足夠的備份時間窗口，那麼能夠考慮把這個百分比調整到更大，好比90%，95%等。
- 1. 24Linux - 文件管理（歸檔管理：tar）
- 2. oracle歸檔文件管理
- 3. Windows DG環境中ORACLE 自動清理歸檔
- 4. DG平常維護管理
- 5. 如何管理歸檔文件和歸檔目錄
- 6. ORACLE物理DG平常管理
- 7. Linux-進程，歸檔管理等
- 8. oracle之歸檔日誌空間管理
- 9. oralce搭建DG恢復歸檔時遇到一個"大坑"
- 10. DG上RMAN歸檔刪除策略及with warnings
- 更多相關文章...
- • Swarm 集羣管理 - Docker教程
- • Maven 依賴管理 - Maven教程
- • 算法總結-歸併排序
- • Docker 清理命令
-
每一个你不满意的现在，都有一个你没有努力的曾经。