It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,857
×6,027
×4,308
×1,381

question asked: May 22 '17, 3:18 a.m.
question was seen: 3,599 times
last updated: Jun 13 '17, 4:06 p.m.

Related questions

When is rebuildIndices required and when is reindex -all enough

1
Ian Wark (797●1●35●53) | asked May 22 '17, 3:18 a.m.
retagged Jun 13 '17, 4:06 p.m. by Ken Tessier (841●1●7)

We had a diagnostic error CRJZS5884E under /jts/admin in the JFS Indices section, so performed a repotools-jts.bat -reindex all to recreate the JFS indices. After doing that the error message changed, but this time we received CRJZS5756E error in the JFS Indices section of diagnostics. So then we decided to do

1. repotools-jts -rebuildIndices
2. repotools-jts -reindex all

This resolved the second error. So our question is .. Why did we have to do -rebuildIndices to get rid of the diagnostic error in JFS Indices section? In the help it says that Database Indices section errors need -rebuildIndices, but it doesn't mention other sections.

We are thinking that some of "JFS Indices" diagnostic errors are referenced from the database (e.g. DB2) instead of just the file system. Could someone explain? In the below article it talks about Item Query Services that seem to rely on the database. Does "JFS Indices" section report issues in these services?

https://jazz.net/library/article/1271

3 answers

Most liked answers|Newest answers|Oldest answers ↑

0
permanent link
Arun K Sriramaiah (3.2k●2●36●77) | answered May 22 '17, 10:22 a.m.

Hi Ian,

Please refer https://jazz.net/library/article/1272 you will find additional information.

Let me know if you still have any questions.

Regards,
Arun.

Comments
Geoffrey Clemm commented May 22 '17, 2:18 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Note that article 1272 does not talk about -rebuildIndices, so doesn't appear to help with this question.

0
permanent link
Kevin Ramer (4.5k●9●186●201) | answered May 22 '17, 5:07 p.m.

From the repotools help.log

   -rebuildIndices --Rebuild the database's indices.


So that option works on the database corresponding to whatever application "belongs" to repotools.   My interpretation is that existing table indices are dropped and recreated, thereby also making them "up-to-date", perhaps making them more efficient.

Does your DBMS (database management system ) provide facility to automatically keep indices "efficient" ?
DB2 has via these database settings:


 Automatic maintenance                      (AUTO_MAINT) = ON
   Automatic database backup            (AUTO_DB_BACKUP) = OFF
   Automatic table maintenance          (AUTO_TBL_MAINT) = ON
     Automatic runstats                  (AUTO_RUNSTATS) = ON
       Real-time statistics            (AUTO_STMT_STATS) = ON
       Statistical views              (AUTO_STATS_VIEWS) = OFF
       Automatic sampling                (AUTO_SAMPLING) = OFF
     Automatic reorganization               (AUTO_REORG) = ON



Comments
Ian Wark commented May 22 '17, 9:47 p.m.

Thanks for the feedback. The problem here is not efficiency in the DB2 indices but an error in the diagnostic page -- and what causes it to disappear. I suppose we mainly have two questions:

1. Does repotools reindex -all command do anything to alter the DB2 indices? Or does it ONLY regenerate the Jena and text index files?

2. Do you need to do both repotools rebuildIndices and repotools reindex -all to completely regenerate JFS indices?

I notice in the recent help that we are recommended to do both, so I get the feeling that the two are complementary.. but until this happened I thought that reindex -all was enough to completely fix JFS index problems. See here for example:

https://jazz.net/help-dev/clm/index.jsp?topic=%2Fcom.ibm.jazz.install.doc%2Ftopics%2Ft_migrate_dbs.html

1
permanent link
Ian Wark (797●1●35●53) | answered Jun 06 '17, 6:11 a.m.
edited Jun 07 '17, 8:02 p.m.

I checked RTC source code. What I found makes sense, so I'll report here.

The "JFS Indices" diagnostic information does reference the database (e.g. DB2, Oracle) indices. There is a check to see if the Jena index store last processed timestamp is newer than the last modified timestamp of the database. If this happens it means that there are resources not yet in the database and it throws an index ahead of database error (CRJZS5756E). It just happens that the database unreachable error (CRJZS5884E) only has one cause, which is that it was not possible to obtain the latest last modified timestamp of the database for this test because a TeamRepositoryException was thrown.

So we can explain this behaviour now.

1. There was a temporary problem accessing the database indices, so diagnostic processing failed to obtain the database timestamp and displayed the CRJZS5884E error.
2. Then due to having performed repotools reindex, the Jena index store was newer than the database indices, so we received a diagnostic error CRJZS5756E.
3. So it was only when the database was updated with repotools rebuildIndices command that the timestamp test passed. This is because repotools reindex will only regenerate the Jena index store. repotools rebuildIndices is required to drop and recreate the database indexes. [It looks like rebuildIndices only impacts on the database indices.]

Your answer

Register or to post your answer.


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.