Standby Common Database Error Handling

1. Execute: Alter database recover managed standby database disconnect from session;
The following error is reported in the background alert file:
Errors in file/u01/Oracle/admin/primary/bdump/primary_mrp0_2967.trc:
ORA-19527: Physical standby redo log must be renamed
ORA-00312: Online log 1 thread 1: '/u01/Oracle/oradata/primary/redo01.log'

This error is caused by Oracle's risk of accidentally clearing the online logs of the master database.
Oracle does not know whether your master and slave databases are on one machine or different machines. If they are on the same machine, the primary database may be cleared online accidentally.

If you switch logfile in the master database first, then alter database recover managed standby database disconnect from session; the following error is reported:
Errors in file/u01/Oracle/admin/primary/bdump/primary_mrp0_2967.trc:
ORA-00313: Open failed for members of log group 1 of thread 1
ORA-00312: Online log 1 thread 1: '/u01/Oracle/oradata/primary/redo01.log'
ORA-27037: unable to obtain File status
Linux error: 2: no such file or directory
Additional information: 3

This error will occur at 10 GB and 9i will not. This is because online logs need to be cleared during switch over. In 10 Gb, Oracle clears online logs of the slave database during recovery to speed up swich over.

There is no redologs when the slave database is initially created. to specify the log_file_name_convert parameter, re-Alter database recover managed standby database disconnect from session; then the process will automatically create the redo file.

The above two problems can be seen as a problem. The solution is to set log_file_name_convert in the standby database, as shown in:
Log_file_name_convert = '/u01/primary/', '/u01/primary /'

Note: This error occurs even in the master-slave database with the same directory structure.

2,
Run: Alter database recover managed standby database cancel;
The following error occurs in the background alert file:
Errors in file/u01/Oracle/admin/primary/bdump/primary_mrp0_2967.trc:
ORA-16037: user requested cancel of managed recovery operation
Recovery interrupted!
This error is normal and you don't have to worry about it.

3. Errors in file/opt/u01/APP/Oracle/admin/ora8/bdump/ora8_arc1_27096.trc:
ORA-16401: archivelog rejected by RFS

ORA-16401:	Archivelog rejected by RFS
Cause:	An attempt was made to re-archive an existing archivelog. This usually happens because either a multiple primary database or standby database (s) or both are trying to archive to this standby database.
Action:	See Alert Log and trace file for more details. No action is necessary; this is an informational statement provided to record the event for diagnostic purposes.

It is a normal information. By observing the logs of the slave machine, we find that redo is still applied.
For example:
Thuoct 16 15:18:44 2008
Redo shipping Client Connected as public
-- Connected user is valid
RFS [6]: assigned to RFS process 14001
RFS [6]: identified database type as 'physical standby'
RFS [6]: archivelog thread 1 sequence 7616 cannot be reused
Thuoct 16 15:18:44 2008
Errors in file/u01/APP/Oracle/admin/ora8/udump/ora8_rfs_14001.trc:
ORA-16401: archivelog rejected by RFS
Thuoct 16 15:19:14 2008
Media recovery log/opt/archive/1097616_652298303.arc
Media recovery waiting for thread 1 sequence 7617 (in transit)

4,
Errors in file/u01/Oracle/admin/primary/udump/primary_rfs_3380.trc:
ORA-00313: Open failed for members of log group 4 of thread 1
ORA-00312: Online log 4 thread 1: '/u01/Oracle/oradata/primary/standbyredo04.log'
ORA-27037: unable to obtain File status
Linux error: 2: no such file or directory
Additional information: 3
Sun Jun 24 15:36:05 2007
Errors in file/u01/Oracle/admin/primary/udump/primary_rfs_3380.trc:
ORA-00313: Open failed for members of log group 4 of thread 1
ORA-00312: Online log 4 thread 1: '/u01/Oracle/oradata/primary/standbyredo04.log'
ORA-27037: unable to obtain File status
Linux error: 2: no such file or directory
Additional information: 3
.......
......
Sun Jun 24 15:36:05 2007
Errors in file/u01/Oracle/admin/primary/udump/primary_rfs_3380.trc:
ORA-00313: Open failed for members of log group 7 of thread 1
ORA-00312: Online log 7 thread 1: '/u01/Oracle/oradata/primary/standbyredo7.log'
ORA-27037: unable to obtain File status
Linux error: 2: no such file or directory
Additional information: 3
Sun Jun 24 15:36:05 2007
Errors in file/u01/Oracle/admin/primary/udump/primary_rfs_3380.trc:
ORA-00313: Open failed for members of log group 7 of thread 1
ORA-00312: Online log 7 thread 1: '/u01/Oracle/oradata/primary/standbyredo7.log'
ORA-27037: unable to obtain File status
Linux error: 2: no such file or directory
Additional information: 3
RFS [1]: Unable to open standby log 7: 313
RFS [1]: No standby redo logfiles created
RFS [1]: Archived log: '/u01/archivelog/41012_626824231.dbf'
Sun Jun 24 15:36:07 2007
Redo shipping Client Connected as public

This error occurs mainly because the standby redo log is created in the master database before the backup. The slave database is created based on the information of the master database. At first, it contains the standby redo log information of the master database, if the log transmission method set by the master database is lgwr, when the master database switches, The RFS of the slave database tries to use the standby redo log to store the logs sent from the master database, because the standby database does not actually have the standby redo log, the Standby database reports an error. When the standby database fails to open all standby redo logs of the dictionary information, the Standby database automatically converts the log transfer method to arcn and clears the standby redo log information in the data dictionary.

The following is the data dictionary information before the standby redo log information is cleared:
SQL> select * from V $ logfile;

Group # status type member is _
---------------------------------------------------------------------------------------
1 online/u01/Oracle/oradata/primary/redo01.log No
2 online/u01/Oracle/oradata/primary/redo02.log No
3 online/u01/Oracle/oradata/primary/redo03.log No
4 standby/u01/Oracle/oradata/primary/standbyredo04.log No
5 standby/u01/Oracle/oradata/primary/standbyredo5.log No
6 standby/u01/Oracle/oradata/primary/standbyredo6.log No
7 standby/u01/Oracle/oradata/primary/standbyredo7.log No

7 rows selected.

The following information is the data dictionary information after the standby database tries to open the standby redo log:

SQL> select * from V $ logfile;

Group # status type member is _
---------------------------------------------------------------------------------------
1 online/u01/Oracle/oradata/primary/redo01.log No
2 online/u01/Oracle/oradata/primary/redo02.log No
3 online/u01/Oracle/oradata/primary/redo03.log No

Note: After you add the standby redo log to the slave database, Oracle will send the log again with lgwr during the next log switch.