Reversing Db2 server upgrade

Reversing Db2 server upgrade involves creating a plan using the steps in this procedure to fall back to the Db2 release from which you upgraded your server. There is no utility to fall back to a previous release of Db2 database after upgrading your Db2 server.

Performing an upgrade in a test environment will help you identify any issues with the process and avoid having to reverse the upgrade.

Before you begin

Ensure that you have SYSADM authority, as well as root on Linux® and UNIX operating systems or Local Administrator authority on Windows operating systems.
Perform the following steps before upgrading your Db2 server:
- Review upgrade recommendations and disk space requirements.
- Take an offline or online full backup of all databases that you are going to upgrade.
- 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.
Keep your existing pre- version 11.1 copy during server upgrade. To do this, select the Install New option to create a new copy when installing version 11.1. Do not select the Work with an existing option and then choose a pre- version 11.1 copy with the upgrade action that is available on Windows operating systems.
Save all log files in the active log paths to another directory in case you want to rollforward through these log files after reversing the upgrade.
Use the db2cklog utility to determine what log files in the active log paths are from the pre- version 11.1 release. Record this information for later use if rolling forward after reversing the upgrade.

Restrictions

This procedure applies only to Db2 server upgrade. It does not include Db2 clients.
In partitioned database environments you must perform this procedure on all participating database partition servers. If you have several database partitions on a partition server, execute tasks at the database level, such as backup and restore, on each database partition.
Additional upgrade restrictions apply. Review the complete list.

Procedure

To reverse a Db2 server upgrade, you need to perform the following steps:

Log on to the Db2 server as a user with SYSADM authority.
For all recoverable databases, save all log files in the active log paths (primary and mirror if defined) in case you want to rollforward through these log files after reversing the upgrade. This is required to protect log files during the DROP DATABASE command needed in the ensuing steps in the procedure.
Drop all databases in Db2 version 11.1 by running the DROP DATABASE command.
Log on to the Db2 server as root on Linux and UNIX operating systems or a user with Local Administrator authority on Windows operating systems.
Drop your Db2 version 11.1 instances by running the db2idrop command. This command does not remove the database files; you need to drop your databases before dropping your instances.
If you upgraded your pre- version 11.1 instances to version 11.1, re-create your instances in the pre- version 11.1 by running the db2icrt. Then restore the database manager configuration parameter values for each instance using the UPDATE DATABASE MANAGER CONFIGURATION command.
For each pre- version 11.1 instance, log on to the server as the instance owner and restore your upgraded databases from a pre- version 11.1 offline full backup by running the RESTORE DATABASE command. You cannot upgrade your databases from version 11.1 to pre- version 11.1 release.

If you recreated the instances using the same instance owner they had before upgrade and you did not upgrade a database to a Db2 version 11.1 instance, the database is still in pre-Db2 version 11.1 release and you can access it by just re-cataloging it.
If you have recoverable databases and you want to rollforward through the log files you had before the upgrade, issue the ROLLFORWARD DATABASE command. Ensure that you supply the log files saved off in step 2 to the ROLLFORWARD DATABASE command. This can be done by copying the log files back in to the active log paths or by supplying the OVERFLOW LOG PATH parameter on the ROLLFORWARD DATABASE command.
- If using Db2 version 10.5 Fix Pack 7 or later, the ROLLFORWARD DATABASE command may return success or SQL2463N. Reissue the command with the STOP option to bring up the database at the end of the pre-version 11.1 release.
- If using Db2 version 10.5 Fix Pack 6 or earlier, the ROLLFORWARD DATABASE command may return success or SQL1263N. Rename the error S*.LOG log file to a .NEW extension and reissue the command. If using a multi-partition or multi-member environment, you may need to repeat the same steps for each partition or member. If using log archiving additional steps, such as manually retrieving log files to disk, may be required to ensure that the rollforward utility does not replay the log file from Db2 version 11.1.