Migrating the database using exportConcurrent or importConcurrent commands

You can migrate the database of Engineering Lifecycle Management applications from one vendor to another.

1. Stop all Engineering Lifecycle Management servers.
2. Use the exportConcurrent repotools command to export the data.
   /server/repotools_[app] -exportConcurrent -clean multipleZips toFile=../export/[app].zip.

   Statistical information about the migration is collected and saved in the repotools log. This information can be used by IBM Support for troubleshooting.

   Note: The statsLogFrequency parameter is used to change the default logging period to once in 60 minutes.

   /server/repotools_[app] -exportConcurrent -clean multipleZips toFile=../export/[app].zip statsLogFrequency=60

   To ignore the statistical data when you are exporting the data, use the following commands:/server/repotools_[app] -exportConcurrent multipleZips statsEnabled=false -clean toFile=../export/[app].zip/server/repotools_[app] -exportConcurrent multipleZips statsEnabled=no -clean toFile=../export/[app].zip

3. Check the logs for any errors and runtime statistics.
   /server/repotools_[app]_exportConcurrent.log
4. Update the Engineering Lifecycle Management server with the new database settings.
   You can set up a new Engineering Lifecycle Management server, which is of the same version as the exported Engineering Lifecycle Management data, or use the existing Engineering Lifecycle Management server from which you exported the data. If you are using the existing Engineering Lifecycle Management server, you must back up the teamserver.properties files. These files are used in the compare repotools command.

   If you set up a new Engineering Lifecycle Management server, ensure that you use the same URI by changing the IBM HTTP Server (IHS) configuration. Update the following properties in the server/conf/[app]/teamserver.properties file to point to the new location:

   com.ibm.team.repository.db.vendor com.ibm.team.repository.db.jdbc.location com.ibm.team.repository.db.jdbc.password

5. Import the data by using the importConcurrent repotools command.
   /server/repotools_[app] -importConcurrent -clean fromFile=../export/[app].zip

   Statistical information about the migration is collected and saved in the repotools log. This information can be used by IBM Support for troubleshooting.

   Note: The statsLogFrequency is used to change the default logging period to once in 60 minutes.

   /server/repotools_[app] -importConcurrent -clean fromFile=../export/[app].zip statsLogFrequency=60

   To ignore the statistical data when you are exporting the data, use the following commands:/server/repotools_[app] -importConcurrent statsEnabled=false -clean fromFile=../export/[app].zip/server/repotools_[app] -importConcurrent statsEnabled=no -clean fromFile=../export/[app].zip

6. Check logs for any errors and runtime statistics.
   /server/repotools_[app]_importConcurrent.log
7. Rebuild the database indexes.
   The database indexes are not rebuilt automatically when the [skipRebuildIndices] argument is present in the concurrentImport command. If the database indexes are not rebuilt, run the -rebuildIndices command in the imported environment.

   /server/repotools-[app] -rebuildIndices

8. Clear the execution plans for the imported database.

   Database	Steps
   Oracle	Run the following command: alter system flush shared_pool;
   Db2	Connect to the database. Create a script to clear the execution plan, for example: db2 -x "SELECT 'RUNSTATS ON TABLE ' || TRIM(TABSCHEMA) || '.' || TRIM(TABNAME) || ' AND INDEXES ALL;' FROM SYSCAT.TABLES WHERE TYPE = 'T' AND TABSCHEMA NOT LIKE 'SYS%' ORDER BY TABSCHEMA, TABNAME"> db2_runstats.sql.out Ensure that the db2_runstats.sql.out table contains the names of all the tables on which you want to run your script. Run the script by using the db2 -tvf command, for example: C:\IBM\SQLLIB\BIN>db2 -tvf db2_runstats.sql.out> outcomestats.txt

9. Use the -compare repotools command to ensure no discrepancies between the source and the target databases.
   ExportJazzServerInstall/server/repotools_[app] -compare target.teamserver.properties=/opt/IBM/ImportJazzServerInstall/server/conf/jts/teamserver.properties
   You must run the -compare command in the test environment before you migrate the data in the production environment. Do not run the -compare command in the production environment because the downtime required might be too long. The -compare command performs an exhaustive cell-by-cell comparison of the source and the target databases. Two teamserver.properties files are required, one that contains the connection information of the source database and another that contains the connection information of the target database. Ensure that both the databases are accessible from the Engineering Lifecycle Management server.

   Important: Do not start your Engineering Lifecycle Management applications that use source or target databases before the -compare command finishes. If you use any of the Engineering Lifecycle Management applications, they might update the data in the databases and create a false positive in the compare log.

   For better performance, indicate the MS SQL server database in the source.teamserver.properties argument and the Oracle or Db2 database in the target.teamserver.properties argument.

10. Run the -verify command to check the integrity of the databases.
    /server/repotools_[app] -verify level=5

    Note: If you applied any migration patches, you must remove them and restore the original patches before you run the -verify command.