Down Level Recovery

(1) Level id

     在Header Page中有两个值HPGLEVEL和HPGPLEVL，HPGLEVEL存放的是当前的Level id的值(新的RBA或者LSRN)，HPGPLEVL存放的是老的Level id的值。

  

     在Physical Open Page set时，当发现HPGLEVEL与SYSLGRNX中不匹配的时候，就是down-level page sets；

 

 

     在DB2 Restart时候，不检查SYSLGRNX，因此当发现HPGLEVEL与Page Set Checkpoint Log Record中的Current Level id或者Previous Level id不匹配时，就是down-level page sets；

 

 

 

 

 

 (2) 何时会产生 down-level page sets

    DSN1COPY(无RESET)(之后需要REPAIR LEVELID)

    (LOAD REPLACE不检查LEVEL ID)

 

 

 

 

 

 

1．Create Table后

 UCTIME      START RBA      STOP  RBA     START LRSN     STOP  LRSN

13325123   23039EAE3AA0   23039EAE59AA   C4D5C7258178   C4D5C7258331

13325131   23039EB80DFD   000000000000   C4D5C7259517   000000000000

 

HPGRBRBA='C4D5C7258331'X  HPGLEVEL='C4D5C7258331'X  HPGPLEVL='000000000000'X 

 

2．DSN1COPY(OBIDXLAT,FULLCOPY)

如何从FULL IMAGECOPY中确定DBID，PSID，OBID？

使用DSN1PRNT，其中的HPGOBID为DBID+PSID，HPGROID为OBID

 

 UCTIME      START RBA      STOP  RBA     START LRSN     STOP  LRSN

13325123   23039EAE3AA0   23039EAE59AA   C4D5C7258178   C4D5C7258331

13325131   23039EB80DFD   23039ECB935F   C4D5C7259517   C4D5C7F48F79

 

HPGRBRBA='C4BC4F22640D'X  HPGLEVEL='C4BC4F22640D'X  HPGPLEVL='C4BC4BD791E7'X

 

3．REPAIR

 UCTIME      START RBA      STOP  RBA     START LRSN     STOP  LRSN 

13325123   23039EAE3AA0   23039EAE59AA   C4D5C7258178   C4D5C7258331

13325131   23039EB80DFD   23039ECB935F   C4D5C7259517   C4D5C7F48F79

 

 UCTIME      START RBA      STOP  RBA     START LRSN     STOP  LRSN 

13404396   C4D5C8E855E9   C4D5C8E855E9   C4D5C8E855E9   C4D5C8E855E9

 

HPGRBRBA='C4D5C8E855E9'X  HPGLEVEL='C4D5C8E855E9'X  HPGPLEVL='C4BC4F22640D'

ref:
http://db24zos.blogbus.com/logs/47140924.html
后记： 看到上面的东西，然后在google上，搜索了一下，还真有高人介绍这方面的东西，这里在补充一下：
在DB2restart的时候，在mstr的地址空间，经常看到如下的信息：

DSNB232I -DBXX DSNB1OPD - UNEXPECTED DATA SET LEVEL
ID ENCOUNTERED
LEVEL ID= X'C374D2DAC1CE'
EXPECTED LEVEL ID= X'C374CDCAE699'
DSN=DSN1CAT.DSNDBC.DATABASE.TABLESPACE.I001.A001

看到这个，是不是很熟悉，在继续讨论之前，我们先看看level id的相关信息：
关于level id 的更新信息？
LEVEL ID UPDATE FREQUENCY is a ZPARM used by DB2 it controls how often (in the number of checkpoints) the level ID of a set or partition is to be updated. A zero (0) disables down-level detection. 
The acceptable values, default and its name in the DSNZPxxx module is as follows 


LEVELID UPDATE FREQ Details: 
Acceptable values: 0 to 32767 
Default: 5 (checkpoints) 
DSNTIPB DSNZPxxx: DSN6SYSP DLDFREQ 
下面讨论一下WHY ?
Why we need down-level detection or LEVEL ID update? 
Way back around DB2 V4, many customers were coming up with more and more ways to make backups of data. For example, at the time, a lot of users were turning to processes like DFDSS's concurrent copy, full pack backups etc. Somehow DB2 had to make sure that regardless of the method used to backup the data, a mechanism was in place that could make sure the correct level of data was restored when a non-DB2 restoration technique was used. 
那什么是level id？
What is down-level detection? 
DB2 Version 4 provided that mechanism with down level page detection. Before explaining how this was implemented, let's take a look at the problem. At one DB2 shop a full pack backup is taken at the end of day one. Day two is then just a normal day with end users making modifications to their DB2 data and maybe even running some utilities like LOAD or REORG. Sometime during day three a disk error occurs. In the case a disk analyst is called in rather than the DB2 DBA. The disk person notices that a full pack backup exists for the volume and uses it to correct the device error. When the users come on-line later on day three, their data looks the same as it did on day one. All work performed on day two has been lost. 
解决上面问题的方法就是我们的level ID？
What did DB2 Version 4 do to help prevent this from happening? 
V4 introduced the DSNZPARM parameter DLDFREQ on the macro DSN6SYSP (or "LEVELID UPDATE FREQ" on installation panel DSNTIPL) that allows you to set the update interval of the level ID used in determining down level page detection. The fields in the data (including individual partitions), index and LOB page set header pages are HPGLEVEL (the current level ID value) and HPGPLVL (the previous level ID value). By default, this interval is set to update the level ID every 5 checkpoints but can be in the range of 0 to 32767. If DLDFREQ is set to 0 (zero) page set down level detection is disabled. At each interval, the level ID is updated with the current RBA or the current LRSN if data sharing has been enabled. 
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.
上面这段话，其实就是对图1 的解释了
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. Restart could use the previous level ID (HPGPLVL) because restart assumes the current level ID was not successfully written because of system failure. 
上面这段话，其实就是对图1 的解释

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.

下面我们讨论我们开始的例子：
DSNB232I -DBXX DSNB1OPD - UNEXPECTED DATA SET LEVEL 
ID ENCOUNTERED 
LEVEL ID= X'C374D2DAC1CE' 
EXPECTED LEVEL ID= X'C374CDCAE699' 
DSN=DSN1CAT.DSNDBC.DATABASE.TABLESPACE.I001.A001 

从DSNB232I的信息，可以看出，通过DSN1PRINT，我们可以看出tablespace的 current level id，
然后同SYSLGRNX的进行对比
From the above DSNB232I message we can conclude that the actual data in the Tablespace is good but there is something wrong with the SYSLGRNX and it is at the DOWN LEVEL. We can confirm this by running DSN1PRNT of the header page for that particular TABLESPACE reported by DSNB232I message. 
//PRINT EXEC PGM=DSN1PRNT,PARM='FORMAT,PRINT(0)' 
//SYSPRINT DD SYSOUT=*,OUTLIM=1000 
//SYSUT1 DD DISP=SHR,DSN=DSN1CAT.DSNDBC.DATABASE.TABLESPACE.I001.A001 

The output gives us the HPGLEVEL and this should be equal to the encountered LEVELID. Now, since we have concluded that it is a fake DLD and it is only the SYSLGRNX which is at a lower level, we have to find a way to get rid of this issue and restore the normal SQL operations on the data in those TABLESPACES. We know that the ZPARM DLDFREQ is the one which tells DB2 to check whether the data is at the appropriate level or not. To get rid of the issue TURN OFF the DLD i.e set DLDFREQ to 0 (Go for this option if you are not sure of the root cause of the DLD issue like there was no RECOVERY done on SYSLGRNX to a prior point which might have caused this issue). 

This will allow the normal SQL operations on the data. Now take image copies of all the TABLESPACes that you found in the DSNB232I messages in the MSTR log. Taking image copy updates the SYSLGRNX entries for those TABLESPACEs. After ensuring that the imagecopies are run for all these TABLESPACes turn on the DLD i.e change the ZPARM DLDFREQ back to its previous value. 

If the encountered LEVELID is lesser than the expected LEVELID then it is a genuine LEVELID issue and it can corrected by choosing one of the following options 
1. RECOVER 
2. LOAD 
3. REPAIR LEVELID (use this if you are left with no other option) 
4. LOAD REPLACE 
解决level id不一致的方法：
There are a few utilities that avoid down level page detection. They are RECOVER, LOAD, REPAIR, and DSN1PRNT. RECOVER or LOAD REPLACE should be used to correct the problem. If necessary (you have no other choice), REPAIR can be used to modify the level ID in the table space header page as a last resort. 
ref:
http://it.toolbox.com/blogs/db2-dba-diary/downlevel-detection-dldfreq-part-2-35120
http://it.toolbox.com/blogs/db2-dba-diary/down-level-detection-what-is-it-how-does-db2-handle-it-dldfreq-34940
http://it.toolbox.com/blogs/db2zos/down-level-page-detection-dsnzparm-dldfreq-22558