Quick Beginnings for DB2 Extended Enterprise Edition for UNIX
This procedure describes how to migrate DB2 instances that were created
using a previous version of DB2.
|
To update a Version 5 single-partition database system to a Version 5
partitioned database system, you must update the instance using the
db2iupdt command. For more information, see "Updating Instances".
|
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.
- Verify that databases can be migrated. This step is optional;
however, we recommend that you perform this step before migrating an
instance.
- Ensure that the user exit program can be migrated.
- Migrate the DB2 instance.
Note: | If you want to migrate several instances, you must repeat these steps for
each instance.
|
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.
- Ensure that there are no applications using any databases owned by this
DB2 instance. You can get the list of all applications using databases
owned by the instance by issuing the db2 list applications
command.
- When all applications are complete, stop all database server processes
owned by the DB2 instance by issuing the db2stop command.
- Stop all command line processor sessions by issuing the db2
terminate command in each session that was running the command line
processor.
- Issue the db2_kill command to clean up any remaining DB2
resources.
- Log off.
The DB2 instance is now ready for migration.
DB2 provides the db2ckmig migration
command. This command verifies whether all cataloged databases can be
migrated.
|
To ensure that you can migrate all databases to DB2 Extended Enterprise
Edition, you should run the db2ckmig command before you migrate the
instance.
|
You must correct errors reported by this command before continuing with
instance migration. For detailed information about the
db2ckmig command, refer to the Version 5 Command
Reference.
For example, to verify that all cataloged databases can be migrated, log in
as the instance owner and issue the following command:
DB2DIR/instance/db2ckmig -h -a 0 -l INSTHOME/migration.log
| where DB2DIR
| = /usr/lpp/db2_05_00
| on AIX
|
|
| = /opt/IBMdb2/V5.0
| on 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. If it shows any errors, see Table 8 for suggested corrective
actions. In the partitioned database system, errors may be returned at
the database partition level.
Note: | The log file displays the errors that occur when you run the
db2ckmig command. Check that the log is empty before
continuing with the instance migration. Backup the database after
making corrections.
|
Table 8. 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 log 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
- Issue the alter table command to drop the constraint.
- Function
- Issue the drop function command to drop the function dependent
on SYSFUN.DIFFERENCE.
- Trigger
- Issue the drop trigger command to drop the trigger.
- View
- Issue 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 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.
|
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 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.
|
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:
- Log in as root.
- 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 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 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 server product is installed. Otherwise,
the AuthType is set to CLIENT.
Notes:
- The authentication type of the instance applies to all databases owned by
the instance.
- Authentication type DCE is valid. However, it is not valid to
choose DCE as an AuthType for this command. To enable DCE
authentication for a DB2 instance, refer to the Administration Guide.
- -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.
|
Because the INSTHOME directory is NFS mounted on all machines,
you only have to run the db2imigr command on one machine to migrate
the entire instance.
|
- If there are any errors in verifying that all databases can be migrated,
see Table 8 and take the suggested corrective actions. Then, reissue the
db2imigr command.
If you are migrating a DB2 Version 2.1 instance, created on AIX, and
the instance uses the environment variableDB2SORT 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 runtime 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 ]