11g主庫歸檔自動刪除的小問題分析

最近在無疑中檢視一個資料庫的日誌的時候，發現裡面有這麼一段內容。

這段日誌的亮點就在於"Deleted Oracle managed file"
這是一個11gR2的主庫，使用了ASM作為資料儲存。如果看到這段自動刪除歸檔的內容，很可能和一個特性聯絡起來，那就是閃回區的自動刪除歸檔的閥值 80%，在11g ADG中會有這樣的而一個特性，閃回區使用率達到80%以上的時候，會幫助清理一些過期的歸檔日誌檔案。同時出現這個問題和另外一個引數有關，那就是閃回 區的大小設定，如果太小了，使用率馬上就會達到80%，所以這個引數db_recovery_file_dest_size也值得關注。
目前的引數配置為：

SQL> show parameter reco

NAME                                 TYPE        VALUE

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

control_file_record_keep_time        integer     7

db_recovery_file_dest                string      +ARCH

db_recovery_file_dest_size           big integer 100G

db_unrecoverable_scn_tracking        boolean     TRUE

recovery_parallelism                 integer     0

那麼這個問題中，先不說主備庫是否都使用哪個特性，先看看主庫閃回區使用率到底是多少呢？

SQL>select *from v$flash_recovery_area_usage;

FILE_TYPE            PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES

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

CONTROL FILE                        .01                         0               1

REDO LOG                              0                         0               0

ARCHIVED LOG                       3.92                      3.89             112

BACKUP PIECE                          0                         0               0

IMAGE COPY                            0                         0               0

FLASHBACK LOG                         0                         0               0

FOREIGN ARCHIVED LOG                  0                         0               0

所以這個問題就比較奇怪了，使用率遠遠沒有達到80%的閥值，怎麼會自動刪除呢，當然檢視了MOS也發現了一些相關的bug,（4911954），有的可能是v$flash_recovery_area_usage和V$RECOVERY_FILE_DEST的資料情況會有較大出入，會有這種情況，不過我的這個環境從版本的日誌來看，是沒有關係的。

FILE_TYPE            PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES

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

CONTROL FILE                        .01                         0               1

REDO LOG                              0                         0               0

ARCHIVED LOG                       3.92                      3.89             112

BACKUP PIECE                          0                         0               0

IMAGE COPY                            0                         0               0

FLASHBACK LOG                         0                         0               0

FOREIGN ARCHIVED LOG                  0                         0               0

然後繼續找可能的情況，從日誌中發現了一個特別的情況，也是規律，那就是刪除的歸檔是24天以前的，切一次日誌，刪除一次24天以前的舊歸檔。
可以透過rman中的操作 crosscheck archivelog all觀察和分析日誌得出。

關於歸檔的刪除策略，其實從rman中也可以做一些配置。如果配置是這樣的情況，刪除策略就是保留24天。
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 24 DAYS;
不過我這個問題的情況還不是，rman的配置都是取預設，只有一條新增的配置。
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
這個時候，怎麼透過sql語句來檢視rman中的相關設定呢，主要可以透過下面的方式來看。
SELECT NAME,VALUE FROM V$RMAN_CONFIGURATION；
當然裡面只有一條自定義的配置

我們這個時候來簡單測試一下這個配置的影響。取消自定義的配置。取預設值。

然後手工切換一次日誌。得到的日誌如下，又看到了一些額外的資訊。

對於看起來有些陌生的日誌，當然也是集各家之言。
有一個老外的建議非常專業，我就直接貼出來了，對於這些日誌的說明，他的解釋如下：

好了，看到這裡，我們還是很有必要去看一下涉及的檢視 v$controlfile_record_section，

修改rman配置之後的檢視內容如下，只顯示了alert日誌中說明的部分section 11相關的記錄。

TYPE         RECORD_SIZE RECORDS_TOTAL RECORDS_USED FIRST_INDEX LAST_INDEX LAST_RECID

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

LOG HISTORY           56           292          292          12         11       4683

所以這個問題又指向了控制檔案，對於控制檔案，我們有一個資料庫引數相關。

SQL> show parameter control_file_record_keep_time

NAME                                 TYPE        VALUE

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

control_file_record_keep_time        integer     7
所以透過日誌中的一條資訊，逐步測試最後發現了一些意料之外的情況，還是需要好好琢磨琢磨這些內容。