Upgrading Oracle GoldenGate for Heterogeneous Databases

Even though you may only be upgrading Extract or Replicat, rather than both, all processes are involved in the upgrade. All processes must be stopped in the correct order for the upgrade, regardless of which component you upgrade, and the trails must be processed until empty.

(Source and target systems) Back up the current Oracle GoldenGate installation directory on the source and target systems, and any working directories that you have installed on a shared drive in a cluster (if applicable).
(Source and target systems, as applicable) Expand the Oracle GoldenGate upgrade build into a new directory on each system (not the current Oracle GoldenGate directory). Do not create the sub-directories; just complete the steps to the point where the installation files are expanded.
Stop all user activity that generates DML and DDL on objects in your Oracle GoldenGate configuration and ensure that there are no outstanding open transactions against the database.

For SQL Server CDC Extract on a Source system, manually stop the CDC Capture job for the database.
(Source system) In GGSCI on the source system, issue the SEND EXTRACT command with the LOGEND option until it shows YES, indicating that there is no more data in the transaction log to process.

For SQL Server CDC Extract on Source system, monitor that the current read position of the Extract is no longer updating, by repeatedly running SEND EXTRACT group STATUS for a few seconds, and observe that the LSN value for the current read position is no longer updating.

GGSCI> SEND EXTRACT group LOGEND
(Source system) In GGSCI, stop Extract and data pumps.

GGSCI> STOP EXTRACT group
(Target systems) In GGSCI on each target system, issue the SEND REPLICAT command with the STATUS option until it shows a status of "At EOF" to indicate that it finished processing all of the data in the trail. This must be done on all target systems until all Replicat processes return "At EOF."

GGSCI> SEND REPLICAT group STATUS
(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 and close GGSCI.

GGSCI> STOP MANAGER
If you want to upgrade the source or target database, or both, do so at this time according to the upgrade instructions provided for that database. Ensure that you start the databases after the upgrade, but do not permit transactions on the objects in the Oracle GoldenGate configuration.
For MySQL, if you upgrade from Oracle GoldenGate 19c (19.1.0) and the database is MySQL 5.7, then no change is required. However, if you upgrade from Oracle GoldenGate 19c (19.1.0) and the database is MySQL 8.0, then you need to perform the following steps:
1. Enable logging of full metadata because it's mandatory for MySQL 8.0 and higher, regardless of DDL or DML replication. Logging of full metadata can be enabled by setting the value of MySQL server variable binlog_row_metadata to FULL inside the MySQL configuration file (my.cnf for Linux and my.ini for Windows). You need to bounce the server after changing the configuration file for the settings to take effect.
2. Run the DDL uninstall scripts to disable old DDL solutions if DDL replication was enabled previously.
  
  The script name:
  
  For Windows: ddl_install.bat
  
  For Linux: ddl_install.sh
3. To uninstall, run the following script:
  
  bash$ ./ddl_install.sh uninstall mysql userid password port
(Source and target systems) Move the expanded Oracle GoldenGate files from the new directory to your existing Oracle GoldenGate directory on the source and target systems overwriting the existing files.
(DB2 for i) Run ggos400install without arguments. For an upgrade, no arguments are necessary. However, if you change the library, the old library is left on the system until you remove it.
(Source and target systems) Start GGSCI.
(Target systems, if upgrading Replicat from version 11.2.1.0.0 or earlier only) In GGSCI on each target system, issue the following commands to upgrade the Replicat checkpoint tables on those systems. This step updates the table definition.
```
GGSCI> DBLOGIN {
        [SOURCEDB data_source] |
        [, database@host:port] |USERID {/ | userid}
        [, PASSWORD password]   
        [algorithm ENCRYPTKEY {keyname | DEFAULT}] |USERIDALIAS alias [DOMAIN domain] |
        [SYSDBA | SQLID sqlid]
        [SESSIONCHARSET character_set]}
```
GGSCI> UPGRADE CHECKPOINTTABLE [owner.table]

Note:

owner.table can be omitted if the checkpoint table was created with the name listed with CHECKPOINTTABLE in the GLOBALS file.
(SQL Server Source system) Follow the requirements for installing Oracle GoldenGate for SQL Server by reviewing the Installing on SQL Server in the Installing Oracle GoldenGate guide.
(SQL Server Classic Extract on Source system) DELETE TRANDATA against any tables previously enabled with it, including the gg_heartbeat and gg_heartbeat_seed tables if using the Oracle GoldenGate heartbeat implementation, and then ADD TRANDATA again to the tables.
```
GGSCI> DBLOGIN {[SOURCEDB data_source] | |USERID {/ | userid}[, PASSWORD password] |USERIDALIAS alias [DOMAIN domain]
GGSCI> DELETE TRANDATA schema.tablename
GGSCI> ADD TRANDATA schema.tablename
```
(SQL Server CDC Extract on Source system) Run ADD TRANDATA again on any tables previously enabled with it, including any filter table and the gg_heartbeat and gg_heartbeat_seed tables if using the Oracle GoldenGate heartbeat implementation.
```
GGSCI> DBLOGIN {[SOURCEDB data_source] | |USERID {/ | userid}[, PASSWORD password] |USERIDALIAS alias [DOMAIN domain]
GGSCI> ADD TRANDATA schema.tablename
```
(Source and target systems) From Oracle GoldenGate 19c onward, you don't need to perform explicit ETROLLOVER because Oracle GoldenGate allows Extract to write into the trail in the same format as any existing trail.
(Source system if not upgrading Extract) Add the SOURCECHARSET parameter to the Replicat parameter file. Specify the character set of the source database with this parameter.
(Source system if not upgrading Replicat) If you are not upgrading Replicat on the target systems at this time, add the following parameter to the Extract parameter file to specify the version of Oracle GoldenGate that is running on the target. This parameter causes Extract to write a version of the trail that is compatible with the older version of Replicat.
```
{EXTTRAIL | RMTTRAIL} file_name FORMAT RELEASE major.minor
```
By default, Extract writes trail file in the exact same format with existing trail file format that is written before upgrade. The FORMAT RELEASE parameter is only required if you want to write trail in a newer format than the existing one.
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, and give them the same names as the old parameter files. If using case-sensitivity support, make certain that you either added 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.

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 will abend with an error that indicates the log to restore. Restore the logs back to, and including that log, and then restart Extract.

Parent topic: Upgrading Oracle GoldenGate for Heterogeneous Databases