Before you upgrade your databases,
it is important to use the db2ckupgrade command
to verify that your databases are ready for upgrade.
The db2ckupgrade command verifies
that a list of conditions are true in order to succeed at the database
upgrade. Also, this command writes to the log file, specified with
the -l parameter, a warning message for a list
of conditions that impact database upgrades. See the Command Reference
for details about the list of conditions.
The db2iupgrade calls
the db2ckupgrade command. The db2iupgrade fails
if the db2ckupgrade command finds any of the conditions
are not true, and returns the error code DBI1205E.
About this task
Restrictions
In a partitioned database environment, to verify that
your databases are ready for upgrade, you must run the db2ckupgrade command
on each database partition. If you do not run the db2ckupgrade command
on each database partition, the db2iupgrade command
could succeed even when one or more database partitions are not ready
for upgrade. However, the database upgrade will fail. The db2iupgrade command
only runs the db2ckupgrade command on the database
partition where you issue the db2iupgrade command.
Procedure
To verify that your databases are
ready for upgrade:
- Log on to the DB2 server
as the DB2 instance owner that
you want to upgrade.
- If the instance owning the databases that
you want to verify is not running, start the instance by running the db2start command.
- From the command line prompt, change
to the appropriate directory:
- On UNIX or Linux operating systems, change
to the DIRIMG/db2/OS/utilities/db2ckupgrade/bin directory
where DIRIMG is the location where you uncompressed
the DB2 Version 9.7 installation
image or the directory where you mounted the DB2 product DVD, and OS is
the operating system name of the DB2 server.
- On Windows operating
system, you need to insert the DB2 Version
9.7 product CD in the drive and change to the \db2\Windows\utilities directory.
- Verify that the local databases that
are owned by the current instance are ready to be upgraded and generate
a log file by running the db2ckupgrade command,
as follows:
db2ckupgrade sample -l db2ckupgrade.log -u adminuser -p password
db2ckupgrade was successful. Database(s) can be upgraded.
where sample is
the database name and db2ckupgrade.log is the
log file created in the current directory that includes details on
errors and warnings.
Each time you issue this command, it overwrites
the existing log file. You can rename the log file to avoid losing
the error details. You must correct these errors before you upgrade.
If you performed the Converting type-1 indexes to type-2 indexes pre-upgrade
task, you can use the -not1 parameter to skip
the check for type-1 indexes. See 7 for
details.
When the db2iupgrade command
runs the db2ckupgrade command, the update.log log
file is specified for db2ckupgrade in the instance
home directory for Linux and UNIX operating systems or in the
current directory for Windows operating
systems.
- If you created user-defined data types
using a name that is a system built-in data type name, drop these
user-defined data types and re-create them using a different name
that is not restricted. The db2ckupgrade command
returns the SQL0473N error
message when user-defined data types have a name that is a system
built-in data type name. If you try to upgrade the database, the UPGRADE
DATABASE command will fail.
- If you created database objects using
restricted schema names, drop all the database objects that use reserved
schema names and re-create them using a schema name that is not restricted. The db2ckupgrade command returns the SQL0553N error
message when database objects have restricted schema names. If you
try to upgrade the database, the UPGRADE DATABASE command
will fail.
- If you have type-1 indexes
, perform the Converting type-1 indexes to type-2 indexes pre-upgrade task
or run the generated script file. Alternatively, if you omit the -not1 parameter,
you can run the type1_index_dbname.db2 script
file.
The db2ckupgrade command returns
the SQL1498W warning
message and generates the type1_index_database-name.db2
script file in the same directory as the db2ckupgrade log
file. The script file contains REORG INDEXES ALL statements with the
ALLOW WRITE ACCESS and CONVERT clauses for each identified type-1
index.
If you do not perform the pre-upgrade
task or do not run the generated script, the UPGRADE DATABASE command
marks all type-1 indexes as invalid. The database manager will automatically
rebuild the type-1 indexes as type-2 indexes on the first table access
after database upgrade and you might experience an unexpected degradation
in response time. Access to the table is not allowed until the index
rebuild is completed.
- If you have external unfenced routines
on Linux and UNIX that have no dependency on the DB2 engine library in your database,
use generated list to determine if you can safely run your routines
as unfenced in the new multithreaded database manager after database
migration. See Upgrading C, C++, and COBOL routines for details.
The db2ckupgrade command writes the ADM4100W warning
message to the log file and generates a file, in the same directory
as the db2ckupgrade log file, called alter_unfenced_database-name.lst containing
a list of all the external unfenced routines that will be redefined
as FENCED and NOT THREADSAFE when you upgrade the database.
- If you have identifiers called NULL for
column names, routine parameter names, or variable names, qualify
or delimit with quotes these identifiers in your SQL statements to
avoid conflict with the NULL keyword.
The db2ckupgrade command
writes the ADM4102W warning
message to the log file when a database has identifiers called "NULL".
If you use identifiers called "NULL" that are not fully qualified
or delimited with quotes in your SQL statements, the identifier name
might resolve to the NULL keyword instead. This would result in a
change in behavior from previous releases. See Upgrade impact from SQL statement changes for
details.
- If workload connection attributes contain
asterisks (*), replace the asterisks (*) with another character. The db2ckupgrade command
writes the ADM4103W warning
message to the log file when workload connection attributes contain
asterisks (*).
Starting with DB2 Version 9.7, you can use a single asterisk
(*) as a wildcard character and two asterisks (**) to represent one
literal asterisk (*) in some workload attributes. The UPGRADE DATABASE
command replaces the single asterisk (*) with two asterisks (**) depending
the type of connection attribute.
- If the database is enabled for XML Extender,
perform all the steps in Upgrading a DB2 server with XML Extender to DB2 Version 9.7 to completely
disable XML Extender and remove XML Extender functionality before
upgrading your instance and databases. The db2ckupgrade command
writes the ADM4104E warning
message to the log file when a database is enabled for XML Extender.
Starting with DB2 Version
9.7, XML Extender is discontinued.
- Ensure that the log file for db2ckupgrade command
contains the following text: Version of DB2CKUPGRADE being
run: VERSION 9.7. This text confirms that you are running
the correct level of the db2ckupgrade command.
- Check and fix any invalid flavor fields on
SQLSPCS files using the fixtbspflvr tool. Details about this tool
can be obtained from http://www.ibm.com/support.