Catalog and Directory Inconsistencies

Bob Jeandron

Catalog and Directory Inconsistencies
Not sure if this got through, so this is a resend.

hrough several manipulations of Alter to TYPE 2 of indexes, repairs, reorgs,
quiesces and copies. There is an index out of sync with the
directory/catalog. We are getting 00C90101 when accessing data using the bad
index and 00E40317 when either recovering or checking the index. Can't drop
the index or table. Production DB2, so can't drop the tablespace, not sure if
it would work anyway. Ironic thing is that this is a test table and index.
Does anyone know a way to get rid of this bad table/index pair short of a
REPAIR DBD REBUILD?

Anyone have any experience using REPAIR DBD REBUILD? Good/Bad?


Thanks in advance.

craig patton

Re: Catalog and Directory Inconsistencies
(in response to Bob Jeandron)
Bob,

I have run the REPAIR DBD REBUILD without any ill effects and it corrected
this type of problem. Have you run CHECKINDEX or DSN1CHKR against the
index? The error messages can, possibly, be helpful in directing you to the
proper corrective action.

P.S. make sure to back up the directory and catalog PRIOR and AFTER the
REPAIR.

Craig Patton
DB2 DBA


>From: BOB JEANDRON <[login to unmask email]>
>Reply-To: DB2 Data Base Discussion List <[login to unmask email]>
>To: [login to unmask email]
>Subject: Catalog and Directory Inconsistencies
>Date: Wed, 6 Oct 1999 09:17:00 -0400
>
>Not sure if this got through, so this is a resend.
>
>hrough several manipulations of Alter to TYPE 2 of indexes, repairs,
>reorgs,
>quiesces and copies. There is an index out of sync with the
>directory/catalog. We are getting 00C90101 when accessing data using the
>bad
>index and 00E40317 when either recovering or checking the index. Can't
>drop
>the index or table. Production DB2, so can't drop the tablespace, not sure
>if
>it would work anyway. Ironic thing is that this is a test table and index.
>Does anyone know a way to get rid of this bad table/index pair short of a
>REPAIR DBD REBUILD?
>
>Anyone have any experience using REPAIR DBD REBUILD? Good/Bad?
>
>
>Thanks in advance.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

BUFF (PB) COLLINS

Re: Catalog and Directory Inconsistencies
(in response to craig patton)
Bob,
How were your indexes altered to type 2. Did you alter them and then
recover them with an OEM product? We encountered a problem similar to what
you describe when using BMC to recover the indexes. BMC put a value of
x'40' at +7F of page 0 of the index. The valid values are '00' (type 1),
x'40' and x'50'. If you determine this is your problem, you can run a
verify similar to what I list below:
//Jobcard
//*********************************************************************
//STEP1 EXEC DSNUPROC,SYSTEM=xxxx,UID='REPAIR.IDX',
// UTPROC=''
//SYSIN DD *
REPAIR OBJECT LOG YES
LOCATE INDEX index name PAGE X'000000'
VERIFY OFFSET X'7F' DATA X'40'
REPLACE OFFSET X'7F' DATA X'04'
/*

Don't know if that's what you're encountering but if so maybe this will
help.


E. A. Collins - DB2 System Support
Pacific Bell - 925/901-6304
EACOLLI@.PACBELL.COM


-----Original Message-----
From: BOB JEANDRON [mailto:[login to unmask email]
Sent: Wednesday, October 06, 1999 6:17 AM
To: [login to unmask email]
Subject: Catalog and Directory Inconsistencies
Sensitivity: Personal


Not sure if this got through, so this is a resend.

hrough several manipulations of Alter to TYPE 2 of indexes, repairs, reorgs,
quiesces and copies. There is an index out of sync with the
directory/catalog. We are getting 00C90101 when accessing data using the
bad
index and 00E40317 when either recovering or checking the index. Can't drop
the index or table. Production DB2, so can't drop the tablespace, not sure
if
it would work anyway. Ironic thing is that this is a test table and index.
Does anyone know a way to get rid of this bad table/index pair short of a
REPAIR DBD REBUILD?

Anyone have any experience using REPAIR DBD REBUILD? Good/Bad?


Thanks in advance.

David Chapman

Re: Catalog and Directory Inconsistencies
(in response to BUFF (PB) COLLINS)
Bob,

If you're sure it's the index then stop the index and deleting the
underlying dataset. If the index is stogroup defined then recover the index
to recreate it. Otherwise, for a non-stogroup defined index, create the
underlying dataset and then do the recovery.

David.


-----Original Message-----
From: BOB JEANDRON [SMTP:[login to unmask email]
Sent: Wednesday, October 06, 1999 11:17 PM
To: [login to unmask email]
Subject: Catalog and Directory Inconsistencies
Sensitivity: Personal

Not sure if this got through, so this is a resend.

hrough several manipulations of Alter to TYPE 2 of indexes, repairs, reorgs,
quiesces and copies. There is an index out of sync with the
directory/catalog. We are getting 00C90101 when accessing data using the
bad
index and 00E40317 when either recovering or checking the index. Can't drop
the index or table. Production DB2, so can't drop the tablespace, not sure
if
it would work anyway. Ironic thing is that this is a test table and index.
Does anyone know a way to get rid of this bad table/index pair short of a
REPAIR DBD REBUILD?

Anyone have any experience using REPAIR DBD REBUILD? Good/Bad?


Thanks in advance.

Leslie Pendlebury-Bowe

Re: Catalog and Directory Inconsistencies
(in response to David Chapman)
Bob
I have encountered this problem myself (infact I raised a PMR at IBM
for the very problem).

My situation was that when recovering a user defined index on the
Catalog we received the 00E40317 message.


Quick fix

Should you ever need to get around this in the event of emergency then
just create an index with a new name on the table using the same
columns, type etc - then modify the stats in sysindexes to force the
optimizer to choose that index over the problem one.

Final Solution

I worked with IBM to determine what was the root cause of it and this
determined that REPAIR DBD REBUILD would not solve it. The only
resolution was to manually fix the catalog - we were lucky in that we
did not need to do this as we were refreshing the system from our
production system a few weeks later - so we limped along until then.

I would suggest that you speak with IBM and see if they have developed
an easy way to fix the problem that you have(I would hope that would
have by now) - do you want the PMR number from when I had the problem.

regards

Leslie
Fastrack Information Systems Ltd


______________________________ Reply Separator _________________________________
Subject: Re: Catalog and Directory Inconsistencies
Author: David Chapman <[login to unmask email]> at Internet
Date: 10/7/99 2:45 PM


Bob,

If you're sure it's the index then stop the index and deleting the
underlying dataset. If the index is stogroup defined then recover the index
to recreate it. Otherwise, for a non-stogroup defined index, create the
underlying dataset and then do the recovery.

David.


-----Original Message-----
From: BOB JEANDRON [SMTP:[login to unmask email]
Sent: Wednesday, October 06, 1999 11:17 PM
To: [login to unmask email]
Subject: Catalog and Directory Inconsistencies
Sensitivity: Personal

Not sure if this got through, so this is a resend.

hrough several manipulations of Alter to TYPE 2 of indexes, repairs, reorgs,
quiesces and copies. There is an index out of sync with the
directory/catalog. We are getting 00C90101 when accessing data using the
bad
index and 00E40317 when either recovering or checking the index. Can't drop
the index or table. Production DB2, so can't drop the tablespace, not sure
if
it would work anyway. Ironic thing is that this is a test table and index.
Does anyone know a way to get rid of this bad table/index pair short of a
REPAIR DBD REBUILD?

Anyone have any experience using REPAIR DBD REBUILD? Good/Bad?


Thanks in advance.