OGG-01028:Object with object number 124750 is compressed. Table compression is not supported.

最近晚上通过 GoldenGate Director 发现，生产环境绝大多数数据库上的 extract 进程经常会自动 abended，过几分钟后又跟没事一样的正常重启。

分析 ggserr.log 发现：

2013-03-17 06:05:15  ERROR   OGG-01028  Oracle GoldenGate Capture for Oracle, ets_xx7.prm:  Object with object number 124750 is compressed. Table compression is not supported.
2013-03-17 06:05:15  INFO    OGG-00991  Oracle GoldenGate Capture for Oracle, ets_xx7.prm:  EXTRACT ETS_XX7 stopped normally.
2013-03-17 06:05:46  INFO    OGG-01735  Oracle GoldenGate Collector for Oracle:  Synchronizing ./dirdat/ly002536 to disk.
2013-03-17 06:05:46  INFO    OGG-01735  Oracle GoldenGate Collector for Oracle:  Synchronizing ./dirdat/ly002536 to disk.
2013-03-17 06:05:46  INFO    OGG-01670  Oracle GoldenGate Collector for Oracle:  Closing ./dirdat/ly002536.
2013-03-17 06:05:46  INFO    OGG-01669  Oracle GoldenGate Collector for Oracle:  Opening ./dirdat/ly002537 (byte -1, current EOF 0).
2013-03-17 06:08:58  INFO    OGG-00975  Oracle GoldenGate Manager for Oracle, mgr.prm:  EXTRACT ETS_XX7 starting.
2013-03-17 06:08:58  INFO    OGG-00965  Oracle GoldenGate Manager for Oracle, mgr.prm:  EXTRACT ETS_XX7 restarted automatically.
2013-03-17 06:08:58  INFO    OGG-00992  Oracle GoldenGate Capture for Oracle, ets_xx7.prm:  EXTRACT ETS_XX7 starting.
2013-03-17 06:08:58  INFO    OGG-03035  Oracle GoldenGate Capture for Oracle, ets_xx7.prm:  Operating system character set identified as ISO-8859-1. Locale: en_US, LC_ALL:.
2013-03-17 06:08:58  WARNING OGG-00254  Oracle GoldenGate Capture for Oracle, ets_xx7.prm:  CONVERTUCS2CLOBS is a deprecated parameter

更令人吃惊的是生产环境当中凡是extract 进程中 table 参数指定了 table 列表的均未报改错误，凡是指定了 schema_name.* 的全部报了该错误，而且频率还非常高

有些进程甚至每天都会报，而且时间点固定。我们的生产环境 GoldenGate 版本为 v11.2.1.0.1，数据库版本为 11.2.0.3.0，而且我们的所有数据库中几乎都不使用压缩表

一开始按照错误中的 object number 在数据库中反复查找，均未发现该对象，于是我们开始怀疑是否是数据库在具体的 schema 下生成了某些临时表对象，导致 extract

进程无法正常捕获挂起，当 mgr 尝试重启 extract 进程时这些临时对象已从数据库中删除，metalink 对于这一疑问给了明确答案：

Extract abends with the below error displaying only the object id in the error messege when the source db is Oracle 11gR2, although the source db doesnot have any compressed tables:

Eg: 2012-10-30 22:02:00 ERROR OGG-01028 Object with object number 169008 is compressed. Table compression is not supported.

When the error occurs, the extract process would not provide the object name as well to exclude it from replication.

Cause

This issue happens when the extract hits the table DBMS_TABCOMP_TEMP_UNCMP and DBMS_TABCOMBP_TEMP_CMP  when the source db is Oracle 11gR2.  Since these tables are created and dropped dynamically by Oracle, by the time we check the object ID reported in the error messege, the object ID is already gone.

Solution

 The idea is to exclude these tables from replication by doing the below:

tableexclude *.DBMS_TABCOMP_TEMP*

For the extract, to show the object names in question instead of object id, the fix will be from OGG v11.2.1.0.5

在 Oracle 11g R2 中，数据库生成的临时表 DBMS_TABCOMP_TEMP_UNCMP 和  DBMS_TABCOMBP_TEMP_CMP 导致了这一错误，要避免出现该错误，可以直接通过

tableexclude 参数在出库进程中排除这两张表。在OGG v11.2.1.0.5 中，出现该错误时，显示的不是 object number 而是 object name

这里我们可能更关心 DBMS_TABCOMP_TEMP_UNCMP 和  DBMS_TABCOMBP_TEMP_CMP 这两种表是干什么的，对此，metalink 上另一篇文章给了解释：

Streams Capture Aborting With ORA-26767 Due To Temp Tables Created By DBMS_COMPRESSION [ID 1082323.1]
DBMS_COMPRESSION is a new utility introduce in 11GR2 which is used for Compression Advisory.

DBMS_COMPRESSION creates two temporary tables (namely, 
DBMS_TABCOMP_TEMP_UNCMP & 
DBMS_TABCOMP_TEMP_CMP) 

while doing the analyze of the table in the table owner schema. These tables are compared to see what compression level can be achieved. 

By default ddl for above mentioned tables has nologging option enabled. 

Now if CAPTURE has schema level rule defined, then DDL/DML for these tables will be captured as well.Since ddl for above mentioned table has nologging option enabled., enough redo information for the capture process was not available, and hence CAPTURE failed with ORA-26767 .


转载请注明出处及原文链接：
http://blog.csdn.net/xiangsir/article/details/8759990