dataguard歸檔路徑的問題

最近處理了一起看似比較奇怪的dataguard歸檔路徑問題。
問題的背景是這樣的。
有一套一主兩備的環境，備庫1和主庫在同一個機房，可以嘗試在failover的時候切換備庫IP為主庫IP。另外還有一臺伺服器是作為異地災備。
最近有一臺伺服器出現了當機，然後做了災難切換，類似下面的情況。

當然，災備的重要性在某一天觸發。然後做了failover,就近的伺服器由備庫變為主庫。

這個時候如果備庫1這臺伺服器再出問題，那麼就只能切換到異地機房，同時應用端就需要修改IP地址了。當然這也是預案。
在此期間，主庫也在嘗試進行修復，然後過了些天之後，這臺伺服器就修復了。
所以現在的工作是搭建第二個備庫，當然搭建這個備庫為了減少主庫的壓力，是直接透過在第一個備庫中進行rman備份，然後複製到備庫2，再做恢復。

這種情況下對於主庫的壓力最小。只需要主庫在最後的dg broker驗證階段建立主備的關係即可。問題就發生在這個備庫的搭建過程中。
其實配置這些都做了檢查，也都沒有問題，但是備庫搭建好之後，配置dg broker開始應用日誌的時候，發現備庫的歸檔接收地址竟然是$ORACLE_HOME/dbs這個目錄。
當然從接收歸檔的角度而言，這個對於dataguard是沒有影響的，但是我再三做了檢查，快速閃回區，歸檔路徑都配置了。歸檔就是在$ORACLE_HOME/dbs這個路徑下面。
生成的歸檔檔案類似下面的格式。
-rw-r-----   1 oracle   oinstall 469527552 Jan 31 00:23 dgsby_stestdb31_603_901350450.arc
-rw-r-----   1 oracle   oinstall 196185600 Jan 31 00:23 dgsby_stestdb31_604_901350450.arc
-rw-r-----   1 oracle   oinstall 195798528 Jan 31 00:24 dgsby_stestdb31_605_901350450.arc
-rw-r-----   1 oracle   oinstall 195805184 Jan 31 00:25 dgsby_stestdb31_606_901350450.arc
-rw-r-----   1 oracle   oinstall 506630656 Jan 31 00:25 dgsby_stestdb31_607_901350450.arc
-rw-r-----   1 oracle   oinstall 196911616 Jan 31 00:25 dgsby_stestdb31_608_901350450.arc
-rw-r-----   1 oracle   oinstall 196895744 Jan 31 00:25 dgsby_stestdb31_609_901350450.arc
-rw-r-----   1 oracle   oinstall 507368960 Jan 31 00:27 dgsby_stestdb31_610_901350450.arc
dg broker也沒有任何錯誤，使用verbose檢視備庫的明細資訊：
   HostName                        = 'testcenter.test.com'
    SidName                         = 'testdb'
    LocalListenerAddress            = '(ADDRESS=(PROTOCOL=TCP)(HOST=10.xxxxx)(PORT=1539))'
    StandbyArchiveLocation          = 'dgsby_testdb'
    AlternateLocation               = ''
    LogArchiveTrace                 = '0'
    LogArchiveFormat                = '%t_%s_%r.arc'
    LatestLog                       = '(monitor)'
    TopWaitEvents                   = '(monitor)'
備庫的歸檔設定是一個別名，而不是一個路徑
對於這種情況感覺非常彆扭，就希望儘快把這個問題弄明白。然後手工修改歸檔路徑，閃回區設定還是無濟於事。
這種情況越是奇怪，越是引起了我的好奇，然後就開始認真檢視日誌。發現了這麼一段內容。
ARC0: Thread not mounted
Sat Jan 30 23:07:26 2016
Errors in file /U01/app/oracle/admin/testdb/udump/testdb_ora_15343.trc:
ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not known to database.
Sat Jan 30 23:07:26 2016

trace日誌的詳細內容為：
/U01/app/oracle/admin/testdb/udump/testdb_ora_15343.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning and Data Mining options
ORACLE_HOME = /U01/app/oracle/product/10.2
System name:    SunOS
Node name:      stestdb3.test.com
Release:        5.10
Version:        Generic_137111-06
Machine:        sun4v
Instance name: testdb
Redo thread mounted by this instance: 0 <none>
Oracle process number: 21
Unix process pid: 15343, image: oracle@stestdb3.test.com (TNS V1-V3)

*** 2016-01-30 23:07:22.206
*** ACTION NAME:(0000010 FINISHED129) 2016-01-30 23:07:22.205
*** SERVICE NAME:() 2016-01-30 23:07:22.205
*** SESSION ID:(5270.9) 2016-01-30 23:07:22.205
kccsga_update_ckpt: num_1 = 8, num_2 = 0, num_3 = 0, lbn_2 = 0, lbn_3 = 0
ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not known to database.
*** 2016-01-30 23:07:26.436
*************************************************************
WARNING: Files created after time 01/30/2016 11:17:41 may exist in
db_recovery_file_dest that is not known to the database.
Use the RMAN command CATALOG RECOVERY AREA to re-catalog
any such files. This is most likely the result of a crash
during file creation.
********************************************
對於這個問題其實還沒怎麼看明白，歸檔路徑還有什麼特殊的設定。
使用rman crosscheck archivelog all的時候，發現這個歸檔路徑下面竟然有2014年的一些歸檔日誌。
archive log filename=/U01/app/oracle/flash_recovery_area/Stestdb3/archivelog/2014_05_15/o1_mf_1_208468_9q788hoo_.arc recid=1 stamp=902531829
validation failed for archived log
archive log filename=/U01/app/oracle/flash_recovery_area/Stestdb3/archivelog/2014_05_15/o1_mf_1_208469_9q79r89t_.arc recid=2 stamp=902531829
validation failed for archived log
archive log filename=/U01/app/oracle/flash_recovery_area/Stestdb3/archivelog/2014_05_15/o1_mf_1_208470_9q79v2y3_.arc recid=3 stamp=902531829  
而且這些歸檔日誌檔案是很早以前的，不知道什麼原因竟然保留了下來，可見就是這些過舊的歸檔檔案造成了干擾。
這麼陳舊的歸檔檔案確實不需要確認，直接刪除即可。這就是前人留下的一個坑。
然後刪除之後，dg broker就需要重新配置了。
DGMGRL> edit database stestdb3 set property StandbyArchiveLocation='location=use_db_recovery_file_dest';
Property "standbyarchivelocation" updated
然後再次從主庫切換歸檔，就可以看到在新的目錄下生成了得到了最新的歸檔日誌檔案。
drwxr-x---   3 oracle   oinstall   15872 Jan 31 01:03 archivelog
drwxr-x---   2 oracle   oinstall     512 Mar  6  2012 onlinelog
-bash-3.1$ cd archivelog/
-bash-3.1$ ls -R
total 2
drwxr-x---   2 oracle   oinstall     512 Jan 31 01:03 2016_01_31
total 18512
-rw-r-----   1 oracle   oinstall 209715712 Jan 31 01:04 o1_mf_1_637_cbsv6p84_.arc
所以對於資料庫中的過舊的歸檔檔案也需要格外主要，如果不加以注意，很可能在以後會被很多資訊所干擾。