What differences are allowed between a Primary Database and a Data Guard Physical Standby Database (Redo Apply)?

This note is updated for Redo Apply and Oracle Data Guard 11g Release 2. It applies to all versions of Oracle Database 10g and Oracle Database 11g.

Would you like to explore this Topic further with other Oracle Customers, Oracle Employees and Industry Experts ??

You can discuss this Note, show your Experiences or ask Questions about it directly right at the Bottom of this Note in the Discussion Thread about this Document.

If you want to discover Discussions about other Articles und Subjects or even post new Discussions you can access the My Oracle Support Community Page for High Availability Data Guard

For information on supported configurations using Logical Standby (SQL Apply), see Support Note 1085687.1

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 Oracle software 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 a supported 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

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.
Both primary and standby databases must be set at the same compatibility mode as the minimum release (if specified) in the table below.
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.
Please be sure to read Support Notes when referenced in the table below.
RMAN generally supports instantiation of a physical standby database for the supported platform combinations. Please see Support Note 1079563.1 for details.
Platforms in a supported combination may operate in either the primary or standby role.
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.

PLATFORM_ID	PLATFORM_NAME Release name	PLATFORM_IDs supported within the same Data Guard configuration when using Data Guard Redo Apply (Physical Standby)
2	Solaris[tm] OE (64-bit) Solaris Operating System (SPARC) (64-bit)	2 6 - This is not supported due to issues reported in Bug 12702521
3	HP-UX (64-bit) HP-UX PA-RISC	3 4 - Oracle 10g onward, see Support Note: 395982.1 and Note:414043.1
4	HP-UX IA (64-bit) HP-UX Itanium	4 3 - Oracle 10g onward, see Support Notes Note: 395982.1 and Note:414043.1
5	HP Tru64 UNIX HP Tru64 UNIX	5
6	IBM AIX on POWER Systems (64-bit)	2 - This is not supported due to issues reported in Bug 12702521 6
7	Microsoft Windows (32-bit) Microsoft Windows (x86)	7 8, 12 - Oracle 10g onward, see Support Note: 414043.1 10 - Oracle 11g onward, requires Patch 13104881 11, 13 - Oracle 11g onward, see Support Note: 414043.1, also requires Patch 13104881
8	Microsoft Windows IA (64-bit) Microsoft Windows (64-bit Itanium)	7 - Oracle 10g onward, see Support Note: 414043.1 8 12 - Oracle 10g onward 11, 13 - Oracle 11g onward, requires Patch 13104881
9	IBM zSeries Based Linux z/Linux	9 18 (64-bit zSeries only)
10	Linux (32-bit) Linux x86	7 - Oracle 11g onward, requires Patch 13104881 10 11, 13 - Oracle 10g onward, see Support Note: 414043.1
11	Linux IA (64-bit) Linux Itanium	10 - Oracle 10g onward, see Support Note: 414043.1 11 13 - Oracle 10g onward 7 - Oracle 11g onward, see Support Note: 414043.1, also requires Patch 13104881 8, 12 - Oracle 11g onward, requires Patch 13104881
12	Microsoft Windows 64-bit for AMD Microsoft Windows (x86-64)	7 - Oracle 10g onward, see Support Note Note: 414043.1 8 - Oracle 10g onward 12 11, 13 - Oracle 11g onward, requires Patch 13104881
13	Linux 64-bit for AMD Linux x86-64	7 - Oracle 11g onward, see Support Note: 414043.1, also requires Patch 13104881 10 - Oracle 10g onward, see Support Note Note: 414043.1 11 - Oracle 10g onward 8, 12 - Oracle 11g onward, requires Patch 13104881 13 20 - Oracle 11g onward
15	HP Open VMS HP OpenVMS Alpha HP IA OpenVMS OpenVMS Itanium	15
16	Apple Mac OS Mac OS X Server	16
17	Solaris Operating System (x86) Solaris Operating System (x86)	17 20 - Oracle 10g onward, see Support Note: 414043.1
18	IBM Power Based Linux Linux on Power	9 (64-bit zSeries only) 18
20	Solaris Operating System (AMD64) Solaris Operating System (x86-64)	13 - Oracle 11g onward 17 - Oracle 10g onward, see Support Note: 414043.1 20

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 both the 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

ITPub博客

DATA GUARD 跨平台支持(Redo Apply)