DB2 - Problem description
Problem IC79711 | Status: Closed |
SVT: COMPLETE BACKUP ENTRIES IN HISTORY FILE AFTER RESTORE OF HISTORY FILE OR COMPLETE DATABASE | |
product: | |
DB2 FOR LUW / DB2FORLUW / 950 - DB2 | |
Problem description: | |
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. | |
Problem Summary: | |
**************************************************************** * 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.5 fp9. * * * * There is no action needed by other customers. * **************************************************************** | |
Local Fix: | |
Customers who use DB2 Merge Backup should upgrade DB2 to v9.5 fixpak 9. Other customers do not need to do anything. | |
available fix packs: | |
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows | |
Solution | |
The error is corrected in Fixpak 9. | |
Workaround | |
not known / see Local fix | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 09.11.2011 07.03.2012 07.03.2012 |
Problem solved at the following versions (IBM BugInfos) | |
9.0., 9.5.FP9 | |
Problem solved according to the fixlist(s) of the following version(s) | |
9.5.0.9 |