Quick Beginnings for DB2 Universal Database for UNIX

Migrating Instances

This procedure describes how to migrate DB2 instances that were created using a previous version of DB2.

If you upgraded your installed DB2 product by applying a PTF or a FixPak, you should update instances, using the db2iupdt command, instead of migrating them. Instance updates do not apply to DB2 Product Documentation and DB2 Product Messages. See Updating Instances for further information.

Before you can migrate an instance to use the latest version of DB2, you must install DB2 Version 5 on your system.

If there are several DB2 instances using previous versions of DB2, you do not need to migrate all of these instances at this time. Instances that are not migrated will continue to use previous versions of DB2.

Each DB2 instance must be migrated separately. To successfully migrate a DB2 instance, you need to perform the following steps:

Prepare the DB2 instance for migration.
Ensure that the user exit program can be migrated.
Migrate the DB2 instance.

If you want to migrate several instances, you must repeat these steps for each instance.

Prepare the DB2 Instance for Migration

Before you can migrate a DB2 instance, all applications using any databases owned by this instance must be completed. To prepare a DB2 instance for migration, you need to perform the following steps:

Log in as the DB2 instance owner.
Ensure that there are no applications using any databases owned by this DB2 instance. To get a list of all applications owned by the instance, enter the db2 list applications command.
You can end a session by entering the db2 terminate command. It is not recommended to force termination of applications using the db2 force applications all command, since some applications may have unexpected behavior when terminated using this command. See the Command Reference for usage and details of this command.
When all applications are complete, 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.
Enter the db2_kill command to clean up any remaining DB2 resources.
Log off.

The DB2 instance is now ready for migration.

Verify that Databases Can Be Migrated

DB2 provides the db2ckmig migration command. The db2ckmig command can be used to verify whether all cataloged databases can be migrated. The db2imigr command in Migrate the DB2 Instance uses the db2ckmig command to verify whether the cataloged databases can be migrated.

To ensure that you can migrate the instance to DB2 Version 5, you should run the db2ckmig command. If instance migration failed, you must correct errors reported by this command. You can choose to run the db2ckmig command again to verify that the errors have been corrected and then migrate the instance.
For detailed information about the db2ckmig command, refer to the Version 5 Command Reference.

To verify that all cataloged databases can be migrated, you need to perform the following steps:

Log in as the instance owner.
Enter the following command:
```
   DB2DIR/bin/db2ckmig -h -a 0 -l INSTHOME/migration.log
```
where DB2DIR = /usr/lpp/db2_05_00 on AIX

= /opt/IBMdb2/V5.0 on HP-UX, SCO UnixWare 7, or Solaris

and INSTHOME is the home directory of the instance and migration.log is the name for the output file.
Check the log file; for example, INSTHOME/migration.log.

The log file displays the errors that occur when you run the db2ckmig command. If it shows any errors, see Table 11 for suggested corrective actions..
Check that the log file is empty before continuing with the instance migration.
Backup the database after making corrections.

Table 11. 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.
Note: This error does not apply to DB2 Parallel Edition or Version 1.x single-partition database.

A database is in an inconsistent state Restart the database to return it to a consistent state.
The database contains database objects that have a schema name of SYSCAT, SYSSTAT, or SYSFUN These schema names are reserved for the Version 5 database manager. To correct this error, do the following:

Back up the database.
Export the data from the database object (catalogs or tables).
Drop the object.
Recreate the object with the corrected schema name.
Import/Load the data into the object.
Run the db2ckmig command against the database again, ensuring that the database passes the db2ckmig check.
Make a backup copy of the database.

The 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, do the following:

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.

Notes:

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.
This error does not apply to DB2 Parallel Edition or Version 1.x. single-partition database.

The database contains user-defined distinct types that use the type name of DATALINK or REFERENCE. The data type names, DATALINK and REFERENCE are reserved for the Version 5 database manager. To correct this error, do the following:

Back up the database.
Export the data from any tables that are dependent on the data types.
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.
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.
Import/Load the data into the object.
Run the db2ckmig command against the database again, ensuring that the database passes the db2ckmig check.
Make a backup copy of the database.

Note: This error does not apply to DB2 Parallel Edition or Version 1.x single-partition database.

All local databases now have the same authentication type as the instance where they reside; the authentication type in the database directory is ignored by DB2 Version 5.2 servers. If a warning is logged due to a conflicting authentication type, and you want a database to retain its previous authentication type, then you can do one of the following:

Change the authentication type of the instance to the previous one.
Move the database to another instance that has the required authentication type.

Before changing the authentication type of the instance, you should make sure that the new authentication type will be appropriate for all databases residing there. Be certain to consider the security implications of the different authentication types.

If there are databases that you do not want to migrate, you can uncatalog them (along with all aliases); the db2ckmig command does not perform any verification of uncataloged databases.

Refer to the Administration Guide for more information about the actions required to correct these conditions.

Migration Considerations for the User Exit Program

Follow these instructions if you are using the db2uexit user exit program with previous versions of DB2.

DB2 Version 5 has changed the interface it uses to invoke the user exit program to archive and retrieve log files. For more information on these new interfaces, refer to the Administration Guide. The name for the user exit program has changed to db2uext2 in Version 5. (In previous versions, it was called db2uexit.)

The following should be considered before migrating instances:

If the pre-Version 5 db2uexit program is installed in the INSTHOME/sqllib/adm directory before migration, it will remain in this directory after migration. The DB2 Version 5 db2uext2 program will be also installed in this directory. Its function is to invoke db2uexit using the pre-Version 5 interface. This allows the old user exit program to be used on DB2 Version 5.
If db2uexit is installed in a directory other than INSTHOME/sqllib/adm, it will not be installed after migration. For example, if db2uexit was in the INSTHOME/sqllib/bin directory, after migration the db2uexit file will not be in the INSTHOME/sqllib/bin directory. If you want to continue using the old user exit after migration, you must copy db2uexit to the INSTHOME/sqllib/adm directory. Then, you can do one of the following:
- If you are migrating from DB2 Version 1.x or Version 2.x, copy db2uext2.v2 from the DB2DIR/misc directory to the INSTHOME/sqllib/adm directory and rename it to db2uext2. You can use the following command to copy the file:
```
   cp DB2DIR/misc/db2uext2.v2 INSTHOME/sqllib/adm/db2uext2
```
  where DB2DIR = /usr/lpp/db2_05_00 on AIX
  
  = /opt/IBMdb2/V5.0 on HP-UX, SCO UnixWare 7, or Solaris
- If you are migrating from DB2 Parallel Edition Version 1.x, copy db2uext2.pe from the DB2DIR/misc directory to the INSTHOME/sqllib/adm directory and rename it to db2uext2. You can use the following command to copy the file:
```
   cp DB2DIR/misc/db2uext2.pe INSTHOME/sqllib/adm/db2uext2
```
  where DB2DIR = /usr/lpp/db2_05_00 on AIX.
Note: You must ensure that db2uext2 is owned by the instance owner and is executable by the owner.

At a convenient time, you should modify your user exit program to use the new DB2 Version 5 interfaces. The new user exit program should replace db2uext2 in the INSTHOME/sqllib/bin directory, used to support the pre-Version 5 user exit program, db2uexit, which should be removed.

Migrate the DB2 Instance

Only local cataloged databases that are owned by the DB2 instance are checked for migration. Uncataloged databases may be unusable after the instance has been migrated. Refer to the Administration Guide for further information.

After an instance is ready for migration, use the db2imigr command to migrate the instance as follows:

If the library_path environment variable is set to /usr/lib on AIX or /opt/lib on HP-UX, SCO UnixWare 7, or Solaris, and there is a link in /usr/lib or /opt/lib to the Version 5 libdb2.a DB2 library, this can cause an error when using the db2imigr command. To fix the error, you should reset the library_path environment variable so that it does not reference the libraries in those paths by entering the following command:

   unset library_path

where library_path is:

LIBPATH on AIX
SHLIB_PATH on HP-UX
LD_LIBRARY_PATH on Solaris or SCO UnixWare 7

After migrating the DB2 instance, you should reset LIBPATH to its original setting.

Run the db2imigr command as follows:
```
DB2DIR/instance/db2imigr [-d] [-a AuthType] [-u fencedID] InstName
```
where DB2DIR = /usr/lpp/db2_05_00 on AIX

= /opt/IBMdb2/V5.0 on HP-UX, SCO UnixWare 7, or Solaris

and where:
-d
Sets the debug mode that you can use for problem determination
-a AuthType
Is an optional parameter that specifies the authentication type for the instance. Valid authentication types are (SERVER), (CLIENT), and (DCS). If the -a parameter is not specified, the authentication type defaults to (SERVER), if a DB2 server is installed. Otherwise, the AuthType is set to (CLIENT).
Notes:
1. The authentication type of the instance applies to all databases owned by the instance.
2. While authentication type (DCE) is an optional parameter, it is not valid to choose (DCE) for this command.
-u fencedID
Is the user under which the fenced user-defined functions (UDFs) and stored procedures will execute.
InstName
Is the login name of the instance owner.
If there are any errors in verifying that all databases can be migrated, see Table 11 and take the suggested corrective actions. Then, reenter the db2imigr command.

If you are migrating a DB2 Version 2.1 instance, created on AIX, and the instance uses the environment variable DB2SORT set to a keyword SMARTSORT, you must set the registry value db2sort after the instance is migrated to Version 5. Set the db2sort registry value to the run time library for the sort command as follows:

   db2set DB2SORT="/usr/lib/libsort.a"

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

[ DB2 List of Books | Search the DB2 Books ]

	where `DB2DIR`	= /usr/lpp/db2_05_00	on AIX
		= /opt/IBMdb2/V5.0	on HP-UX, SCO UnixWare 7, or Solaris