Testing and operational considerations

Persisted indexes, FILE indexes are designed to retain built indexes between server resets.

The data also persists between database rebuild operations, and this may cause issues for testers if index data becomes inconsistent with the current database.

Similarly, in an operational setting, if database updates occur without search index updates being enabled in the application (via the "curam.lucene.luceneOnlineSynchronizationEnabled" property) the data in the index will become out of date and problems may occur.

In the event of either of the above scenarios, persisted data can be removed manually from the database by dropping all database tables that begin with "GSS_" (there will be one table for each Search Service). The persisted indexes will be rebuilt as normal when an extract or persist operation is run.

In the case of a FILE index the file may be deleted, and in the event of a standard RAM search service encountering such issues, rerunning the extract process will fix the problems.