It's all about the answers!

Ask a question

How long do repotools -rebuildIndices take to run?


John Owen (462122) | asked Jan 15 '13, 4:04 a.m.
retagged Jul 08 '13, 11:40 a.m. by Jennifer Cianchetta-Riordan (2512)
We've just upgraded a repository to Jazz V4.0.0.1 and the diagnostics are displaying:

CRJAZ2055W Some indices were missing from the database, and missing indices can negatively impact application performance. To add the missing indices, you should stop your server and execute the -rebuildIndices command in repotools.

I'd like to understand how long this command takes to run.  I realise that this is going to be dependent upon a host of factors including the size of the database and the CPU available on the server but are there any guidelines at all??

Accepted answer


permanent link
Rosa Naranjo (2.8k11420) | answered Jan 15 '13, 11:49 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Chances are your 4001 upgrade install location just can't find the index locations of the previous installation.  We tried to provide information in the interactive upgrade guide that allowed you to be more cognizant of your existing index location prior to upgrade so such that during the upgrade, the indices would either 1) remain in their existing 'stable' locations and be accurately pointed at from the teamserver.properties or 2) be copied from their existing locations to a new location specified in the 'new' teamserver.properties file of the upgraded software. 

Just look for this line in both your JTS and <app-specific> teamserver.properties, where app is ccm or qm:
com.ibm.team.fulltext.indexLocation.

Here is an excerpt from the
v4.0.1 infocenter on verifying your index locations prior to upgrading:

Before you start the upgrade, verify that the index locations in the application's properties files are pointing to absolute paths on the file system, rather than relative paths.

  1. For Jazz Team Server, go to old_JTS_install_dir/server/conf/jts and open teamserver.properties file for editing.
  2. For Change and Configuration Management application, go to old_CCM_install_dir/server/conf/ccm and open teamserver.properties file for editing.
  3. Search for the com.ibm.team.fulltext.indexlocation line.
  4. If the location is a relative path, the indices will be located relative to the WebSphere Application Server profile hosting the applications. Change the location to an absolute path:
    • For Jazz Team Server, enter com.ibm.team.fulltext.indexLocation=WAS_Install_Dir/appServer/profiles/Appsrv01/conf/jts/indices/workitemindex where WAS_Install_Dir is the WebSphere Application Server installation directory and Appsrv01 is the application server profile name.
    • For Change and Configuration Management application, enter com.ibm.team.fulltext.indexLocation=WAS_Install_Dir/appServer/profiles/Appsrv01/conf/ccm/indices/workitemindex where WAS_Install_Dir is the WebSphere Application Server installation directory and Appsrv01 is the application server profile name.
  5. During the upgrade, after the properties are merged, the script opens the version 4.0.1 teamserver.properties file so that you can preview the properties. In the version 4.0.1 teamserver.properties file, change the location of the index files to an absolute path of a stable location on your drive. A stable location is a directory that will not be deleted when an application is uninstalled. The absolute stable location should look like this example:
    • com.ibm.team.fulltext.indexLocation=JTS_4.0.1_install_dir/server/conf/jts/indices/workitemindex where JTS_4.0_install_dir is the location where Jazz Team Server 4.0.1 application is installed.
    • com.ibm.team.fulltext.indexLocation=CCM_4.0.1_install_dir/server/conf/ccm/indices/workitemindex where CCM_4.0_install_dir is the location where Change and Configuration Management 4.0.1 application is installed.
    The script then copies the indexes from the previous installation location to the new version 4.0.1 stable directory.

John Owen selected this answer as the correct answer

Comments
John Owen commented Jan 15 '13, 11:57 a.m. | edited Jan 15 '13, 11:58 a.m.

Thank you for your append Rosa.

Just to clarify does the repotools -rebuildIndices command rebuild the database indices (i.e. DB2 indexes) or indices stored in the filesystem (as described above)?


1
Rosa Naranjo commented Jan 15 '13, 12:04 p.m.
FORUM MODERATOR / JAZZ DEVELOPER

4 other answers



permanent link
Javier Paez (464) | answered Jul 17 '14, 4:13 a.m.
Hello
I'm involved in a RTC 4.0.6 migration project,
these are the times of the repotools commands:

Hardware specifications:
    WAS 8.5.5 + DB2 10.1 Server
        RHEL 6.5 / 64 bits
        8GB RAM
        2 CPU (4 cores) Pentium XEON 50110 1.6GHz

DD.BB Sizing:
    JTS DB about 11GB
    CCM DB about 48GB

On JTS:
    ./repotools-jts.sh -reindex                     --> 1 min.
    ./repotools-jts.sh -rebuildTextIndices   --> 30 sec.
    ./repotools-jts.sh -rebuildIndices          --> 30 sec.

On CCM:
    ./repotools-ccm.sh -reindex                    --> 55 min
    ./repotools-ccm.sh -rebuildTextIndices  --> 40 min.
    ./repotools-ccm.sh -rebuildIndices         --> 15 min.

Comments
John Owen commented Jul 17 '14, 4:38 a.m.

Thank you for sharing your answer Javier.


permanent link
Clement Liu (1.5k54149) | answered Jul 07 '13, 9:51 a.m.
My two cents - our RTC DB has about 35 GB data and rebuildIndices took about 30 mins. Because it is just creating DB indexes, it won't take as much time as rebuildTextIndices which usually took hours.

Comments
John Owen commented Jul 08 '13, 4:18 a.m.

Thank you for your feedback Clement.


permanent link
Guido Schneider (3.3k137699) | answered Jan 15 '13, 5:24 a.m.

I just did it a week ago.

On JTS:

  • -renidex  9min50 sec
  • -rebuildTextIndices  24sec (one NPE exception)
  • -rebuildIndices  33sec

On CCM:

  • -renidex  41sec
  • -rebuildTextIndices  8h9min50sec
  • -rebuildIndices  crashed (open PMR)
  • -rebuildClosureTable  1h6min50sec

On QM:

  • -renidex  31sec
  • -rebuildTextIndices  1min5sec
  • -rebuildIndices  3min50sec

Sizing info of my environemnt:

  • JTS DB about 2GB (incl. RM)
  • CCM DB about 4GB
  • QM Db about 1GB
  • Application Server:
    • Windows2008-R2/64
    • 24GB Ram
    • 4 core
  • DB Server
    • Windows 2008R2/64
    • DB29.7
    • 24GB Ram
    • 4Core
  • 1GB Network between the two servers

Remark:

  • The long time on CCM for the -rebuildTextIndices is suspect. This I will retry another weekend.
  • open problems with NPW's on -rebuildIndices on CCM and JTS 

Comments
Ralph Schoon commented Jan 15 '13, 5:34 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Thanks for sharing Guido.


1
Guido Schneider commented Jan 15 '13, 5:47 a.m.

your welcome.

Hope to earn some reputation points. This year goal is to be over 2000 and on first page of the users list.

:-)


permanent link
Ralph Schoon (55.5k23642) | answered Jan 15 '13, 4:27 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Jan 15 '13, 5:35 a.m.
Hi John,

please be careful which index command you run. One is creating the index on the database tables and typically not intended to be run by a user (I have been told). We are in the process of updating articles (the backup articles) and creating new content, based on recent information we gathered about the indexing story.

I can't give you an idea about how long it takes to recreate the indexes. I think you might have to try. It would be good if you measure how long it takes.

Here a summary of reindex commands with our latest information:

Recreate the Fulltext Index

You can recreate the Fulltext index files using the command:

repotools-${APP} -rebuildTextIndices

Recreate the JFS Index

You can recreate the JFS index files using the command:

repotools-${APP} -reindex all


Comments
Ralph Schoon commented Jan 15 '13, 4:29 a.m. | edited Jan 15 '13, 4:30 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I just realized you are missing the database indexes. I am unsure how that could have happened. I would suggest to talk to support to find out how that could have happened and be prevented to happen in the future.


John Owen commented Jan 15 '13, 7:08 a.m.

Thanks for your reply, Ralph.  All we need to do is rebuild the the indices using the -rebuildIndices option of the repotools command. I've done some further exploring.  Sam had to do this on another repository last weekend it took about 15 minutes for the ccm application which comprised a 35GB database.

I am now running the same command on a 70GB database for another repository and will provide details of how long that takes.


1
John Owen commented Jan 15 '13, 12:26 p.m.

The -rebuildIndices has completed on the 70GB /ccm database and it took about 30 minutes to run.


Ralph Schoon commented Jan 16 '13, 4:35 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Hi John, thanks for the update. I am still curious how comes the database indexes got messed up. Did anyone work directly on the database and changed policies or maintenance settings? Was this caused by an issue with the database? I just want to make sure this is not a symptom of a lingering problem somewhere.

Your answer


Register or to post your answer.