Pre-upgrade tasks for Db2 servers

Before you upgrade your Db2 server, review the upgrade essentials for Db2 servers, including recommendations, restrictions, and disk space requirements to identify the changes or restrictions that can affect your upgrade. You must be ready to address any issues before upgrade in order to have a successful upgrade.

Prepare for the upgrade of your Db2 servers by performing the following tasks:

1. Ensure that you have at least one free page of index space per object index to eliminate the overhead of a potential index rebuild.
   If an index root page does not have enough free space during upgrade, then the index will need to grow by one page. If a free page cannot be found in the index object, then a page will be requested from the tablespace. If the tablespace is full, then the entire index object will be marked invalid and will be rebuilt when the underlying table is accessed for the first time after upgrade.
2. If you use distributed transactions involving Db2 databases, ensure that the databases to be upgraded do not contain any indoubt transactions by using the LIST INDOUBT TRANSACTIONS command to get a list of indoubt transactions and to interactively resolve any indoubt transactions.
3. Verify that the server time has not been reset or changed, and that the times associated with the members in multi-partitioned database environments are in sync. If the server time is not verified, the upgrade might return a SQL0440N error message.
4. Verify that databases are ready for Db2 upgrade to identify any problems before the actual upgrade. You must resolve them before you proceed with the upgrade.

   Refer to Verifying that your databases are ready for upgrade.

5. Upgrade from Db2 Query Patroller to Workload Manager.
   Query Patroller is discontinued. Perform the steps in Migrating from Query Patroller to Db2 workload manager to upgrade.
6. Based on your recovery plan for upgrade, verify existing backup images or create a new backup of your databases to be able to upgrade them to a new upgraded system or restore them in the original pre-upgrade system.

   Refer to Backing up databases before or after upgrade.

7. Back up configuration and diagnostic information to have a record of your current configuration that you can compare with the configuration after the upgrade. You can also use this information to create new instances or databases using the same configuration that you had before upgrade.

   Refer to Backing up Db2 server configuration and diagnostic information.

8. For HADR environments that support upgrade without the need for standby reinitialization (single partition ESE Db2 version 10.5 Fix Pack 7 or later databases, or Db2 pureScale V10.5 Fix Pack 9 or later databases) Using high availability disaster recovery monitoring, ensure that both the primary's log shipping functionality and the standby's log replaying functionality is working correctly. In order to use the new HADR upgrade procedure without the need for standby reinitializatrion, the db2ckupgrade command and the UPGRADE DATABASE command validates that the primary's log shipping position equals the standby's log replay position. If this cannot be validated or fails, then HADR must be stopped before upgrade and re-initialized after upgrade.
9. Archive all of the Db2 log files, either for SQL replication or Q replication if the log files are needed by the Capture or Q Capture programs, or for recovery through database upgrade, or for high availability disaster recovery (HADR) replication if the log files are needed to create a standby database.
10. Review the disk space requirements to ensure that you have enough free disk space, system temporary table space and log space for the upgrade and increase table space and log file sizes if necessary.
    Depending on the number of database objects, you might require more log space to perform the upgrade.

    Refer to Disk space requirements for Db2 server upgrades and Increasing table space and log file sizes before upgrade.

11. Optional: For recoverable databases, if your recovery plan for upgrade involves a possible rollforward through upgrade, consider turning on the logindexbuild database configuration parameter. Database upgrade usually recreates indexes for catalog tables. This operation is not logged. This means that if something goes wrong post upgrade and you need to recover through database upgrade the ensuing rollforward will mark these indexes bad and on first access after the rollforward completes takes the time to recreate these indexes. If this is of a concern to your environment consider turning on logindexbuild and index recreation during upgrade is logged. This comes with a trade-off that additional log space is required. For HADR standby databases that have reads on standby enabled, turning on logindexbuild on the primary is highly advised to allow for read only connections once upgrade is completed on the standby.
12. Windows only: If you obtained customized code page conversion tables from the Db2 support service, you need to backup all of the files in the DB2OLD\conv directory where DB2OLD is the location of your existing pre-Db2 version 11.1 copy.

    You do not need to backup standard code page conversion tables. Upgrading your pre-Db2 version 11.1 copy removes these tables because standard code page tables are contained in a Db2 version 11.1 library.

13. Linux® only: Change raw devices to block devices.

    Refer to Changing raw devices to block devices (Linux).

14. Collect information to troubleshoot issues that might occur while performing an upgrade.

    Refer to Gathering pre-upgrade diagnostic information.

15. Optional: Upgrade your Db2 server in a test environment to identify upgrade issues and to verify that applications, scripts, tools and routines work as expected before upgrading your Db2 server in the production environment.

    Refer to Upgrading Db2 servers in a test environment.

16. Check the "diagnostic error capture level" using the GET DBM CFG command. If the diagnostic error capture level (set by the diaglevel parameter) is 2 or less, set the diagnostic error capture level to 3 or higher before upgrade.
17. Perform one of the following actions:
    • For Linux and UNIX operating systems, stop all Db2 processes.
    • For Windows operating systems, stop all Db2 instances, services, and applications.
18. Take the Db2 server offline for upgrade.

    Refer to Taking a Db2 server offline for upgrade or for converting to a Db2 pureScale environment.

19. Refresh the data in existing materialized query tables.
    All materialized query tables that depend on the system views are dropped during database upgrade. After upgrade you must refresh the data in existing materialized query tables by using the REFRESH TABLE statement.