orphan cdr_deltab... tables

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Pete - 02 Jul 2008 14:36 GMT

We had to "brute force" kill ER tables and rebuild awhile back (per
Informix support).

I see that there are some "orphan" cdr_deltab_xxxx tables left around
that actually "hang" dbschema when it is run on them.

My question is... can these tables be manually deleted without
crashing either the engine or ER?

Running version "Informix Dynamic Server 2000 Version 9.21.UC5XF" on
AIX 5.2. Yes, I KNOW, old version of Informix, Vendor is in process of
upgrading to ver 10.

Pete

Reply to this Message

dcruncher4@aim.com - 02 Jul 2008 14:54 GMT

>We had to "brute force" kill ER tables and rebuild awhile back (per
>Informix support).
[quoted text clipped - 8 lines]
>AIX 5.2. Yes, I KNOW, old version of Informix, Vendor is in process of
>upgrading to ver 10.

Yes you may. I have done it many times. You can always write a script
which will check the cdr_deltab with that of syscdr.deltabdef table
and see whether a row exist in that table for that cdr_deltab. if not
then it is an orphan cdr-deltab which can be deleted.

Reply to this Message

Pete - 02 Jul 2008 14:59 GMT

[snip]

Thanks Much!!!! I thought I could, but we've had so many issues with
this old version I'm just a little "gun-shy".

Pete

Reply to this Message

Madison Pruet - 02 Jul 2008 15:01 GMT

> We had to "brute force" kill ER tables and rebuild awhile back (per
> Informix support).
[quoted text clipped - 4 lines]
> My question is... can these tables be manually deleted without
> crashing either the engine or ER?

Yes - if you do it very carefully.....

In the syscdr database, you need to examine the deltabdef table. The
tabname, owner, and dbname are the names of the table that the delete
table is a shadow of. The deltabid is the number portion of the delete
tabe id. (the # part of cdr_deltab_######). The orphans can be
identified by comparing the number part of cdr_del_###### with the
deltabid within the deltabdef table. If the number is not found in the
deltabdef column, then it is an orphan and can (or rather should) be
dropped.

N.B. If you manually delete the syscdr database, then you must manually
drop the shadow delete tables as well. If this is not done, then you
can run into a 57 error when trying to add replicates later on.

> Running version "Informix Dynamic Server 2000 Version 9.21.UC5XF" on
> AIX 5.2. Yes, I KNOW, old version of Informix, Vendor is in process of
> upgrading to ver 10.
>
> Pete

Reply to this Message

Madison Pruet - 02 Jul 2008 15:04 GMT

>> We had to "brute force" kill ER tables and rebuild awhile back (per
>> Informix support).
[quoted text clipped - 19 lines]
> drop the shadow delete tables as well. If this is not done, then you
> can run into a 57 error when trying to add replicates later on.

I should have added. The prferred way to get rid of the syscdr DB is to
run cdr remove (if ER is down) or cdr delete server (if ER is running).

>> Running version "Informix Dynamic Server 2000 Version 9.21.UC5XF" on
>> AIX 5.2. Yes, I KNOW, old version of Informix, Vendor is in process of
>> upgrading to ver 10.
>>
>> Pete

Reply to this Message

Pete - 02 Jul 2008 15:49 GMT

> I should have added. The prferred way to get rid of the syscdr DB is to
> run cdr remove (if ER is down) or cdr delete server (if ER is running).
[quoted text clipped - 8 lines]
>
> - Show quoted text -

Yeah, that's the way we did it when we had to drop and rebuild it the
"correct" way, but in the case of 2/20, it actually turned out to be a
network issue where ER was all backed up due to something wrong with
the primary NPLS circuit (long story!) and since nobody (including
Informix support) could figure out what was going on so Informix had
us whack ER really "brutally"... we worked on the issue for about 14
hours when one of our other network techs was doing some unrelated
work on the network switched to the secondary circuit, and magically
everything that was still backing up after recreating all 200+
replicates immediately flowed across to the other server... if he
hadn't switched circuits we'd probably still be scratching our
heads...

thx again !

Pete

Reply to this Message