DB2 FOR LUW / DB2FORLUW / 910 - 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.1 on Linux, Unix and Windows          * 
* platforms.                                                   * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* 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   * 
* "TRACKMOD" 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 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       * 
* instate 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 instate of "Backup in         * 
* Progress".Therefore, only if a table space has been under    * 
* the "backup in progress" state for a long time during the    * 
* backup, should you consider it's indeed being backed up.     * 
* When you see table spaces in state of "Backup in Progress"   * 
* at the beginning 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.                                    * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 UDB Version 9.1 FixPak 9 or higher levels.    * 
****************************************************************

DB2 Version 9.1 Fix Pack 9  for Linux, UNIX and Windows
 DB2 Version 9.1 Fix Pack 10  for Linux, UNIX and Windows
 DB2 Version 9.1 Fix Pack 11  for Linux, UNIX and Windows
 DB2 Version 9.1 Fix Pack 12  for Linux, UNIX and Windows
 

First fixed in DB2 UDB Version 9.1 FixPak 9.

keiner bekannt / siehe Local-Fix

Vorgänger  : APAR is sysrouted TO one or more of the following: IC65251 IC65252 
Nachfolger : 

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

17.12.2009
25.04.2010
25.04.2010

9.0.,
9.1.