RFS: No standby redo logfiles …


Some day, you may trap the following error message with your standby database alert log (seen on a 10.2.0.3):

RFS: No standby redo logfiles available

The reason for this message is most probably that you have cloned your standby database with rman and configured your dataguard environment to directly write into redo log at standby (using LGWR), instead of just transfering the archive log items from primary (using ARCH), but have missed to provide the necessary standby redo log files. RFS may also log RFS[1]: Unable to open standby log 9: 313 or something similar (the primary will also complain about connection problems to the standby destination target, which is the standby redo log, actually).

RFS: No standby redo logfiles available of size 104857600 bytes

This is another message you may hit for a comparable reason, however, this one implies that standby redo log files do exist, but of a wrong size. Standby redo log files indeed have to match the size of the online log files as well as the archive log files, respectively. As for this example, oracle expects standby redo log files of size 100 mb.

It is interesting though to see, that dataguard does an intelligent fallback in just leaving the transactional log shipping aside (or in error) and proceeding in the traditional log switch triggered shipping mode (using ARCH). That is, dataguard continues to work, although some misconfiguration is pending. Really cool!

Do regard, by the way, that the things have changed with the introduction of 10.2.0.4. From this release on, a standby database resulting from an rman clone is smart enough to create the necessary standby redo log on the run. In detail and supposed that you already created the standby redo log on the initial primary, the standby database finds from the standby control file that there should exist standby redo log files (which is true for the online log also). However, only with the first log switch from primary, the standby database will step into some standby redo log regeneration by means of log file clearing (see elsewhere what that means). I collected some alert log output to trace what actually happens and it reads as follows:

  • Recovery of rman duplicate has finished, rfs starts and finds the srl’s missing.
    Incomplete Recovery applied until change 599746
    Completed: alter database recover logfile 'J:\ORADATA\DGP\ARCH\ARC00008_0733948503.001'
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[1]: Assigned to RFS process 3172
    RFS[1]: Identified database type as 'physical standby'
    Mon Nov 01 19:59:50 2010
    RFS LogMiner: Client disabled from further notification
    Mon Nov 01 20:00:53 2010
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[2]: Assigned to RFS process 6048
    RFS[2]: Identified database type as 'physical standby'
    Primary database is in MAXIMUM PERFORMANCE mode
    Primary database is in MAXIMUM PERFORMANCE mode
    Mon Nov 01 20:00:53 2010
    Errors in file e:\oracle\product\10.2.0\admin\dgs\udump\dgs_rfs_6048.trc:
    ORA-00313: open failed for members of log group 4 of thread 0
    ORA-00312: online log 4 thread 0: 'E:\ORADATA\DGS\STBREDO\STBREDO04B.LOG'
    ORA-27041: unable to open file
    OSD-04002: unable to open file
    O/S-Error: (OS 2) The system cannot find the file specified.
    ORA-00312: online log 4 thread 0: 'E:\ORADATA\DGS\STBREDO\STBREDO04A.LOG'
    ORA-27041: unable to open file
    OSD-04002: unable to open file
    O/S-Error: (OS 2) The system cannot find the file specified.
    
  • However oracle seems to notice that the srl’s have already been registered with the controlfile (from the initial primary) but not yet created on standby.
    SRL log 4 needs clearing because log has not been created
    
  • Well, after cycling through all the srl’s and repeating the above entries, rfs finally prints that no srl’s are seen (of a certain size, ha ha).
    RFS[2]: No standby redo logfiles of size 102400 blocks exist
    
  • But, now oracle automatically creates (cleares) the srl’s.
    Clearing online log 7 of thread 0 sequence number 0
    ...
    Clearing online log 4 of thread 0 sequence number 0
    
  • And … some way further down the alert, the first srl has been successfully opened.
    Mon Nov 01 20:00:54 2010
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[3]: Assigned to RFS process 4116
    RFS[3]: Identified database type as 'physical standby'
    RFS[3]: Successfully opened standby log 4: 'E:\ORADATA\DGS\STBREDO\STBREDO04A.LOG'
    
  • By the way, the same procedure will be applied for the orl’s, but only after media recovery has been started.
    ALTER DATABASE recover managed standby DATABASE disconnect
    MRP0 started with pid=21, OS id=596
    Managed Standby Recovery not using Real Time Apply
     parallel recovery started with 15 processes
    Mon Nov 01 20:09:57 2010
    Waiting for all non-current ORLs to be archived...
    ...
    Mon Nov 01 20:10:00 2010
    Errors in file e:\oracle\product\10.2.0\admin\dgs\bdump\dgs_mrp0_596.trc:
    ORA-00313: open failed for members of log group 2 of thread 1
    ORA-00312: online log 2 thread 1: 'E:\ORADATA\DGS\REDO\REDO02B.LOG'
    ORA-27041: unable to open file
    OSD-04002: unable to open file
    O/S-Error: (OS 2) The system cannot find the file specified.
    ORA-00312: online log 2 thread 1: 'E:\ORADATA\DGS\REDO\REDO02.LOG'
    ORA-27041: unable to open file
    OSD-04002: unable to open file
    O/S-Error: (OS 2) The system cannot find the file specified.
    ...
    Clearing online redo logfile 2 E:\ORADATA\DGS\REDO\REDO02.LOG
    Clearing online log 2 of thread 1 sequence number 14
    ...
    Clearing online redo logfile 2 complete
    

Have fun!

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s