Quick Beginnings EEE for Windows**
If you are migrating from Version 5.0 or
Version 5.2 to DB2 Version 7, you must prepare your databases and
instances before installing DB2 Version 7. If you are upgrading from
Version 6, there is nothing you have to do prior to installing Version
7.
The migration of pre-Version 5.0 databases and instances is not
supported in DB2 Version 7.
When you migrate from a Version 5.x or Version 6 database system to
a DB2 Enterprise - Extended Edition Version 7 database system, depending on
the installation option you choose, the installation program will migrate all
instances to the Version 7 multipartition or single-partition format.
If you are migrating a database with populated tables, refer to the Administration Guide for descriptions of how to add database partition servers to a system and
redistribute data across database partitions.
After you install DB2 Enterprise - Extended Edition, any databases that you
created with earlier versions of DB2 will not automatically work with the new
version of DB2. You must follow the steps in this section to migrate
your instances and databases.
Windows allows only one version of DB2 to be installed on a machine.
For example, if you have DB2 Version 6 and install Version 7, Version 6 will
be deleted during the installation.
This section describes how to prepare existing DB2 Version 5.x
databases and instances for migration to a format usable by DB2 Version
7. If you want to migrate more than one instance, you must repeat these
steps for each instance.
To prepare your databases for migration:
-
Ensure that there are no applications using any databases owned by the DB2
instance you are preparing to migrate. To get a list of all
applications owned by the instance, enter the db2 list applications
command. If all applications are disconnected, this command will return
the following message:
SQL1611W No data was returned by the Database System Monitor.
SQLSTATE=00000
You can end a session by entering the db2 terminate command.
- Ensure that all databases are cataloged. To view a list of all the
cataloged databases in the current instance, enter the following
command:
db2 list database directory
- Make a backup copy of all Version 5.x databases. You do not
have to back up Version 6 databases. Refer to the Administration Guide for your DB2 product for information on making a backup copy
of a database and to the Command Reference for the syntax of the backup command.
- When all applications are complete and you have backed up your databases,
stop all database server processes owned by the DB2 instance by entering the
db2stop command.
- Stop the DB2 license daemon by entering the db2licd -end
command.
- Stop all command line processor sessions by entering the db2
terminate command in each session that was running the command line
processor.
Next, you should verify that all cataloged databases are ready for
migration before installing DB2 Version 7.
To ensure that you can migrate your databases to the DB2 Version 7 format, you
should run the db2ckmig command before installing DB2 Version
7.
Note: | This section applies to databases created with DB2 Version 5.x
only. You do not have to run this command against databases created
with DB2 V6.
|
To run the db2ckmig command:
- Insert your DB2 Version 7 product CD-ROM into the drive.
- Change to the x:\db2\common directory where
x: represents your CD-ROM drive letter.
- Enter the db2ckmig command to verify that the databases on your
system can be correctly migrated. The syntax of the command is as
follows:
DB2CKMIG Command
>>-db2ckmig----+-database_alias-+--/l--drive:\path\filename------------------->
'-/e-------------'
>-----+---------------------------+----------------------------><
'-/u--userid--/p--password--'
- database_alias
- Specifies a database_alias name of a database to be verified for
migration. This parameter is required if the /e parameter is
not specified.
- /e
- Specifies that all cataloged databases are to be verified for
migration. This parameter is required if the database_alias
parameter is not specified.
- /l drive:\path\filename
- Specifies a drive, target path and filename to keep a list of errors and
warnings generated for the scanned database. The path variable
is optional; if you do not specify a path, the path from which you
execute the db2ckmig command will be used. You must specify
a filename.
- /u userid
- Specifies the user account used to connect to the database. This
parameter must be specified if you are logged on as a user without connect
authority.
- /p password
- Specifies the password of the user account used to connect to the
database. This parameter must be specified if you are logged on as a
user without connect authority.
You can enter the db2ckmig command on remote systems. The
database parameter must specify the database_alias name of the remote
database. You can run this command from any database partition
server. The file will be written on your local system.
For example, to check that all databases cataloged on your system can be
migrated and to log all the messages from this command to the
c:\temp\message.txt file, enter the following
command:
x:\db2\common\db2ckmig /e /l c:\temp\message.txt
where x: represents your CD-ROM drive.
- If any errors are found, the db2ckmig command generates a log
file and places it in the path and file specified by the /l
option. If there are errors, refer to the information that follows for
suggested corrective actions. Once the errors have been corrected,
re-enter the db2ckmig command to ensure that the databases are
ready to be migrated.
- Make a backup copy of the database. For more information, refer to
the Administration Guide.
Possible DB2CKMIG Error Conditions
- A database is in backup pending state
-
Perform a backup of the database.
- A database is in roll-forward pending state
-
Recover the database as required. Perform or resume a roll-forward
database to end of logs and stop.
- Table space ID is not in normal state
-
Recover the database and table space as required. Perform or resume
a roll-forward database to end of logs and stop.
- A database is in an inconsistent state
-
Restart the database to return it to a consistent state.
- Structured type and function have the same name
-
A structured type and function (with no arguments) belonging to the same
schema cannot have the same name. The type or function, and objects
using the type or function, must be dropped and recreated using another
name. To correct this error:
- Back up the database.
- Export the data from any tables that are dependent on the structured types
or functions.
- Drop any tables dependent on the structured types or functions, and then
drop the structured types or functions. These drops may drop other
objects such as views, indexes, triggers, or functions.
- Create structured types or functions with different type or function names
and recreate the tables using the new structured type or function
names. Recreate any dropped views, indexes, triggers, or
functions.
- Import or load the data into the object.
- The database contains user-defined distinct types (UDTs) that use the type
name BIGINT, DATALINK, or REFERENCE.
-
These data type names are reserved for the Version 7 database
manager. To correct this error:
- Back up the database.
- Export the data from any tables that are dependent on these data
types.
- Drop any tables dependent on these data types, and then drop the data
types. These drops may drop other objects such as views, indexes,
triggers, or functions.
- Create data types with different type or function names and recreate the
tables using the new data type names. Recreate any dropped views,
indexes, triggers, or functions.
- Import or load the data into the object.
Refer to the Administration Guide for more information about the actions required to correct these
conditions.
[ Top of Page | Previous Page | Next Page ]