Heterogeneous dataguard

admin

Scope and Application:


The simplest path when deploying Data Guard is to configure a homogeneous and symmetric primary/standby configuration. However, it is often useful to deploy a heterogeneous configuration either to utilize existing servers that happen to run different operating systems or to facilitate migrations from one platform to another with minimal downtime or risk. It is also reasonable for users to wish to reduce their disaster recovery investment by purposely
configuring a standby system with less processing capacity than production, or by utilizing lower cost components than used for their primary system. Use the instructions and information provided in this support note to determine which platform combinations are supported within a single Data Guard configuration and any additional requirements or restrictions that may apply.
If a heterogeneous primary/standby configuration is under consideration, Oracle recommends that users conduct sufficient testing to be sure that required service levels will continue to be achieved following a switchover or failover to
the standby system.


1. Determine the Platform ID for your primary and standby database.


You can find the PLATFORM_ID inside the database in the V$DATABASE view using the query below:
SQL> select platform_id, platform_name from v$database;
PLATFORM_ID PLATFORM_NAME
----------- -----------------------------------
10 Linux IA (32-bit)

Differences between the primary server(s) and the standby server(s) are always supported as long as the Oraclesoftware installed on all servers is of the same Oracle Platform as defined above, is certified to run on each server, and is the same Oracle Database Release and Patch Set. Examples of such differences that are supported include the following:


Hardware manufacturer (e.g. Dell and Sun or Hitachi and EMC)
Hardware configuration (e.g. number of CPUs, amount of RAM, storage configuration, etc)
Processor (e.g. x86-64 AMD64 and x86-64 Intel 64; POWER4 and POWER5)
Operating system distribution (e.g. Red Hat Linux, SUSE Linux or Oracle Enterprise Linux)
Operating system version (e.g. Windows 2000 and Windows XP)

2. If Platform ID's for your primary and standby are different, check the table below to see if you have asupported configuration for Data Guard Redo Apply (Physical Standby) In addition to general support when using the same Oracle platform, Data Guard Redo Apply (physical standby) can support specific mixed Oracle Platform combinations. Oracle Platform IDs, platform names, and which combinations of platform ID(s) that can be combined to form a supported Data Guard configuration using Redo Apply are listed in the table below. Platform combinations not listed in the table below are not supported using Data Guard Redo Apply.


Table Notes


1. Prior to Data Guard 11g, the Data Guard Broker did not support different word-size in the same Data Guard configuration, thus requiring management from the SQL*Plus command line for mixed word-size Data Guard configurations. This restriction is lifted from Data Guard 11g onward.
2. Both primary and standby databases must be set at the same compatibility mode as the minimum release (if specified) in the table below.
3. A standby database cannot be open read-only in any environment that has binary-level PL/SQL-related incompatibilities between primary and standby databases. Support Note:414043.1 is referenced in the table below for any platform combinations where this is the case (the note provides instructions for eliminating incompatibilities post role transition). It is possible to access a standby database in such environments in Oracle Database 11g by temporarily converting it to a Snapshot Standby database, or in Oracle Database 10g by opening the standby read/write as described in the Data Guard 10g Concepts and Administration guide: Using a Physical Standby Database for Read/Write Testing and Reporting. Both procedures require following the steps in Note:414043.1 before making the database available to users.
4. Please be sure to read Support Notes when referenced in the table below.
5. RMAN generally supports instantiation of a physical standby database for the supported platform combinations. Please see Support Note 1079563.1 for details.
6. Platforms in a supported combination may operate in either the primary or standby role.
7. Enterprise Manager can not be used for standby database creation or other administrative functions in any configuration where PLATFORM_IDs are not identical. Oracle recommends using the Data Guard Broker command line interface (DGMGRL) to administer mixed platform combinations from Oracle Database 11g onward and SQL*Plus command line for configurations that pre-date Oracle Database 11g.





3. Additional information:
Transient Logical Database Rolling Upgrades: Beginning with Oracle Database 11.1.0.7, a physical standby database can be used to execute a rolling database upgrade to a new Oracle Patch Set or database release by using the transient logical rolling database upgrade process. See the Maximum Availability Architecture Best Practice paper, " Rolling Database Upgrades for Physical Standby Databases using Transient Logical Standby 11g". The database rolling upgrade process enables a standby database to apply redo sent by a primary database that is operating at a previous
Oracle release or patchset. The transient logical rolling upgrade process requires that the primary and standby platform combination be a supported configuration for both Redo Apply (see table above) and SQL Apply (see Support Note 1085687.1) as of the pre-upgrade Oracle release deployed in the Data Guard configuration. Data Guard Configurations that Include a Combination of Physical and Logical Standby Databases: A Data Guard configuration includes a primary database and up to 30 standby databases. These standby databases may be a mix of physical and logical standby databases. All physical standby databases within a single Data Guard configuration must adhere to the requirements described in this note. Likewise, if the configuration includes logical standby databases, they must conform to the requirements of Support Note 1085687.1. Real Application Cluster & Automatic Storage Management: It is not necessary that the primary and the standby both be Oracle RAC databases, or both use ASM. For example, the primary database may be running Oracle RAC with or without ASM, and the standby database(s) may be single-instance, with or without ASM. Also, in case boththe primary and standby are Oracle RAC databases, the number of Oracle RAC nodes between the primary and standby databases may vary. Furthermore, the versions of ASM and CRS do not need to be the same between the primary and standby systems. Exadata Database Machine: It is transparent to Data Guard whether primary and/or standby databases reside on an Exadata Database Machine or on other hardware, as long as the platform ID's of primary and standby systems within the same Data Guard configuration conform to the support requirements defined in the above table. If Exadata Hybrid Columnar Compression (EHCC) is used, it is strongly recommended that both primary and standby databases reside on Exadata. See the Maximum Availability Architecture Best Practice paper, "Disaster Recovery for Exadata Database Machine".