最近在無疑中查看一個數據庫的日志的時候，發現里面有這么一段內容。

Sat Feb 06 10:07:25 2016
Deleted Oracle managed file +ARCH/testdb2/archivelog/2016_01_13/thread_1_seq_4566.261.901038877
Archived Log entry 9262 added for thread 1 sequence 4678 ID 0x26b3e123 dest 1:
Sat Feb 06 14:04:52 2016
Thread 1 advanced to log sequence 4680 (LGWR switch)
? Current log# 1 seq# 4680 mem# 0: +DATA/testdb2/onlinelog/group_1.261.815382013
Sat Feb 06 14:04:52 2016
LNS: Standby redo logfile selected for thread 1 sequence 4680 for destination LOG_ARCHIVE_DEST_2
Sat Feb 06 14:04:52 2016
Deleted Oracle managed file +ARCH/testdb2/archivelog/2016_01_13/thread_1_seq_4567.258.901058415
Archived Log entry 9264 added for thread 1 sequence 4679 ID 0x26b3e123 dest 1:

這段日志的亮點就在于"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>crosscheck archivelog all;
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1668 device type=DISK
validation succeeded for archived log
archived log file name=+ARCH/testdb2/archivelog/2016_01_14/thread_1_seq_4568.369.901073863 RECID=9042 STAMP=901073862
validation succeeded for archived log
archived log file name=+ARCH/testdb2/archivelog/2016_01_14/thread_1_seq_4569.262.901095119 RECID=9043 STAMP=901095118
validation succeeded for archived log
archived log file name=+ARCH/testdb2/archivelog/2016_01_14/thread_1_seq_4570.259.901095121 RECID=9045 STAMP=901095121

關于歸檔的刪除策略，其實從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；
當然里面只有一條自定義的配置

NAME?????????????????????????? VALUE
------------------------------ ------------------------------
ARCHIVELOG DELETION POLICY???? TO APPLIED ON ALL STANDBY

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

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY clear;
old RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
RMAN configuration parameters are successfully reset to default value

然后手工切換一次日志。得到的日志如下，又看到了一些額外的信息。

Sat Feb 06 22:16:30 2016
Thread 1 advanced to log sequence 4683 (LGWR switch)
? Current log# 7 seq# 4683 mem# 0: +DATA/testdb2/onlinelog/group_7.271.817297835
Sat Feb 06 22:16:30 2016
Trying to expand controlfile section 11 for Oracle Managed Files
Expanded controlfile section 11 from 224 to 448 records
Requested to grow by 224 records; added 8 blocks of records
LNS: Standby redo logfile selected for thread 1 sequence 4683 for destination LOG_ARCHIVE_DEST_2
Sat Feb 06 22:16:30 2016
Archived Log entry 9270 added for thread 1 sequence 4682 ID 0x26b3e123 dest 1:

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

this is nothing to worry about.
the following is an extract from metalink

Starting in Oracle8 the controlfile is automatically expanded.
A new datafile is added beyond the maxdatafiles limited specified
in the control file.

This also happens if new records are added to the "log_history" section of
the control files and there are no entries that could be replaced.

The routine that performs the expansion writes this message to the alert log.
The messages specifies the section that was expanded and the amount of
the expansion. Please note that this message cannot be turned off.

好了，看到這里，我們還是很有必要去看一下涉及的視圖 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
所以通過日志中的一條信息，逐步測試最后發現了一些意料之外的情況，還是需要好好琢磨琢磨這些內容。

來自 “ ITPUB博客 ” ，鏈接：http://blog.itpub.net/23718752/viewspace-1987044/，如需轉載，請注明出處，否則將追究法律責任。

轉載于:http://blog.itpub.net/23718752/viewspace-1987044/

總結

以上是生活随笔為你收集整理的11g主库归档自动删除的小问题分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。