Tuesday, March 22, 2011

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!!!

3 comments:

  1. Hi,

    I tried REPAIR LEVELID after getting 'REASON 00C2010D' during REORG. but getting below error

    DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = REPAIR.INST
    DSNUGTIS - PROCESSING SYSIN AS EBCDIC
    DSNUGUTC - REPAIR
    DSNUCBLI - LEVELID TABLESPACE DDIS01A.T2894 PART 1
    DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40404'
    CAUSE=X'00C20064'

    Please suggest

    ReplyDelete
  2. Did you try forcing the tablespace open:

    -STA DB(DBNAME) SPACE(TSNAME) ACCESS(FORCE)

    ReplyDelete