Upgrade Goldengate

Upgrade Instructions for Oracle GoldenGate for Oracle Database 

These instructions contain steps for upgrading to Oracle GoldenGate 12.1.2 for Oracle Database. 

1. Upgrade Instruction 

To upgrade: 

1. (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. 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 EXTRACT group, SHOWCH

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: 

 a. 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 

b. 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] 

 c. 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.

2. (Source system) Stop user activity that generates both DDL and DML on objects in the Oracle GoldenGate configuration. After DDL and DML are stopped, run the following query. 

select current_scn from v$database; 

You can avoid stopping DMLs when performing the Oracle GoldenGate upgrade, but you should stop DML when there is a requirement to run some SQL, such as DDL or any other upgrade SQL scripts as specified in Step 7, 17, and 19. 

3. Record the current SCN from the query result. 

 4. (Source system, if currently using classic capture) In GGSCI on the source system, issue the SEND EXTRACT command with the LOGEND option until it shows there is no more redo data to capture. (Source system if using integrated capture) Wait for the Extract recovery checkpoint to progress past the current SCN from the query result. 

To determine whether Extract is past that SCN in its checkpoints, view the Extract report file. 

 GGSCI> SEND EXTRACT group LOGEND 

5. (Source system) In GGSCI, stop Extract and data pumps. 

 GGSCI> STOP EXTRACT group

6. (Source system if not upgrading Target) 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. Before making the changes to the extract parameter file, please take a backup of the Oracle GoldenGate parameter files on source.

 {EXTTRAIL | RMTTRAIL} file_name FORMAT RELEASE major.minor 

Where: version specifies an Oracle GoldenGate release version. major is the major version number, and minor is the minor version number, such as 11.2 or 12.1. Make certain to include the dot.

7. (Source system, if currently using trigger-based DDL capture support) Do the followings: 

 a. Run SQL*Plus and log in as a user that has sysdba privileges. 

 b. Disconnect all sessions that ever issued DDL. Otherwise the database might generate an ORA-04021 error. Make certain no DDL sessions can be started for the duration of this upgrade. 

 c. From the Oracle GoldenGate directory, run the ddl_disable script to disable the Oracle GoldenGate DDL trigger.

 d. Run the ddl_remove script to remove the Oracle GoldenGate DDL trigger and other associated objects. You are prompted for the name of the Oracle GoldenGate DDL schema. This script produces a ddl_remove_spool.txt file that logs the script output and a ddl_remove_set.txt file that logs current user environment settings for debugging. 

 e. Run the marker_remove script to remove the Oracle GoldenGate marker support system. You are prompted for the name of the Oracle GoldenGate DDL schema. This script produces a marker_remove_spool.txt file that logs the script output and a marker_remove_set.txt file for debugging. 

8. (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 

9. (Target systems) In GGSCI, stop all Replicat processes. 

 GGSCI> STOP REPLICAT group 

10. (Source and target systems) In GGSCI, stop Manager on the source and target systems.

 GGSCI> STOP MANAGER 

 11. When updating target systems only, or if updating target side before source side, BEFORE you do any work on the target, please STOP all data pumps (and any extracts that write directly to the target) on any source running on this target. There may have also been static collectors started that must be stopped as well. To verify there are no server processes running, use the processes checking commands such as ps and grep LINUX commands. 

 12. (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). You can avoid backing up the dirdat folder. 

 13. If you want to upgrade the source or target database, or both, do so at this time according to the upgrade instructions provided by Oracle for the new version. Make certain to start and mount the databases after the upgrade, but do not permit DML or DDL transactions on the objects in the Oracle GoldenGate configuration. 

 14. (Source and target systems) If you are using Oracle GoldenGate Version prior to 11.2.1, grant write permission to Install user on the existing Oracle GoldenGate directory. For example, on Unix/Linux, run the following command: $ chmod –R u+w existing_Oracle_GoldenGate_directory 

15. (Source and target systems) Install Oracle GoldenGate Version 12.1.2.0 using OUI in your existing Oracle GoldenGate directory on the source and target systems. Make certain to uncheck the Start Manager option during OUI install; otherwise this might overwrite your existing parameter files. 

16. (Target systems, if upgrading Replicat) 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 to add columns that support version 12.1.2. 

 GGSCI> DBLOGIN [{SOURCEDB} data_source]|[, database@host:port] |{USERID {/ | user id}[, PASSWORD password] [algorithm ENCRYPTKEY {keyname | DEFAULT}] |USERIDALIAS alias [DOMAIN domain]}

 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.

17. (Source system) On the source system, run the ulg.sql script as sysdba. This script converts the existing supplemental log groups to the new format required by the new software. This step is required even if you plan to use the new triggerless capture method. The script should run without error. If it does run into errors, contact Oracle Support.

18. (Source and target systems) Updates to the trail version, the checkpoint storage format, and integrated capture require that you perform the following steps:

 a. In GGSCI, alter the primary Extract process and the associated data-pump Extract processes to write to a new trail sequence number. The command should return “Rollover performed.” 

GGSCI> ALTER EXTRACT group ETROLLOVER

 b. In GGSCI, issue the INFO EXTRACT command with DETAIL for the primary Extract and the data pumps to verify the trail sequence number. 

 GGSCI> INFO EXTRACT group, DETAIL 

 c. In GGSCI, reposition the data pumps and the Replicat processes to start at the new trail sequence number. 

GGSCI> ALTER EXTRACT pump, EXTSEQNO seqno, EXTRBA RBA 

GGSCI> ALTER REPLICAT group, EXTSEQNO seqno, EXTRBA RBA 

19. (Source system, if plan to use new native DDL capture for Oracle Database 11.2.0.4 and later versions) Run the following the commands: 

 GGSCI> DBLOGIN [{SOURCEDB} data_source]|[, database@host:port] |{USERID {/ | user id}[, PASSWORD password] [algorithm ENCRYPTKEY {keyname | DEFAULT}] |USERIDALIAS alias [DOMAIN domain]} 

 GGSCI> ADD SCHEMATRANDATA schema_name 

 You should do this for all the schemas that are included in the Oracle GoldenGate replication. You may comment out the “DDLOPTIONS ADDTRANDATA, REPORT” in the existing extract parameter file.

20. (Source system, if plan to use the trigger-based DDL capture for Oracle Database) Follow the sub-steps in this step to rebuild the Oracle GoldenGate DDL trigger environment to a clean state.

a. Run SQL*Plus and log in as a user that has sysdba privileges. 

 b. Run the marker_setup script to reinstall the Oracle GoldenGate marker support system. You are prompted for the name of the Oracle GoldenGate schema. 

 c. Run the ddl_setup script. You are prompted for the name of the Oracle GoldenGate DDL schema. 

 d. Run the role_setup script to recreate the Oracle GoldenGate DDL role. 

 e. Grant the role that you created to all Oracle GoldenGate users under which the following Oracle GoldenGate processes run: Extract, Replicat, GGSCI, and Manager. You may need to make multiple grants if the processes have different user names. 

 f. Run the ddl_enable.sql script to enable the Oracle GoldenGate DDL trigger

21. You may now restore DDL and DML activity on the source database. 

22. 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.

23. 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.

You can learn more about oracle database administration: 

Pro Oracle GoldenGate for the DBA

Oracle Security Tools Installation and Configuration

Expert Oracle Exadata 

Oracle Database 12c Release 2 Real Application Clusters Handbook: Concepts, Administration, Tuning & Troubleshooting

Expert Oracle RAC 12c

==========================================================

 

Comments

Popular posts from this blog

Restart Innodb MySQL Cluster after Complete outage(All node Down)

Oracle Block Corruption - Detection and Resolution

Add or Remove a node in MySQL Innodb Cluster