DB2 FOR LUW / DB2FORLUW / 970 - DB2

There are some cicrumstances in which the recovery history entry 
for a backup indicates that the 
backup contains fewer backup sequences than it really has.  This 
is typically not a problem in practice, 
since DB2 will be able to correctly recover the database even in 
the presence of these incomplete 
recovery history file entries. 
. 
Customers who use the DB2 Merge Backup tool may encounter rare 
circumstances in which the tool 
is unable to generate merged backup images when it encounters 
incorrect recovery history 
entries. 
. 
Here is a typical scenario. 
. 
db2start 
db2 create db foo 
db2 update db cfg for foo using logarchmeth1 logretain 
db2 backup db foo to /dev/null 
db2 backup db foo online use tsm 
db2 list history all for foo 
--> There will be two entries for the latest backup 
db2 restore db foo history file use tsm 
db2 list history all for foo 
--> There will be one entry for the latest backup 
. 
You can get the same result if you replace the last two commands 
with 
db2 drop db foo 
db2 restore db foo 
db2 list history all for foo 
--> There will be one entry for the latest backup 
. 
What's going on here is that when a user restores a database (or 
just the history 
file from a database) DB2 will verify that the history has an 
entry for the backup being 
restored. If it doesn't exist, DB2 will (re)create the entry 
from the information that 
it has available. The problem is that DB2 doesnt have all the 
information at restore 
time that it had at backup time, so a Backup entry in the 
history file that's created 
at restore time could be missing some important information. In 
particular, DB2 won't 
necessarily know the number of sessions that are in the backup. 
It knows the 
value that was specified on the original BACKUP command ("... 
open 4 sessions") 
but in some cases the backup will have more than that. 
. 
The most common example of this is that an online backup to TSM 
will have one more 
session than was requested on the BACKUP command. (This is a 
result of the way 
that TSM handles timeouts. DB2 has to close the TSM session 
after sending the data 
and before sending the logs and LFH because there are cases 
where TSM will drop the 
connection and cause the backup to fail.) There are a few other 
situations where a 
backup to disk will have more sessions than were requested but 
these cases are 
quite rare these days.

**************************************************************** 
* USERS AFFECTED:                                              * 
* All DB2 LUW platforms.  The error will only lead to customer * 
* problems when using DB2 Merge Backup.                        * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* The user restores a database backup into a new database and  * 
* then uses DB2 Merge Backup tool to create a merged backup.   * 
* Merge Backup fails with an error such as                     * 
* .                                                            * 
* MBKB036E [<hostname>] [0] Error during the creation of the   * 
* partition 0 backup image taken at <timestamp> (type <backup  * 
* type>, device TSM)                                           * 
* .                                                            * 
* with system-appropriate values replacing <hostname>,         * 
* <timestamp> and <backup type>).  This failure is caused by   * 
* errors in the database recovery file, introduced when the    * 
* backup was restored into a new database.                     * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Customers who use DB2 Merge Backup should upgrade to DB2     * 
* v9.7 fp5.                                                    * 
*                                                              * 
* There is no action needed by other customers.                * 
****************************************************************

Customers who use DB2 Merge Backup should upgrade DB2 to v9.7 
fixpak 5.  Other customers do not 
need to do anything.

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

The error is corrected in Fixpak 5.

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

31.10.2011
09.11.2011
09.11.2011

9.7.FP5