Cookies on this site

We would like to use cookies to understand how the site is used and to measure our campaigns. Nothing is set until you choose, and you can change your mind at any time from “Cookie settings” at the foot of every page. Privacy policy

Contact UsContact Us

Resources / Blogs

Oracle & databases

A Brief Overview of Oracle GoldenGate Architecture: Part 2

In part 1 of this blog, we discussed Oracle GoldenGate architecture and its primary components, i.e., Extract, Remote Trail and Data Pump. This blog covers the remaining important components you need to know to understand Oracle GoldenGate architecture completely.

· · 2 min read

A Brief Overview of Oracle GoldenGate Architecture: Part 2

Oracle GoldenGate is a software that enables you to replicate, transform, and filter data from one database to another, even across multiple heterogeneous systems in your enterprise.

In part 1 of this blog, we discussed Oracle GoldenGate architecture and its primary components, i.e., Extract, Remote Trail and Data Pump. This blog covers the remaining important components you need to know to understand Oracle GoldenGate architecture completely.

Manager

The manager process is responsible for maintaining the rest of the processes in Oracle GoldenGate. It runs both on your source and the target site. This procedure is launched first by GoldenGate. The Manager then initiates and terminates each subsequent GoldenGate process, maintains the trail files, and also generates reports and log files.

Checkpoint

Checkpoints are used for recovery purposes to store the current read and write positions of a process to disk.

Checkpoints ensure that data changes are marked for synchronization and are extracted by Extract, and applied to the target. This leads to the prevention of redundant processing. Hence, they also prevent loss of data if the system, the network, or an Oracle GoldenGate process needs to be restarted.

Moreover, Checkpoints also help in complex synchronization configurations by facilitating multiple Extract/ Replicat processes to read from the same set of trails. They also ensure inter-process revelations and prevent message loss in the network.

Delivery (Replicat)

Applying data updates to the target database is the procedure known as delivery. Delivery in GoldenGate is carried out utilising the native SQL database using a procedure known as the Replicat. Using different bind variables, Replicat executes a single SQL statement several times using dynamic SQL.

To preserve the reliability of the data, the Extract process writes data changes to the trail file in the same order as they were committed on the source database, and the Replicat applies those changes in the same order. To boost throughput, you can run multiple Replicat processes simultaneously with one or more Extract processes and data pumps. Alternatively, you can configure one Replicat in an integrated mode rather than running multiple Replicat processes.

This is essentially all the Oracle GoldenGate theory you need to be aware of. In case you have any questions, let us know in the comments below. Want to know more about Oracle GoldenGate and best-in-class technology solutions? Get in touch with the experts at Princeton IT Services.

← All articles

Case studies

Oracle Consulting in practice

Client names are withheld. We are happy to share details on a call.

All case studies
  • Delivered

    30 TB, zero downtime

    Financial services

    Oracle

    Zero-downtime move of a 30 TB Oracle database for a global retail bank

    The bank's transaction database served thousands of users around the clock. We built the new Oracle 12c RAC platform on IBM AIX alongside the old Solaris system, kept the two in sync with Oracle GoldenGate, tested everything and switched over with no downtime and no data loss.

    • 30 TB moved with zero downtime
    • Zero data loss at cut-over
  • Delivered

    Zero downtime

    Legal technology

    Oracle

    Sybase to Oracle with zero downtime for an e-discovery company

    Sybase was holding back a platform that processes large volumes of legal data. We converted the schema, kept both databases in sync with continuous replication, validated the data and switched over without interrupting the business.

    • Zero downtime at cut-over
    • No disruption to client workflows
  • Delivered

    No service disruption

    Local government

    Oracle

    A city's Oracle database moved off ageing Solaris hardware

    A major California city ran a mission-critical Oracle database on Solaris servers nearing end of life. We mapped the dependencies, confirmed the applications would work unchanged and re-platformed the database to Linux without disrupting public services.

    • No disruption to public services
    • Minimal application changes

Planning an Oracle or database migration?

Request a migration plan consult with the DBAs who do this work, and leave with a fixed-scope plan.