Hi,

RMAN backup for creating a standby database is failing when I tried to executing BACKUP DEVICE TYPE DISK FORMAT '/u01/backup/%U' DATABASE PLUS ARCHIVELOG;

The error shows that it could not find the older archive logs that donot exists. So I carried RMAN backup with backup database excluding archivelog.

I copied all the archive logs from primary onto the standby arch location, and the backup piece to the /u01/backup on the standby.

I have copied the initSID.ora from the primary and edited parameters for standby.

On the standby I created orapwdSID file, startup nomount the standby database, then connected the primary database using RMAN as below.

rman catalog rman/catrman@rman target sys/oracle@prod auxiliary /

and executed the DUPLICATE TARGET DATABASE FOR standby;

The duplicate database failed with below error.

ORA-19504: failed to create file "/u01/oradata/prod/
data/control03.ctl"
ORA-27040: file create error, unable to create file
Linux Error: 2: No such file or directory

Please let me know if I am doing errors in the steps.. I have also checked for the permissions for oracle , all privileges are there. I have verified that other two control files that are mulitplexed are being created on the local drive. the duplicate is failing as RMAN is trying to create control03 on the storage.

Hi Nick,

>> The error shows that it could not find the older archive logs that donot exists.

OK, that's expected behavior, right?


*******************************************************************************
>> So I carried RMAN backup with backup database excluding archivelog.

Sorry? Carried them where?

*******************************************************************************
>> I copied all the archive logs from primary onto the standby arch location, and the backup piece to the /u01/backup on the standby.


********************************************************************************

>> failed to create file "/u01/oradata/prod/data/control03.ctl"

This is your core error. The INODE for data should be owned by ORACLE with permissions of 77x.

To test it, try manually creating the file . . . .

Hi Burleson,

Thank You,I have duplicated for standby after assigning file permissions.

Already we are running 3 standbys and this is the fourth standby.The logs are not shipping, Should I need to create the redolog groups for new standby. If so how many redolog groups needs to be created.

Hi Nick,

>> Already we are running 3 standbys and this is the fourth standby.The logs are not shipping,

OK, you need to troubleshoot the redo transport apply process.

************************************************************************
>> Should I need to create the redolog groups for new standby.

No, you need to check your RFS process. . .

Also, Oracle notes these steps to set-up redo log shipping:

http://www.oracle.com/technology/deploy/av...edoShipping.htm

Step 1

Begin by configuring Data Guard in MAXIMUM PERFORMANCE Mode (the default protection mode) using the ARCH process:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=STANDBYTNS ARCH';

This mode uses the equivalent log shipping mechanism used by Oracle8i. Run in this mode through a complete processing cycle that includes time periods with peak redo generation rates. Follow the guidelines in the Data Guard documentation and the Network Best Practices white paper to be insure optimal tuning. Use Statspack to obtain a performance baseline from which the impact of the following configuration changes can be compared.

Step 2

Assuming success with step 1, upgrade redo transport services from ARCH to LGWR ASYNC using the following command.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=STANDBYTNS LGWR ASYNC';

At the next log switch, LGWR will begin shipping redo asynchronously to the standby server. From this point forward, as long as the LGWR ASYNC buffer (initially set at its default value of 1MB) does not become full and as long as the primary can sustain a network connection with the standby, redo is always shipped as quickly as the network will allow.

Step 3

Lets assume success strikes a second time. You find that primary performance is unaffected using LGWR ASYNC. You find that LGWR ASYNC proves capable of utilizing available bandwidth and keeping pace with the primary redo generation rate. Instances where the ASYNC buffer becomes full and shipping reverts to ARCH are limited to bursts of peak activity that occur after hours during batch processing. Generally, during work hours, it is possible to sustain LGWR ASYNC and benefit from enhanced data protection. Things have gone so well, it is desirable to test LGWR SYNC and see if zero data loss protection is feasible given your network environment. Use the following command to dynamically alter redo transport to use LGWR SYNC:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=STANDBYTNS LGWR SYNC';

Repeat the monitoring described in #2 above.

Step 4

Lets assume yet another successful outcome. Your evaluation of network performance is complete, and you decide to make LGWR SYNC the default redo shipping transport by upgrading the Data Guard protection mode from MAXIMUM PERFORMANCE to MAXIMUM AVAILABILITY. Be sure to review the Data Guard documentation for a full understanding of MAXIMUM AVAILABILITY protection mode (for example, archive destination attributes for NET_TIMEOUT and REOPEN). Upgrade to MAXIMUM AVAILABILITY by using the command, below. Unlike changes to redo transport in steps 1-3, the change in the protection mode does require a bounce of the primary database, but it need not be done until the next maintenance period.

SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY;

Step 5

OK - the world is not perfect. You have proceeded through the above steps and somewhere along the way, you find that the network can not keep pace, regardless of how well you tune it. For example, you made it through step 3, and determined that LGWR ASYNC with a 10MB buffer works well, but there is an unacceptable impact to primary database performance of using LGWR SYNC. Simply revert to LGWR ASYNC by repeating the command from step 2.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=STANDBYTNS LGWR ASYNC=20480';

Likewise, if at any time you desire to revert to ARCH, repeat the command from step 1:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=STANDBYTNS ARCH';

Hi Burleson,

The informations are very much useful. I have your book Oracle Data Guard -- RAMPANT and followed the steps.

Now everything seems to working fine, Log is shipped and applied on the standby , But the alert log in primary has

ORA-16401: archivelog rejected by RFS

Should I add redolog files for this standby ? the alert log in standby has the following errors.

Mon Jun 23 12:34:06 2008
Errors in file /opt/oracle/admin/prod/udump/prod_rfs_18121.trc:
ORA-00313: open failed for members of log group 120 of thread 1
ORA-00312: online log 120 thread 1: '/u01/oradata/prod/sys/redoprod60_stby.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 120: 313
Mon Jun 23 12:34:06 2008
Errors in file /opt/oracle/admin/prod/udump/prod_rfs_18121.trc:
ORA-00313: open failed for members of log group 121 of thread 1
ORA-00312: online log 121 thread 1: '/u01/oradata/prod/sys/redoprod61_stby.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3

How many redolog files should be added. the current logfiles for primary is 31 and 92 exists for standbys. Should I create another 30 redolog files for the 4th standby.

>> Should I add redolog files for this standby

No, that's just a "noise error:

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.

Thank You Burleson for your wonderful support.

I am getting the below error consistently for every log thats being shipped and applied.

Tue Jun 24 08:17:05 2008
RFS[1]: No standby redo logfiles created

Please let me know if I need to add logfiles for standby database.I am sure that we have to create (max of logfiles +1) * number of threads for new standby databases.

We are about to remove one of the standby from the existing configuration, in this case how would be the redologs behaviour. ie Whether it will be used by the new standby that we have added or we have to drop the redolog files and recreate.

I suspect during the switchover or failover situations this will create problems.I appreciate to share your expertise knowledge.