Using GoldenGate Replication

Once connectivity is established between your cloud service tenancy and your target tenancy, you request a Database Copy of the source environment. This Database Copy is then transferred to your object storage location in Oracle Data Pump format, from where your database administrators can then import the Database Copy into your target Autonomous Transaction Processing database instance.

See Requesting a Database Copy in the Oracle Utilities Cloud Services Cloud Operations Guide for more details about requesting a database copy.

There are important considerations regarding the initial load process:

• Initial load extract files can be large, and are directly proportional to the source database size. Information Lifecycle Management (ILM) should be used in the source database to ensure it is as small as possible.

• The extract may require downtime in the source database (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 database autoscaling should be enabled during the initial load.

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

Also, note the following important operational considerations:

• Ongoing replication is not the 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/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 database in terms of partitioning, indexes, and so on, as these will be highly dependent on the reporting and integration requirements.

• Retention of trail files is 7 days

• This 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