Why LEVELID REPAIR??

Hi,

In my previous post, I mentioned about the error faced while REPAIR LEVELID. But why and when a repair of LEVELID is required.

The most common scenario where you face this issue is while restoring your data from a dump produced by ADRDSSU or if you have copied your TS using DSN1COPY.

Let's take an example. You are the owner of a Library having thousands of books with hundred's of customer. The customer comes, issues a book, reads it and then returns. Hope that doesn't makes a difference to you. But what if a customer comes, issues a book and tampers it or changes it or do some nuisances? You would love to have some automated process through which you can keep an eye on such idiots!!! That's what DB2 does in case of level ID just to ensure that no one from outside is messing with its files and correct level of data is restored when a non-DB2 restoration technique is used.

DB2 creates IX and TS datasets when a TS or IX is created. Now if any of the offline utility(without informing DB2) messes with that dataset, a flag is set alerting the user indicating that the default generated Datasets have been modified or something messy is going on and makes it unavailable to the application.

Searching more in manuals I found

"At table space close, or pseudo close, all of the table space pages are written back to disk. The header page on disk now reflects the last update to the level ID. At that time, the level ID from the header page is also written to the DB2 log and to SYSLGRNX. The next time the table space is opened for an SQL statement or utility, the level ID (HPGLEVEL) in the header page of the table space is compared to the level ID recorded in SYSLGRNX. If they are not equal, DB2 will not allow access to the table space until the condition is corrected. During a DB2 restart, the level ID recorded on the log is compared to the LEVEL ID in the header page.
Again, if they are not equal, DB2 will not allow access to the table space."

A mismatch in the LEVELID gives-:

DSNB232I UNEXPECTED DATA SET LEVEL
ID ENCOUNTERED LEVEL ID= X' xxxxxxxxxxxxx ' EXPECTED LEVEL ID= X'xxxxxxxxxxxxx

Now REPAIR LEVELID indicates that the level identifier is to be reset to a new identifier. We use LEVELID Repair to accept the use of a down-level dataset.

In brief, if you are changing a file or dataset hiding from DB2 (ADRSSU,DSN1COPY etc.) DB2 finds about it and informs the user which is rectified by using REPAIR LEVELID. You can turn off the down level detection by updating the zparm DLDFREQ to 0.

Cheers!!!

Repair Level Id Operation Disallowed

During one of my assignments of copying the data from one environment to another I faced this issue. In our site we generally use DSN1COPY Db2 offline utility to copy the data. After successful translation of OBID's and PSID's in the dataset we run the REPAIR LEVELID utility in absence of which we face 'Resource Unavailable" with reason code 00C2010D(DB2 was unable to open a required data set because an unexpected level ID was encountered).
While running the REPAIR LEVELID I came across the issue of "REAPIR LEVELID OPERATION DISALLOWED".
Displaying the corresponding DATABASE didn't help me. There were no claimers. Searching the manuals I found the possible reasons like

• The data set was in use at the time the REPAIR utility was run.
• The page set has outstanding log apply activity (an indoubt UR has interest in the page set or the page set has pages in the logical page list (LPL)).

I checked for the second option ie. –DIS DATABASE(DBNAME) SP(SPNAME) LPL ….. but to increase my efforts it gave nothing.
Then I tracked back the sequence of the process in my JCL .In the prior step, DSN1COPY was used and translations of OBID were done and then the REPAIR LEVELID was initiated. Due to some reason the Dataset was not closed as I checked in CA Insight and hence the Repair was not successful.
So I decided to REAPIR LEVELID of all the TS and it successfully completed.
So if you face similar issue 1) just check if any utility is stopped using the resource.2) Check if the corresponding dataset is open. 3) Rerun the job after some time.
Cheers!!!

Resource Unavailable Reason 00C90080 Abend S04E

"Resource Unavailable" is very common for any DBA and generally resource with "resource type" is used by another resource apart from many other reasons.The basic approach is to check for the "Resource Type" ,"Reason" and "Name" in the DSNU message in your sysout.Accordingly check for the status of the object in DB2Interactive or any other third party tool that your site uses.
You can use the comm -DIS DATABASE (DBNAME) SP(SPNAME) CLAIMERS LIMIT(2000)
Depending on your needs choose from several options present for DIS DATABASE command in DB2 Command Reference.
The Most common Resource Types are-
00000100         Database DB
00000200         Table space DB.SP
00000201         Index space DB.SP
00000202         Table space RD.DB.TS
00000210         Partition DB.SP.PT
00000220         Data set DSN

You can also check the LPL state or any restrictive state of the object by using
-DIS DATABASE (DBNAME) SP(SPNAME) LPL
-DIS DATABASE (DBNAME) SP(SPNAME) RES respectively.
The most common reason for Resource Unavailable with 00C90080 reason code  implies that your Resource is in READONLY(RO) mode and you are trying to do some update operations that needs RW access. You can simply Start the DB with Access RW and rerun your job.

Cheers !!!