資料庫日誌中一條"異常"資訊所包含的細節

今天在梳理伺服器的資訊的時候，發現有一臺伺服器沒有設定crontab作業,一般的伺服器中可能會需要一些定時的任務來觸發一些備份，清理等等工作。
因為這是一臺備庫機器，上面有11gR2的備庫,所以首要工作就是檢視是否在正常應用日誌。
從日誌來看，歸檔已經正常應用。不過似乎有一些相對陌生的操作在日誌裡面。
Archived Log entry 68735 added for thread 1 sequence 95373 ID 0x70141a28 dest 1:
Tue Aug 04 16:00:29 2015
Media Recovery Waiting for thread 1 sequence 95374 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 95374 Reading mem 0
  Mem# 0: /U01/app/oracle/oradata/xxxxxx/std_redo04.log
Tue Aug 04 16:22:32 2015
RFS[6]: Selected log 5 for thread 1 sequence 95375 dbid 1880348712 branch 828552874
Tue Aug 04 16:22:32 2015
Deleted Oracle managed file /U01/app/oracle/fast_recovery_area/xxxxxx/archivelog/2015_07_15/o1_mf_1_92947_btbdqpm3_.arc
Tue Aug 04 16:22:32 2015
Media Recovery Waiting for thread 1 sequence 95375 (in transit)
Recovery of Online Redo Log: Thread 1 Group 5 Seq 95375 Reading mem 0
  Mem# 0: /U01/app/oracle/oradata/xxxxxx/std_redo05.log
Archived Log entry 68736 added for thread 1 sequence 95374 ID 0x70141a28 dest 1:
Tue Aug 04 16:45:30 2015
RFS[6]: Selected log 4 for thread 1 sequence 95376 dbid 1880348712 branch 828552874
Tue Aug 04 16:45:30 2015
Deleted Oracle managed file /U01/app/oracle/fast_recovery_area/xxxxxx/archivelog/2015_07_15/o1_mf_1_92948_btbdqwmt_.arc
Tue Aug 04 16:45:30 2015
Media Recovery Waiting for thread 1 sequence 95376 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 95376 Reading mem 0
  Mem# 0: /U01/app/oracle/oradata/xxxxxx/std_redo04.log
Archived Log entry 68737 added for thread 1 sequence 95375 ID 0x70141a28 dest 1:
按照這個頻率，似乎每次接受一次歸檔，都會觸發一次自動的刪除就歸檔的操作。
這個操作很明顯不是在crontab中觸發的，因為crontab沒有啟用，就算啟用，這些操作也不會同步的如此緊密，資料庫日誌中不會有這些資訊。
帶著疑問，檢視了一些相關的帖子，其中有一篇文章是老熊寫的， /> 在文章中還提供了一個metalink的連結解釋。
Files being deleted in the flash recovery area, messages in the alert log Deleted Oracle managed file <filename> (文件 ID 1369341.1)
對於這個問題，其實在11gR2開始，Oracle會根據閃回恢復區的大小，設定一個閥值，預設是80%,即如果歸檔空間的使用率超過80%,則會自動觸發刪除歸檔。
可以在當前的環境簡單驗證。
SQL> SQL> show parameter recover
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      /U01/app/oracle/fast_recovery_area                                                 
db_recovery_file_dest_size           big integer 120G
檢視閃回區域的使用情況如下：
[fast_recovery_area]$ du -sh ./*
18M     ./hxxxx
96G     ./SHxxxxx
如果細細檢視，會發現在近期確實生成了大量的歸檔檔案。
...
3.9G    ./2015_07_23
3.8G    ./2015_07_24
3.9G    ./2015_07_25
3.9G    ./2015_07_26
8.7G    ./2015_07_27
3.9G    ./2015_07_28
4.1G    ./2015_07_29
4.0G    ./2015_07_30
4.3G    ./2015_07_31
4.1G    ./2015_08_01
4.1G    ./2015_08_02
8.9G    ./2015_08_03
3.2G    ./2015_08_04
當然系統級檢視似乎還是不夠清晰，我們可以用個試圖來看看，一目瞭然。
SQL> select * from V$RECOVERY_AREA_USAGE;  
FILE_TYPE            PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
-------------------- ------------------ ------------------------- ---------------
CONTROL FILE                          0                         0               0
REDO LOG                              0                         0               0
ARCHIVED LOG                      79.98                     79.92            2427
BACKUP PIECE                          0                         0               0
IMAGE COPY                            0                         0               0
FLASHBACK LOG                         0                         0               0
FOREIGN ARCHIVED LOG                  0                         0               0
可以看到現在的使用情況已經達到了79.98%,已經處於觸發的臨界點了。
對於這個問題，明白了原因，解決起來就容易多了，自己也暗自慶幸這個庫是一個11gR2的庫，要不然沒準我在近期就會收到報警簡訊了。
刪除歸檔，還是直接用rman來做，可以使用下面的指令碼來簡單處理，把一天前的歸檔刪除。
rman target / <<EOF
CONFIGURE ARCHIVELOG DELETION POLICY TO applied on all standby ;
crosscheck archivelog all;
delete noprompt expired archivelog all;
delete noprompt archivelog until time "sysdate-1";
exit
EOF

刪除後再次檢視，空間就釋放了不少。
[archivelog]$ du -sh .
4.1G 
如果對於80%這個閥值存在異議，還是可以透過事件19823來觸發，比如我們希望把閥值調整為90%
就可以這麼設定。
alter system set event='19823 trace name context forever,level 90‘ scope=spfile; 然後需要重啟資料庫生效。
所以透過這個問題我們看到日誌中的一個細小的差別，其實在資料庫層面在觸發一些工作，這個特性相對來說還是比較合理的一個處理。