Prerequisites for migrating databases

Review these prerequisites before you migrate your database from Microsoft SQL Server to Db2 or Oracle Enterprise Edition.

Before you start migrating your database, ensure that the following prerequisites are met:
  • You have administrator privileges.
  • Your test environment has the most recent copy of the production data for testing the migration.
    • The recent copy of the production data ensures that the most recent updates are included in the migration.
    • Test data for each application and all application instances you want to migrate is needed.

      For example, if you have two DOORS® Next servers, data from both servers is needed to test the migration. However, if the servers are configured in a cluster setup, they share one database instance and require data from only that database instance.

    • Use similar hardware for the test environment as the production environment so that the time that is needed for the migration is more accurate time.
  • The Engineering Lifecycle Management servers are offline during the migration process. Hence, plan for a downtime until the migration process is completed.
  • The Engineering Lifecycle Management servers must have sufficient disk space to accommodate the export files.

    The migration process compresses the database data when it is exported. However, the compression ratio is not the same for all databases, so ensure that your disk space equivalent to the size of your databases is available on the Engineering Lifecycle Management servers.

  • The Engineering Lifecycle Management servers are available during the migration process because partial migration is not supported. The migration process requires an export and import of data together.
  • Delete the work item attachments that are no longer needed. These attachments use a considerable amount of space in the database, which increases the time that is required for migration and its complexity.

    To migrate attachments, see Work item attachment migration utility.

  • Check the integrity of the database by using the verify repotools command.
    To check the integrity of the database, run the following command:
    • <JAZZ_HOME>/server/repotools_[app] -verify level=5
  • Back up the applications that you want to migrate. Keep the backup data for six months to ensure that the product is functioning as expected after migrating databases and that no remedial actions are needed. For more information, see Backing up and restoring IBM Engineering Lifecycle Management applications
  • Increase the repotools script heap size to 4096 Mb. If the repository contains attachments that are of a few gigabytes, increase the heap size to 8192 Mb.
    To increase the heap size for database migration, update the value of the following environment variable:
    • REPOTOOLS_MX_SIZE=4096M

      The minimum recommended value is 4096 Mb, and the maximum value depends on the resources that are available on the server.

  • For Engineering Lifecycle Management versions 7.0.1 and 7.0.2, you must install the JTS_DB_Migration interim fix. For Engineering Lifecycle Management versions 6.0.6 or 6.0.6.1, the migration commands are available as a part of the regular interim fix.
    Note: Ensure that you install the interim fixes in the [install]/server/patch location and follow the instructions that are provided in the associated readme files.
  • Ensure that the version of the Engineering Lifecycle Management application from which you are exporting the database and the version of Engineering Lifecycle Management application in which you are importing the database is the same.

    Exporting the database from one version of an Engineering Lifecycle Management application and importing it to another version is not supported.

  • Ensure that the source database and the target database are supported for your Engineering Lifecycle Management version. For more information, see System requirements.

Preparing the Engineering Lifecycle Management server

The repotools migration code is optimized to reduce the downtime during the migration. However, the operating environment plays a vital role in determining the speed of the migration. The exportConcurrent and importConcurrent repotools commands use multiple CPU cores, disk, and network I/O.

Disk
Use a local Solid State Disk (SSD) disk for reading and writing the exported files. Disk speed also contributes in speeding up the migration process. Importing or exporting data from a shared network or shared storage device might limit the processing speed of the migration.
CPU cores
Use servers that have between 8 to 16 cores for Engineering Lifecycle Management and database servers. The migration process relies on concurrency to reduce the overall processing time.
Add more heap space for the repotools commands.
  • Modify the threadpool size for the migration by using the Java system properties that are defined in the repotools script file:

    -Dcom.ibm.team.repository.migration.internal.service.sql.MigrationThreadPool.THREAD_POOL_SIZE=50

    The default thread pool size for this command is 20.

    -Dcom.ibm.team.repository.migration.internal.service.sql.DBStore.STORE_THREAD_POOL_SIZE=60

    The default thread pool size for this command is 26. The value that is specified must be 6 or more than the value that is specified in MigrationThreadPool.THREAD_POOL_SIZE command. For example, if the MigrationThreadPool.THREAD_POOL_SIZE size is set to 50, then you must set a value of 56 or a higher value in the DBStore.STORE_THREAD_POOL_SIZE command.

Memory
Ensure that sufficient RAM and processor cores are available for the Engineering Lifecycle Management and database servers. The exportConcurrent, importConcurrent, and compare repotools commands might use a significant amount of the system memory. Minimize other processes that use the system resources when you run these commands.

On the Linux system, the Out Of Memory Killer stops the migration process while it is running. In such cases, the administrators need to reduce the memory usage by the other processes and run the stopped commands again.

Databases
The import databases optimize their execution plans based on the number of times that data is written in the database after you run the importConcurrent command.
  • To clear the execution plan for the Oracle databases, run the following command:
    • alter system flush shared_pool;
  • To clear the execution plan for the Db2 databases, enable the Db2 AUTO_MAINT job.
The following actions might improve the performance of a Db2 database:
  • Set the memory to be automatic to allow the migration process to use more memory when required:

    db2 "update db cfg for [DatabaseName] using DATABASE_MEMORY 5000000 automatic"

  • Increase the size of the buffer pool:

    db2 "ALTER BUFFERPOOL IBMDEFAULTBP SIZE [Appropriate size based on avaiable physical memory]"

  • Enable the statement concentrator:

    db2 "update db cfg using stmt_conc literals immediate"

  • Increase the heap size:

    db2 "update db cfg using APPLHEAPSZ 10000 automatic"