Recovering through a Db2 server upgrade
For recoverable databases, as part of the upgrade procedure to Db2 11.1, you must develop a recovery plan in case issues arise during the upgrade or post upgrade.
- A backup image and log files from a pre-Db2 11.1 deployment.
- Log files from a Db2 11.1 deployment.
- Restore a pre-Db2 11.1 online backup image.
- Roll forward through log files created in a pre-Db2 11.1 release.
- 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 11.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 11.1, then you must reinstall Db2 11.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.
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 release.
- After the upgrade, ensure that you have valid log files for all databases taken from your Db2 11.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.
- This procedure applies only to Db2 server upgrade. 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 Db2 9.7, 10.1 or 10.5 Fix Pack 7 or earlier.
- This procedure should only be used for failures that occur after upgrading to Db2 11.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 11.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 restoring the most recent backup. For example, storage failures or data corruptions.
About this task
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:
- Moving only once to the previous release.
- Recovering all databases to the end of release.
- Moving up to Db2 11.1 once.
- 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 11.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.