Configuring change delivery
Change delivery is the process of applying the logical change
records (LCR) generated from transactions that occurred on the source database. The data delivery is the responsibility of the Replicat process that mines the remote trail files, converts the LCRs to DML and DDL statements, and applies them to the target database. This process can often cause a bottleneck, depending on the volume of data being replicated. Oracle recommends enabling Integrated Capture or Coordinated Delivery against the target database to leverage parallel processing and enhance the performance of Replicat.
For this example, we will create one Replicat named ROLAP01 to apply DML to the EMP and DEPT tables in the PDB2: TGT schema. For a nonCDB database, the schema will be TGT in our OLAP target database.
For classic mode, the first step in order to configure Change Data Delivery (CDD) is the creation of a Checkpoint table. This is optional; Oracle highly recommends it over the default...
Testing change data capture and delivery
To test whether
change synchronization is working, we must make some data changes on our source database and ensure that they are propagated to and applied on the target.
The following simple steps provide a basic test case that will confirm all is well.
On the source database server, start a SQL*Plus session and connect it to the PDB1 database as the SRC user:
We can call the following script to generate a test transaction:
Issuing a commit forces Oracle to write the transaction details to the database's online redo logs. These are subsequently read by the Extract process (EOLTP01) in real time and written to the local trail. The transaction in the local trail is read by the data pump process (EPMP01) that transfers the data via TCP/IP to the remote trail. The Replicat process (ROLAP01) reads the remote trail, converts the...
Stopping GoldenGate processes
Now that we know how to start the Manager, Extract, and Replicat processes using GGSCI commands, let's take a look at how to stop them. Issuing a stop command will gracefully shutdown the GoldenGate processes.
First, check the processes that are running in your GoldenGate Home using the following code:
Stop all processes using a wildcard, as shown in the following code:
Check the processes again using the following code:
Trail files are used by Extract and Replicat processes; their primary role is for data persistence. You could argue that writing files to what could be deemed as a staging area is wasteful and suboptimal. Having said that, GoldenGate writes only the committed transactions to trail files in large blocks minimizing I/O. Furthermore, the architecture provides a guaranteed no data loss solution that is not to be underestimated.
By default, trail files are in the canonical format being unstructured, but with a header record. They are stored in the ./dirdat subdirectory under the GoldenGate Home. Each record contains the changed data and is of a variable record length. A trail can contain numerous trail files, each having a two-character prefix with a six-digit sequence number suffix.
An Extract process can write data to many trails. A Replicat can process data from only one trail. In classic mode, it is possible to configure multiple Replicat processes to handle...
Configuring Oracle Manager process
In the previous chapter, we discussed the PORT parameter that is mandatory for the GoldenGate Manager process communication. In the previous section, you learned how to set a retention period for the trail files in the Manager configuration. Let's now look at some additional, Oracle recommended Manager process parameters: AUTOSTART and AUTORESTART.
The following code will tell the Manager to start the Extract or Replicat processes when the Manager starts and to restart only the Extract process(es) after two minutes in the event of a failure. With the following code, the Manager will try five times before abending the processes:
When you edit the GoldenGate Manager parameter file from GGSCI, ensure that the Extract, Replicat, and Manager processes are restarted for all the changes to take effect.
Configuring the downstream mining database
The downstream mining database topology has been available since Oracle GoldenGate 11g Release 2. Its functionality is reminiscent of Oracle Streams, where both the capture and apply processes are configured on the target system. Known as source database offloading, the source database sends its redo stream to the target system. Here, the Extract process uses the Logminer server on the downstream database to mine the logs.
The configuration is largely conducted on the source and target database to enable the Oracle Data Guard transport mechanism of log shipping. This can be in real-time mode or archive log shipping mode. Configuring the former allows Oracle to fall back to the latter when it is under extreme load or experiencing network latency.
The following diagram illustrates the architecture of the downstream mining database that includes the naming convention used in the example configuration:
Preparing the source database
The first step involved...
The examples given in this chapter illustrate the configuration process, providing a greater understanding of the GoldenGate architecture.
You learned how to configure the Extract and Replicat processes for different instantiation methods, such as File to Replicat and Direct Load, to perform the initial load. We also considered the importance of data synchronization between a source and target database in a replication environment.
Configuring change data capture and delivery has shown us how to enable zero downtime migrations as well as provide the final step in the GoldenGate instantiation.
Exploring new features, we discovered that there are many parameters and options along with their available functions, offering enormous scope and flexibility.
In the next chapter, we will look at configuration in more detail (from data mapping and filtering to finally discussing data transformation and error handling), all of which help to create a robust GoldenGate environment.
