Learn to determine need of re-indexing on version upgrade in EngageOne Vault

UPDATED: July 28, 2017

In most cases when upgrading EngageOne Vault versions from 5.4 through 7.4.1, no changes to the indexes are required.

There are a few exceptions as following:
1) Unicode index sort order changes from 7.0:
Version 7.0 introduced a new version of the Unicode libraries we use (ICU). This version updated the underyling tables and behavior used to sort Unicode data. In some cases this could affect the order of index entries in Vault Unicode indexes.
Typically if using a Unicode index by the presence of LanguageDefault of LanguageN settings in database.ini with a value other than "*":

; Unicode indexes and account table, Greek sort order
See "Updating unicode indexes" in a 7.0 or later EngageOne vault Customizing Guide provided with installer package.
2) Taking advantage of Indexer as a Service (aka indexerd):
Later versions of Vault introduced a separate process to handle indexing operations: indexerd.
Using indexerd is optional but is worth considering. Indexes using indexerd are in a different format and have different requirements but come with some advantages.
Indexerd based indexes are normally considerably faster than Vault's standard indexes. They also have commit points that they can roll back to in order to maintain consistency in the event of system crashes. Migrating to indexerd indexes could be done using a full reindex but it isn't necessary in most cases.
It is usually possible to use the indexcheck utility to copy data from a standard index to an indexerd index, a process that is much faster than reindexing.
See section 'Vault Indexer as a Service' in a 6.0 or later EngageOne vault Customizing Guide provided with installer package.
3) Damaged or suspect indexes:
If some sort of consistency or integrity of the indexes is there, may want to consider reindexing (or at least reconstructing the indexes with indexcheck's copy operation).
Normally a full reindex is extremely time consuming. One thing that can help is to switch to indexerd to take advantage of the improved speed of indexing.
4) Splitting Vault instances:
In some cases business reasons arise that require a Vault instances be split or merged (for example a business unit being sold to another company). In those situation, it may be appropriate to take the data (drd/drp/jrn) for the new instance and rebuild the indexes from scratch. The alternative, large scale purging, can leave slack in the index files that wastes space and reduces performance.



  • No Downloads