ITPub博客

首页 > 数据库 > Oracle > dataguard归档路径的问题

dataguard归档路径的问题

原创 Oracle 作者:jeanron100 时间:2016-02-04 22:34:16 0 删除 编辑
最近处理了一起看似比较奇怪的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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
技术文章每天更新,阵地已转移到微信公众号端。 公众号:jianrong-notes

注册时间:2012-05-14

  • 博文量
    1498
  • 访问量
    14397516