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. Convert type-1 indexes to type-2 indexes because type-1 indexes are discontinued in DB2 Version 9.7, and later. Converting them before upgrade eliminates the overhead of index rebuild when you access tables using these indexes for the first time after upgrading to DB2 Version 10.1.

   For details, refer to Converting type-1 indexes to type-2 indexes.

5. Migrate from XML Extender. Migrate your database applications that use XML Extender to use the pureXML® feature so that they can run in DB2 Version 10.1. For details, refer to Migrating from XML Extender to pureXML.
6. 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.

7. Optional: Stop HADR on the primary and standby databases.
8. 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.
9. Back up 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.

10. 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.

11. 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 high availability disaster recovery (HADR) replication if the log files are needed to create a standby database.
12. 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.

13. 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 10.1 copy.

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

14. Linux only: Change raw devices to block devices.

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

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. Take the DB2 server offline for upgrade.

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

18. 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.