GoldenGate Instantiation methods

Using RMAN to create a copy of a large source database for replication.

Instantiation is the process of preparing the target database with a consistent copy of the source data, ensuring it is in sync at a specific point in time, so Oracle GoldenGate can begin replicating changes seamlessly from that point forward.

There are three commonly used methods for instantiating a target database:

• GoldenGate Initial Load – Uses GoldenGate to perform a one-time load of source data into the target.
• Oracle Data Pump (expdp/impdp) – Exports data from the source and imports it into the target using Oracle’s Data Pump utility.
• Oracle Recovery Manager (RMAN) – Creates the target database by restoring a backup of the source database.

GoldenGate Initial Load and Oracle Data Pump are logical instantiation methods, ideal for small tables and scenarios requiring data manipulation or transformation during the load process. In contrast, Oracle RMAN provides a physical, block-based instantiation method, offering faster performance for large-scale data transfers.

This Blog focuses on the RMAN instantiation method. Other methods might be explained in further blog articles.

For databases in the terabyte range, logical instantiation methods can be time-consuming and inefficient. In such cases, Oracle RMAN is a preferred solution for creating a physical clone of the source database. RMAN duplication is a well-documented and widely used approach that allows you to efficiently create a target database tailored to your replication needs. The process involves the following steps:

• Use a backup of the source database.
• Restore the backup to a new auxiliary (cloned) database.
• Perform media recovery on the auxiliary database to bring it to a consistent state.
• Configure and adjust the cloned database to meet the specific requirements of the target environment.

When using RMAN cloning for GoldenGate, it’s important to manage the timing of replication to avoid data loss and ensure smooth integration. The key is to identify the point in time (or SCN) when the target database was consistent, so that both the source and target databases stay in sync.

To do this, start the GoldenGate Extract process on the source database before the backup is taken. If you find a transaction that has an older timestamp than when you registered Extract, you must wait until that transaction has completed. This is important as Extract only processes complete transactions. Once the target system is set up through cloning, direct the replication changes to the target system using the DistPath and add the Replicat process. When you start the Replicat, make sure to start exactly at the SCN where the target database was recovered.

Example:
It’s Saturday evening at 10 PM, and the regular scheduled backup of the source database is running. The backup includes database files and archive logs, which are backed up more frequently. The backup finishes at 10:30 PM with an SCN of 1420004711. This backup is then used to clone (restore and recover) the new target database. File copying, restore, and recovery take several hours, and by Sunday morning at 6 AM, the new target database is ready. At this point, both the source and target databases are consistent.

As time passes, new changes continue to occur on the source database, and its SCN increases (e.g., SCN = 1420501007). To keep the target database in sync, GoldenGate’ s Extract process captures changes starting from a point before the backup was taken.

Even though the Replicat process is not started immediately, once it is, it will ignore any changes that occurred before the STARTCSN (the SCN to which the target database was recovered). After that point, Replicat begins applying the backlog of changes. It may take a few hours to catch up, but once it does, replication transitions into the normal, real-time phase.

Here are the simplified technical steps in detail using an example:
 

1. Install and set up GoldenGate by deploying the software on both the source and target systems. Before configuring anything, make sure all database prerequisites are met. This includes enabling minimal supplemental logging on the source database, and using ADD TRANDATA or ADD SCHEMATRANDATA to ensure key columns in the replicated tables are logged.

• Once that’s done, you can configure the GoldenGate processes:
  • Extract and DistPath for the source database (DBNORTH)
  • Replicat for the target database (DBSOUTH)
• Start the Extract process right away. Just make sure it’s running before any long-running transactions begin because Extract only captures complete transactions.
• You can also start the DistPath process immediately.
  • Do not start the Replicat process yet — wait until the target database has been fully recovered.
     

2. Use RMAN to take a backup of the DBNORTH database. This backup will be used later to create the
   new DBSOUTH database. The backup files need to be securely transferred to the target system.

3. Use RMAN to create a duplicate of the DBNORTH database and name it DBSOUTH. This involves restoring and recovering the database using backup files from DBNORTH.
   Make sure to note the SCN (System Change Number) during the process, as it marks the exact point in time where both databases are in sync.

4. Start the Replicat process on the DBSOUTH database, making sure it starts exactly at the same SCN the database was recovered to using RMAN. Use the ATSCN option to ensure there’s no data gap during replication:

When working with large databases, RMAN is often the best solution. As you’ve seen in the previous example, using RMAN to set up GoldenGate replication is not only straightforward, but also surprisingly efficient. But here’s where it gets interesting: RMAN offers even more flexibility than you might expect. Want to speed things up? You can leverage Transportable Tablespaces (TTS). Need to exclude certain data? You can skip tablespaces, as long as your sets are self-contained. RMAN provides a variety of options. If you get creative, you can push the boundaries of what’s possible during instantiation.
The same applies to techniques like Data Guard splits or Split-Mirror-Copy methods, where a consistent snapshot of the database gives you even more flexibility and speed during setup.