IBM Support

IC79544: RECOVERY HISTORY FILE CONTAINS THE WRONG NUMBER OF SESSIONS FOR A BACKUP WHEN IT IS RESTORED TO A NEW DATABASE

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error 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.
    

Local fix

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

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.7 fp5.                                                    *
    *                                                              *
    * There is no action needed by other customers.                *
    ****************************************************************
    

Problem conclusion

  • The error is corrected in Fixpak 5.
    

Temporary fix

Comments

APAR Information

  • APAR number

    IC79544

  • Reported component name

    DB2 FOR LUW

  • Reported component ID

    DB2FORLUW

  • Reported release

    970

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2011-10-31

  • Closed date

    2011-11-09

  • Last modified date

    2011-11-09

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    DB2 FOR LUW

  • Fixed component ID

    DB2FORLUW

Applicable component levels

  • R970 PSY

       UP



Document information

More support for: DB2 for Linux, UNIX and Windows

Software version: 9.7

Reference #: IC79544

Modified date: 09 November 2011