寫的很好的關於GoldenGate的文章

Oracle GoldenGate OGG 11gR2 with Oracle RDBMS – Fundamentals (PK/UK, substitute keys KEYCOLS, ADD TRANDATA, Before and After images and they how work together)

Oracle GoldenGate OGG 11gR2 with Oracle RDBMS – Fundamentals (PK/UK, substitute keys KEYCOLS, ADD TRANDATA, Before and After images and they how work together)

In this article you will have a look at some basic fundamentals related to keys, supplemental logging and before and after images related to deploying OGG for transactional data replication using Oracle RDBMS as a source and/or target database. I will cover some OGG related concepts and you will glimpse at some practical test as an illustration. The concepts covered in the article apply to both CLASSIC and INTEGRATED capture, introduced in OGG 11gR2, once the specifics and nature of each capture methods are understood and taken into account. For information related to OGG setup look at here.

The article consists of the following subsections

1. Some OGG fundamental concepts : PK/UK, KEYCOLS, ADD TRANDATA, Before and After images and they how work together
   
2. Test cases as a practical concept illustration
   

1. Some OGG fundamental concepts : PK/UK, KEYCOLS, ADD TRANDATA, Before and After images and they how work together
   

OOG 11gR2 supports classic and integrated capture methods. The integrated method was introduced in OGG 11gR2, while the classic was available since the invention of the transaction log capture methods in GG 9, prior to that was a trigger capture method. In the CLASSIC OGG capture method extract process extracts transaction changes directly from the transaction log, which in case of an Oracle RDBMS is either the redo log or the archived redo log. In the INTEGRATED OGG capture method Extract process interacts directly with a database logmining server, mining the Oracle redo logs and archive logs, to receive data changes in the form. of logical change records (LCR). Integrated capture supports more data and storage types as compared to classic. For the sake of simplicity the article will not focus on distinct operational specifics for each of the extraction methods but instead will cover the common concepts related to keys, supplemental logging, before and after images required for OGG administrator to get a transactional change from the source, identify the corresponding row on the target and apply the change on the target. For transactional data change replication from Oracle RDBMS the two change capture methods can be summarized as follows.

• CLASSIC : tranlog-> Extract
  
• INTEGRATED: tranlog->Logmining Server->Extract
  

By default OGG capture all DML operations inserts, deletes and updates and replicate it on the target. OGG parameters, (GETINSERTS/IGNOREINSERTS,GETDELETES/IGNOREDELETES,GETUPDATES/IGNOREUPDATES) can customize the processing to capture any of the above DML operation. OGG enables to convert one source operation to a different operation of the target(INSERTUPDATES,INSERTDELETES,UPDATEDELETES).

Before image refers to the values of the rows before operation, whereas after image refers to values of the rows after operation (insert, update, delete). Thus operations are as flows.

• Insert operations are always after image.
  
• Delete operations are always before image.
  
• Updates are before and after image.
  

Keys in OGG can be a PK/UK of a table or OGG designated substitute keys using KEYCOLS provided that the table column values selected guarantee uniqueness. If there are neither PK nor UK OGG uses all table columns. You might opt for a substitute keys using the KEYCOLS. See the examples in the practice test cases.

OGG relies on keys on source and target to ensure transaction data change replication. A source table and the corresponding target table must have keys. For update and delete operations OGG uses the before image value of the key from the source table to identify the respective row on the target that have the same before image value of its key. Once the row on the target is identified the operation the processing is as follows.

• If the operation is delete the target rows that match the before image from the source is deleted.
  
• If the operation is update the target rows that match the before image from the source is updated.
  
• Inserts are always after images and are inserted as is subject to PK/UK constrains.
  

By default Oracle uses so called compressed updates and logs only updates to the redo log and the required key values are not logged. In order to deploy OGG on Oracle RDBMS as a source database a supplemental logging is required to be enabled for Oracle to log keys values in addition to the changes into the redo log. Supplemental logging in Oracle RDBMS must be enabled at the following levels.

• Database level supplemental login
  
• Schema level supplemental login or Table level supplemental login
  

Database level supplemental logging is required to process updates to keys and chained rows and must be enabled with the following command.

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Schema level supplemental logging is an enhancement related to the support for DDL replication. Once the supplemental logging for a schema is enabled all present and new tables created in that schema will have their keys logged in the Oracle redo log. ADD SCHEMATRANDATA logs all valid keys to the redo log.

Table level supplemental logging is required to log the table’s key to the Oracle redo log. The ADD TRANDATA tablename command is executed to enable table-level supplemental logging of key values for use by OGG by creating supplemental log groups for the table specified as an argument. If the table has a PK/UK the key values is logged into the redo log otherwise all columns are logged. You can also use the COLS option to specify columns to log into the redo log if you will dedicate a substitute key at OGG level instead of table level using the KEYCOLS.

You can look at the OGG reference guide for more information about the commands syntax from OGG online documentation here.

You will be probably asking what to do if a target table cannot have the same PK/UK as the source due to heterogeneous environments where target table is not identical to the source table or if you do not have a PK/UK on the source and or target?

This is the cases you will look at in the practical test cases in the article.

If both source and target tables has identical keys the before image key value logged on the source uniquely identify a row on the target for update or delete.

OGG enables you to dedicate substitute keys at OGG level, not table level, using KEYCOLS argument of TABLE and MAP parameter. Table column specified with KEYCOLS and ADD TRANDATA COLS must match, that is columns specified with KEYCOLS must have logging enabled with ADD TRANDATA.

If you do not have a table key on particular column or columns you can use KEYCOLS to provide substitute keys at OGG level provided that these column values are unique. OGG treat the table as if there is a table key. When defining substitute keys using OGG KEYCOLS make sure that the before image key value logged on the source uniquely identify a row on the target for update or delete.

If table has a table key on the source but does not have a table key on the target use KEYCOLS on the target MAP in the replicat parameter file to designate OGG level key to match the table key on the source. When defining substitute keys using OGG KEYCOLS make sure that the before image key value logged on the source uniquely identify a row on the target for update or delete.

If table does not a table key on the source but does have a table key on the target use KEYCOLS on the source TABLE in the extract parameter file to designate OGG level key to match the table key on the target. When defining substitute keys using OGG KEYCOLS make sure that the before image key value logged on the source uniquely identify a row on the target for update or delete.

If both source and target tables have table level keys, but there is a mismatch between the target table level keys and source table level keys make use KEYCOLS to overwrite the keys at OGG level and ensure that the before image key value logged on the source uniquely identify a row on the target for update or delete. Make sure that the source keys are either equal or a superset of the target keys. For example if three columns are on the target key and two columns are on the source key the before images captured on the source might not uniquely identify a row on the target, thus you will need to overwrite the key on the source using KEYCOLS by adding an additional column to the keys to ensure that the before image key value logged on the source uniquely identify a row on the target for update or delete.

If both source and target tables do not have table keys construct a key on both source and target by specifying a set of columns that are unique in KEYCOLS in the TABLE parameter in the extract parameter file on the source and MAP parameter in the replicat parameter file on the target. When defining substitute keys using OGG KEYCOLS make sure that the before image key value logged on the source uniquely identify a row on the target for update or delete.

After enabling the supplemental logging at the source Oracle RDBMS the primary extract captures operations from source transactions and writes to the records in the trail. By default the record contains the following

• Only the primary key (before image) for delete operations. The key provides enough information to delete the correct target record, while restricting the amount of data that must be processed. This behavior. corresponds to setting the COMPRESSDELETES, default setting, parameter in extract parameter file. Conversely, NOCOMPRESSDELETES sends all of the columns to the trail. This becomes the default when a table definition does not include a PK/UK. If a substitute key was defined with the KEYCOLS option of TABLE, then only those columns are written to the trail, whether or not a real key was defined.
  

• Only the primary key (before image) and the changed columns (after image) of a row for update operations. This provides enough information to update the correct target record, while restricting the amount of data that must be processed. This behavior. corresponds to setting the COMPRESSUPDATES, default setting, parameter in extract parameter file. Conversely, NOCOMPRESSUPDATES sends all of the columns to the trail. This becomes the default when a table definition does not include a PK/UK. If a substitute key was defined for that table with the KEYCOLS option of the TABLE parameter, then those columns are written to the trail, whether or not a real key was defined.
  
• The whole insert record (after image)
  

The default described above behavior. is specified by IGNOREUPDATEBEFORES, default value, parameter or by not specifying GETUPDATEBEFORES. Conversely, by specifying the GETUPDATEBEFORES parameter in an extract parameter files in addition to the default behavior. the before image values of the update changes are also captured. Before images can be used wither for

• conflict resolution for bi-directional replication
  
• maintaining a transaction-history table
  

So to put it together the approach of planning an OGG deployment on Oracle RDBMS will include the following steps

• Examine the source and target tables involved in a transaction data change replication and design keys ( PK/UK – table based, substitute keys based on KEYCOLS- OGG based or mix of table based and OGG based keys) on both source and target tables.
  
• Configure Extracts, trails and Replicats for online change replication and start the Extract
  
• Perform. an initial data load in order to start transactional data replication from synchronized source and targets.
  
• Start the replicat for the change synchronization
  

In the next section you will look at practical examples of creating a substitute keys using KEYCOLS and what kind of errors you will have if you do not have keys. You will learn how OGG enable you to address some errors resulting from lack of keys.

1. Test cases as a practical concept illustration
   

Keys, whether at table level or substitution keys defined with KEYCOLS, are required at both source and target tables for the OGG to replicate properly transaction data changes, updates and deletes, from the source database to the target database. It is the key before image from the source that is used to uniquely identify a row on the target database. For information related to OGG setup look at here.

There will be two tests with tables described below:

• With default mapping between source and target tables
  

• with additional substitute keys created by using KEYCOLS
  

The test cases involve four tables, test_table, test_table1, test_table2 and test_table3 on both source and target Oracle database. The tables are defined as follows:

create table test_table(

COL1 NUMBER primary key,

COL2 VARCHAR2(50));

create table test_table1(

COL1 NUMBER ,

COL2 VARCHAR2(50));

create table test_table2(

COL1 NUMBER primary key,

COL2 VARCHAR2(50));

create table test_table3(

COL1 NUMBER ,

COL2 VARCHAR2(50));

The table summarizes the test environment, tables on source and target and the mappings between the tables.

I will create an extract extt1 and a replicat repp1 and exttrail ./dirdat/1x

GGSCI (raclinux1.gj.com) 17> add extract extt1, tranlog, begin now, threads 2

EXTRACT added.

GGSCI (raclinux1.gj.com) 18>

GGSCI (raclinux1.gj.com) 18> add rmttrail ./dirdat/1x, extract extt1, megabytes 20

RMTTRAIL added.

GGSCI (raclinux1.gj.com) 19>

GGSCI (raclinux1.gj.com) 19> add replicat rept1, exttrail ./dirdat/1x

REPLICAT added.

GGSCI (raclinux1.gj.com) 24>

GGSCI (raclinux1.gj.com) 24> start extract extt1

Sending START request to MANAGER …

EXTRACT EXTT1 starting

GGSCI (raclinux1.gj.com) 25>

GGSCI (raclinux1.gj.com) 27> info extract extt1

EXTRACT EXTT1 Last Started 2012-10-13 15:51 Status RUNNING

Checkpoint Lag 00:00:00 (updated 00:00:10 ago)

Log Read Checkpoint Oracle Redo Logs

2012-10-13 15:52:18 Thread 1, Seqno 254, RBA 17820672

SCN 0.4289972 (4289972)

Log Read Checkpoint Oracle Redo Logs

2012-10-13 15:48:49 Thread 2, Seqno 0, RBA 0

SCN 0.0 (0)

GGSCI (raclinux1.gj.com) 28> info extract extt1, detail

EXTRACT EXTT1 Last Started 2012-10-13 15:51 Status RUNNING

Checkpoint Lag 00:00:00 (updated 00:00:01 ago)

Log Read Checkpoint Oracle Redo Logs

2012-10-13 15:52:40 Thread 1, Seqno 254, RBA 17830912

SCN 0.4289992 (4289992)

Log Read Checkpoint Oracle Redo Logs

2012-10-13 15:48:49 Thread 2, Seqno 0, RBA 0

SCN 0.0 (0)

Target Extract Trails:

Remote Trail Name Seqno RBA Max MB

./dirdat/1x 0 1035 20

Extract Source Begin End

Not Available 2012-10-13 15:48 2012-10-13 15:52

Not Available * Initialized * 2012-10-13 15:48

Current directory /u02/stage_ogg112_ora11

Report file /u02/stage_ogg112_ora11/dirrpt/EXTT1.rpt

Parameter file /u02/stage_ogg112_ora11/dirprm/extt1.prm

Checkpoint file /u02/stage_ogg112_ora11/dirchk/EXTT1.cpe

Process file /u02/stage_ogg112_ora11/dirpcs/EXTT1.pce

Stdout file /u02/stage_ogg112_ora11/dirout/EXTT1.out

Error log /u02/stage_ogg112_ora11/ggserr.log

GGSCI (raclinux1.gj.com) 29>

GGSCI (raclinux1.gj.com) 5> start replicat rept1

Sending START request to MANAGER …

REPLICAT REPT1 starting

GGSCI (raclinux1.gj.com) 6> info replicat rept1

REPLICAT REPT1 Last Started 2012-10-13 15:53 Status RUNNING

Checkpoint Lag 00:00:00 (updated 00:00:04 ago)

Log Read Checkpoint File ./dirdat/1×000000

First Record RBA 1035

GGSCI (raclinux1.gj.com) 7> info replicat rept1, detail

REPLICAT REPT1 Last Started 2012-10-13 15:53 Status RUNNING

Checkpoint Lag 00:00:00 (updated 00:00:04 ago)

Log Read Checkpoint File ./dirdat/1×000000

First Record RBA 1035

Extract Source Begin End

./dirdat/1×000000 * Initialized * First Record

./dirdat/1×000000 * Initialized * First Record

Current directory /u02/stage_ogg112_ora11

Report file /u02/stage_ogg112_ora11/dirrpt/REPT1.rpt

Parameter file /u02/stage_ogg112_ora11/dirprm/rept1.prm

Checkpoint file /u02/stage_ogg112_ora11/dirchk/REPT1.cpr

Checkpoint table ddl_ogg.oggchkpt

Process file /u02/stage_ogg112_ora11/dirpcs/REPT1.pcr

Stdout file /u02/stage_ogg112_ora11/dirout/REPT1.out

Error log /u02/stage_ogg112_ora11/ggserr.log

GGSCI (raclinux1.gj.com) 8>

Issue the add trandata tablename for all four tables on the source database to prepare the source tables for OGG replication. Take a note that if there is a PK/UK only the key is logged otherwise all the columns are logged.

GGSCI (raclinux1.gj.com) 36> dblogin userid ogg_extract, password ogg_extract

Successfully logged into database.

GGSCI (raclinux1.gj.com) 37>

GGSCI (raclinux1.gj.com) 38> info trandata test.test_table

Logging of supplemental redo log data is enabled for table TEST.TEST_TABLE.

Columns supplementally logged for table TEST.TEST_TABLE: COL1.

GGSCI (raclinux1.gj.com) 39> info trandata test.test_table1

Logging of supplemental redo log data is enabled for table TEST.TEST_TABLE1.

Columns supplementally logged for table TEST.TEST_TABLE1: ALL.

GGSCI (raclinux1.gj.com) 40> info trandata test.test_table2

Logging of supplemental redo log data is enabled for table TEST.TEST_TABLE2.

Columns supplementally logged for table TEST.TEST_TABLE2: COL1.

GGSCI (raclinux1.gj.com) 41> info trandata test.test_table3

Logging of supplemental redo log data is enabled for table TEST.TEST_TABLE3.

Columns supplementally logged for table TEST.TEST_TABLE3: ALL.

GGSCI (raclinux1.gj.com) 42>

For both test the following command will be issued on the source.

insert into test.test_table values (1,’Hello world’);

insert into test.test_table1 values (1,’Hello world’);

insert into test.test_table2 values (1,’Hello world’);

insert into test.test_table3 values (1,’Hello world’);

commit;

update test_table set col2 = ‘Hello world from here’ where col1 = 1;

commit;

update test_table1 set col2 = ‘Hello world from here’ where col1 = 1;

commit;

update test_table2 set col2 = ‘Hello world from here’ where col1 = 1;

commit;

update test_table3 set col2 = ‘Hello world from here’ where col1 = 1;

commit;

update test_table set col2 = ‘Hello world’ where col1 = 1;

commit;

update test_table1 set col2 = ‘Hello world’ where col1 = 1;

commit;

update test_table2 set col2 = ‘Hello world’ where col1 = 1;

commit;

update test_table3 set col2 = ‘Hello world’ where col1 = 1;

commit;

update test_table set col2 = ‘Hello world’ where col1 = 1;

update test_table1 set col2 = ‘Hello world’ where col1 = 1;

update test_table2 set col2 = ‘Hello world’ where col1 = 1;

update test_table3 set col2 = ‘Hello world’ where col1 = 1;

commit;

delete from test.test_table;

delete from test.test_table1;

delete from test.test_table2;

delete from test.test_table3;

commit;

Test with additional substitute keys created by using KEYCOLS

Create the following parameter files for extract extt1 and replicat rept1. Note that a substitute keys are created using the KEYCOLS to match the PK.

GGSCI (raclinux1.gj.com) 48> view param extt1

extract extt1

SETENV (ORACLE_SID = “RACD1″)

tranlogoptions asmuser sys@ASM, asmpassword sys1

userid ogg_extract, password ogg_extract

rmthost raclinux1, mgrport 7809

rmttrail ./dirdat/1x

table test.test_table;

table test.test_table1, keycols(col1,col2);

table test.test_table2;

table test.test_table3, keycols(col1);

GGSCI (raclinux1.gj.com) 49>

GGSCI (raclinux1.gj.com) 239> view params rept1

replicat rept1

–reperror(-1403, IGNORE)

–reperror(DEFAULT, IGNORE)

–APPLYNOOPUPDATES

SETENV (ORACLE_SID = “RACDB1″)

userid ogg_replicat, password ogg_replicat

–handlecollisions

assumetargetdefs

discardfile ./dirrpt/rept1.dsc, purge

map test.test_table, target test.test_table;

map test.test_table1, target test.test_table1, keycols(col1,col2);

map test.test_table2, target test.test_table3, keycols(col1);

map test.test_table3, target test.test_table2;

GGSCI (raclinux1.gj.com) 240>

Start the extract extt1 and start the replicat rept1.

Make sure that both source and target tables are synchrionized.

truncate table test.test_table;

truncate table test.test_table1;

truncate table test.test_table2;

truncate table test.test_table3;

Inserts on the source are replicated successfully to the target.

insert into test.test_table values (1,’Hello world’);

insert into test.test_table1 values (1,’Hello world’);

insert into test.test_table2 values (1,’Hello world’);

insert into test.test_table3 values (1,’Hello world’);

commit;

Updates on the source are successfully replicated to the target.

update test_table set col2 = ‘Hello world from here’ where col1 = 1;

commit;

update test_table1 set col2 = ‘Hello world from here’ where col1 = 1;

commit;

update test_table2 set col2 = ‘Hello world from here’ where col1 = 1;

commit;

update test_table3 set col2 = ‘Hello world from here’ where col1 = 1;

commit;

update test_table set col2 = ‘Hello world’ where col1 = 1;

commit;

update test_table1 set col2 = ‘Hello world’ where col1 = 1;

commit;

update test_table2 set col2 = ‘Hello world’ where col1 = 1;

commit;

update test_table3 set col2 = ‘Hello world’ where col1 = 1;

commit;

update test_table set col2 = ‘Hello world’ where col1 = 1;

update test_table1 set col2 = ‘Hello world’ where col1 = 1;

update test_table2 set col2 = ‘Hello world’ where col1 = 1;

update test_table3 set col2 = ‘Hello world’ where col1 = 1;

commit;

Delete on the source are successfully replicated to the target.

delete from test.test_table;

delete from test.test_table1;

delete from test.test_table2;

delete from test.test_table3;

commit;

With keys replication works as expected.

Test with default mapping between source and target tables

Create the following parameter files for extract extt1 and replicat rept1. Take a note that I am not constructing keys with KEYCOLS.

GGSCI (raclinux1.gj.com) 7> view param extt1

extract extt1

SETENV (ORACLE_SID = “RACD1″)

tranlogoptions asmuser sys@ASM, asmpassword sys1

userid ogg_extract, password ogg_extract

rmthost raclinux1, mgrport 7809

rmttrail ./dirdat/1x

table test.test_table;

table test.test_table1;

table test.test_table2;

table test.test_table3;

GGSCI (raclinux1.gj.com) 8>

GGSCI (raclinux1.gj.com) 17> view param rept1

replicat rept1

–reperror(-1403, IGNORE)

–reperror(DEFAULT, IGNORE)

–APPLYNOOPUPDATES

SETENV (ORACLE_SID = “RACDB1″)

userid ogg_replicat, password ogg_replicat

–handlecollisions

assumetargetdefs

discardfile ./dirrpt/rept1.dsc, purge

map test.test_table, target test.test_table;

map test.test_table1, target test.test_table1;

map test.test_table2, target test.test_table3;

map test.test_table3, target test.test_table2;

GGSCI (raclinux1.gj.com) 18>

Synchronize the source and target

truncate table test.test_table;

truncate table test.test_table1;

truncate table test.test_table2;

truncate table test.test_table3;

Inserts on the source are replicated to the target.

insert into test.test_table values (1,’Hello world’);

insert into test.test_table1 values (1,’Hello world’);

insert into test.test_table2 values (1,’Hello world’);

insert into test.test_table3 values (1,’Hello world’);

commit;

Let’s perform. updates to a new value on the source tables. Take a note that the replicat abends in case of an update on a PK on the source that does not have a corresponding key on target.

update test_table set col2 = ‘Hello world from here’ where col1 = 1;

commit;

OK

update test_table1 set col2 = ‘Hello world from here’ where col1 = 1;

commit;

OK

update test_table2 set col2 = ‘Hello world from here’ where col1 = 1;

commit;

2012-10-14 14:56:48 ERROR OGG-01168 Encountered an update for target table TEST.TEST_TABLE3, which ha

s no unique key defined. KEYCOLS can be used to define a key. Use ALLOWNOOPUPDATES to process the updat

e without applying it to the target database. Use APPLYNOOPUPDATES to force the update to be applied usi

ng all columns in both the SET and WHERE clause.

update test_table3 set col2 = ‘Hello world from here’ where col1 = 1;

commit;

OK.

Let’s perform. updates to the same value on the source tables. This is called a NO OP and can be addressed as per note [ID 1144303.1] Using OGG NOALLOWNOOPUPDATES/ALLOWNOOPUPDATES Replicat Parameter and the post here. You can also look at the NOALLOWNOOPUPDATES/ALLOWNOOPUPDATES or APPLYNOOPUPDATES | NOAPPLYNOOPUPDATES parameters in the OGG reference guide here.

I opted to apply the no op by using the APPLYNOOPUPDATES in this article.

By default replicat abends if there are no keys on the target, either pk/uk or substitute keys defined with KEYCOLS. Each update operation was executed without APPLYNOOPUPDATES parameter. Once replicat abended I added the APPLYNOOPUPDATES to the replicat parameter file and restarted the replicat in case of error to apply the record. After replicat started successfully and applied the record I stopped the replicat, commented the APPLYNOOPUPDATES and restarted the replicat again.

update test_table set col2 = ‘Hello world from here’ where col1 = 1;

commit;

OK.

update test_table1 set col2 = ‘Hello world from here’ where col1 = 1;

commit;

2012-10-14 15:10:06 ERROR OGG-01168 Encountered an update for target table TEST.TEST_TABLE1, which ha

s no unique key defined. KEYCOLS can be used to define a key. Use ALLOWNOOPUPDATES to process the updat

e without applying it to the target database. Use APPLYNOOPUPDATES to force the update to be applied usi

ng all columns in both the SET and WHERE clause.

update test_table2 set col2 = ‘Hello world from here’ where col1 = 1;

commit;

2012-10-14 15:29:32 ERROR OGG-01168 Encountered an update for target table TEST.TEST_TABLE3, which ha

s no unique key defined. KEYCOLS can be used to define a key. Use ALLOWNOOPUPDATES to process the updat

e without applying it to the target database. Use APPLYNOOPUPDATES to force the update to be applied usi

ng all columns in both the SET and WHERE clause.

update test_table3 set col2 = ‘Hello world from here’ where col1 = 1;

commit;

OK.

Summary

In the article you looked at the OGG fundamentals related to Keys (PK/UK, substitute keys with KEYCOLS), supplemental logging, before and after images where OGG 11gR2 is deployed in Oracle RDBMS environment and observed some extreme cases where APPLYNOOPUPDATES/NOAPPLYNOOPUPDATES, NOALLOWNOOPUPDATES/ALLOWNOOPUPDATES parameters can prevent replicat from abending in case of lack of keys on the target database.

文章出處：

http://gjilevski.com/2012/10/15/oracle-goldengate-ogg-11gr2-with-oracle-rdbms-fundamentals-pkuk-substitute-keys-keycols-add-trandata-before-and-after-images-and-they-how-work-together/

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8520577/viewspace-766398/，如需轉載，請註明出處，否則將追究法律責任。