Options and methods to optimize repotools export and import performance in the Rational solution for Collaborative Lifecycle Management
Boris Kuschel, Jazz Jumpstart Team & Gerald Mitchell, Global Response Team
Last updated: January 26, 2012
Build basis: Collaborative Lifecycle Management 3.0.1 (2011)
NOTE: These techniques are for repotools export/import migration purposes only and the configurations are not recommended as permanent changes to the structure of the Rational solution for Collaborative Lifecycle Management. Also note that in the majority of cases, it is recommended to use the repotools ‘-addTables’ option and re-use the existing database where possible when looking to reduce the migration process time. This article is meant for situations where this is not possible. There are some instances where these techniques are not possible due to the lack of middle ware support for the RDBMS operation system or other data requirements. Proceed at your own discretion.
Options specific to Rational Quality Manager (RQM) 188.8.131.52 iFix5 migration to RQM 184.108.40.206
If performing an RQM 220.127.116.11 iFix5 to RQM 18.104.22.168 migration then please take note of the new options that can increase the performance of the operation.
Using these options it has been found, through internal testing, that a performance gain of 20-30% has been observed for a migration. This can be higher or lower as results may very depending on the particular data mix of the repository.
For RQM 22.214.171.124 iFix5 export:
In the repotools(.sh/.bat) located in the <middleware install directory>/server after the following line:
Add the following two lines :
DEFINE="$DEFINE -Dcom.ibm.rqm.migration.options.exportHistoricalArchivedStates=false" DEFINE="$DEFINE -Dcom.ibm.rqm.migration.options.exportHistoricalStates=false"
This will skip data that is inaccessible from RQM in normal operations, namely historical states and historical states that have been archived. This should be acceptable in a vast majority of cases and will reduce both the time and size of the export and consequently the time required to do a subsequent import as well. There will be cases, due to auditing and data retention requirements, which may require this data to be retained in the database, even it it is inaccessible. Verify that this is not the case before using these options.
For RQM 126.96.36.199 import:
In the repotools-jazz(.sh/.bat) located in the
Add the following line:
This option skips rebuilding the Lucene Index as part of the export procedure. It should be noted that if the index is not rebuilt then quick search results for work items may not return accurate results until the indexes have been rebuilt manually using:
The actual procedure for export and import remains unchanged other then the modifications and extra step post-import for creating the text indices.
Collocated export and import
Fig 1. Standard Export operation
Fig 2. Standard Import operation
For the migration of medium and large databases to Rational solution for Collaborative Lifecycle Management 2011, it may be necessary to collocate the middleware with the database server in order to reduce the time required for the repotools export and import. One technique that can be used is to reduce the network latency between the CLM middleware and database servers (the RDBMS and the database) is to move or collocate the middleware on the same server (thereby eliminating network latency)
There are a couple of approaches that can be applied, depending on the availability and capability of available systems. We have found through internal testing that 20-30% improvement in the time to do a complete migration in some cases. This can be higher or lower as results may very depending on the particular data mix of the repository and the topology and systems used.
Reducing the latency between network hops and increasing the throughput can result in a much faster migration. This can be done by reducing or eliminating the network infrastructure the CLM, DB, and SAN systems, and putting the systems on the same subnet, or even better, eliminate network concerns all together by placing the middleware on the same server as the RDBMS.If RDBMS server operation system is the same as the middleware:
- Compress the CLM middleware directory (JazzTeamServer, for example) using zip, tgz or something similar and uncompress it into same location on the filesystem of the database server.
- Install a fresh copy of the middleware for the RDBMS’s OS version. Do not perform setup after install is complete.
- Copy the teamserver.properties file from the middleware to the corresponding location on the database server. <middleware install directory>/server/conf/jazz, for example.
- Edit the teamserver.properties file and ensure any hard coded absolute paths are pointing to the correct path on the RDBMS server middleware install. These include entries such as file://C:/ and C:/, for example if moving from windows to unix. These should be changed to point to the correct unix paths on the RDBMS new middle ware install. Properties that may need to be changed include:
- If an RQM 2.x to 3.x migration is to be perform it is better to ensure that the disk being used for the export or import tar file is not shared by the database server, either the database executable files or the tablespace files. This will reduce disk contention.
- For export, perform:
repotools -export toFile=migration.tar logFile=export.logor for import:
repotools -import fromFile=export.tar logFile=export.log
Fig 3. Collocated Export operation
Fig 4. Collocated Import operation
For more information
- The Jazz metronome tool keeps us honest (A performance debugging tool for RTC)
- Collaborative Lifecycle Management 2011 Sizing Guide
- Rational Team Concert 3.0 sizing guide
- Tuning the Rational Team Concert 3.0 server
- Rational Quality Manager 3.0.1 server sizing guide
- Rational Requirements Composer 3.0.1 server sizing guide
Copyright © 2012 IBM Corporation