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 is 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 affect 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.
Before you begin
- Ensure that you have SYSADM authority.
- Ensure that all the local databases that you want to upgrade are
cataloged.
- On Linux or UNIX operating systems, uncompress
a DB2® Version 10.1 installation image to be able to run the db2ckupgrade command.
- Ensure that you meet the installation
requirements for DB2 database
products.
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 10.1 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, insert the DB2 Version 10.1 product DVD in the drive and change to the \db2\Windows\utilities directory.
Or change to the DIRIMG directory, where DIRIMG is
the location where you decompressed the DB2 Version 10.1 installation image.
- 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.
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 step 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.
In a partitioned database environment, the db2ckupgrade command
only needs to be issued once. It checks all partitions.
- 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 fails.
- 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
fails.
- 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 commands
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 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. In some
workload attributes, if the intention is to represent an actual asterisk,
then you can use two asterisks (**). 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 10.1 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.
- If you created global variables
of XML data type or created compiled SQL functions with parameters
of XML data type or XML data type in the RETURNS clause, you must
upgrade to the Version 10.1 Fix Pack 1 software or later fix pack releases that
support the XML data type in these database objects. If you decide
to upgrade to the Version 10.1 software, you must drop these database objects and
re-create them specifying a supported data type.
The db2ckupgrade command
writes the ADM4004W warning message to the log file when a database
has global variables of XML data type or compiled SQL functions with
parameters of XML data type or XML data type in the RETURNS clause.
The XML data type is not supported on these database objects. Therefore,
these database objects will be invalidated during the database upgrade.
- Ensure that the log file for db2ckupgrade command
contains the following text: Version of DB2CKUPGRADE being
run: Version 10.1. This text confirms that you are running the
correct level of the db2ckupgrade command.
- Check and fix any invalid flavor fields on SQLSPCS files
by using the fixtbspflvr tool. Details
about this tool can be obtained from http://www.ibm.com/support/.