Quick Beginnings for Windows NT**

Pre-Installation Migration Steps

These steps will help you to ensure that all databases on your system can be migrated to the new DB2 Version 6 format. Before installing your new version of DB2, perform the following steps:

Step 1. Back Up Databases

You should back up all databases before installing your new version of DB2. To back up the databases, perform the following steps:

step  1.
Complete all database transactions.
step  2.
Ensure all applications disconnect from each database.
To list all applications that are connected to a database, 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

To force all applications to disconnect from the database, enter the db2 force applications all command.
step  3.
Ensure 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

step  4.
Make a backup copy of all databases. For more information on backing up databases, refer to the Administration Guide for the DB2 version you are backing up. For the syntax of the backup command, refer to the Command Reference for the DB2 version you are backing up.

Make sure that this is the most recent backup copy of the database before you start the next procedure.

step  5.
Stop the database manager by entering the db2stop command.

Step 2. Verify that Databases Can Be Migrated

DB2 provides the db2ckmig command to check that databases can be migrated. This command must be run prior to installation. The command is located on the product CD-ROM.

To run the db2ckmig command:

Insert the CD-ROM into the drive.

If you are installing DB2 on a Windows NT workstation, the setup program might be started automatically via the operating system's autorun feature. In this case, do not proceed with the install. Instead, cancel and proceed to the next step.

Set the current directory to the x:\db2\language\install directory on the CD-ROM, where x: is the CD-ROM drive and language is the two-character identifier that represents your language. For information on the directory names for each language, see Table 8.

Enter the db2ckmig command to verify that the databases on your system can be correctly migrated. The syntax of the command is as follows:

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 the /p parameter is specified.
/p password: Specifies the password of the user account used to connect to the database. This parameter must be specified if the /u parameter is specified.

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, see Table 7 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.

Table 7. Correcting Error Messages

Error Action
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.
The Version 2 database contains database objects that have a schema name of SYSCAT, SYSSTAT, or SYSFUN These schema names are reserved for the Version 6 database manager. To correct this error, perform the following steps:

step  1.
Back up the database.
step  2.
Export the data from the database object (catalogs or tables).
step  3.
Drop the object.
step  4.
Recreate the object with another schema name.
step  5.
Import/Load the data into the object.
step  6.
Run the db2ckmig command against the database again, ensuring that the database passes the db2ckmig check.
step  7.
Make a backup copy of the database. For more information, refer to the Administration Guide.

The Version 2 database contains database objects that have a dependency on the SYSFUN.DIFFERENCE function. Possible violated database objects are:

Constraint
Function
Trigger
View
The SYSFUN.DIFFERENCE function must be dropped and recreated during database migration. However, if there is a database object that is dependent on this function, migration will fail. To correct this error:

Constraint
Enter the alter table command to drop the constraint.
Function
Enter the drop function command to drop the function dependent on SYSFUN.DIFFERENCE.
Trigger
Enter the drop trigger command to drop the trigger.
View
Enter the drop view command to drop the view.

Note: Any package dependent on the SYSFUN.DIFFERENCE function will be marked inoperative after migration. Therefore, the db2ckmig command will not report any package that is dependent on the SYSFUN.DIFFERENCE function. For more information, refer to the Administration Guide.

The database contains user-defined distinct types (UDTs) that use the type name BIGINT, DATALINK, REAL or REFERENCE. These data type names are reserved for the Version 6 database manager. To correct this error, perform the following steps:

step  1.
Back up the database.
step  2.
Export the data from any tables that are dependent on the data types.
step  3.
Drop any tables dependent on the data types, and then drop the data types. These drops may drop other objects such as views, indexes, triggers, or functions.
step  4.
Create data types with different type names and recreate the tables using the new data type names. Recreate any dropped views, indexes, triggers, or functions.
step  5.
Import/Load the data into the object.
step  6.
Run the db2ckmig command against the database again, ensuring that the database passes the db2ckmig check.
step  7.
Make a backup copy of the database. For more information, refer to the Administration Guide.

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 have to dropped and recreated using another name. To correct this error, perform the following steps:

step  1.
Back up the database.
step  2.
Export the data from any tables that are dependent on the structured types or functions.
step  3.
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.
step  4.
Create structured types or functions with different type or function names and recreate the tables using the new data type or function names. Recreate any dropped views, indexes, triggers, or functions.
step  5.
Import/Load the data into the object.
step  6.
Run the db2ckmig command against the database again, ensuring that the database passes the db2ckmig check.
step  7.
Make a backup copy of the database. For more information, refer to the Administration Guide.

Migration Considerations for the DB2 Version 2.x User Exit Program

These instructions apply only to the DB2 Version 2.x db2uexit user exit program. If you are not using the Version 2.x db2uexit user exit program, skip this section and go to Installing DB2 Version 6.

DB2 Version 6 uses the db2uexit user exit program to archive and retreive log files. For more information on the db2uexit interfaces, refer to the Administration Guide.

The following should be considered before migrating from Version 2.x to Version 6 .

If the Version 2.x user exit program, db2uexit.exe, is found in the \sqllib\bin directory before installation, it will remain in this directory after the installation completes. The db2uext2.exe program will also be installed in this directory. Its function is to invoke the db2uexit.cmd or db2uexit.exe user exit programs using the Version 2.x interface. This allows the old user exit program to be used on Version 6.
If db2uexit.exe is in a directory other than the sqllib\bin directory, it will remain there after installation, but db2uext2.exe will not be installed in the sqllib\bin directory. Following installation, if you want to use the old user exit program, you will have to copy it to the sqllib\bin directory, then copy db2uext2.v2 from the sqllib\misc directory to the sqllib\bin directory, and rename it to db2uext2.exe.

If you are migrating from DB2 Version 2.x, you should modify your user exit program to use the DB2 Version 6 interfaces. The new user exit program db2uexit should replace db2uext2 in the sqllib\bin directory.

Installing DB2 Version 6

After you have successfully completed the pre-installation checks, you can now start installing DB2 Version 6 using either the interactive or distributed method. During the installation of DB2 Version 6, instance migration for instances created in previous versions of DB2 occurs. For installation procedures, see the following sections:

Installing DB2 Universal Database on Windows NT for interactive installation.
Installation and Configuration Supplement for distributed installation.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]