Heterogeneous dataguard aix2solaris

admin

The focus of this document is how to configure Data Guard between Oracle Solaris on SPARC systems and IBM AIX on POWER systems. In order to document the necessary steps and requirements please observe the following: Oracle Solaris on SPARC systems will be referred herein as 'SPARC' IBM AIX on POWER systems will be referred herein as 'AIX' The 'directionality' of the setup is not important as long as one side will be AIX and the other SPARC. The steps are applicable to all Oracle Database releases starting from 11.2.0.1 until otherwise noted. The scenario used will be one where primary is on AIX while the physical standby will be on SPARC.

Step 1. Create a SPARC standby from the AIX primary using the steps outlined in section Creating a Physical Standby Database in the Data Guard Concepts and Administration guide.

(a) Do not use RMAN DUPLICATE process. Instead, use a supported manual backup/restore method to populate the primary database files to the standby site.
(b) When configuring LOG_ARCHIVE_DEST_n on primary for redo shipping to standby, set the associated LOG_ARCHIVE_DEST_STATE_n to DEFER first.
(c) Do not open the standby.
(d) Stop in the steps before section 3.2.6 'Start the Physical Standby Database' and go to step 2 in this note.

The following note can be use for guidance on using RMAN for the manual backup/restore process: Note 469493.1 Step By Step Guide To Create Physical Standby Database Using RMAN Backup and Restore -- Do not perform Step #5 and instead return here to continue with Step #2 below. -- Do NOT set event 10463 during RMAN backup/restore.

Step 2. Mount the SPARC standby using the standby control file created on AIX primary in Step 1. To avoid seeing assert ORA-600[kcc_upgrade_1] we will need to set event 10463 when first mounting the control file.

If using an spfile: SQL> alter system set event='10463 trace name context forever, level 3' scope=spfile sid='*'; SQL> startup mount force; For init.ora add following line then startup mount standby: event='10463 trace name context forever, level 3'

Step 3. Remove event 10463 setting once mounting the standby has been successful. Shut it down, remove event 10463 setting from the standby's init.ora file, and re-mount the standby database.

If using an spfile: SQL> alter system reset event scope=spfile sid='*'; SQL> startup mount force; For init.ora remove line for 'event' then startup mount standby:

Step 4. Configure normal Data Guard redo shipping & apply from AIX -> SPARC Continue with the documentation starting at section 3.2.6 Start the Physical Standby Database in the Data Guard Concepts and Administration guide. The LOG_ARCHIVE_DEST_STATE_n on primary can then also be set to ENABLE.

RESTRICTIONS: Before the very first switchover and while SPARC standby is still in physical standby role using the standby control file that was created from AIX primary: Do NOT use RMAN to restore backups taken on AIX to SPARC standby. Do NOT use RMAN to backup SPARC standby - if you want to backup SPARC standby, please use OS level backup procedures. Do NOT use/enable Flashback Database at SPARC standby outside the scope of the Snapshot standby feature.

Step 5. (OPTIONAL) Convert the physical standby to a snapshot standby Before the very first switchover [to convert SPARC standby into a Primary], customers may wish to use the Snapshot Standby feature as described in section 9.7 Managing a Snapshot Standby Database of the Data Guard Concepts and Administration guide in order to test the readiness of their SPARC server's ability to handle the production workloads. Once testing is completed, the snapshot standby is then converted back to a physical standby and switchover planned.

The same restrictions listed above must still be observed.

Step 6. Perform switchover and open the new SPARC production Use section 8.2.1 Performing a Switchover to a Physical Standby Database of the Data Guard Concepts and Administration guide to convert the SPARC standby into a Production (new primary) database and the AIX database into the new standby.

Do not allow users or applications to connect to the new primary yet once the switchover completes.

Step 7. Recreate a new controlfile for the new production database and open production with new controlfile:

To recreate a new primary control file, use the following procedure: a) On the open production, connect as SYSDBA, and issue "alter database backup controlfile to trace noresetlogs;" b) Check the <DIAGNOSTIC_DEST> for a trace file that contains CREATE CONTROLFILE command: % cd $ORACLE_BASE/diag/rdbms/<db_unique_name>/<instance_name>/trace % grep 'CREATE CONTROLFILE' *trc c) Shutdown the production database SQL> shutdown; d) Run the commands in the trace file starting with 'startup NOMOUNT', 'CREATE CONTROLFILE REUSE .. NORESETLOGS ..', 'RECOVER DATABASE', etc. Adjust syntax is needed.

Step 8. Production on SPARC is now ready At the end of execution of all the commands in Step 7, the production database is now available for users & applications to access.

Note: It is possible that when opening the new Primary some ORA-07445 errors or other errors may occur indicating that some PL/SQL packages are invalid. If so refer to Support Note: 414043.1 to recompile them.

IMPORTANT: Oracle recommends that a full backup be taken immediately at this point of the new production primary, including the newly created controlfile. Full usage of RMAN backup/restore procedures plus Flashback Database is now allowed.

Step 9. Configure the new primary to ship redo to the new standby on the AIX server At the end of execution of all steps, the new primary can be setup to ship redo to the new physical standby as well as start redo apply.

Note: Future switchover & failover based role transitions are supported with this Data Guard setup as described in section 8 Role Transitions of the Data Guard Concepts and Administration guide.

IMPORTANT: If the controlfile of the standby ever needs to be re-freshed using a new copy from the primary the following MUST be observed: Before performing a future switchover IF primary was AIX, perform Steps #2 and #3 again. After a subsequent switchover, the *new* primary must have it's controlfile re-created as outlined in Step 7 and the restrictions covered under Step 4 will be in place until done.