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.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.
- 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.5, 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.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.
- 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 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 10.1,
or Version
9.7 copy
and DB2DIR is the location of your DB2 Version 10.5 copy. You do not have to copy standard code page conversion
tables.
If you upgraded your existing DB2 Version 10.1,
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.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.
- 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.5
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 10.1,
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.5 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.5, 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 10.1, Version
9.7 or DB2 Version 9.8 copies
that you no longer need.