9 Configuring Oracle GoldenGate

9.1.1 Oracle GoldenGate and Oracle RAC

Oracle Real Application Clusters (Oracle RAC) enables multiple instances that are linked by an interconnect to share access to an Oracle database. In an Oracle RAC environment, Oracle Database runs on two or more systems in a cluster while concurrently accessing a single shared database. The result is a single database system that spans multiple hardware systems, enabling Oracle RAC to provide high availability and redundancy during failures in the cluster. Oracle GoldenGate is integrated with Oracle RAC and Cluster Ready Services (CRS) using the Oracle Grid Infrastructure Agent such that during cluster node failures, GoldenGate will automatically restart on a surviving node.

9.1.2 Oracle GoldenGate and Oracle Data Guard/Oracle Active Data Guard

Oracle GoldenGate is Oracle's strategic logical replication product. Oracle Data Guard is Oracle's strategic physical replication product focused on data protection and data availability, and is the standard MAA recommendation for such purposes because of the advantages it offers over logical replication. Oracle Data Guard is also commonly used in place of storage-remote mirroring or host-based mirroring solutions for disaster protection. Oracle Data Guard also minimizes planned downtime by supporting database rolling upgrades, select migrations (for example, Windows to Linux), data center moves, and other types of planned maintenance. Oracle Active Data Guard, an extension to Oracle Data Guard, is the simplest, fastest, most efficient method of maintaining a synchronized physical replica of a source database open read-only for offloading read-only workload and backups. For a detailed discussion of Data Guard advantages for data protection, see the Product Technical Brief, "Oracle Active Data Guard and Oracle GoldenGate" available from the GoldenGate link at

http://www.oracle.com/technetwork/database/features/availability/index.html

Oracle GoldenGate is often used in Data Guard configurations in a complementary manner. Oracle GoldenGate is integrated with Data Guard using the Oracle Grid Infrastructure Agent, so that during a Data Guard role transition (switchover or failover) the GoldenGate processes will restart automatically on the primary database. The Data Guard protection mode can be either MaxAvailability/MaxProtection (zero data loss) or MaxPerformance (data loss).

9.1.3 Oracle GoldenGate and Edition-Based Redefinition

Edition-based redefinition is a capability implemented entirely within Oracle Database that enables database objects that implement the back end of an application to be patched or upgraded without interrupting the availability of the application. Edition-based redefinition enables customers to implement application upgrades online with zero database downtime. Edition-based redefinition requires Oracle Database 11g Release 2, and it requires application changes; an application must be made editionable to upgrade online.

Oracle GoldenGate can also be used for online application upgrades. The application itself does not need to be modified to implement an upgrade, but the administrator must have sufficient knowledge of the differences between old and new versions of the application to implement mapping between versions using Oracle GoldenGate. User control over the application, and user preference for the second major distinction between these technologies determines which approach makes the most sense to achieve a zero downtime application upgrade.

The second major difference between these technologies is that edition-based redefinition uses only the single database that ordinarily supports the application. Oracle GoldenGate uses a second synchronized database to execute the upgrade.

• Using edition-based redefinition, the old version of the application is in the old edition and the new version of the application is in the new edition - both within the same database; the edition is the isolation mechanism. Data that is represented the same in the old and the new versions of the application is represented only once in table columns used by both versions; only data that is represented differently in the two application versions must exist twice. Synchronization is needed, therefore, only for that typically small proportion of the total data that differs between the two versions. Because a cross edition trigger fires within a transaction, potential conflicts between the old and the new representations are prevented before they can be committed, and there is no need for conflict-resolution.

• Using Oracle GoldenGate, the old version of the application runs on the original database and the new version of the application runs on a second database; the second database is the isolation mechanism. All data - both that which is represented the same in the old and the new versions of the application and that which is represented differently in the two application versions must exist twice. Synchronization is needed, therefore, for all the data. The synchronization is implemented using code that intervenes in the replay mechanism for the SQL that is constructed by mining the redo logs. It is, therefore, non-transactional; and conflicts between the old and the new representations cannot be prevented. Rather, conflict-resolution must be implemented as an explicit, post-processing step.

9.2.1 Oracle GoldenGate Integrated Extract and Integrated Replicat

With Oracle GoldenGate version 12.1.2, Replicat can now operate in integrated mode for improved scalability within Oracle target environments. The apply processing functionality within the Oracle database is leveraged to automatically handle referential integrity and data description language (DDL) so that the operations are applied in the correct order. Extract can also be used in integrated capture mode with an Oracle database, introduced with Oracle GoldenGate version 11.2.1. Extract integrates with an Oracle database log mining server to receive change data from the database in the form of logical change records (LCR). Extract can be configured to capture from a local or downstream mining database. Because integrated capture is fully integrated with the database, no additional setup is required to work with Oracle RAC, ASM, TDE, and data compression which greatly simplify setup without sacrificing performance.

The latest version of Oracle GoldenGate can be downloaded from My Oracle Support, Patches and Updates.

To make use of Integrated Extract you must use database release 11.2.0.3 or later. The specific patch numbers required for 11.2.0.3 are listed in My Oracle Support node 1557031.1. Integrated capture mode Extract can also be used to capture changes from Oracle versions starting with 10.2.0.4 with downstream mining using an 11.2.0.3 or higher, mining database.

To make use of Integrated Replicat use database release of 11.2.0.4 or later.

9.2.2 Use of a Clustered File System

Using a clustered file system is fundamental to the continuing availability of Oracle GoldenGate checkpoint and trail files in the event of a node failure. Ensuring the availability of the checkpoint files is essential to ensure that, after a failure occurs, the Extract process can continue mining from the last known archived redo log file position and Replicat processes can start applying from the same trail file position before a failure occurred. Using Oracle Database Filesystem (DBFS) or Oracle Automatic Storage Management Cluster File System (Oracle ACFS) allows a surviving database or ASM instance to be the source of an Extract process or destination for the Replicat processes.

Best practices for configuring DBFS or Oracle ACFS for use with Oracle GoldenGate are described in each of the following references.