Replication: CDRDTCleaner failure messages 
Author Message
 Replication: CDRDTCleaner failure messages

What does the following message mean when found in the engine's message
file, and what needs to be done to fix it?

13:58:10  CDR CDRDTCleaner: Operation reading delete table on table
cdr_deltab_000001 failed (isam error -103).

ISAM error -103 says:

<quote>
-103    ISAM error: illegal key descriptor (too many parts or too long).

The ISAM processor has been given an invalid key descriptor. For C-ISAM
programs, review the key descriptor. Each key descriptor has a maximum
of 8 parts and 120 characters. If the error recurs, please refer to the
Appendix entitled "Trapping Errors" in your Administrator's Guide to
acquire additional diagnostics. Contact Informix Technical Support
with the diagnostic information.
</quote>

So this sounds like an internal problem, since we users aren't responsible
for the shape of the delete tables.

Columns on the cdr_deltab_000001 are

cdrserver            integer
cdrtime              integer
cust_code            char(6)
user_id              char(20)
password             char(32)
security_level       char(2)
create_date          date
private_email        char(70)
expiry_date          date
status               char(1)
fgn_id               char(6)

and the PK of the underlying table is the user_id column.



Mon, 07 Jun 2004 11:07:47 GMT
 Replication: CDRDTCleaner failure messages

Version number? Case number?

We've had problems from time to time because of the shadow columns, but I
didn't think that any of these had made it to the released product.  Please
open a case with the following:
select * from systables where tabname = "cdr_deltab_000001".  It sounds like
there is some confusion between the table definition and systables.  The two
shadow columns should not be hidden in the delete table.

Also dump the dictionary information concerning the cdr_deltab_000001.  You
can get this from
onstat -g dic cdr_deltab_000001

Quote:

> What does the following message mean when found in the engine's message
> file, and what needs to be done to fix it?

> 13:58:10  CDR CDRDTCleaner: Operation reading delete table on table
> cdr_deltab_000001 failed (isam error -103).

> ISAM error -103 says:

> <quote>
> -103    ISAM error: illegal key descriptor (too many parts or too long).

> The ISAM processor has been given an invalid key descriptor. For C-ISAM
> programs, review the key descriptor. Each key descriptor has a maximum
> of 8 parts and 120 characters. If the error recurs, please refer to the
> Appendix entitled "Trapping Errors" in your Administrator's Guide to
> acquire additional diagnostics. Contact Informix Technical Support
> with the diagnostic information.
> </quote>

> So this sounds like an internal problem, since we users aren't responsible
> for the shape of the delete tables.

> Columns on the cdr_deltab_000001 are

> cdrserver            integer
> cdrtime              integer
> cust_code            char(6)
> user_id              char(20)
> password             char(32)
> security_level       char(2)
> create_date          date
> private_email        char(70)
> expiry_date          date
> status               char(1)
> fgn_id               char(6)

> and the PK of the underlying table is the user_id column.

--
---------------------------------------------------------
Madison Pruet
Enterprise Replication Product Development
IBM Informix Dynamic Server


Mon, 07 Jun 2004 12:31:41 GMT
 Replication: CDRDTCleaner failure messages
Is the replicated table fragmented with rowids as well as CRCOLS????

Quote:

> What does the following message mean when found in the engine's message
> file, and what needs to be done to fix it?

> 13:58:10  CDR CDRDTCleaner: Operation reading delete table on table
> cdr_deltab_000001 failed (isam error -103).

> ISAM error -103 says:

> <quote>
> -103    ISAM error: illegal key descriptor (too many parts or too long).

> The ISAM processor has been given an invalid key descriptor. For C-ISAM
> programs, review the key descriptor. Each key descriptor has a maximum
> of 8 parts and 120 characters. If the error recurs, please refer to the
> Appendix entitled "Trapping Errors" in your Administrator's Guide to
> acquire additional diagnostics. Contact Informix Technical Support
> with the diagnostic information.
> </quote>

> So this sounds like an internal problem, since we users aren't responsible
> for the shape of the delete tables.

> Columns on the cdr_deltab_000001 are

> cdrserver            integer
> cdrtime              integer
> cust_code            char(6)
> user_id              char(20)
> password             char(32)
> security_level       char(2)
> create_date          date
> private_email        char(70)
> expiry_date          date
> status               char(1)
> fgn_id               char(6)

> and the PK of the underlying table is the user_id column.

--
---------------------------------------------------------
Madison Pruet
Enterprise Replication Product Development
IBM Informix Dynamic Server


Mon, 07 Jun 2004 12:37:53 GMT
 Replication: CDRDTCleaner failure messages

Quote:

> Version number? Case number?

> We've had problems from time to time because of the shadow columns, but I
> didn't think that any of these had made it to the released product.
Please
> open a case with the following:
> select * from systables where tabname = "cdr_deltab_000001".  It sounds
like
> there is some confusion between the table definition and systables.  The
two
> shadow columns should not be hidden in the delete table.

> Also dump the dictionary information concerning the cdr_deltab_000001.
You
> can get this from
> onstat -g dic cdr_deltab_000001

Thanks for the answer - I'll open a case - as the error message 103 says...

To answer question from your other reply: no fragmentation on the two tables
getting this error, therefore just the traditional rowid.

They are low volume tables with not many rows, and I just figgered out that
it's the cleanup threads right? which kick in every time the synchronising
timestamps are exchanged (please excuse my really poor explanation; i'm sure
you know what I mean).

Sorry about not giving the versions - cardinal sin.

Engine: 7.31.FD1A
Machine: SunOS minetdata 5.8 Generic_108528-12 sun4u sparc SUNW,Sun-Fire-880

Dump of the dictionary:

$ onstat -g dic cdr_deltab_000001

Informix Dynamic Server Version 7.31.FD1A   -- On-Line -- Up 1 days
05:49:04 -- 957440 Kbytes

Dictionary entry for table: cdr_deltab_000001 [hashes to list#: 10]


23068731
ddt_fextsize:   16      ddt_nextsize:   16      ddt_locklevel:  2
ddt_flag:       -2147483648     ddt_flag2:      0       ddt_ps:         0
ddt_row:        1
36ede438
ddt_altcount:   37      ddt_ncols:      11
ddt_rowsize:    153     ddt_nallidxs:   1       ddt_nindexes:   0
ddt_type:       T
ddt_nrows:      10      ddt_npused:     1       ddt_tabid:      183
ddt_majversion: 183     ddt_minversion: 2       ddt_perms:      136edec90
Table Permissions:
Userthread <adaptive> has <SU IDXAR>
Userthread <informix> has <SU IDXAR>
Userthread <public  > has <s------->
ddt_cols:       136ede838       ddt_indexes:    136ede568       ddt_uniq:
136eded58
ddt_ref:        0       ddt_check:      136edeeb8       ddt_dummytab:
136ede5d8
ddt_nopcls:     0       ddt_opcls:      0       ddt_numreftabs: 0
ddt_reftabs:    0       ddt_next:       136e48050       ddt_prev:
1361bc450
ddt_refcount:   0       ddt_frags:      0Column Descriptors:
ddc_name:       cdrserver       ddc_colno:      1       ddc_default:    0
ddc_flags:      0       ddc_type:       0       ddc_start:      0
ddc_len:        4       ddc_nunique:    0       ddc_next:       136ede898

ddc_name:       cdrtime ddc_colno:      2       ddc_default:    0
ddc_flags:      0       ddc_type:       0       ddc_start:      4
ddc_len:        4       ddc_nunique:    0       ddc_next:       136ede8f8

ddc_name:       cust_code       ddc_colno:      3       ddc_default:    0
ddc_flags:      0       ddc_type:       0       ddc_start:      8
ddc_len:        6       ddc_nunique:    0       ddc_next:       136ede958

ddc_name:       user_id ddc_colno:      4       ddc_default:    0
ddc_flags:      8388608 ddc_type:       8388608 ddc_start:      14
ddc_len:        20      ddc_nunique:    10      ddc_next:       136ede9b8

ddc_name:       password        ddc_colno:      5       ddc_default:    0
ddc_flags:      0       ddc_type:       0       ddc_start:      34
ddc_len:        32      ddc_nunique:    0       ddc_next:       136edea18

ddc_name:       security_level  ddc_colno:      6       ddc_default:    0
ddc_flags:      0       ddc_type:       0       ddc_start:      66
ddc_len:        2       ddc_nunique:    0       ddc_next:       136edea78

ddc_name:       create_date     ddc_colno:      7       ddc_default:    0
dc_flags:      0       ddc_type:       0       ddc_start:      68
ddc_len:        4       ddc_nunique:    0       ddc_next:       136edead8

ddc_name:       private_email   ddc_colno:      8       ddc_default:    0
ddc_flags:      0       ddc_type:       0       ddc_start:      72
ddc_len:        70      ddc_nunique:    0       ddc_next:       136edeb38

ddc_name:       expiry_date     ddc_colno:      9       ddc_default:    0
ddc_flags:      0       ddc_type:       0       ddc_start:      142
ddc_len:        4       ddc_nunique:    0       ddc_next:       136edeb98

ddc_name:       status  ddc_colno:      10      ddc_default:    0
ddc_flags:      0       ddc_type:       0       ddc_start:      146
ddc_len:        1       ddc_nunique:    0       ddc_next:       136edebf8

ddc_name:       fgn_id  ddc_colno:      11      ddc_default:    0
ddc_flags:      0       ddc_type:       0       ddc_start:      147
ddc_len:        6       ddc_nunique:    0       ddc_next:       0

Index Descriptors:
ddil_name:       183_83 ddil_keylen:    20      ddil_flags:     8
ddil_next:      0       ddil_colno:     { 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 }
ddil_count: 1   ddil_frags:     0
ddil_state:     D

Referential Constraints:

Unique Constraints:
ddc_constrid:   83      ddc_owner:      informix        ddc_name:
u183_83
ddc_type:       P       ddc_flags:      0       ddc_uindex:     136ede568
ddc_urefc:      0       ddc_selfrefcnt: 0
ddc_colnml:     { user_id }
ddc_state:      D

Check Constraints:
ddc_constrid:   83      ddc_owner:      informix        ddc_name:
u183_83
ddc_type:       C       ddc_flags:      32      ddc_checkexp:   136edee70
ddc_checktxt:   <nil>   ddc_txtsize:    0
ddc_colnml:     { }
ddc_state:      D

Triggers:

1 entries found.

ddt_viotid:     0
ddt_diatid:     0



Mon, 07 Jun 2004 12:54:50 GMT
 Replication: CDRDTCleaner failure messages
Forgot to put the version numbers of the pyramid:

Machine: ReliantUNIX-Y crtes 5.44 B0033 RM600 4/1024 R10000
Engine: 7.31.UC6

But I've lodged a support case and Michael Leong will be handling it and
doing all the right things.



Mon, 07 Jun 2004 14:08:51 GMT
 Replication: CDRDTCleaner failure messages
Yes - these are the threads that delete rows from the shadow delete table.

However, I'm not so much concerned about the impact of not cleaning out the
delete tables as much as the fact that the problem exists at all.

Quote:


> > Version number? Case number?

> > We've had problems from time to time because of the shadow columns, but I
> > didn't think that any of these had made it to the released product.
> Please
> > open a case with the following:
> > select * from systables where tabname = "cdr_deltab_000001".  It sounds
> like
> > there is some confusion between the table definition and systables.  The
> two
> > shadow columns should not be hidden in the delete table.

> > Also dump the dictionary information concerning the cdr_deltab_000001.
> You
> > can get this from
> > onstat -g dic cdr_deltab_000001

> Thanks for the answer - I'll open a case - as the error message 103 says...

> To answer question from your other reply: no fragmentation on the two tables
> getting this error, therefore just the traditional rowid.

> They are low volume tables with not many rows, and I just figgered out that
> it's the cleanup threads right? which kick in every time the synchronising
> timestamps are exchanged (please excuse my really poor explanation; i'm sure
> you know what I mean).

> Sorry about not giving the versions - cardinal sin.

> Engine: 7.31.FD1A
> Machine: SunOS minetdata 5.8 Generic_108528-12 sun4u sparc SUNW,Sun-Fire-880

> Dump of the dictionary:

> $ onstat -g dic cdr_deltab_000001

> Informix Dynamic Server Version 7.31.FD1A   -- On-Line -- Up 1 days
> 05:49:04 -- 957440 Kbytes

> Dictionary entry for table: cdr_deltab_000001 [hashes to list#: 10]


> 23068731
> ddt_fextsize:   16      ddt_nextsize:   16      ddt_locklevel:  2
> ddt_flag:       -2147483648     ddt_flag2:      0       ddt_ps:         0
> ddt_row:        1
> 36ede438
> ddt_altcount:   37      ddt_ncols:      11
> ddt_rowsize:    153     ddt_nallidxs:   1       ddt_nindexes:   0
> ddt_type:       T
> ddt_nrows:      10      ddt_npused:     1       ddt_tabid:      183
> ddt_majversion: 183     ddt_minversion: 2       ddt_perms:      136edec90
> Table Permissions:
> Userthread <adaptive> has <SU IDXAR>
> Userthread <informix> has <SU IDXAR>
> Userthread <public  > has <s------->
> ddt_cols:       136ede838       ddt_indexes:    136ede568       ddt_uniq:
> 136eded58
> ddt_ref:        0       ddt_check:      136edeeb8       ddt_dummytab:
> 136ede5d8
> ddt_nopcls:     0       ddt_opcls:      0       ddt_numreftabs: 0
> ddt_reftabs:    0       ddt_next:       136e48050       ddt_prev:
> 1361bc450
> ddt_refcount:   0       ddt_frags:      0Column Descriptors:
> ddc_name:       cdrserver       ddc_colno:      1       ddc_default:    0
> ddc_flags:      0       ddc_type:       0       ddc_start:      0
> ddc_len:        4       ddc_nunique:    0       ddc_next:       136ede898

> ddc_name:       cdrtime ddc_colno:      2       ddc_default:    0
> ddc_flags:      0       ddc_type:       0       ddc_start:      4
> ddc_len:        4       ddc_nunique:    0       ddc_next:       136ede8f8

> ddc_name:       cust_code       ddc_colno:      3       ddc_default:    0
> ddc_flags:      0       ddc_type:       0       ddc_start:      8
> ddc_len:        6       ddc_nunique:    0       ddc_next:       136ede958

> ddc_name:       user_id ddc_colno:      4       ddc_default:    0
> ddc_flags:      8388608 ddc_type:       8388608 ddc_start:      14
> ddc_len:        20      ddc_nunique:    10      ddc_next:       136ede9b8

> ddc_name:       password        ddc_colno:      5       ddc_default:    0
> ddc_flags:      0       ddc_type:       0       ddc_start:      34
> ddc_len:        32      ddc_nunique:    0       ddc_next:       136edea18

> ddc_name:       security_level  ddc_colno:      6       ddc_default:    0
> ddc_flags:      0       ddc_type:       0       ddc_start:      66
> ddc_len:        2       ddc_nunique:    0       ddc_next:       136edea78

> ddc_name:       create_date     ddc_colno:      7       ddc_default:    0
> dc_flags:      0       ddc_type:       0       ddc_start:      68
> ddc_len:        4       ddc_nunique:    0       ddc_next:       136edead8

> ddc_name:       private_email   ddc_colno:      8       ddc_default:    0
> ddc_flags:      0       ddc_type:       0       ddc_start:      72
> ddc_len:        70      ddc_nunique:    0       ddc_next:       136edeb38

> ddc_name:       expiry_date     ddc_colno:      9       ddc_default:    0
> ddc_flags:      0       ddc_type:       0       ddc_start:      142
> ddc_len:        4       ddc_nunique:    0       ddc_next:       136edeb98

> ddc_name:       status  ddc_colno:      10      ddc_default:    0
> ddc_flags:      0       ddc_type:       0       ddc_start:      146
> ddc_len:        1       ddc_nunique:    0       ddc_next:       136edebf8

> ddc_name:       fgn_id  ddc_colno:      11      ddc_default:    0
> ddc_flags:      0       ddc_type:       0       ddc_start:      147
> ddc_len:        6       ddc_nunique:    0       ddc_next:       0

> Index Descriptors:
> ddil_name:       183_83 ddil_keylen:    20      ddil_flags:     8
> ddil_next:      0       ddil_colno:     { 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 }
> ddil_count: 1   ddil_frags:     0
> ddil_state:     D

> Referential Constraints:

> Unique Constraints:
> ddc_constrid:   83      ddc_owner:      informix        ddc_name:
> u183_83
> ddc_type:       P       ddc_flags:      0       ddc_uindex:     136ede568
> ddc_urefc:      0       ddc_selfrefcnt: 0
> ddc_colnml:     { user_id }
> ddc_state:      D

> Check Constraints:
> ddc_constrid:   83      ddc_owner:      informix        ddc_name:
> u183_83
> ddc_type:       C       ddc_flags:      32      ddc_checkexp:   136edee70
> ddc_checktxt:   <nil>   ddc_txtsize:    0
> ddc_colnml:     { }
> ddc_state:      D

> Triggers:

> 1 entries found.

> ddt_viotid:     0
> ddt_diatid:     0

--
Madison Pruet

===========================================
Enterprise Replication Product Developement
Dallas, Texas
Informix Software
===========================================



Mon, 07 Jun 2004 20:20:22 GMT
 
 [ 6 post ] 

 Relevant Pages 

1. communication link failure message during replication

2. Replication Error: ASN0506E - Could not attach to Replication Comm Message queue

3. LogReader failure (no message)

4. Enterprise Manager "catastrophic failure" message

5. Enterprise Manager "catastrophic failure" message

6. Catastrophic Failure Message?

7. Communication Link Failure ERROR MESSAGE

8. dbrpcparam failure w/no error message

9. SQL Server Login failure messages with new database

10. 8000FFFF "Catastrophic failure" Message

11. Weird login failure message (EventID 17055)

12. How to avoid a DTS failure message?


 
Powered by phpBB® Forum Software