RAC to Single Instance Data Guard Physical Standby

This article shows how to setup an Oracle binary on both a Solaris 10 and on an OEL (Oracle Linux Server release 6.4) system.

Shutdown Standby Database

Step 1. Disable standby archive writing:

In the primary/production database


Step 2. Deactivate auto recovery in the Standby Database


PS: When using a Real Application Cluster (RAC) the above command should be run on just ONE of the standby RAC nodes.


This should be applied on all standby nodes in an RAC environment.


Startup Standby Database

If necessary archivelogs should be copied to the standby.


Step 3. Open the standby database and start the automatic recovery process.


PS: In a Real Appication Cluster (RAC) environment this should be applied on all of the standby nodes.


Step 4. Enable Standy Archive writing

On the primary/production database


This only needs to be run on a single node in an RAC environment (sid=’*’).

Taking precautions before encountering any failures. Refer to Doc ID 1302539.1 for further details.



Errors & Solutions

1. File/Disk erro
ORA-15025: could not open disk “/dev/oracleasm/disks/DATA001”
ORA-27041: unable to open file
Linux-x86_64 Error: 13: Permission denied
Additional information: 9
SUCCESS: diskgroup DATA was mounted
Errors in file /u01/app/oracle/diag/rdbms/stdhira/stdhira/trace/stdhira_ora_26491.trc (incident=7361):

If there any errors, run the following command as a root user:

2. Deletion of Applied Archivelogs

If the archivelog files are being managed in the Fast Recovery Area then automatic deletion of backed up and applied archivelog files can be setup by issuing the following RMAN configure command on the primary database:

Creating a physical standby from ASM primary [ID 787793.1]

3. Data Guard Broker Status Summary:
Type Name Severity Status
Configuration dg_broker Warning ORA-16608
Primary Database hira Success ORA-00000
Physical Standby Database stdhira Warning ORA-16792

If there are any errors:
Using: show database ‘stdhira’ ‘InconsistentProperties’, find any different values (even if values are occasionally the same) and fix these errors with scope=spfile/both.

4. SQL Execution error=604, sql=[alter system set log_archive_dest_1=”]. See error stack below.
ORA-00604: error occurred at recursive SQL level 1
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-16028: new LOG_ARCHIVE_DEST_1 causes less destinations than LOG_ARCHIVE_MIN_SUCCEED_DEST requires
ORA-00604 ORA-02097 ORA-16028

In the Primary


single instance

The following steps have been explained in the metalink:
a. Use DGMGRL to gather information about the Broker configuration.
— From current Primary

# This should be done for the Primary and each Standby

b. Remove the broker configuration.

# This ensures standby operations continue while the Broker configuration is being re-created.

c. Change the LOG_ARCHIVE_DEST_n destinations defined with LOCATION to remove DB_UNIQUE_NAME.

# This must be done on all databases in the Data Guard environment that Broker will manage.

d. Re-create the Broker configuration.
— From current Primary:

# Use the info from Step #1 to re-create the Broker configuration
# and modify the properties on each database before enabling.

e. ORA-16826: apply service state is inconsistent with the DelayMins property
This can be fixed by disabling and and then enabling the dgmgrl configuration as follows:

5. Places to look if there are any connection problems:

6. Exception in thread “main” java.lang.UnsatisfiedLinkError: /tmp/OraInstall2013-12-30_01-26-43PM/jdk/jre/lib/sparcv9/motif21/libmawt.so: ld.so.1: java: fatal: libXm.so.4: open failed: No such file or directory…..
Solution to this problem

Please letus know if there are any mistakes or omissions in the steps described in this article.

Useful resources: