I don't understand all the different repotools indexing commands
5 answers
Use repotools -rebuildTextIndices when you have one of the following symptoms:
You run a quick search (the edit box in the lower left hand side of the thick client, or upper right side of the web client) for a workitem or planning item and the result isn't found as expected. Make sure there's also an error in the ccm.log or qm.log. The error often will reference Lucene. CRJAZ8201E is also a common symptom.
You may also see the problem above if you run a query that includes a full text condition as part of a larger query. In either case, use repotools-qm.bat or repotools-ccm bat to reindex depending on which application is failing.
You run a quick search (the edit box in the lower left hand side of the thick client, or upper right side of the web client) for a RM requirement, and you don't get the result you expected. The error often will reference Lucene.
When reindexing use repotools-rm.bat for RM issues.
You open a view in RM or Open a dashboard and you don't get the result you expected and there is an error in the application log (rm.log or jts.log ) indicating the index is corrupt. The error often references Jena.
You look at the application diagnostics page and see an error reported for JFS index or JFS storage, and when you look at the application log file (rm.log, jts.log, ccm.log - but only if you're using Enterprise Extensions), and you see an error. The error often references Jena.
Use repotools -rebuildIndices when you see an error in the Database Indices section of the diagnostics.
Use repotools -synchronizeJFSIndexes if the index is found to be corrupt via repotools -verifyJFSIndexes.
Here are the steps to fix the corruption. Restore the most recent indices that pass repotools -verifyJFSIndexes, then run repotools -synchronizeJFSIndexes to catch the indices up with the underlying database.
Here's some background explaining how repotools -verifyJFSIndexes and repotools -synchronizeJFSIndexes work. Each time you save an artifact in RM, it's stored twice - once in the database, and once in the filesystem Jena indices.
When you open an artifact (e.g. a requirement), the requirement is fetched from the database. When you open a RM view, RM queries the indices via Jena indices. The indices need to be in sync with the database. When you restore the indices, but not the database, you need to sync the indices to to the database via repotools -synchronizeJFSIndexes.
Don't use repotools -reindex scope=all. Instead use repotools -reindex all.
@GlennBardwell
Could we also have some inputs on the functionality of -compacttdb --Compact the RDF indexes too on this very comment?
If the reindex is reducing the size of the indices to half and so does -compacttd, what is it that this command does? Is there any specific switch with -verifyJFSIndexes that could prompt the admins to opt for a compacttdb?
Could we also have some inputs on the functionality of -compacttdb --Compact the RDF indexes too on this very comment?
If the reindex is reducing the size of the indices to half and so does -compacttd, what is it that this command does? Is there any specific switch with -verifyJFSIndexes that could prompt the admins to opt for a compacttdb?
Comments
1 vote
Hi Rosa,
as an answer here:
- Part 1: Query, Search and indexing technologies in CLM
- Part 2: Indices storage and management: Backup, recovery and recreation
With respect to your question, there is an issue that customers have reported where Back links from RTC to DNG are missing. L3 has created a follow up action that fixes this. There is a task to integrate the code into the work item command line to be able to run fix runs.