Quick Beginnings for DB2 Universal Database EEE for Windows NT**

Post-Installation Steps

After installing DB2 Version 6, you can now migrate databases and complete other migration activities. Do not scale the database system before migrating all the databases; otherwise, the database migration will fail.

You should perform the following steps after DB2 is installed to complete the migration process:

Pre-Version 6	Migrate your databases. See Migrating Databases for more information. Update all instances that you want to use in a partitioned database system. See Updating Single-Partition Instances for use in Partitioned Database Systems for details.
DB2 Universal Database Version 5.x Enterprise - Extended Edition	Migrate your databases. See Migrating Databases for more information.
DB2 Universal Database Version 6	Update all instances that you want to use as partitioned database systems. See Updating Single-Partition Instances for use in Partitioned Database Systems for details.

Migrating Databases

If you are updating a single-partition Version 6 instance to the Version 6 multipartition format, you do not need to migrate the databases in that instance.

When pre-Version 6 databases are migrated for use in a Version 6 partitioned database system, default nodegroups are created for them. For more information about default nodegroups and how they are used, see Nodegroups and Data Partitioning.

To migrate pre-Version 6 databases owned by an instance, perform the following steps:

Step  1.	Log in with a user account that has SYSADM authority. See Working with the System Administrative Group for more information.
Step  2.	Ensure that the databases you want to migrate are cataloged. To retrieve a list of all catalogued databases on your system, enter the db2 list database directory command.
Step  3.	Migrate the database using the db2 migrate database command. For more information refer to the Command Reference.

Updating Single-Partition Instances for use in Partitioned Database Systems

After migrating databases, you are then ready to update any instances that you want to use in a partitioned database system. To do this, use the db2iupdt command. The syntax of the db2iupdt command is as follows:

where:

instance_name

Specifies the name of the instance to be updated. This parameter is required.

/u:domain_name\username,password

Specifies the domain user account for the DB2 service. This parameter is required.

/p:instance_profile_path

Specifies the instance profile path. If you do not specify the instance profile path, the instance directory is created in the \sqllib directory, and given the shared name DB2-instance_name. Read and write permissions will automatically be granted to everyone in the domain. You can change the permissions to restrict access to that directory. This parameter is optional.

/r:baseport,endport

Specifies the range of TCP/IP ports to be used for FCM communications among database partition servers. This parameter is optional.

When this option is specified, the services file of the local machine is updated with entries similar to the following:

   DB2_instance_name      12000/tcp
   DB2_instance_name_END  12004/tcp

If you do not specify a valid port range, DB2 will select one for you.

/h:hostname

Overrides the default TCP/IP hostname if there is more than one TCP/IP hostname for the current machine. This parameter is optional.

Optional Post Migration Actions

There are optional activities you may want to undertake following database migration. You can also apply these optional activities to a down-level database backup which is restored to Version 6, because at the end of the restore, the database is migrated to Version 6.

• Migration of Unique Indexes (db2uiddl)

  DB2 Versions 5 and 6 support deferred checking for duplicate index key values until the end of UPDATE statements. This ensures that temporary duplicate index key values which may be present in mid-UPDATE, but no longer are present at the end of the UPDATE, will not cause the statement to fail.

  With DB2 Version 2 the same UPDATE statement may fail because checking for duplicate key index values is performed row by row as the statement processes the table. For example, if a row with value 1 is changed to value 2, but a row with value 2 already exists, a duplicate value 2 will be detected causing the DB2 Version 2 UPDATE statement to fail.

  Version 2.x and 5.x unique indexes are not automatically migrated to Version 6 semantics for several reasons:

  • Converting unique indexes is a very time-consuming operation.

  • You may have applications that depend on the previous version's unique index semantics.

  • You may want to manage the staged conversion of unique indexes on your own schedule, when needed, using the db2uiddl command.
  
  

  All existing applications will continue to work even if the unique indexes are not converted to Version 6 semantics. You have to convert unique indexes to Version 6 semantics only if support for deferred uniqueness checking is required.

  To convert unique indexes, you need to perform the following steps:

  Step  1.	Log in with a user account that has SYSADM authority. See Working with the System Administrative Group for more information.
  Step  2.	Start the database manager by entering the db2start command.
  Step  3.	Run the db2uiddl command against your migrated database. Refer to the Command Reference for the syntax of this command. The db2uiddl command searches the database catalog tables and generates all the CREATE UNIQUE INDEX statements for user tables in an output file.
  Step  4.	Review the output generated from the db2uiddl command. We recommend that you remove any unwanted indexes from the output file to reduce the time needed to execute it. Comments in the output will flag other situations that require your attention.
  Step  5.	Connect to the database by entering the db2 connect to database_alias command. where database_alias is the alias of the database you are migrating.
  Step  6.	Execute the output file, generated by the db2uiddl command, as a DB2 Command Line Processor command file, using a command similar to the following: db2 -tvf filename where filename is the name of the file generated by the db2uiddl command.
  Step  7.	Disconnect from the database by entering the db2 connect reset command.

  DB2 interprets the re-creation of an existing unique index using the db2uiddl command to signal that the index is ready to be converted to Version 6 semantics.

• Update Statistics

  When database migration is completed, the old statistics that are used to optimize query performance are retained in the catalogs. However, Version 6 of DB2 has statistics that are modified or do not exist in Versions 2.x or 5.x. To take advantage of these, you may want to execute the runstats command on tables, particularly those tables that are critical to the performance of your SQL queries.

  Refer to the Command Reference for the syntax of the runstats command. For details on the statistics, refer to the Administration Guide.

• Rebind Packages

  During database migration, all existing packages are invalidated. After the migration process, each package is rebuilt when it is used for the first time by the Version 6 database manager.

  For better performance we recommend that you run the db2rbind command to rebuild all packages stored in the database. In DB2 Version 6 this command has a new option, all, which, when specified, rebinds all packages (valid and invalid). If the all option is not specified with the db2rbind command, only those packages marked as invalid are rebound. Refer to the Command Reference for the syntax of this command.

• Update database and database manager configuration

  Some of the database configuration parameters are changed to Version 6 defaults or to other values during database migration. The same is true for database manager configuration parameters which may have changed to Version 6 defaults or to other values. Refer to the Administration Guide for more information about configuration parameters.
  

  We recommend that you run the DB2 Performance Monitor for suggestions in choosing appropriate configuration parameters. For more information, refer to the Administration Guide.

• Migrate Explain Tables

  To migrate the explain tables in a database that has been migrated to Version 6, run the following command:

     db2exmig -d dbname -e explain_schema [-u userid password]
  

  where:

  • dbname represents the database name. This parameter is required.

  • explain_schema represents the schema name of the explain tables to be migrated. This parameter is required.

  • userid and password represent the current user's ID and password. These parameters are optional.

  The explain tables belonging to the user ID that is running db2exmig, or that is used to connect to the database, will be migrated. The explain tables migration tool will rename the Version 2 or Version 5 tables, create a new set of tables, using the EXPLAIN.DDL, and copy the contents of the old tables to the new tables. Finally, it will drop the old tables. The migration utility, db2exmig, will preserve any user added columns on the explain tables.

[ DB2 List of Books | Search the DB2 Books ]