最近处理了一起看似比较奇怪的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 所以对于数据库中的过旧的归档文件也需要格外主要，如果不加以注意，很可能在以后会被很多信息所干扰。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1986554/，如需转载，请注明出处，否则将追究法律责任。