Jazz Library Options and methods to optimize repotools export and import performance in the Rational solution for Collaborative Lifecycle Management
Author name

clm,elm,test-management,workflow-management,rational-quality-manager,rational-requirements-composer,rational-team-concert

Mon, 30 Jan 2012
5 min read
0

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)

This page describes a usage or software configuration that may not be supported by IBM.

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) 2.0.1.1 iFix5 migration to RQM 3.0.1.2

If performing an RQM 2.0.1.1 iFix5 to RQM 3.0.1.2 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 2.0.1.1 iFix5 export:

In the repotools(.sh/.bat) located in the <middleware install directory>/server after the following line: 

DEFINE="$DEFINE -Djava.awt.headless=true"

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 3.0.1.2 import:

In the repotools-jazz(.sh/.bat) located in the /server after the following lines: 

DEFINE="$DEFINE -Djava.awt.headless=true"

Add the following line: 

DEFINE="$DEFINE -Dcom.ibm.rqm.migration.options.createLuceneIndex=false"

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: 

repotools-jazz(.sh/.bat) -rebuildTextIndices

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
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:

  1. 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.
or if the RDBMS server operation system is different then the middleware:
    1. Install a fresh copy of the middleware for the RDBMS’s OS version. Do not perform setup after install is complete.
    2. Copy the teamserver.properties file from the middleware to the corresponding location on the database server. <middleware install directory>/server/conf/jazz, for example.
    3. 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:
      • com.ibm.team.fulltext.indexLocation
  2. Since network latency will be less of a concern in such a situation, it is important to ensure there is no disk contention as disk I/O is usually the next most common bottleneck encountered.
    1. 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.
    2. For export, perform: 
      repotools -export toFile=migration.tar logFile=export.log
      or for import: 
      repotools -import fromFile=export.tar logFile=export.log
    Fig 3. Collocated Export operation
    Fig 3. Collocated Export operation
  3. (Import only) After an import has been performed return to the original middleware and rebuild the text indexes otherwise results from quick searches may not be accurate. (In the case of the RQM option above that disables rebuilding of text indices as part of export, this will have to be done anyway but in this case on the original operational middleware.) 
    repotools-<context>(.sh/.bat) -rebuildTextIndices
    Fig 4. Collocated Import operation
    Fig 4. Collocated Import operation

For more information

Copyright © 2012 IBM Corporation

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Mon, 30 Jan 2012