Oracle Utilities Cloud Service - GoldenGate Replication

Oracle Utilities Cloud Service - GoldenGate Replication enables the deployment of Oracle managed OCI GoldenGate Cloud Service extract processes, which extract Change Data Capture (CDC) information from the source (SaaS) environment via the redo/archive logs normally generated by the source (SaaS) environment database. This redo/archive log information is transformed by the extract processes into GoldenGate trail files, which are made available to customers via a Named Distribution Path (a GoldenGate distribution path).

In order to leverage this GoldenGate Replication feature, you must subscribe to Part # B110320 Oracle Utilities Cloud Service, GoldenGate Replication, which enables the Oracle managed source (SaaS) side GoldenGate extract services.

In addition, you must subscribe to the following OCI services, which are available directly on OCI via Universal Credits:

  1. OCI Autonomous Database ATP (Autonomous Transaction Processing), which is the target database into which data is replicated.
  2. OCI GoldenGate Service, which provides the replicat and other GoldenGate services and features for maintaining ongoing replication.

Once all pre-requisite subscription components are in place, your administrators will work with Oracle to establish secure OCI network connectivity between your target OCI tenancy (which is fully owned and managed by you) and the SaaS tenancy in which your Oracle Utilities Enterprise SaaS service is deployed. See the documentation for details on what is required.

When connectivity is established between the two tenancies, you request a Database Copy of the source environment. This Database Copy is then transferred to your object storage in DataPump format, from where your DBAs then import the Database Copy into your target ATP database instance.

There are important considerations regarding the initial load process:

  • Initial load extract files can be large, and they are directly proportional to the source DB size. ILM should be used in the source to ensure the source database is as small as possible.
  • The extract may require downtime in the source (approx. 1 hour) to establish proper synchronization data required for replication, and therefore needs to be scheduled during a scheduled maintenance window (or will be considered scheduled maintenance).
  • Full schema extract is used to maximize performance.
  • Target DB autoscaling should be enabled during the initial load.

Assuming the Database Copy is successfully imported into the target ATP database, you can then configure your OCI GoldenGate service to begin applying CDC information received via the Named Distribution Path to your target database instance in order to keep the target synchronized with the source.

This provides you with full and direct access to all SaaS data replicated to the target Autonomous DB ATP database instance. It enables you to query, report on, and develop data driven integrations based on your SaaS data (in the target database). It also allows for retention of data that is useful for reporting and integration purposes, even if the data is removed from the source SaaS database via ILM processes (partition drops).

Steps to Enable

To enable this feature, refer to the GoldenGate Replication chapter in the Oracle Utilities Cloud Services Administration Guide.

Tips And Considerations

You should be aware of the Target Environment minimum sizing recommendations:

  • Database – Autonomous Database
    • Single Database
    • Transaction Processing & Mixed (ATP)
    • 4 Peak ECPUs
    • Autoscale ON
    • DB and backup storage as required
  • OCI GoldenGate
    • 2-4 OCPUs
    • Autoscale ON

NOTE: Four OCPUs covers 80% of use cases for GoldenGate customers generally.

Also, note the following important operational considerations:

  • Ongoing replication is not full schema, as the following are excluded:
    • High change working tables (for example, to track batch execution)
    • IMD CLOBs (MSCS, AMS)
    • The staging schema
    • Custom tables (via Java Migration Cloud Service) until data volumes are assessed
  • Multiple target replicats are recommended to prioritize and optimize replication performance. It is recommended that groupings are based on:
    • Data volumes
    • Priority
    • Table parent/child relationships
  • Lag after heavy processing the source (for example, nightly batch processing) should be expected:
    • Prioritized and parallelized replicats should catch up within several hours if properly sized.
  • Upgrades and Data Model Changes:
    • DDL is largely excluded except CREATE and ALTER TABLE statements to add new tables/columns
    • Indexes, partitions, and more may be created via initial load, but are not maintained via replication (ILM partition drops are not replicated in the target, as customers are likely to want to keep that data)
    • You are responsible for managing any required changes to the target DB in terms of partitioning, indexes, etc., as these will be highly dependent on the reporting and integration requirements.
  • Retention of trail files is 7 days:
    • Allows recovery within that time period
  • Re-establishment of replication services is possible and will involve:
    • A new full schema data extract/initial load
    • Restarting of replicats
    • Data management to merge the new source data with existing target data