How to use GoldenGate HANDLECOLLISIONS Parameter correctly?
When is the Oracle Goldengate HANDLECOLLISIONS parameter useful?
The Goldengate HANDLECOLLISIONS parameter is configured on the target database in the Replicat process to enable processing of the data when there are duplicate data integrity issues in the destination database.
There could be a number of reasons which could cause this condition.
• The table data was instantiated at a particular CSN in the destination database but the Replicat process was started at a CSN prior table load CSN. This causes an overlap.
• Duplicate data exists in the source table.
• Misconfiguration of the extract or Replicat configuration
The HANDLECOLLISIONS parameter is utilized when there is a possibility of an overlap of the trail data being applied by the Replicat process to the destaination database.
Without the use of this parameter, the Replicat will ABEND when it tries to process the inserts from the trail into the table which already has the rows (PK or unique constraint violation).
It will also ABEND when the Replicat tries updating or deleting rows which are not present in the destination tables. To overcome this normally the RBA of the trail has to be moved forward one transaction before the Replicat can be restarted and will stay running.
How do you apply rows which would normally fail on target?
To capture rows which are either duplicate INSERTS or do not exist in the destination to be updated or deleted, REPERROR can be used to record these rows into a discard file.
In the example below, the REPERROR (1403, Discard) parameter is used to identify a condition when the row the Replicat is looking for, is not present in the destination database.
Similarly, the REPERROR (0001, Discard) is raised when a duplicate INSERT is attempted but it violates a PK or unique value key as the row is already present in the table.
Replicat rep
USERID gg_user, PASSWORD XXXX,
ASSUMETARGETDEFS
DISCARDFILE /u01/app/gg/dirrpt/rep.dsc, APPEND, MEGABYTES 1024
DBOPTIONS SUPPRESSTRIGGERS
DDLOPTIONS UPDATEMETADATA, REPORT
REPERROR (0001, DISCARD)
REPERROR (1403, DISCARD)
How can we enable HANDLECOLLISIONS for only one table?
Firstly, as discussed above the Goldengate HANDLECOLLISIONS should be used only when and where necessary.
It should be removed from the Oracle Goldengate Replication configuration as soon as possible.
Secondly if it has to be enabled, it should only be done so ONLY for tables requiring this.
This can be achieved by using HANDLECOLLISION, but by listing the specific tables and then turning it off using the NOHANDLECOLLISIONS clause for the remaining tables, as shown below.
Enabling HANDLECOLLISIONS
1. Set Globally
Enable global HANDLECOLLISIONS for ALL MAP statements
HANDLECOLLISIONS
MAP vst.inventory, TARGET vst.inventory;
MAP vst.trans_hist, TARGET vst.trans_hist;
MAP vst.trans, TARGET vst.trans;
MAP vst.orders, TARGET vst.orders;
2. Set for Group of MAP Statements
Enable HANDLECOLLISIONS for some MAP statements
HANDLECOLLISIONS
MAP vst.inventory, TARGET vst.inventory;
MAP vst.trans_hist, TARGET vst.trans_hist;
NOHANDLECOLLISIONS
MAP vst.trans, TARGET vst.trans;
MAP vst.orders, TARGET vst.orders;
3.Set for Specific Tables
Enable global HANDLECOLLISIONS but disable for specific tables
HANDLECOLLISIONS
MAP vst.inventory, TARGET vst.inventory;
MAP vst.trans_hist, TARGET vst.trans_hist;
MAP vst.trans, TARGET vst.trans, NOHANDLECOLLISIONS;
MAP vst.orders, TARGET vst.orders, NOHANDLECOLLISIONS;
Don't forget to remove the HANDLECOLLISIONS parameter after the Replicat has moved past the CSN where it was abending previously.
Also make sure to restart the Replicat after the removing this parameter.
When is the Oracle Goldengate HANDLECOLLISIONS parameter useful?
The Goldengate HANDLECOLLISIONS parameter is configured on the target database in the Replicat process to enable processing of the data when there are duplicate data integrity issues in the destination database.
There could be a number of reasons which could cause this condition.
• The table data was instantiated at a particular CSN in the destination database but the Replicat process was started at a CSN prior table load CSN. This causes an overlap.
• Duplicate data exists in the source table.
• Misconfiguration of the extract or Replicat configuration
The HANDLECOLLISIONS parameter is utilized when there is a possibility of an overlap of the trail data being applied by the Replicat process to the destaination database.
Without the use of this parameter, the Replicat will ABEND when it tries to process the inserts from the trail into the table which already has the rows (PK or unique constraint violation).
It will also ABEND when the Replicat tries updating or deleting rows which are not present in the destination tables. To overcome this normally the RBA of the trail has to be moved forward one transaction before the Replicat can be restarted and will stay running.
How do you apply rows which would normally fail on target?
To capture rows which are either duplicate INSERTS or do not exist in the destination to be updated or deleted, REPERROR can be used to record these rows into a discard file.
In the example below, the REPERROR (1403, Discard) parameter is used to identify a condition when the row the Replicat is looking for, is not present in the destination database.
Similarly, the REPERROR (0001, Discard) is raised when a duplicate INSERT is attempted but it violates a PK or unique value key as the row is already present in the table.
Replicat rep
USERID gg_user, PASSWORD XXXX,
ASSUMETARGETDEFS
DISCARDFILE /u01/app/gg/dirrpt/rep.dsc, APPEND, MEGABYTES 1024
DBOPTIONS SUPPRESSTRIGGERS
DDLOPTIONS UPDATEMETADATA, REPORT
REPERROR (0001, DISCARD)
REPERROR (1403, DISCARD)
How can we enable HANDLECOLLISIONS for only one table?
Firstly, as discussed above the Goldengate HANDLECOLLISIONS should be used only when and where necessary.
It should be removed from the Oracle Goldengate Replication configuration as soon as possible.
Secondly if it has to be enabled, it should only be done so ONLY for tables requiring this.
This can be achieved by using HANDLECOLLISION, but by listing the specific tables and then turning it off using the NOHANDLECOLLISIONS clause for the remaining tables, as shown below.
Enabling HANDLECOLLISIONS
1. Set Globally
Enable global HANDLECOLLISIONS for ALL MAP statements
HANDLECOLLISIONS
MAP vst.inventory, TARGET vst.inventory;
MAP vst.trans_hist, TARGET vst.trans_hist;
MAP vst.trans, TARGET vst.trans;
MAP vst.orders, TARGET vst.orders;
2. Set for Group of MAP Statements
Enable HANDLECOLLISIONS for some MAP statements
HANDLECOLLISIONS
MAP vst.inventory, TARGET vst.inventory;
MAP vst.trans_hist, TARGET vst.trans_hist;
NOHANDLECOLLISIONS
MAP vst.trans, TARGET vst.trans;
MAP vst.orders, TARGET vst.orders;
3.Set for Specific Tables
Enable global HANDLECOLLISIONS but disable for specific tables
HANDLECOLLISIONS
MAP vst.inventory, TARGET vst.inventory;
MAP vst.trans_hist, TARGET vst.trans_hist;
MAP vst.trans, TARGET vst.trans, NOHANDLECOLLISIONS;
MAP vst.orders, TARGET vst.orders, NOHANDLECOLLISIONS;
Don't forget to remove the HANDLECOLLISIONS parameter after the Replicat has moved past the CSN where it was abending previously.
Also make sure to restart the Replicat after the removing this parameter.