Post-upgrade tasks for Db2 servers
After upgrading your Db2 servers, you should perform several post-upgrade tasks to ensure that your Db2 servers perform as expected and at their optimum level.
Perform the following post-upgrade tasks that apply to your Db2 server:
- Run the db2licm -a <license file name> command on each server you have upgraded to re-apply your Db2 license.
- If you set the diaglevel database manager configuration parameter to 3 or higher as recommended in the pre-upgrade tasks for Db2 servers, reset this parameter to the value set before the upgrade.
- Existing tables that have row compression enabled from a pre-Db2 version 11.5 database will have classic row compression enabled. If you want to use adaptive compression, it must to be enabled after the upgrade is performed. For details, see Adjusting adaptive compression settings.
- Restore the log space settings. If you changed your log space settings as recommended in the pre-upgrade tasks for Db2 servers, you can reset the logsecond and logarchmeth1 database configuration parameters to their pre-upgrade values.
- If you changed the logindexbuild database configuration parameter as optionally suggested in the pre-upgrade tasks for Db2 servers, reset the parameter to the pre-upgrade value.
- Ensure that existing libraries for your external routines remain on the original location before the upgrade, if necessary, restore these libraries from the backup that you perform in Backing up Db2 server configuration and diagnostic information.
- If you want to create incremental backups of the upgraded database, perform a full database backup. This serves as the new starting point for the incremental backups.
- Activate your database after upgrade to start your database and all necessary database services.
- Automatic storage table spaces inherit media attribute values, including overhead, device read rate and data tag attributes, from the storage group it is using by default. If upgrading to Db2 version 10.1, the existing table spaces retain their settings and the OVERHEAD and DEVICE READ RATE attributes for the storage group are set to undefined. You can set media attributes with the ALTER STOGROUP statement. For details, see Storage group attributes.
- Manage changes in Db2 server behavior. There are new registry variables, new configuration parameters, and new default values for registry variables and configuration parameters introduced in Db2 version 11.5 that can impact the behavior of Db2 server. There are also changes in physical design characteristics of databases and changes to security that also have an impact.
- If the automatic collection of statistics failed on certain system catalog tables during database upgrade, update the statistics on those system catalog tables.
- If you did not use the REBINDALL option on the UPGRADE DATABASE command, then you can rebind packages in upgraded databases to validate packages. You can also rebind these packages to use updated statistics or new index information. This step may be skipped because the system task, db2pkgrb, will be started automatically and will rebind all invalid packages when a database starts on the catalog node. See Rebinding packages in upgraded databases for details.
- Refresh the data in existing materialized
query tables by using the REFRESH TABLE statement.
Materialized query tables (MQT) on unicode databases using language aware collation, where the MQT definition involves a LIKE predicate or substring function involved in a basic predicate, need to be refreshed.
- Migrate Db2 explain tables to retain explain table information that you previously gathered.
If you obtained customized code page conversion tables from the Db2
support service, copy all of the files for those tables from the
DB2DIR/conv, where DB2OLD is the location
or version 11.1 copy
and DB2DIR is the location of your
version 11.5 copy. You do not have to copy standard code page conversion tables.
If you upgraded your existing Db2 version 10.5 or version 11.1 copy on Windows operating systems, you can restore the customized code page conversion tables that you backed up as part of the pre-upgrade tasks for Db2 servers to the DB2PATH\conv directory, where DB2PATH is the location of your Db2 version 11.5 copy.
- Upgrade existing target tables for event monitors that write to tables and to unformatted event (UE) tables by using the new EVMON_UPGRADE_TABLES procedure. For details, see Event monitor data retention from release to release.
- Verify that your Db2 server upgrade was successful. Test your applications and tools to ensure that the Db2 server is working as expected. See Verifying upgrade of Db2 servers for details.
- Back up your databases after the Db2 server upgrade is complete.
- For recoverable databases, Db2 no longer renames log files in the active log paths to the .MIG extension. Log files from previous releases are now treated like log files from the current release and regular Db2 log file management will occur. The db2cklog utility can be used to determine what log files in the active log paths are from the pre-version 11.5 release. If necessary, this can be used to assist in manual log file management.
- If you have not already done so, you must migrate your SQL Replication in order to support new LSN formats.
What to do next
- If you upgraded your existing Db2 version 10.5 or earlier copy, the database log directories will have been changed. Review the db2diag.log file which will have entries detailing the new log directories. If a user defined log directory is used, for example /usr/logpath, after upgrade the location of the log files will be /usr/logpath/NODE0000/LOGSTREAM0000. If the default database directory is being used, for example /home/db2user/db2inst/NODE0000/SQL00001/SQLOGDIR, after upgrade the location of the log files will be /home/db2user/db2inst/NODE0000/SQL00001/LOGSTREAM0000.
- If you upgraded a Db2 server running high availability disaster recovery (HADR), and during upgrade to Db2 version 11.5 the database role was changed from primary to standard, then re-initialize HADR.
- As an optional step, consider a strategy for updating statistics after version upgrades. New versions might introduce new SQL optimization, data statistics or both. To take full advantage of this, consider a strategy for updating your statistics over time. Simply relying on automatic statistics collection is one such strategy. Explicitly RUNSTATs invocation is another. However, again this is strictly optional. If the current performance and access plans meet your needs, you can skip this step.
- In general, version upgrades do not introduce additional reasons to reorganize all tables and indexes. That said, on occasion, functionality might be introduced that requires a reorganization for full exploitation. For example, new compression functionality might require a reorganization to be fully used. Considerations for reorganizing, if any, are provided with the documentation of the related new function.
At this point, you should resume all of your maintenance activities such as backing up databases and updating statistics. You should also remove any Db2 version 11.1 or earlier copies that you no longer need.