Best practices for upgrading Db2 servers

When planning your Db2 server upgrade, there are a number of best practices to consider. Review these best practices before you start your upgrade.

Review changes in existing Db2 database product functionality

Changes in existing functionality introduced in Db2 version 11.1 can potentially impact your applications, scripts, maintenance processes, and any other aspects related your Db2 server upgrade process.

Changes in existing functionality introduced in pre-Db2 version 11.1 releases can also have an impact. Review these changes and plan how to address these changes before the upgrade:

• Changed functionality in Db2 Version 9.7
• Changed functionality in Db2 Version 10.1
• Changed functionality in Db2 Version 10.5

Upgrading in a test environment allows you to learn about possible issues, evaluate the impact on your environment and find a resolution.

Perform hardware and operating system upgrades before Db2 database product upgrade

The supported UNIX, Linux® and Windows operating systems have changed in Db2 version 11.1. Review the installation requirements for Db2 database products to determine whether your operating system version is supported and if you need to upgrade your operating system before installing Db2 version 11.1. Newer versions of operating systems can also bring new hardware requirements.

Performing hardware and operating system upgrades separately from Db2 database product upgrade simplifies problem determination if you encounter upgrade difficulties. If you upgrade your software or hardware before a Db2 database product upgrade, ensure that your system is operating as expected before attempting to upgrade your Db2 database product.

If you have a Db2 version 9.7 copy on SUSE Linux Enterprise Server 10, first apply Db2 version 9.7 Fix Pack 2 or later, before you upgrade the operating system to SUSE Linux Enterprise Server 11.

Benchmark Db2 server performance

Run a number of performance tests before upgrading your Db2 server. The db2batch benchmark tool helps you to collect elapsed and CPU times for running queries. You can use this tool to develop performance tests. Record the exact environment conditions where you run your tests.

Also, keep a record of the db2expln command output for each test query. Compare the results before and after upgrade. This practice can help to identify and correct any performance degradation that might occur.

Develop or Select a recovery plan for upgrade

For recoverable databases, a database upgrade can be a recoverable operation. Depending on your environment and upgrade window, it can be possible to take advantage of this recoverability feature to reduce your overall upgrade time and minimize your downtime. This recoverability feature can impact your need for taking an offline database backup before and after the database upgrade. See Recovering through a Db2 server upgrade to know whether the feature is applicable for the databases in your environment. Your recovery plan must consider the following two scenarios:

• Reversing an upgrade or fall back from Db2 version 11.1 to a pre-version 11.1 release.
• Recovering through a database upgrade to a point in time in version 11.1.

Develop a plan to reverse an upgrade

There is no utility to reverse an upgrade or fall back from Db2 version 11.1 to a pre-Db2 version 11.1 release. See Reversing Db2 server upgrade to learn all the required steps to reverse a database upgrade.

Perform pre-upgrade tasks

There are several pre-upgrade tasks outlined in the Pre-upgrade tasks for Db2 servers topic that you should execute for a successful upgrade, such as backing up Db2 configuration parameters settings, ensure that you have enough disk free space for table spaces and log files, and verifying that databases are ready for upgrade.

Determine whether to upgrade Db2 servers or clients first

Upgrading your Db2 servers before upgrading your data server clients is the traditional approach to avoid any known restrictions and limitations such as support of new Db2 database product functionality, network protocols, and connectivity. These restrictions and limitations are not associated with Db2 Connect.

Upgrading your data server clients first requires that you manage any incompatibilities between releases. If you must upgrade your client due to a software requirement, make sure that the software supports the Db2 database product version that you are running on your Db2 server. In this case, the software manages any incompatibilities between releases. See Best practices for upgrading clients in the Db2 version 11.1 documentation for details about incompatibilities.

Upgrade database applications and routines

If you upgrade your Db2 server, you might also need to upgrade your database applications and routines to support changes for 64-bit instances, SQL stored procedures, Java™ Virtual Machine (JVM), and development software.

Review the factors that can impact your database application upgrade or routine upgrade and make any necessary changes to your database applications and routines to ensure that they run after the upgrade. See Upgrade essentials for database applications and Upgrade essentials for routines for details about the factors that can impact your database application upgrade or routine upgrade.

In an upgrade to your testing environment, you can test and verify that your database applications and routines run successfully in Db2 version 11.1 to find out if you need to upgrade them. You can also upgrade your database applications and routines before you upgrade your production environment.

Upgrading Db2 High Availability Disaster Recovery (HADR) environments

Upgrading a single partition ESE Db2 version 10.5 Fix Pack 7 or later primary and standby database to Db2 version 11.1 is now supported without having to change the database role and without needing to reinitialize HADR. For more information, see Upgrading Db2 servers in HADR environments (without standby reinitialization).

Upgrading a pureScale® Db2 Version 10.5 primary and standby database to Version 11.1 is supported without needing to reinitialize HADR, if the 10.5 Fix Pack is at the supported level. Review the FAQ technote "http://www-01.ibm.com/support/docview.wss?uid=swg21298716" for supported 10.5 Fix Pack levels. For more information, see Upgrading Db2 servers in HADR pureScale environments (without standby reinitialization).

Upgrading a Db2 version 9.7, version 10.1 or version 10.5 Fix Pack 6 or earlier primary database to version 11.1 changes the database role from primary to standard. Upgrading a Db2 version 9.7, version 10.1 or version 10.5 Fix Pack 6 or earlier standby databases to version 11.1 is not supported because these databases are in rollforward pending state. For more information, see Upgrading Db2 servers in HADR environments.

Migrating SQL replication environments

After upgrading your database servers, you can optionally migrate your SQL replication environment.

Upgrading Db2 Spatial Extender

If you had Db2 Spatial Extender installed and you upgraded your spatially enabled databases to Db2 version 11.1, see Upgrading to Db2 Spatial Extender 10.5 for upgrade details specific to Db2 Spatial Extender.

Upgrading Microsoft Cluster Server environments

In a Microsoft Cluster Server (MSCS) environment, install Db2 version 11.1 as a new copy and then run the db2iupgrade command to upgrade the MSCS instance. See Upgrading Db2 servers in Microsoft Cluster Server environments for details.

Upgrading from Query Patroller to Workload Manager

Query Patroller is discontinued. See Migrating to SQL replication Version 10.5 for details on how to migrate.