orphan cdr_deltab... tables
Pete found leftover "orphan" cdr_deltab_xxxx shadow delete tables (which hang dbschema) after Enterprise Replication had been force-killed and rebuilt on IDS 9.21 under AIX 5.2, and asked whether they could be dropped safely. Answer: yes. Compare the numeric part of each cdr_deltab_###### name against the deltabid column in syscdr's deltabdef table; any with no matching row are orphans and should be dropped, otherwise error 57 can occur when adding replicates later. Preferred removal of syscdr is via 'cdr remove' (ER down) or 'cdr delete server' (ER running).
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
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
>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.
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.
[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
Pete wrote:
> 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?
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
Madison Pruet wrote:
> Pete wrote:
>> 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?
>
> 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.
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
> > 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- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - 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