Moving User Activity Back to the Primary System

This procedure does the following:

Perform these steps after the recovery of the primary system is complete.

To Recover the Source Oracle GoldenGate Environment

On the primary system, recover the Oracle GoldenGate directory from your backups.
On the primary system, run GGSCI.
On the primary system, delete the primary Extract group.
```
DELETE EXTRACT ext_1
```
On the primary system, delete the local trail.
```
DELETE EXTTRAIL local_trail_1
```
On the primary system, add the primary Extract group again, using the same name so that it matches the parameter file that you restored from backup. For documentation purposes, this group is called ext_1. This step initializes the Extract checkpoint from its state before the failure to a clean state.
```
ADD EXTRACT ext_1, {TRANLOG | INTEGRATED TRANLOG}, BEGIN time
[, THREADS n]
```
- For TRANLOG and INTEGRATED TRANLOG, see Reference for Oracle GoldenGate. INTEGRATED TRANLOG enables integrated capture for an Oracle database.
On the primary system, add the local trail again, using the same name as before. For documentation purposes, this trail is called local_trail_1.
```
ADD EXTTRAIL local_trail_1, EXTRACT ext_1
```
- For EXTRACT, specify the ext_1 group to write to this trail.
On the primary system, start the Manager process.
```
START MANAGER
```

To Copy the Database from Standby to Primary System

On the primary system, run scripts to disable triggers and cascade delete constraints.
On the standby system, start making a hot copy of the database.
On the standby system, record the time at which the copy finishes.
On the standby system, stop user access to the applications. Allow all open transactions to be completed.

To Propagate Data Changes Made During the Copy

On the primary system, start Replicat.
```
START REPLICAT rep_2
```
On the live standby system, start the data pump. This begins transmission of the accumulated user transactions from the standby to the trail on the primary system.
```
START EXTRACT pump_2
```
On the primary system, issue the INFO REPLICAT command until you see that it posted all of the data changes that users generated on the standby system during the initial load. Refer to the time that you recorded previously. For example, if the copy stopped at 12:05, make sure that change replication has posted data up to that point.
```
INFO REPLICAT rep_2
```
On the primary system, issue the following command to turn off the HANDLECOLLISIONS parameter and disable the initial-load error handling.
```
SEND REPLICAT rep_2, NOHANDLECOLLISIONS
```
On the primary system, issue the STATUS REPLICAT command until it returns "At EOF (end of file)" to confirm that Replicat applied all of the data from the trail to the database.
```
STATUS REPLICAT rep_2
```
On the live standby system, stop the data pump. This stops transmission of any user transactions from the standby to the trail on the primary system.
```
STOP EXTRACT pump_2
```
On the primary system, stop the Replicat process.
```
STOP REPLICAT rep_2
```

At this point in time, the primary and standby databases should be in a state of synchronization again.

(Optional) To Verify Synchronization

Use a compare tool, such as Oracle GoldenGate Veridata, to compare the source and standby databases for parity.
Use a repair tool, such as Oracle GoldenGate Veridata, to repair any out-of-sync conditions.

To Switch Users to the Primary System

On the primary system, run the script that grants insert, update, and delete permissions to the users of the business applications.
On the primary system, run the script that enables triggers and cascade delete constraints.
On the primary system, run the scripts that fail over the application server, start applications, and copy essential files that are not part of the replication environment.
On the primary system, start the primary Extract process.
```
START EXTRACT ext_1
```
On the primary system, allow users to access the applications.