DB2 Version 10.1 for Linux, UNIX, and Windows

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.

Procedure

Perform the following post-upgrade tasks that apply to your DB2 server:

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 10.1 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.
Adjust the log space size. If you changed your log space setting as recommended in the pre-upgrade tasks for DB2 servers, reset the logfilsiz, logprimary, and logsecond database configuration parameters to their pre-upgrade values. Ensure that the amount of log space that you allocate is adequate for your DB2 server.
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.
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. After 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 10.1 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.
Rebind packages in upgraded databases. If you did not use the REBINDALL option on the UPGRADE DATABASE command then rebind packages in upgraded databases to validate packages and to use updated statistics or new index information.
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 have tables with XML columns that you created in a DB2 Version 9.5 release, convert the XML storage object to the DB2 Version 10.1 format by recreating these tables to have access to new functions such as compression on XML data and collection of statistics to estimate the inline length for XML columns.
If you obtained customized code page conversion tables from the DB2 support service, copy all of the files for those tables from the DB2OLD/conv to DB2DIR/conv, where DB2OLD is the location of your DB2 Version 9.5, or Version 9.7 copy and DB2DIR is the location of your DB2 Version 10.1 copy. You do not have to copy standard code page conversion tables.
If you upgraded your existing DB2 Version 9.5, or Version 9.7 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 10.1 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 tables can now be upgraded.
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.
If you have recoverable databases, the UPGRADE DATABASE command renamed all log files in the active log path using the .MIG extension. After verifying the database upgrade was successful and backing up your databases, you can delete the S*.MIG files that are located in the active log path.
If you have not already done so, you must migrate your SQL Replication in order to support new LSN formats. For details, see Migrating to SQL replication Version 10.1

What to do next

Perform the following post-upgrade tasks that apply to your DB2 database products or add-on features:

If you upgraded your existing DB2 Version 9.5, or Version 9.7 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. The old log directory will only contain renamed log files. 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. The old log directory will only contain renamed log files.
If you upgrade a DB2 server running high availability disaster recovery (HADR) replication, initialize HADR replication During upgrade to DB2 Version 10.1 in a high availability disaster recovery (HADR) replication environment, a database role is changed from primary to standard. Upgrade of standby databases is not supported because these databases are in roll forward pending state.
When your DB2 server performance is stable, take advantage of optimizer improvements and collect statistics for new functionality by updating statistics for your upgraded databases. During database upgrade to DB2 Version 10.1, the statistics collected from your existing database tables retain their values. Statistics for new characteristics on tables and indexes have a value of -1 to indicate there is no information gathered. However, you only need these statistics if you are using new functionality.
After updating statistics for your upgraded databases, determine if index or table reorganization is necessary by running the REORGCHK command. Table and index reorganization can help you to improve performance.

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 9.5, Version 9.7 or DB2 Version 9.8 copies that you no longer need.