This chapter includes the following sections:
The Oracle GoldenGate capture process is known as
Extract. Each instance of an Extract process is known as a
group, which includes the process itself and the associated files that support it.
An additional Extract process, known as a
data pump, is recommended to be used on the source system, so that captured data can be persisted locally to a series of files known as a
trail. The data pump does not capture data but rather reads the local trail and propagates the data across the network to the target.
The Oracle GoldenGate apply process is known as
Replicat. Each instance of a Replicat process is known as a
group, which includes the process itself and the associated files that support it. Replicat reads data that is sent to local storage, known as a
trail, and applies it to the target database.
Figure 5-1 illustrates the basic Oracle GoldenGate process configuration. For more information about Oracle GoldenGate processes, see Administering Oracle GoldenGate for Windows and UNIX.
Note:Oracle databases must be in
ARCHIVELOGmode so that Extract can process the log files.
For an Oracle source database, you can run Extract in either classic capture or integrated capture mode. The method that you use determines how you configure the Oracle GoldenGate processes and depends on such factors as:
the data types involved
the database configuration
the version of the Oracle database
The following explains these modes and the database versions that each mode supports.
In classic capture mode, the Oracle GoldenGate Extract process captures data changes from the Oracle redo or archive log files on the source system or from shipped archive logs on a standby system. Figure 5-2 illustrates the configuration of Extract in classic capture mode.
Classic capture supports most Oracle data types fully, with restricted support for the complex data types. Classic capture is the original Oracle GoldenGate capture method. You can use classic capture for any source Oracle RDBMS that is supported by Oracle GoldenGate, with the exception of the multitenant container database.
You can use classic capture to support the following:
NOLOGGING LOBs with source database compatibility set below 188.8.131.52.0.
Transparent Data Encryption support with source database compatibility set below 184.108.40.206.0.
SECUREFILE LOB support with source database compatibility set below 220.127.116.11.0.
NOLOGGING LOB support with source database compatibility set below 18.104.22.168.0.
For more information, see Section 1.5, "Summary of Supported Oracle Data Types and Objects Per Capture Mode".
In integrated capture mode, the Oracle GoldenGate Extract process interacts directly with a database logmining server to receive data changes in the form of logical change records (LCR). Figure 5-3 illustrates the configuration of Extract in integrated capture mode.
Integrated capture supports more data and storage types as compared to classic capture, and the support is more transparent. For more information, see Section 1.5, "Summary of Supported Oracle Data Types and Objects Per Capture Mode".
The following are some additional benefits of integrated capture:
Because integrated capture is fully integrated with the database, no additional setup is required to work with Oracle RAC, ASM, and TDE.
Integrated capture uses the database logmining server to access the Oracle redo stream, with the benefit of being able to automatically switch between different copies of archive logs or different mirrored versions of the online logs. Thus integrated capture can transparently handle the absence of a log file caused by disk corruption, hardware failure, or operator error, assuming that additional copies of the archived and online logs are available
Integrated capture enables faster filtering of tables.
Integrated capture handles point-in-time recovery and RAC integration more efficiently.
Integrated capture features integrated log management. The Oracle Recovery Manager (RMAN) automatically retains the archive logs that are needed by Extract.
Integrated capture is the only mode that supports capture from a multitenant container database. One Extract can mine multiple pluggable databases within a multitenant container database.
For a release 22.214.171.124 source database and later (with source compatibility set to 126.96.36.199 or higher), the capture of DDL is performed by the logmining server asynchronously and requires no special triggers, tables, or other database objects to be installed. Oracle GoldenGate upgrades can be performed without stopping user applications. The use of a DDL trigger and supporting objects is required when Extract is in integrated mode with an Oracle 11g source database that is earlier than version 188.8.131.52.
Because integrated capture and integrated apply are both database objects, the naming of the objects follow the same rules as other Oracle Database objects. For more information, see Oracle Database Administrator's Guide.
The database version determines the data type support available through integrated capture:
Full support: To support all Oracle data and storage types, the compatibility setting of the source database must be at least 184.108.40.206 with the 220.127.116.11 Database specific bundle patch for Integrated Extract 11.2.x (My Oracle Support Document ID 1557031.1). To get this patch from My Oracle Support, go to:
To support DDL capture without installing DDL support objects, the source database must be at least Oracle 18.104.22.168 or later. For earlier database versions, DDL support objects are required. See Appendix D, "Installing Trigger-Based DDL Capture" for more information.
Limited support: You can use integrated capture on an 22.214.171.124 downstream mining database for a source database with a compatibility less than 126.96.36.199, but in this mode,
SECUREFILE LOBs, XML columns, Transparent Data Encryption, and UDTs have limited support based on database version and compatibility. The downstream mining database must have the 188.8.131.52 Database specific bundle patch for Integrated Extract 11.2.x (Doc ID 1557031.1) applied. See Section 184.108.40.206, "Integrated Capture Deployment Options". The downstream mining database must be at the same (or greater) database release (minimum 220.127.116.11) as the source database release being mined.
To understand the differences in data type support among different RDBMS versions, see Section 1.5, "Summary of Supported Oracle Data Types and Objects Per Capture Mode".
There are two deployment options for integrated capture, depending on where the mining database is deployed. The mining database is the one where the logmining server is deployed.
Local deployment: For local deployment, the source database and the mining database are the same. The source database is the database for which you want to mine the redo stream to capture changes, and also where you deploy the logmining server. Because integrated capture is fully integrated with the database, this mode does not require any special database setup.
Downstream deployment: In downstream deployment, the source and mining databases are different databases. You create the logmining server at the downstream database. You configure redo transport at the source database to ship the redo logs to the downstream mining database for capture at that location. Using a downstream mining server for capture may be desirable to offload the capture overhead and any other overhead from transformation or other processing from the production server, but requires log shipping and other configuration.
When using a downstream mining configuration, the source database and mining database must be of the same platform. For example, if the source database is running on Windows 64-bit, the downstream database must also be on a Windows 64-bit platform. See Appendix B, "Configuring a Downstream Mining Database" and Appendix C, "Example Downstream Mining Configuration" to configure a downstream mining database.
The Replicat process is responsible for the application of replicated data to an Oracle target database. For more information about Oracle GoldenGate processes, see Administering Oracle GoldenGate for Windows and UNIX.
For an Oracle target database, you can run Replicat in either nonintegrated or integrated mode. The following explains these modes and the database versions that each mode supports.
In nonintegrated mode, the Replicat process uses standard SQL to apply data directly to the target tables. In this mode, Replicat operates as follows:
Reads the Oracle GoldenGate trail.
Performs data filtering, mapping, and conversion.
Constructs SQL statements that represent source database DML or DDL transactions (in committed order).
Applies the SQL to the target through Oracle Call Interface (OCI).
Figure 5-4 illustrates the configuration of Replicat in nonintegrated mode.
Use nonintegrated Replicat when:
The target Oracle database is a version earlier than Oracle 18.104.22.168.
You want to make heavy use of features that are not supported in integrated Replicat mode. See Section 5.3.2, "About Integrated Replicat" for more information.
You can apply transactions in parallel with a nonintegrated Replicat by using a coordinated Replicat configuration. See Administering Oracle GoldenGate for Windows and UNIX for more information.
In integrated mode, the Replicat process leverages the apply processing functionality that is available within the Oracle database. In this mode, Replicat operates as follows:
Reads the Oracle GoldenGate trail.
Performs data filtering, mapping, and conversion.
Constructs logical change records (LCR) that represent source database DML transactions (in committed order). DDL is applied directly by Replicat.
Attaches to a background process in the target database known as a database inbound server by means of a lightweight streaming interface.
Transmits the LCRs to the inbound server, which applies the data to the target database.
Figure 5-5 illustrates the configuration of Replicat in integrated mode.
Within a single Replicat configuration, multiple inbound server child processes known as apply servers apply transactions in parallel while preserving the original transaction atomicity. You can increase this parallelism as much as your target system will support when you configure the Replicat process or dynamically as needed. Figure 5-6 illustrates integrated Replicat configured with two parallel apply servers.
Integrated Replicat applies transactions asynchronously. Transactions that do not have interdependencies can be safely executed and committed out of order to achieve fast throughput. Transactions with dependencies are guaranteed to be applied in the same order as on the source.
A reader process in the inbound server computes the dependencies among the transactions in the workload based on the constraints defined at the target database (primary key, unique, foreign key). Barrier transactions and DDL operations are managed automatically, as well. A coordinator process coordinates multiple transactions and maintains order among the apply servers.
If the inbound server does not support a configured feature or column type, Replicat disengages from the inbound server, waits for the inbound server to complete transactions in its queue, and then applies the transaction to the database in direct apply mode through OCI. Replicat resumes processing in integrated mode after applying the direct transaction.
The following features are applied in direct mode by Replicat:
SQLEXEC parameter within a
UDT Note, if the extract uses
USENATIVEOBJSUPPORT to capture the UDT, then integrated Replicat will apply it with the inbound server, otherwise it will be handled by Replicat directly.
Because transactions are applied serially in direct apply mode, heavy use of such operations may reduce the performance of the integrated Replicat mode. Integrated Replicat performs best when most of the apply processing can be performed in integrated mode. See Section 15.5, "Monitoring and Controlling Processing After the Instantiation".
Note:User exits are executed in integrated mode. The user exit may produce unexpected results, however, if the exit code depends on data in the replication stream.
The following are the benefits of using integrated Replicat versus nonintegrated Replicat.
Integrated Replicat enables heavy workloads to be partitioned automatically among parallel apply processes that apply multiple transactions concurrently, while preserving the integrity and atomicity of the source transaction. Both a minimum and maximum number of apply processes can be configured with the
MAX_PARALLELISM parameters. Replicat automatically adds additional servers when the workload increases, and then adjusts downward again when the workload lightens.
Integrated Replicat requires minimal work to configure. All work is configured within one Replicat parameter file, without configuring range partitions.
High-performance apply streaming is enabled for integrated Replicat by means of a lightweight application programming interface (API) between Replicat and the inbound server.
Barrier transactions are coordinated by integrated Replicat among multiple server apply processes.
DDL operations are processed as direct transactions that force a barrier by waiting for server processing to complete before the DDL execution.
Transient duplicate primary key updates are handled by integrated Replicat in a seamless manner.
Integrated Replicat works with single or pluggable databases.
To use integrated Replicat, the following must be true.
The target Oracle database must be Oracle 22.214.171.124 or later.
Supplemental logging must be enabled on the source database to support the computation of dependencies among tables and scheduling of concurrent transactions on the target. Instructions for enabling the required logging are in Chapter 3, "Configuring Logging Properties". This logging can be enabled at any time up to, but before, you start the Oracle GoldenGate processes.
You can use the following capture and apply modes together:
Classic capture (Oracle or non-Oracle source) and nonintegrated Replicat
Classic capture (Oracle or non-Oracle source) and integrated Replicat
Integrated capture and nonintegrated Replicat
Integrated capture and integrated Replicat
You can use integrated capture and classic capture concurrently within the same source Oracle GoldenGate instance, and you can use integrated Replicat and nonintegrated Replicat concurrently within the same target Oracle GoldenGate instance. This configuration requires careful placement of your objects within the appropriate process group, because there is no coordination of DDL or DML between classic and integrated capture modes, nor between nonintegrated and integrated Replicat modes. Each Extract group must process objects that are suited to the processing mode, based on table data types and attributes. No objects in one Extract can have DML or DDL dependencies on objects in the other Extract. The same type of segregation must be applied to the Replicat configuration.
The recommended Oracle GoldenGate configuration, when supported by the Oracle version, is to use one integrated capture on an Oracle source and one integrated Replicat per source database on an Oracle target. Integrated capture supports certain data types more completely than classic capture. One integrated Replicat configuration supports all Oracle data types either through the inbound server or by switching to direct apply when necessary, and it preserves source transaction integrity. You can adjust the parallelism settings to the desired apply performance level as needed.
If the target database is an Oracle version that does not support integrated Replicat, or if it is a non-Oracle database, you can use a coordinated Replicat configuration. See Administering Oracle GoldenGate for Windows and UNIX for more information.
You can switch between process modes. For example, you can switch from classic capture to integrated capture, or from integrated capture to classic capture. For instructions, see Administering Oracle GoldenGate for Windows and UNIX.