Recovering through a Db2 server upgrade

For recoverable databases, as part of the upgrade procedure to Db2 , you must develop a recovery plan in case issues arise during the upgrade or after the upgrade.

A database upgrade is a recoverable operation. After you upgrade, you can restore your database and roll forward to a point in time before any failure. To complete this rollforward operation, you need the following items:
  • A backup image and log files from a pre-Db2 12.1 deployment.
  • Log files from a Db2 12.1 deployment.
Db2 12.1 cannot do the following recovery actions:
  • Restore a pre-Db2 12.1 online backup image.
  • Roll forward through log files created in a pre-Db2 12.1 release.
A pre-Db2 12.1 backup image must be restored in Db2 10.5 Fix Pack 7 or later. Also, the ROLLFORWARD command must be issued from Db2 10.5 Fix Pack 7 or later. You must reinstall the previous release before the restore and rollforward operations begin. The rollforward operation replays all the log records created in the previous release until it comes to the end of release.

When the replay is complete, you can choose to do one of the following:

  • Stay in the previous release. This is also called reversing or the fall-back of upgrading. If this is the preferred option, see Reversing Db2 server upgrade.
  • Move to Db2 12.1 and continue the rollforward operation through the upgrade.

If you intend to roll forward to a point in time after the upgrade operation in Db2 12.1, then you must reinstall Db2 12.1 and continue the rollforward operation to the point in time that you want. When the rollforward operation is complete and the database is no longer in the rollfward pending state, all post-upgrade tasks should be reexamined. This is to ensure that the database is ready to accept new workloads, such as the rebinding of packages. For example, if the database configuration parameter logindexbuild was not on during the initial upgrade, or during the rollforward operation, then catalog indexes are marked bad. First connect recreates these indexes, which might create a delay before data can be accessed.

Important: Create a new online database backup when the recovery process is complete, so that you do not have to rely on this recovery procedure again.

Before you begin

  • Ensure that you have root access on Linux® and UNIX operating systems or Local Administrator authority on Windows.
  • Ensure that you have SYSADM authority.
  • Perform the following steps before you upgrade your Db2 server:
    • Review the upgrade recommendations and disk space requirements.
    • Before the upgrade, ensure that you have a valid backup image and valid log files for all databases from the previous Db2 release.
    • After the upgrade, ensure that you have valid log files for all databases from your Db212.1 instances.
    • Back up all database manager configuration parameter values for each instance and all database configuration parameter values for each database.
    • Perform other pre-upgrade tasks that apply to your environment.
Restriction:
  • This procedure applies only to Db2 server upgrades. It does not include Db2 clients.
  • This procedure is not supported in partitioned database environments. Take an offline full backup of all databases that you are going to upgrade.
  • This procedure does not work if the previous database version is earlier than Db2 10.5 Fix pack 7.
  • This procedure should only be used for failures that occur after upgrading to Db2 12.1 and before a new full database online backup completes.
  • This procedure should only be used to recover a database that has successfully been upgraded to Db2 12.1 and where user workload transactions have been performed that would be lost otherwise.
  • This procedure should only be used on a major failure that can only be recovered by restoring the most recent backup. For example, storage failures or data corruptions.

About this task

This procedure can also be used in a cold-standby system to recover a database after an upgrade, or before a new full database online backup completes. As recommended, the cold-standby system should remain at Db2 10.5 Fix Pack 7 or later until a new full database online backup completes on the main system. For this reason,you begin the recovery procedure on the cold-standby system by restoring the pre-Db2 12.1 backup.
Attention:

When only a subset of the databases require recovery, the procedure does not change. All databases take an outage while the subsets that need recovery are recovered. The steps are optimized using the following sequence:

  1. Moving only once to the previous release.
  2. Recovering all databases to the end of release.
  3. Moving up to Db2 11.5 once.
  4. Finishing the recovery for all databases.

In your previous release, the restore can consist of rebuilding a database. Be sure to choose all table spaces in the database. Choosing a subset of table spaces before rolling forward to Db2 12.1 can prevent table spaces in the restore or rollforward pending states from being recovered. Any lost table spaces must be dropped and re-created.

What to do next

Take a new full online database backup in Db2 12.1. When the backup completes and is verified, this procedure is no longer necessary.