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.
Procedure
Prepare for the upgrade of your DB2 servers by performing the following tasks:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Optional: Stop HADR on the primary and standby
databases.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Linux only: Change
raw devices to block devices.
Refer to Changing raw devices to block devices (Linux).
- 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.
- 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.
- Take the DB2 server
offline for upgrade.
Refer to Taking a DB2 server offline for upgrade or for converting to a DB2 pureScale environment.
- 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.