物理备库被置为managed standby时,其上的online redo log报错
时间:2011-01-27 来源:iolia131
当standby切换为primary时,需要clear其online redo。但在10.2版本上的standby数据库上,如果将standby置为managed standby,Oracle会认为是切换的前奏,并在这一步clear日志,以节省切换的时间。如果备库上online redo在数据字典中存在,但在磁盘上不存在,就会报错:
Thu Oct 27 09:41:47Attempt to start background Managed Standby Recovery process (ora)
MRP0 started with pid=47, OS id=32094
Thu Oct 27 09:41:47 2005
MRP0: Background Managed Standby Recovery process started (ora)
Managed Standby Recovery not using Real Time Apply
Thu Oct 27 09:41:52 2005
Errors in file /app/oracle/admin/ora/bdump/ora_mrp0_32094.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u03/oradata/ora/ora_rdo01c.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/u02/oradata/ora/ora_rdo01b.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
既然不存在,Oracle就要试着创建物理文件,也就是clearing。如果备库online redo的路径与主库一致,并且没有设置log_file_name_convert,就会报错:
Thu Oct 27 09:41:52 2005
Errors in file /app/oracle/admin/ora/bdump/ora_mrp0_32094.trc:ORA-19527: physical standby redo log must be renamed
ORA-00312: online log 1 thread 1: '/ora01/oradata/ora/ora_rdo01a.log'
Clearing online redo logfile 1 complete
Media Recovery Waiting for thread 1 sequence 55
Thu Oct 27 09:41:53 2005
Completed: alter database recover managed standby database disconnect from
session.
检查可发现,物理文件并没有创建,也就是clear失败。
其实这个错误并不影响MRP的启动和运行,只是在每次MRP启动时报一下错而已,完全可以置之不理。
解决方法:
可以看出,这里面有两个错误,磁盘文件不存在,导致第一个;无法创建,导致第二个。如果解决了第二个错误,创建了磁盘文件,那么第一个错误就自然也解决了。
解决第二个错误的方法很简单,设置log_file_name_convert,即使主备库online redo路径完全相同,也要设置。然后重启standby,oralce会自动创建online redo。
其实这是一个Oracle的安全机制,防止当主备库在同一机器上时,备库会把主库的online redo clear掉,设置了这个参数就相当于告诉Oracle,我注意到了这个风险,但是无妨,放心的clear吧!
另一篇淘宝DBA的文章:
Oracle10g的问题还真多,一个接一个。之所以标题说这个是问题而不是bug,是因为metalink说这是10g功能的增强而不是bug。
在做主备切换的时候,需要将备库的联机日志文件清除(clear online redo logfile),为了加快switchover的速度,Oracle10g在将备库置于manged standby状态的时候就提前将这个clear的动作做了,这个想法是好的,只是实现有点糟糕,会在alert里记录错误一堆错误:
Errors in file /u01/oracle/admin/ning/bdump/ning_mrp0_319584.trc:
ORA-00367: checksum error in log file header
ORA-00316: log 1 of thread 1, type 0 in header is not log file
ORA-00312: online log 1 thread 1: ‘/u01/oracle/oradata/ning/redo01_01.dbf’
Clearing online redo logfile 1 /u01/oracle/oradata/ning/redo01_01.dbf
Clearing online log 1 of thread 1 sequence number 3715
Tue Mar 4 19:00:07 2008
Errors in file /u01/oracle/admin/ning/bdump/ning_mrp0_319584.trc:
ORA-19527: physical standby redo log must be renamed
ORA-00312: online log 1 thread 1: ‘/u01/oracle/oradata/ning/redo01_01.dbf’
Clearing online redo logfile 1 complete
Oracle不承认这是bug,不过还是给出了解决方法:首先要在备库创建online redo logfile,然后设置log_file_name_convert参数,即使主备库日志文件的路径和名字都一样也要设置,不然还是会报ORA-19527。
参考Note:352879.1
In this Document
Symptoms
Cause
Solution
References
Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.1.0.7
This problem can occur on any platform.
This issue is seen starting in release 10gR2
Symptoms
Upon starting the Managed Recovery Process in a Standby Database the following Errors may be seen
Thu Oct 27 09:41:47 2005
Attempt to start background Managed Standby Recovery process (ora)
MRP0 started with pid=47, OS id=32094
Thu Oct 27 09:41:47 2005
MRP0: Background Managed Standby Recovery process started (ora)
Managed Standby Recovery not using Real Time Apply
Thu Oct 27 09:41:52 2005
Errors in file /app/oracle/admin/ora/bdump/ora_mrp0_32094.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u03/oradata/ora/ora_rdo01c.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/u02/oradata/ora/ora_rdo01b.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
If the files are created then you may then receive the following errors
Thu Oct 27 09:41:52 2005
Errors in file /app/oracle/admin/ora/bdump/ora_mrp0_32094.trc:
ORA-19527: physical standby redo log must be renamed
ORA-00312: online log 1 thread 1: '/ora01/oradata/ora/ora_rdo01a.log'
Clearing online redo logfile 1 complete
Media Recovery Waiting for thread 1 sequence 55
Thu Oct 27 09:41:53 2005
Completed: alter database recover managed standby database disconnect from
session.
You may also see following messages on MRP startup even with log_file_name_convert parameter set
ORA-00312: online log 11 thread 2: '+ARCH_1/p2brp_dr/onlinelog/group_11.285.609666683'
ORA-17503: ksfdopn:2 Failed to open file +ARCH_1/p2brp_dr/onlinelog/group_11.285.609666683
ORA-15012: ASM file '+arch_1.285.609666683' does not exist
ORA-00312: online log 11 thread 2: '+DATA_1/p2brp_dr/onlinelog/group_11.299.609666681'
ORA-17503: ksfdopn:2 Failed to open file +DATA_1/p2brp_dr/onlinelog/group_11.299.609666681
ORA-15012: ASM file '+data_1.299.609666681' does not exist
Cause
This is in fact an Enhancement to the Data Guard Technology introduced in 10.2.0.
The Goal here is to improve speed of Switchover and Failover. In previous Versions a Role Transition would require to clear the Online Redo Logfiles before it can become a Primary Database. Now we attempt to clear the Online Redo Logfiles when starting Managed Recovery.
If the Files exist then they will be cleared, but if they do not exist we report the Error, attempts to create the Online Redo Logfiles and starts Recovery. Even if this is not possible because of different Structure and log_file_name_convert is not set, MRP does not fail; it only raises these Errors.
As an extra Enhancement if the Online Redologs do exist you must specify the log_file_name_convert Parameter even if there is no difference in the Name. This has been implemented to reduce the chances that the Primary Online Redologs are cleared when MRP starts. It is the equivalent of asking - Are you sure you want the logs to be called this....
If the log_file_name_convert parameter is not set then the ORA-19527 is reported and the log file is not cleared at this time..
Solution
Solution to stop both of these errors is to ensure log_file_name_convert is set correctly.
References
BUG:4724888- DATAGUARD ERROR IN 10.2