物理standby上的online redo log在被置为managed standby时报错

物理备库上的online redo log在被置为managed standby时报错   当standby切换为primary时，需要clear其online redo。但在10.2版本上的standby数据库上，如果将standby置为managed standby，Oracle会认为是切换的前奏，并在这一步clear日志，以节省切换的时间。如果备库上online redo在数据字典中存在，但在磁盘上不存在，就会报错：   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   既然不存在，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吧！       下面是3篇参考文章：     Online Redo Logs on Physical Standby [ID 740675.1]
		Modified 14-AUG-2009     Type HOWTO     Status PUBLISHED

In this Document
  Goal
  Solution
  References

---

Applies to:

Oracle Server - Enterprise Edition - Version: 8.1.7.0 to 11.1.0.7
Information in this document applies to any platform.

Goal

Usage of Online Redo Logs on Physical Standby.

Solution

Online redo logs are not used in the physical standby database.

Physical standby database will be in mount stage or read-only stage all the times so it will not be generating any Redo, therefore Online Redologs are not used on the Physical Standby Database (as long as it is acting as a Standby Database).

Changing the Size and Number of the Online Redolog Files is sometimes done/necessary to tune the Database. You can add or drop Online Redolog File Groups or Members on the Primary Database without affecting the Standby Database. Similarly, you can drop Logfile Groups or Members from the Standby Database without affecting your Primary Database. However, these changes do affect the Performance of the Standby Database after Switchover or Failover when it becomes a Primary Database.

So you may want to add/drop Redologs on the Standby Database when you are adding/dropping the Redologs on the Primary Database.

Operation on Redo logs in Physical Standby:

1. Add Redologs on Standby
2. Drop Redologs on Standby
3. Sync Redologs on Primary and Standby

Add Redo Logs on Standby

1. Stop Redo apply:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2. Set STANDBY_FILE_MANAGEMENT to MANUAL.

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT='MANUAL';

3. Add Redolog File Group:

SQL> ALTER DATABASE ADD LOGFILE GROUP 4 ('\U01\oracle\stdby10g\redo04.log') SIZE 100M;

Add as many Redo Logfile Groups (or Members) you want to add.

4. Set STANDBY_FILE_MANAGEMENT to AUTO.

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT='AUTO';

5. Start Redo Apply (Managed Recovery):

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Drop Redo Logs on Standby

1. Check the Status of the Online Redolog Group.

SQL> SELECT GROUP#, STATUS FROM V$LOG;

GROUP# STATUS
---------- ----------------
1 CLEARING_CURRENT
3 CLEARING
2 CLEARING

If Status is CLEARING_CURRENT or CURRENT then you cannot drop Online Redolog Group, please use "Sync Redo Logs on Primary and Standby" Section in this Case. You will get ORA-01623 if you try to drop a Redolog Group with Status CLEARING_CURRENT or CURRENT.
For Status CLEARING, UNUSED, INACTIVE please follow below steps.

2. Stop Redo Apply:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

3. Set STANDBY_FILE_MANAGEMENT to MANUAL.

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT='MANUAL';

4. Clear the Online Redo Logfile Group:

SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2;

5. Drop the Online Redo Logfile Group:

SQL>ALTER DATABASE DROP LOGFILE GROUP 2;

If you have skipped Step 4 then you will get ORA-01624 while droping the Online Redolog Group with Status CLEARING.

6. Set STANDBY_FILE_MANAGEMENT to AUTO.

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT='AUTO';

7. Start Redo Apply:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Sync Redo Logs on Primary and Standby

1. Make all the Changes related to Redolog Groups (Add/delete/Modify) in the Primary Database available to the Standby Database in one Step.

2. Shutdown the Standby Database.

SQL> SHUTDOWN IMMEDIATE

3. Drop all Redolog Group Files using OS Command or ASMCMD Command depending on the Location of the Online Redo Logs on the Standby Database

4. Recreate the Standby Controlfile using these Notes:

Note 459411.1 : Steps to recreate a Physical Standby Controlfile

OR

Note.734862.1 : Step by step guide on how to recreate standby control file when datafiles are on ASM and using Oracle Managed Files

5. Startup the Database in mount Stage.

Oracle 8i and 9i (8.x - 9.x):

SQL> STARTUP NOMOUNT
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

Oracle 10g and 11g (10.x - 11.x):

SQL> STARTUP MOUNT

6. Clear all Redolog Groups on Standby (only when using Oracle Database <10.2.0.1).

SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;

Repeat step 6 for all Online Redolog File Groups.

7. Start Redo Apply (when using Oracle Database >=10.2.0.1, this will automatically clear and physically create the Online Redologs):

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

References

NOTE:459411.1 - Steps to recreate a Physical Standby Controlfile
NOTE:734862.1 - Step By Step Guide On How To Recreate Standby Control File When Datafiles Are On ASM And Using Oracle Managed Files

---

Related Products Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition Keywords REDO LOG; STANDBY_FILE_MANAGEMENT; PHYSICAL STANDBY; ONLINE REDO LOG; REDOLOG FILE Errors ORA-1623; ORA-1624

 

 

另一篇淘宝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

 

ORA-19527 reported in Standby Database when starting Managed Recovery [ID 352879.1]
		Modified 02-JUN-2009     Type PROBLEM     Status PUBLISHED

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

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

转载于:http://blog.itpub.net/8684388/viewspace-674014/