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!