Best practices with Oracle GoldenGate – Part 2

Leveraging technology to its full potential calls for an understanding of the best practices associated with it. As we discussed in part 1 of this article while considering Oracle GoldenGate technology, familiarity with the product to successfully design and implement a highly available Oracle GoldenGate environment is an essential step. In the previous blog, we discussed a few best practices associated with Oracle GoldenGate and here we are taking it further while looking at a few more suggested practices you should refer to.

Configure the GoldenGate Heartbeat Table

The built-in heartbeat table functionality offers end-to-end replication lag views without requiring you to manually create your own heartbeat table. It was first introduced in Oracle GoldenGate release 12.2.0.1. You can view the end-to-end replication delay by using the GGSCI command ADD HEARTBEAT after constructing the heartbeat table. Also, it is possible to see the end-to-end replication latency if GG LAG database view is being examined.

Database File System Configuration

Oracle advises to store the shared Oracle GoldenGate files (trail files, checkpoint files, bounded recovery files, and parameter files) on Database File System (DBFS) file systems when using Oracle Exadata Database Machine with Oracle RAC or Oracle Data Guard setups.

Utilizing DBFS enables integration with Cluster Ready Services (CRS), which automates the mounting of DBFS file systems on an Oracle RAC cluster survivor node. This enables Oracle GoldenGate processes to launch automatically following the mounting of necessary file systems.

Data Gathering

This is one of the very important best practices when it comes to Oracle GoldenGate. There are several key pieces of information that must be gathered to analyze and troubleshoot Oracle GoldenGate performance. Some of those important information pieces are:

• Latency or lag time (to be checked for every single Oracle GoldenGate process).
• Oracle GoldenGate process report files along with ggserr.log error log.
• Integrated Replicat health check report.
• Active Session History (ASH) database reports.
• CPU and I/O details.
• Oracle Streams Performance Advisor (SPADV) report.
• Automatic Workload Repository (AWR).

Experts recommend using the script provided in MOS note 2262988.1 to gather all of the above points of information.

Oracle GoldenGate Performance Tuning Methodology

It is absolutely important to understand the flow of data between the source and target databases. Especially, when you try to diagnose slow performance in an Oracle GoldenGate environment. Study the flow of data between the source and target databases in detail to avoid issues and implement Oracle GoldenGate performance tuning methodology.

Improving the performance of Oracle GoldenGate is an iterative process. It takes time and effort to understand and implement the best practices in the right way. The series of two blogs covered a glimpse of what you need to do to improve the performance when it comes to Oracle GoldenGate solution. Get in touch with Princeton IT if you are looking for experts in Oracle technology or have any questions regarding Oracle GoldenGate.