Upgrading Oracle GoldenGate Classic Architecture for Oracle Database

These instructions contain the procedure for performing the minimal upgrade.

Note:

Trigger-based DDL capture has been desupported from 21c onward, so you need to upgrade to native DDL capture.

Note:

If you are using integrated capture and plan to upgrade from trigger-based DDL capture to new native DDL capture, do not remove the DDL trigger until prompted. Extract needs to mine DDL to the point where the redo COMPATIBLE level. For example, if Extract is behind by a week when the database is upgraded, Extract does not immediately switch to native DDL capture. It must be allowed to process the previous redo first, then Extract upgrades to native DDL capture automatically.

Use the following command in GGSCI to determine the oldest archive log that you might need to restore when Extract starts. The Recovery Checkpoint field shows the oldest log needed for recovery.

GGSCI> INFO EXTRACTgroup, SHOWCH

It's best to perform upgrade activities outside of the peak hours. If there are large and long running transactions, you may consider that on the source system, the new Extract might need to start processing from the normal recovery checkpoint, rather than the bounded recovery checkpoint, if the first record of the oldest open transaction at the time that you stop Extract is in a log that is not on the system.

You have two options:
- You can restore the archives back to, and including, the one shown in the recovery checkpoint shown with INFO EXTRACT.
- You can clear out the long-running transactions that apply to the Extract that you are upgrading. This can be done by skipping the transactions or by forcing them to the trail as committed transactions. Skipping a transaction may cause data loss, and forcing a transaction to the trail may add unwanted data to the trail if the transaction is rolled back. To skip or force a transaction, follow these steps:
  1. View open transactions with the following command in GGSCI. Record the transaction ID of any transaction that you want to clean up.
```
GGSCI> SEND EXTRACT group, SHOWTRANS
```
  2. Clean up old transactions with the SEND EXTRACT command, using either the SKIPTRANS option to skip a transaction or the FORCETRANS option to force a transaction in its current state to the trail as a committed transaction.
```
GGSCI> SEND EXTRACT group, {SKIPTRANS | FORCETRANS} transaction_ID [THREAD n] [FORCE]
```
  3. After you are finished cleaning up the long-running transactions, force a Bounded Recovery checkpoint.
```
GGSCI> SEND EXTRACT group, BR BRCHECKPOINT IMMEDIATE
```
    Note:
    A forced checkpoint is necessary because the skipped or forced transaction is not cleaned up from the Bounded Recovery checkpoint and will be shown if SHOWTRANS is issued again. This is a known issue. For more information about SEND EXTRACT, see Reference for Oracle GoldenGate.
(Target systems) In GGSCI, stop all Replicat processes.
```
GGSCI> STOP REPLICAT group
```
(Source and target systems) In GGSCI, stop Manager on the source and target systems.
```
GGSCI> STOP MANAGER
```
When updating target systems only, or if updating the target side before the source side, you must use STOP to stop all data pumps and any primary Extracts that write directly to those targets on any source running on this target. Any static collectors that may have been started that must be stopped, as well. To verify that there are no server processes running, use process checking shell commands, such as ps and grep.
You need to use an out-of-place upgrade, which implies that you retain the existing installation in parallel while you run the upgrade. See Install and Patch for details.
In GGSCI, start the Oracle GoldenGate processes on the source and target systems in the following order.
```
GGSCI> START MANAGER
GGSCI> START EXTRACT group
GGSCI> START EXTRACT pump
GGSCI> START REPLICAT group
```
If you need to restore any log files, Extract abends with an error that indicates the log to restore. Restore the logs back to, and including that log, and then restart Extract.

If you made copies of the parameter files to make parameter changes, move the new parameter files into the Oracle GoldenGate directory where the old parameter files were stored then rename them to the same names as the old parameter files. If you are using case-sensitivity support, ensure that you either add NOUSEANSISQLQUOTES to your parameter files, or that you ran the convprm utility to convert the quotes as required. See "Upgrade Considerations if Using Character-Set Conversion" for more information.

Upgrade Considerations for Older Oracle GoldenGate Releases

To accomodate the changes in the checkpoint table and heartbeat table, it is recommended that you upgrade the heartbeat table (source and target) and the checkpoint table (target only). If there is no change related to the objects, then the command returns with an informational message only. This step updates the table definition to add columns that support the Oracle GoldenGate 18c (18.1.0) release.
```
GGSCI> DBLOGIN USERIDALIAS [alias] | 
GGSCI> UPGRADE CHECKPOINTTABLE [owner.table]
```
In case of SQL Server and MySQL, you need to specifyc the SOURCEDB data source with DBLOGIN. See DBLOGIN command for details.

owner.table can be omitted if the checkpoint table was created with the name listed with CHECKPOINTTABLE in the GLOBALS file. If the checkpoint table is already upgraded, then this command doesn't perform any further updates.