因为在extract參数文件里使用了where语句，而where后面的的条件列又不是主键，没有为update、delete操作记录日志，因此会报1008错误。

Applies to:

Oracle GoldenGate - Version 10.0.0.1 and later

Information in this document applies to any platform.

Symptoms

 

1. I am using filter or where clause in extract parameter file and the column is not a part of primary or unique key

2.Update and delete operations are not captured and following warning message is logged to discard file and ggserr.log file

Cause

 

By default, When trandata is added, for a Oracle database supplemental logging is enabled only for primary key columns. If a column other than primary key column is used in FILTER or WHERE clause, then that column needs to be logged for update and delete operations.

By default, In OGG deletes are COMPRESSDELETES, it causes Extract to write only the primary key value to the trail, for delete operations.                                                                                             

So the column will not be logged for update or delete operations, which will make the extract discard the update/delete operations as bad records to discard file, due to missing field

For Non-Oracle databases, updates are compressed updates, it logs only key column used by extract to trail.

Solution

For Oracle database

1. Enter into ggsci

2. Stop the extract

3. Delete trandata <schema>.<table_name>

4. Add trandata <schema>.<table_name>, nokey, cols (col1, col2)

where col1 is the primary key column and col2 is the column included in filter clause.

5. Add the following parameter to extract parameter file. By default, it is compressed deletes.

NOCOMPRESSDELETES

6. Restart the extract

For Non-Oracle database (DB2 LUW,  DB2 z/OS, Teradata version 12 or later,  SQL Server, Sybase)

1. Enter into ggsci

2. Stop the extract  

     ggsci>stop extract <extract-name>

3. Add the following parameter to extract parameter file

NOCOMPRESSUPDATES

NOCOMPRESSDELETES

 

4. Restart the extract and retest the issue

Note :Upcoming updates and delete operations will work fine. The records captured so far does not have the value logged in archive log file for the column used in FILTER clause.

Also if the filter clause is used in replicat parameter file but  not in extract. The replicat may ignore those records without any warning or error messages. Solution is same as above