Archive for 12/01/2010 - 01/01/2011
Dataguard Notes
I wanted to share my notes on "Oracle Data GuardConcepts and Administration 11g Release 2" document.
11gR1 New Features
· Compression of redo traffic over the network in a Data Guard configuration : This feature improves redo transport performance when resolving redo gaps by compressing redo before it is transmitted over the network.
· You can now find the DB_UNIQUE_NAME of the primary database from the standby database by querying the new PRIMARY_DB_UNIQUE_NAME column in the V$DATABASE view. Also, Oracle Data Guard release 11g ensures each database's DB_UNIQUE_NAME is different. After upgrading to 11g, any databases with the same DB_UNIQUE_NAME will not be able to communicate with each other.
· Heterogeneous Data Guard Configuration: This feature allows a mix of Linux and Windows primary and standby databases in the same Data Guard configuration.
Specific to Redo Apply (Physical Standby Database);
· Real-time query capability of physical standby
· Snapshot standby
· Lost-write detection using a physical standby : A "lost write" is a serious form of data corruption that can adversely impact a database. It occurs when an I/O subsystem acknowledges the completion of a block write in the database, while in fact the write did not occur in the persistent storage. This feature allows a physical standby database to detect lost writes to a primary or physical standby database.
· A number of enhancements in RMAN help to simplify backup and recovery operations across all primary and physical standby databases, when using a catalog. Also, you can use the RMAN DUPLICATE command to create a physical standby database over the network without a need for pre-existing database backups.
11gR2 New Features
· The new ALTER SYSTEM FLUSH REDO SQL statement can be used at failover time to flush unsent redo from a mounted primary database to a standby database, thereby allowing a zero data loss failover to be peformed even if the primary database is not running in a zero data loss data protection mode.
· The FAL_CLIENT database initialization parameter is no longer required.
Specific to Redo Apply (Physical Standby Database);
· A corrupted data block in a primary database can be automatically replaced with an uncorrupted copy of that block from a physical standby database that is operating in real-time query mode. A corrupted block in a physical standby database can also be automatically replaced with an uncorrupted copy of the block from the primary database.
11gR1 New Features
· Compression of redo traffic over the network in a Data Guard configuration : This feature improves redo transport performance when resolving redo gaps by compressing redo before it is transmitted over the network.
· You can now find the DB_UNIQUE_NAME of the primary database from the standby database by querying the new PRIMARY_DB_UNIQUE_NAME column in the V$DATABASE view. Also, Oracle Data Guard release 11g ensures each database's DB_UNIQUE_NAME is different. After upgrading to 11g, any databases with the same DB_UNIQUE_NAME will not be able to communicate with each other.
· Heterogeneous Data Guard Configuration: This feature allows a mix of Linux and Windows primary and standby databases in the same Data Guard configuration.
Specific to Redo Apply (Physical Standby Database);
· Real-time query capability of physical standby
· Snapshot standby
· Lost-write detection using a physical standby : A "lost write" is a serious form of data corruption that can adversely impact a database. It occurs when an I/O subsystem acknowledges the completion of a block write in the database, while in fact the write did not occur in the persistent storage. This feature allows a physical standby database to detect lost writes to a primary or physical standby database.
· A number of enhancements in RMAN help to simplify backup and recovery operations across all primary and physical standby databases, when using a catalog. Also, you can use the RMAN DUPLICATE command to create a physical standby database over the network without a need for pre-existing database backups.
11gR2 New Features
· The new ALTER SYSTEM FLUSH REDO SQL statement can be used at failover time to flush unsent redo from a mounted primary database to a standby database, thereby allowing a zero data loss failover to be peformed even if the primary database is not running in a zero data loss data protection mode.
· The FAL_CLIENT database initialization parameter is no longer required.
Specific to Redo Apply (Physical Standby Database);
· A corrupted data block in a primary database can be automatically replaced with an uncorrupted copy of that block from a physical standby database that is operating in real-time query mode. A corrupted block in a physical standby database can also be automatically replaced with an uncorrupted copy of the block from the primary database.
Tag :
oracle,
oracle_dataguard
Dataguard on Different Operating Systems
In 10g, dataguard started to support different binaries on primary and standby database servers with the same OS family. For example Microsoft Windows 64-bit Itanium on primary and Microsoft Windows 32-bit or Microsoft Windows 64-bit for AMD on standby database server. However with 11g, dataguard also supports different OS on primary and standby servers. I wanted to share the support matrix for this feature.
ID | PLATFORM_NAME Release name | PLATFORM_IDs supported within the same Data Guard configuration when using Data Guard Redo Apply (Physical Standby) |
2 | Solaris Operating System (SPARC) (64-bit) | 6 - Oracle 11g onward, primary database must be non-RAC and non-TDE |
3 | HP-UX PA-RISC (64-bit) | 4 - Oracle 10g onward, see Support Notes 395982.1 and 414043.1 |
4 | HP-UX Itanium (64-bit) | 3 - Oracle 10g onward, see Support Notes 395982.1 and 414043.1 |
5 | HP Tru64 UNIX | |
6 | AIX-Based Systems (64-bit) | 2 - Oracle 11g onward, primary database must be non-RAC and non-TDE |
7 | Microsoft Windows (32-bit) | 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 (64-bit Itanium) | 7 - Oracle 10g onward, see Support Note 414043.1 12 - Oracle 10g onward 11, 13 - Oracle 11g onward |
9 | IBM zSeries Based Linux | 18 (64-bit zSeries only) |
10 | Linux (32-bit) | 7 - Oracle 11g onward 11, 13 - Oracle 10g onward, see Support Note 414043.1 |
11 | Linux Itanium (64-bit) | 10 - Oracle 10g onward, see Support Note 414043.1 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 | 7 - Oracle 10g onward, see Support Note 414043.1 8 - Oracle 10g onward 11, 13 - Oracle 11g onward |
13 | Linux 64-bit for AMD | 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 20 - Oracle 11g onward |
15 | HP Open VMS | |
16 | Apple Mac OS | |
17 | Solaris Operating System (x86) | 20 - Oracle 10g onward, see Support Note 414043.1 |
18 | IBM Power Based Linux | 9 (64-bit zSeries only) |
19 | HP IA OpenVMS | |
20 | Solaris Operating System (AMD64) | 13 - Oracle 11g onward 17 - Oracle 10g onward, see Support Note 414043.1 |
Metalink notes specify some restrictions which you should be aware when using the configuration in question. Some important restrictions are:
- DG Broker is not supported on different binary configuration with 10g.
- Logical standby is not supported with 32/64 bit configurations
Tag :
oracle,
oracle_dataguard