DB2 FOR LUW / DB2FORLUW / 950 - DB2

If you interrupt a full backup, the subsequent 
"INCREMENTAL/INCREMENTAL DELTA" backup will scan extra table 
spaces that do NOT have eligible data for this backup. 
Normally DB2 should not scan data on these table spaces during 
"INCREMENTAL/INCREMENTAL DELTA" backup. 
However when a full backup is interrupted, DB2 wrongly sets some 
internal flags on the table spaces included in the full backup. 
As a result, DB2 believes these table spaces have eligible data 
for the subsequent "INCREMENTAL DELTA" backup. 
This problem only occurs in databases where the configuration 
parameter "TRACKMODE" is set to YES. 
 
This issue will bring a big overhead to the "INCREMENTAL DELTA" 
backup if the "extra table spaces" are large in size, as the 
scan on extra table spaces are time-consuming and totally 
unnecessary. 
 
To find out which table spaces are included in an "INCREMENTAL 
DELTA" backup, issue "list tablespaces" command when the backup 
is running to get the hexadecimal state values of the table 
spaces. 
You can then use "db2tbst" command to get the state from the 
hexadecimal state value and see which table spaces are in state 
of "Backup in Progress". 
Please note: 
Normally, at the beginning of "INCREMENTAL/INCREMENTAL DELTA" 
backup there is a short period of time during which you will see 
all table spaces are in state of "Backup in Progress". This 
because DB2 is checking some meta data on all table spaces to 
decide which of them have eligible data and will be included in 
the backup image. 
The checking on meta data will not last for long as the meta 
data is small in size. After it finishes, table spaces that do 
not have eligible data will be back to state of "Normal" and 
only table spaces that have eligible data will remain in state 
of "Backup in Progress". 
Therefore, only if a tablespace has been under the "backup in 
progress" state for a long time during the backup, should you 
consider it's indeeded being backed up. When you see table 
spaces in state of "Backup in Progress" at the beinning of 
"INCREMENTAL/INCREMENTAL DELTA" backup, they might be in stage 
of "checking on meta data". 
 
The wrong internal flags on table spaces will be changed back to 
normal after a successful backup on these spaces. And then the 
problem will be gone.

**************************************************************** 
* USERS AFFECTED:                                              * 
* All users of version 9.5 on Linux, Unix and                  * 
* Windowsplatforms.                                            * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* If you interrupt a full backup, the                          * 
* subsequent"INCREMENTAL/INCREMENTAL DELTA" backup will scan   * 
* extra tablespaces that do NOT have eligible data for this    * 
* backup.Normally DB2 should not scan data on these table      * 
* spacesduring "INCREMENTAL/INCREMENTAL DELTA" backup.However  * 
* when a full backup is interrupted, DB2 wrongly setssome      * 
* internal flags on the table spaces included in the           * 
* fullbackup. As a result, DB2 believes these table spaces     * 
* haveeligible data for the subsequent "INCREMENTAL DELTA"     * 
* backup.This problem only occurs in databases where           * 
* theconfiguration parameter "TRACKMODE" is set to YES.This    * 
* issue will bring a big overhead to the "INCREMENTALDELTA"    * 
* backup if the "extra table spaces" are large in size,as the  * 
* scan on extra table spaces are time-consuming andtotally     * 
* unnecessary.To find out which table spaces are included in   * 
* an"INCREMENTAL DELTA" backup, issue "list tablespaces"       * 
* commandwhen the backup is running to get the hexadecimal     * 
* statevalues of the table spaces.You can then use "db2tbst"   * 
* command to get the state from thehexadecimal state value and * 
* see which table spaces are instate of "Backup in             * 
* Progress".Please note:Normally, at the beginning of          * 
* "INCREMENTAL/INCREMENTALDELTA" backup there is a short       * 
* period of time during whichyou will see all table spaces are * 
* in state of "Backup inProgress". This because DB2 is         * 
* checking some meta data onall table spaces to decide which   * 
* of them have eligible dataand will be included in the backup * 
* image.The checking on meta data will not last for long as    * 
* the metadata is small in size. After it finishes, table      * 
* spaces thatdo not have eligible data will be back to state   * 
* of "Normal"and only table spaces that have eligible data     * 
* will remain instate of "Backup in Progress".Therefore, only  * 
* if a tablespace has been under the "backupin progress" state * 
* for a long time during the backup, shouldyou consider it's   * 
* indeeded being backed up. When you seetable spaces in state  * 
* of "Backup in Progress" at thebeinning of                    * 
* "INCREMENTAL/INCREMENTAL DELTA" backup, theymight be in      * 
* stage of "checking on meta data".The wrong internal flags on * 
* table spaces will be changedback to normal after a           * 
* successful backup on these spaces.And then the problem will  * 
* be gone.                                                     * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 UDB Version 9.5 FixPak 6 or higher levels.    * 
****************************************************************

DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
 

First fixed in DB2 UDB Version 9.5 FixPak 6.

keiner bekannt / siehe Local-Fix

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

21.12.2009
25.05.2010
25.05.2010

9.5.