When should the revisions be reset on the Indexer and Search Runtimes and how is it done? (Doc ID 1464763.1)

Last updated on DECEMBER 20, 2016

Applies to:

Oracle Knowledge - Version 8.1.2.1 and later
Information in this document applies to any platform.

Goal

When revisions are reset on the indexer all these parts of the process are being reset :

  - The full index - this means a completely new index will be created

  - The logs

  - The bundles (files synchronized to the runtime)

  - The dictionary being used for crawling.

There are several key indicators that a reset of the revisions on the Indexer and Search Runtimes may be advisable:

1) The indexer or workclients start failing with Log_Store_Exceptions or UserData exceptions or your crawl has failed with OOM or some unexpected circumstance and your crawl cannot recover.

2) When Indexer jobs start failing at the Synchronization task with with messages that hint at corrupted or missing revision *.xml files such as:

[59 DeployerThread (1)] UNKNOWN MESSAGE ID "REVISION_PARSE_FAILED" called with: "<INQUIRA_INSTALL>\instances\<app>\<env>\content\data\revision\default\revision\00025882.xml" "com.inquira.util.xml.NodeBuilderException: Premature end of file.(-1:-1)"
com.inquira.util.xml.NodeBuilderException: Premature end of file.(-1:-1)
 at com.inquira.util.xml.AbstractNodeBuilder.process(AbstractNodeBuilder.java:247)
 at com.inquira.util.xml.AbstractNodeBuilder.process(AbstractNodeBuilder.java:223)
...

3) When the accumulation of past revisions and bundles has resulted in considerable grown in the consumption of disc space over time. (It is recommended that the disc space consumed by the Indexer and Runtime instances is monitored as part of normal good housekeeping practices.)

4) When the indexer (and/or runtimes) revisions were partially corrupted due to unexpected filesystem failure (like out of disk space, network mounted folder unreachable, ...)

If any of these conditions arise then it is necessary to manually reset revisions and bundles and re-process all the collections.

 

NOTE:  This process requires a downtime on the runtimes to resynch the new index where there is no correlation to an older revision. 

If you want to avoid a downtime and you have more than one runtime you can divide your runtimes into groups, create synch groups for them (How do I set up multiple synch groups? (Doc ID 1039409.1)) and then take one group off the loadbalancer, synch to it, then put it back on, and take the next group off and synch to it and so forth.  This will allow you to not have a downtime on the end user side

.

 

Solution

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms