Quick Beginnings for UNIX**
This procedure describes how to migrate DB2 instances that were created
using a previous version of DB2.
Before you can migrate an instance to use the latest version of DB2, you
must install DB2 Version 6 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, perform the following steps:
step 1.
| Prepare the DB2 instance for migration.
|
step 2.
| Verify that the databases can be migrated. There are also migration
considerations you should take into account if you are using the Version 2
user exit program.
|
step 3.
| Migrate the DB2 instance.
|
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, perform the following steps:
step 1.
| Log in as the DB2 instance owner.
|
step 2.
| 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.
|
step 3.
| When all applications are complete, stop all database server processes
owned by the DB2 instance by entering the db2stop command.
|
step 4.
| Stop the DB2 license daemon by entering the db2licm end
command.
|
step 5.
| Stop all command line processor sessions by entering the db2
terminate command in each session that was running the command line
processor.
|
step 6.
| Enter the db2_kill command to clean up any remaining DB2
resources.
|
step 7.
| Log off.
|
The DB2 instance is now ready for migration.
DB2 provides the db2ckmig migration command which
is used to verify whether all cataloged databases can be migrated. The
db2imigr command in Step 3. 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 the DB2 Version 6 format,
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 Command Reference.
|
To verify that all cataloged databases can be migrated, perform the
following steps:
step 1.
| Log in as the instance owner.
|
step 2.
| Enter the following command:
DB2DIR/bin/db2ckmig -h -a 0 -l INSTHOME/migration.log
| where DB2DIR
| = /usr/lpp/db2_06_01
| on AIX
|
|
| = /opt/IBMdb2/V6.1
| on HP-UX, Solaris, or SGI IRIX
|
and INSTHOME is the home directory of the instance and
migration.log is the name for the output file.
|
step 3.
| Check the log file. The log file displays the errors that occur
when you run the db2ckmig command. If it shows any errors,
see Table 15 for suggested corrective actions..
|
step 4.
| Check that the migration log file is empty before continuing with the
instance migration.
|
step 5.
| Backup the database after making corrections.
|
Table 15. 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.
|
|
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 6 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.
|
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.
If you are using the Version 2.x user exit program, you should
consider the following before migrating instances:
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
INSTHOME/sqllib/adm directory.
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:
|
Only local cataloged databases that reside in 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 user with root authority.
|
If the library_path environment variable is set to
/usr/lib on AIX or /opt/lib on HP-UX, or Solaris, and
there is a link in /usr/lib or /opt/lib to the Version 6
libdb2 shared 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 represents:
- LIBPATH on AIX
- SHLIB_PATH on HP-UX
- LD_LIBRARY_PATH on Solaris
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_06_01
| on AIX
|
|
| = /opt/IBMdb2/V6.1
| on HP-UX, Solaris, or SGI IRIX
|
and where:
- -d
- Sets the debug mode that you can use for problem determination.
This parameter is optional.
- -a AuthType
- 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). This parameter is
optional.
Notes:
- The authentication type of the instance applies to all databases owned by
the instance.
- 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. This parameter is optional only when a
DB2 Run-Time Client is installed. It is required for all other DB2
products.
- InstName
- Is the login name of the instance owner.
- If there are any errors in verifying that all databases can be migrated,
see Table 15 and take the suggested corrective actions. Then,
reenter the db2imigr command.
|
If you are migrating a DB2 Version 2.1 or Version 5 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
6. 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 ]