DataGuard与异构平台

DataGuard对主备库异构平台的支持一直是让很多人纠结的问题,我们在学习Oracle数据卫士时必要优先阅读的官方文档是<Oracle Data Guard Concepts and Administration 10g Release 2>,在这个文档中给出了极为苛刻的硬件环境限制条件:

All members of a Data Guard configuration must run an Oracle image that is built for the same platform.

For example, this means a Data Guard configuration with a primary database on a 32-bit Linux on Intel system
can have a standby database that is configured on a 32-bit Linux on Intel system. However, a primary database
on a 64-bit HP-UX system can also be configured with a standby database on a 32-bit HP-UX system,
as long as both servers are running 32-bit images.

以上主要提出了2点要求:即平台(platform)和字长(word size)都必须一致,注意这里不管是physical standby还是logical standby都要求遵守。

官方文档这样撰写的原因是Oracle并不推荐用户在异构平台上搭建DataGuard,如果有用户大量地部署异构平台上的DataGuard可能给后续的服务和支持带来麻烦;所以除非是找不到其他可用的硬件了,否则不推荐采用异构平台搭建的DataGuard环境来提供高可用性。

实际情况是在10g中已经有少数几个异构平台组合可以兼容physical standby或logical standby,而在11g中更增加了对physical standby支持的几种异构平台组合(As of Oracle Database 11g Data Guard provides increased flexibility for Data Guard configurations in which the primary and standby systems may have different CPU architectures, operating systems (for example, Windows & Linux), operating system binaries (32-bit/64-bit), or Oracle database binaries (32-bit/64-bit). For specific information about mixed-platform support, see the My Oracle Support note 413484.1)。

具体10g/11g DataGuard可以利用的异构平台组合,见下列图表:

10g
Physical Standby Logical Standby
Heterogeneous
Support
No Win<->Linux Only
Different
Word-size
(32 / 64 bit)
Win32<->Win64
Linux32<->Linux64
Win32->Win64  

Linux32->Linux64 (1 way only)

Heterogeneous AND Word-size No No

 

11g
Physical Standby Logical Standby
Heterogeneous
Support
Win<–>Linux
Solaris <–>AIX
Solaris<–>Linux
Win<->Linux Only
Different
Word-size
(32 / 64 bit)
Win32<->Win64
Linux32<->Linux64
Win32->Win64 Linux32->Linux64 (1 way only)
Heterogeneous AND Word-size Win32<->Linux64 Win32->Linux64
(1 way only)

 

而在metalink文档<Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration [ID 413484.1]><Data Guard Support for Heterogeneous Primary and Logical Standbys in Same Data Guard Configuration [ID 1085687.1]>中列出了更为详尽的平台间的兼容信息,在这里一并引用:

Physical Standbys

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.
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 – Oracle 11.2.0.2 onward, primary database must be non-RAC and non-TDE
3 HP-UX (64-bit)
HP-UX PA-RISC
3
4 – Oracle 10g onward, see Support Notes 395982.1 and 414043.1
4 HP-UX IA (64-bit)
HP-UX Itanium
4
3 – Oracle 10g onward, see Support Notes 395982.1 and 414043.1
5 HP Tru64 UNIX
HP Tru64 UNIX
5
6 IBM AIX on POWER Systems (64-bit) 2 – Oracle 11.2.0.2 onward, primary database must be non-RAC and non-TDE
6
7 Microsoft Windows (32-bit)
Microsoft Windows (x86)
7
8, 12  – Oracle 10g onward, see Support Note 414043.1
10 – Oracle 11g onward
11, 13 – Oracle 11g onward, see Support Note 414043.1
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
9 IBM zSeries Based Linux
z/Linux
9
18 (64-bit zSeries only)
10 Linux (32-bit)
Linux x86
7 – Oracle 11g onward
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
8, 12 – Oracle 11g onward
12 Microsoft Windows 64-bit for AMD
Microsoft Windows (x86-64)
7 – Oracle 10g onward, see Support Note 414043.1
8 – Oracle 10g onward
12
11, 13 – Oracle 11g onward
13 Linux 64-bit for AMD
Linux x86-64
7 – Oracle 11g onward, see Support Note 414043.1
10 – Oracle 10g onward, see Support Note 414043.1
11 – Oracle 10g onward
8, 12 – Oracle 11g onward
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

Logical Standby

In addition to general support when using the same Oracle platform, Data Guard SQL Apply (logical standby) can support specific mixed Oracle Platform combinations as of Oracle Database 11g.  Oracle Platform IDs, platform names, and which combinations of platform ID(s) that can be combined to form a supported Data Guard configuration using SQL Apply are listed in the table below.  Platform combinations not listed in the table below are not supported using Data Guard SQL Apply.

Table Notes

  1. All mixed platform combinations for SQL Apply in the table below are supported from Oracle Database 11g onward.
  2. Prior to Data Guard Broker 11g, the Data Guard Broker did not support different word-size in the same Data Guard configuration, thus requiring all management from the SQL*Plus command line.  This restriction is lifted from Data Guard 11g onward.
  3. Both primary and standby databases must be set at the same compatibility mode as the minimum release (if specified) in the table below.
  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 unless otherwise specified.
  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.
PLATFORM_ID PLATFORM_NAME
Release name
PLATFORM_IDs supported within the same Data Guard configuration when using Data Guard SQL Apply (Logical Standby)
2 Solaris[tm] OE (64-bit)
Solaris Operating System (SPARC) (64-bit)
2
3 HP-UX (64-bit)
HP-UX PA-RISC
3, 4
4 HP-UX IA (64-bit)
HP-UX Itanium
3, 4
5 HP Tru64 UNIX
HP Tru64 UNIX
5
6 AIX-Based Systems (64-bit)
AIX5L
6
7 Microsoft Windows (32-bit)
Microsoft Windows (x86)
7, 10
8, 12 – Replication can only occur from a 32-bit primary to a 64-bit standby, once a role transition has promoted the 64-bit system to the primary role, the original 32-bit primary is not supported as a standby database.
8 Microsoft Windows IA (64-bit)
Microsoft Windows (64-bit Itanium)
7 – Replication can only occur from a 32-bit primary to a 64-bit standby, once a role transition has promoted the 64-bit system to the primary role, the original 32-bit primary is not supported as a standby database.
8, 11, 12, 13
9 IBM zSeries Based Linux
z/Linux
9
10 Linux (32-bit)
Linux x86
7, 10
11, 13 – Replication can only occur from a 32-bit primary to a 64-bit standby, once a role transition has promoted the 64-bit system to the primary role, the original 32-bit primary is not supported as a standby database.
11 Linux IA (64-bit)
Linux Itanium
10 – Replication can only occur from a 32-bit primary to a 64-bit standby, once a role transition has promoted the 64-bit system to the primary role, the original 32-bit primary is not supported as a standby database.
8, 11, 13
12 Microsoft Windows 64-bit for AMD
Microsoft Windows (x86-64)
7 – from Oracle 11g onward.  Replication can only occur from a 32-bit primary to a 64-bit standby, once a role transition has promoted the 64-bit system to the primary role, the original 32-bit primary is not supported as a standby database.
8, 12
13 Linux 64-bit for AMD
Linux x86-64
10 – Replication can only occur from a 32-bit primary to a 64-bit standby, once a role transition has promoted the 64-bit system to the primary role, the original 32-bit primary is not supported as a standby database.
8, 11, 13
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
18 IBM Power Based Linux
Linux on Power
18
20 Solaris Operating System (AMD64)
Solaris Operating System (x86-64)
20

Reference:

<Cross Platform Database Migrations>-Owen Ireland

<Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration [ID 413484.1]>

<Data Guard Support for Heterogeneous Primary and Logical Standbys in Same Data Guard Configuration [ID 1085687.1]>



Rolling a Standby Forward using an RMAN Incremental Backup

Rolling a Standby Forward using an RMAN Incremental Backup in 9i

Purpose

This document describes a method of rolling forward a standby database using incremental backups (instead of the typical media recovery process MRP).  The process uses an RMAN incremental backup taken on the primary database which is then applied to the standby database.

Introduction

In normal cases when a gap occurs on a standby database normal gap detection and resolution processes can accurately and efficiently bring the standby up to date.  However, in cases where a physical standby has fallen substantially behind from the primary database it can be beneficial to bring the standby current by using the method described within this article.  The procedure described here can be more efficient for the large gap scenario as incremental backups on the primary and roll forward on the standby can be much faster than normal gap resolution.  In most cases only a small subset of the primary database is altered so incremental backups (and subsequent roll forward) will only contain one complete block for each change versus a large number of change vectors for the same block if read through archivelogs.

This process can be used under either of the following conditions:

  • When the standby database has fallen significantly behind the primary database and there have not been nologging operations performed on the primary database.
  • When nologging operations have been performed on the primary database and the standby database has not yet applied past the point that the nologging operations occurred.

Steps

  1. Stop managed recovery if it is running and mount the standby database.

        SQL> recover managed standby database cancel;
SQL> shutdown immediate;
SQL> startup nomount;
SQL> alter database mount standby database;

  1. Ensure that the primary database is already registered in the recovery catalog.  Note that a recovery catalog must be used since there is no mechanism to manually catalog a backup piece in 9i.

        $ rman target sys/oracle@prod catalog rman/rman@rcvcat
RMAN> register database;

  1. Using RMAN connect to the standby as the target database and catalog the remote standby datafiles as level 0 datafile copies.

        $ rman target sys/oracle@stby catalog rman/rman@rcvcat
RMAN> catalog datafilecopy
'/u03/stby/system01.dbf',
'/u03/stby/undotbs01.dbf',
'/u03/stby/indx01.dbf',
'/u03/stby/tools01.dbf',
'/u03/stby/undotbs02.dbf',
'/u03/stby/users01.dbf'
level 0 tag 'STBY';

  1. Using RMAN connect to the primary database as the target and create the incremental level 1 backup

        $ rman target sys/oracle@prod catalog rman/rman@rcvcat
RMAN> backup incremental level 1 tag 'STBY' database format '/private/%u';

  1. Transfer the incremental backup piece created in the above step to the same path on the standby host.  Connect to the standby as the target database and roll forward the standby datafiles using the incremental backup.

        $ rcp /private/<incr_backup> stby:/private/
$ rman target sys/oracle@stby catalog rman/rman@rcvcat

Note: If datafile names on standby are different, use SET NEWNAME to ensure all standby datafile names are retained:

        RMAN> run {
set newname for datafile 1 to '/u03/stby/system01.dbf';
set newname for datafile 2 to '/u03/stby/undotbs01.dbf';
set newname for datafile 3 to '/u03/stby/indx01.dbf';
set newname for datafile 4 to '/u03/stby/tools01.dbf';
set newname for datafile 5 to '/u03/stby/undotbs02.dbf';
set newname for datafile 6 to '/u03/stby/users01.dbf';
switch datafile all;
recover database noredo;
}

Note:  If datafile names are the same, just run the recover command:

        RMAN> recover database noredo;

  1. Using RMAN delete the incremental backup and uncatalog the datafile copies.

        $ rman target sys/oracle@prod catalog rman/rman@rcvcat
RMAN> delete backup tag 'STBY';
RMAN> change copy tag 'STBY' uncatalog;

  1. If the standby database is on the same host as the primary database then you must uncatalog the online redo logs that are registered in v$archived_log on the standby.  The RECOVER DATABASE command issued in the above step will put entries in v$archived_log if the defined redo logs in the controlfile are accessible.  A local standby will have access to the primary redo logs.  If the standby database is not on the same host as the primary database then this step can be skipped.

        $ rman target sys/oracle@stby catalog rman/rman@rcvcat
RMAN> change archivelog like '...' uncatalog;

  1. On the primary database recreate the standby controlfile.  Transfer the new standby controlfile over to the standby host and mount the standby on the new controlfile.

        SQL> alter database create standby controlfile as '/tmp/stby.ctl';
$ rcp /tmp/stby.ctl stby:/u03/stby

  1. Restart the standby database and start MRP

        SQL> shutdown immediate;
SQL> startup nomount;
SQL> alter database mount standby database;
SQL> alter database recover managed standby database disconnect;

Rolling a Standby Forward using an RMAN Incremental Backup in 10g

Purpose

This document describes a method of rolling forward a standby database using incremental backups (instead of the typical media recovery process MRP).  The process leverages the RMAN incremental roll forward feature available starting with 10g Release 2.

Introduction

In normal cases when a gap occurs on a standby database normal gap detection and resolution processes can accurately and efficiently bring the standby up to date.  However, in cases where a physical standby has fallen substantially behind from the primary database it can be beneficial to bring the standby current by using the method described within this article.  The procedure described here can be more efficient for the large gap scenario as incremental backups on the primary and roll forward on the standby can be much faster than normal gap resolution.  In most cases only a small subset of the primary database is altered so incremental backups (and subsequent roll forward) will only contain one complete block for each change versus a large number of change vectors for the same block if read through archivelogs.

This process can be used under either of the following conditions:

  • When the standby database has fallen significantly behind the primary database and there have not been nologging operations performed on the primary database.
  • When nologging operations have been performed on the primary database and the standby database has not yet applied past the point that the nologging operations occurred.

Steps

1. Stop managed recovery on the physical standby database

        SQL> alter database recover managed standby database cancel;

2. Connect to the recovery catalog and the standby database as the target, and manually catalog the standby datafiles as datafile copies

        RMAN> connect catalog rman/rman@host1/rcvcat
RMAN> connect target sys/manager@host2/stby
RMAN> catalog datafilecopy
'/oracle/oradata/STBY/datafile/o1_mf_system_0chdb5sb_.dbf',
'/oracle/oradata/STBY/datafile/o1_mf_sys_undo_0chdb61n_.dbf',
'/oracle/oradata/STBY/datafile/o1_mf_sysaux_0chdb5wm_.dbf'
level 0 tag 'STBY';

3. Connect to the recovery catalog and the primary database as the target, and create an incremental level 1 backup using the datafile copies as the parent level 0.

        RMAN> connect catalog rman/rman@host1/rcvcat
RMAN> connect target sys/manager@host1/prod
RMAN> backup incremental level 1 tag 'STBY' for recover of copy with tag 'STBY' database format '/private/backup/%u';

4. Copy the newly created backup piece to the same location on the standby system

        $ rcp /private/backup/<incr_backup> stby:/private/backup/

5. Connect to the recovery catalog and the standby database as the target, and roll the datafile copies forward

        RMAN> connect catalog rman/rman@host1/rcvcat
RMAN> connect target sys/manager@host2/stby
RMAN> recover copy of database with tag 'STBY';

6. Delete incremental backup and uncatalog the standby datafiles as datafile copies

        RMAN> delete backup tag 'STBY';
RMAN> change copy like '/oracle/oradata/STBY/datafile/%' uncatalog;

Note: The RECOVER COPY OF DATABASE command causes the ‘STBY’ tag associated with the datafile copies to change to ” (NULL) or back to a previous tag, if one had existed.  Use CHANGE COPY LIKE to uncatalog the standby datafiles as copies.

7. Recreate the Standby Controlfile following
Steps to recreate a Physical Standby Controlfile (Doc ID 459411.1)

8. Restart managed recovery

        SQL> alter database recover managed standby database disconnect;

 

沪ICP备14014813号

沪公网安备 31010802001379号