Role Transitions for Data Guard Configurations Using Mixed Oracle Binaries [ID 414043.1]

Summary

Beginning with Oracle Database 10g, there are certain configurations where Data Guard Redo Apply (physical standby) can support different Oracle binaries between primary and standby databases as long as all systems in the Data Guard configuration are running the same OS family. For example, you may have a primary database with 32bit Oracle binaries on Red Hat 32bit, and a physical standby database with 64bit Oracle binaries on Red Hat 64bit. Such configurations must follow additional procedures during Data Guard role transitions (switchover and failover) as described in this MetaLink note, below. If these procedures are not followed then errors will occur when trying to open the new primary database. One example error sequence would be:

从Oracle10g开始，支持在不同的位数（32位和64位）之间做物理standby，但是前提必须是同样的系统平台，如都是REDHAT的。例如在REDHAT 32位平台上配置一个32bit的主库，64bit的物理备库在REDHAT 64bit操作系统上。这样的主备库搭建，在进行角色切换（包括switchover and failover），切换后必须额外执行下面的操作步骤来保证角色切换完成，否则会出现如下错误：

ORA-00604: error occurred at recursive SQL level 1
ORA-06553: PLS-801: internal error [56327]

For additional information on how Data Guard supports configurations in which the primary database/system may not be identical to its standby database(s)/system(s), please see MetaLink Note 413484.1

oracle Data Guard 异构支持列表可以参照MetaLink Note 413484.1，也可以参照http://blog.csdn.net/java3344520/article/details/8075876

Restrictions
SQL Apply (logical standby) always requires that the bit-ness of the Oracle Database is identical on all systems in a Data Guard configuration. Continuing with the example provided in the summary above of a Red Hat 32bit/64bit primary/standby, if you are using SQL Apply you must use 32 bit Oracle binaries on both primary and standby.

Oracle Data Guard  逻辑standby（SQL apply）的搭建，主备库要求必须在相同的位数（32位和64位）操作系统平台上，例如主备库都在32bit的操作系统上或者主备库都位于64bit的操作系统平台上。

The bit-ness of the Oracle database must be identical if you are using any Oracle release before Oracle Database 10g for both SQL Apply and Redo Apply. Continuing with the example provided in the summary above of a Red Hat 32bit/64bit primary/standby, if you are using Oracle9i you must use 32 bit Oracle binaries on both primary and standby (either physical or logical standby).

Oracle Data Guard  10g以前的物理和逻辑standby的搭建，主备库都必须在相同的位数（32位和64位）操作系统平台上。

The Data Guard Broker does not support different binaries in the same Data Guard configuration in Oracle Database 10g. All such configurations must be managed from the SQL*Plus command line. Beginning with Data Guard 11g onward, this restriction is lifted and the Data Guard Broker does support Oracle 11g databases of mixed word-size in the same Data Guard configuration.
Data Guard Fast-start Failover will failover in a mixed Oracle binary configuration but it will be unable to open the new primary database until the procedure below is followed.

Data Guard Broker 不支持配置不同位数的standby的搭建，只能通过SQL*PlusS命令行操作。11g之后版本，这个限制不存在，Data Guard Broker支持不同位数配置操作。Data Guard 不同位数主备库的Failover切换必须执行下列步骤，否则无法打开（切换后）新的主库。

Additional Role Transition Procedures when using mixed Oracle binaries:

If you are running a physical standby configuration where the primary and standby have different Oracle binaries you will need to follow the instructions below on the new primary as part of any Data Guard role transition (switchover or failover) after a standby becomes a primary database (supported configurations are defined in MetaLink Note 413484.1). This procedure is necessary when transitioning roles in either direction.

（不同位数主备库角色切换必须执行的步骤）

Note: If you are using Oracle OLAP then you must also follow MetaLink Note 352306.1 . Additionally, as a precaution for a failover, you may want to backup/export the user-created AW’s ahead of time and periodically.

1. Shutdown the new primary database
If using RAC then set database to unclustered: SQL> alter system set cluster_database=false scope=spfile;
SQL> shutdown immediate

2. Startup the new primary in UPGRADE mode
SQL> startup upgrade

3. Invalidate existing PL/SQL modules

Invalidate existing PL/SQL modules in preparation to convert the format required by the new primary. Note that there should be no other DDL on the database while running the script. Not following thisrecommendation may lead to deadlocks.
SQL> spool utlirp.log
SQL> @?/rdbms/admin/utlirp
SQL> spool off

4. Restart the database
If using RAC then set database back to clustered:
SQL> alter system set cluster_database=true scope=spfile;
SQL> shutdown immediate
SQL> startup

5. Recompile all invalid PL/SQL modules

Recompile all invalid PL/SQL modules to be in the format required by the new primary database.
SQL> spool utlrp.log
SQL> @?/rdbms/admin/utlrp
SQL> spool off

6. Verify that all expected packages and classes are valid.
SQL> SELECT count(*) FROM dba_objects WHERE status=’INVALID’;
SQL> SELECT distinct object_name FROM dba_objects WHERE status=’INVALID’;