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

Last night, goldengate ctor found that the extract process on most databases in the production environment often automatically abended, and then restarted normally like nothing in a few minutes.

Analysis of ggserr. Log found:

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.
06:05:15 info OGG-00991 Oracle goldengate capture for Oracle, ets_xx7.prm: extract ets_xx7 stopped normally.
06:05:46 info OGG-01735 Oracle goldengate collector for Oracle: synchronizing./dirdat/ly002536 to disk.
06:05:46 info OGG-01735 Oracle goldengate collector for Oracle: synchronizing./dirdat/ly002536 to disk.
06:05:46 info OGG-01670 Oracle goldengate collector for Oracle: Closing./dirdat/ly002536.
06:05:46 info OGG-01669 Oracle goldengate collector for Oracle: Opening./dirdat/ly002537 (byte-1, current EOF 0 ).
06:08:58 info OGG-00975 Oracle goldengate manager for Oracle, Mgr. PRM: extract ets_xx7 starting.
06:08:58 info OGG-00965 Oracle goldengate manager for Oracle, Mgr. PRM: extract ets_xx7 restarted automatically.
06:08:58 info OGG-00992 Oracle goldengate capture for Oracle, ets_xx7.prm: extract ets_xx7 starting.
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 :.
06:08:58 warning OGG-00254 Oracle goldengate capture for Oracle, ets_xx7.prm: convertucs2clobs is a deprecated Parameter

Even more surprising is that in the production environment, no change error is reported if the table parameter specified by the extract process specifies the table list, And Schema_name is specified. * All of them report this error and the frequency is very high.

Some processes even report messages every day, and the time is fixed. In our production environment, the goldengate version is v11.2.1.0.1 and the database version is 11.2.0.3.0. In addition, almost all of our databases do not use compressed tables.

At first, the object number in the error was repeatedly searched in the database, and no such object was found. Therefore, we began to suspect whether the database generated some temporary table objects under the specific schema, resulting in extract

The process cannot normally capture and suspend. When Mgr tries to restart the extract process, these temporary objects have been deleted from the database. Metalink gives a clear answer to this question:

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: 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 wocould 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
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

In Oracle 11g R2, the temporary tables dbms_tabcomp_temp_uncmp and dbms_tabcombp_temp_cmp generated by the database cause this error. To avoid this error, you can directly use

The tableexclude parameter is used to exclude the two tables from the warehouse picking process. In Ogg v11.2.1.0.5, when this error occurs, the object name is displayed instead of the object number.

Here we may be more concerned about what dbms_tabcomp_temp_uncmp and dbms_tabcombp_temp_cmp are doing. Another article on Metalink explains this:

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.

For reprint, please indicate the source and original article links:

Http://blog.csdn.net/xiangsir/article/details/8759990