Verifies that a database can be upgraded.
Scope
In a partitioned
database environment, the db2ckupgrade command
will check each database partition.
Command syntax
>>-db2ckupgrade--+-database-+-- -l--filename--+--------+-------->
'- -e------' '- -not1-'
>--+----------------------------+------------------------------><
'- -u--userid-- -p--password-'
Command parameters
- database
- Specifies an alias name of a local database to be scanned.
- -e
- Specifies that all local cataloged databases are to be scanned.
- -l filename
- Specifies a log file to keep a list of errors and warnings generated
for the scanned database.
- -not1
- Disables the check for type-1 indexes. If this option is not specified,
the db2ckupgrade command checks for type-1 indexes
and generates the type1_index_database-name.db2 script
file, in the same directory indicated for the log file, containing REORG
INDEXES ALL commands with the ALLOW WRITE ACCESS and CONVERT clauses
for each identified type-1 index.
- -u userid
- Specifies the user ID of the system administrator.
- -p password
- Specifies the password of the system administrator's user ID.
Usage notes
To run the
db2ckupgrade command:
- On Linux and UNIX operating systems, install a new DB2® copy to which you want to upgrade.
Then run the db2ckupgrade command from the DB2DIR/bin directory,
where DB2DIR is the location where the DB2 copy is installed.
- On Windows operating
systems, insert the DB2 database
product CD to which you want to upgrade. Then run the db2ckupgrade command
from the db2\Windows\Utilities directory on the
CD.
The db2ckupgrade command fails to run
against databases which are catalogued as remote databases.
This
command verifies that all the following conditions are true:
- A catalogued database actually exists.
- A database is not in an inconsistent state.
- A database is not in a backup pending state.
- A database is not in a restore pending state.
- A database is not in rollforward pending state.
- Tables are not in a load pending state.
- Tables are not in a redistribute pending state.
- For Version 9.8 or
later, that all table space container paths use the same mount point.
- For Version 9.8 FixPack
3 or later, that the I/O write operations for the database are not
suspended or are not being suspended.
- That there are no MQT's that depend on system
views.
- Table spaces are in a normal state.
- A database does not contain user-defined types
(UDTs) with the name ARRAY, BINARY, CURSOR, DECFLOAT, ROW, VARBINARY,
or XML.
- A database does not contain the built-in DATALINK data type.
- A database does not have a schema with the name
SYSPUBLIC.
- A database does not have orphan rows in system catalog tables
that would cause database upgrade to fail.
- A database enabled as an HADR primary database allows successful
connections.
- An HADR database role is not standby.
- If SYSCATSPACE is a DMS table space and AUTORESIZE is not enabled,
SYSCATSPACE has at least 50% free pages of total pages.
- A database is not enabled for XML Extender.
A local database must pass all of these checks to succeed at
the upgrade process.
The db2iupgrade command
calls the db2ckupgrade command with the -not1 parameter,
and specifies update.log as the log file for db2ckupgrade.
The default log file created for db2iupgrade is /tmp/db2ckupgrade.log.processID. The
db2iupgrade fails
if the
db2ckupgrade command finds that any of the
previously listed conditions are not true, and returns the
DBI1205E error
code. The user needs to resolve these errors before upgrading the
instance.
The
db2ckupgrade command writes
a warning message to the log file, as specified with the
-l parameter,
for any of the following conditions:
- Column names, routine parameter names, or variable names are called
NULL.
- Type-1 indexes exist in the database.
- Workload connection attributes contain asterisks (*).
- Database is enabled for DB2 WebSphere® MQ
functions.
During installation on Windows operating
systems, if you select a DB2 copy
with the
upgrade action in the
Work
with Existing window and you have local databases cataloged
on your instances, a message box will warn you that you must run the
db2ckupgrade command
from the DB2 database product
CD. Then you can choose one of the following actions:
- Ignore the message and continue the installation process.
- Run the db2ckupgrade command. If this command
runs successfully, continue the installation process. If you find
errors, quit the installation process, fix any errors, and then rerun
the installation process.
- Quit the installation process.
For Version 9.5 databases,
if the
-not1 parameter is omitted, the
db2ckupgrade command
calls the
db2IdentifyType1 command to identify
type-1 indexes and to generate a script to convert type-1 indexes
to type-2 indexes for a specified database. The
db2IdentifyType1 command
can take a long time to complete its processing. The running time
of the
db2IdentifyType1 command is proportional
to the number of tables in the database and the number of database
partitions. Take into account the following performance considerations:
- For Version 9.5 databases with a large number of tables, large
number of database partitions, or both, first run the db2IdentifyType1 command
on specific schemas or tables by using the -s or -t parameters
until you process all your tables. Then run the db2ckupgrade command
with the -not1 parameter.
- For Version 9.5 partitioned database environments, run the db2ckupgrade command
from one database partition, preferably the catalog partition for
faster performance, to detect all type-1 indexes.
To verify that a database is ready for upgrade, refer
to "Verifying that your databases are ready for upgrade".