Rebuilding the index for InfoSphere Information Server clients
You can rebuild the index to ensure that assets from Information Governance Catalog, InfoSphere® Information Analyzer, and InfoSphere Metadata Asset Manager are updated and displayed in each client.
Before you begin
- You must have the Suite Administrator role to complete this task.
- If you are planning to rebuild index due to missing synchronization, follow the instructions in this technote to troubleshoot indexing.
About this task
The index of assets is used during search operations and in the display of certain attributes
like the number of business terms that are associated with an asset. There are several instances
when you need to rebuild the index.
- If there are existing assets in the metadata repository when you install the clients, you must rebuild the index before you can view them in each client. If you are doing a new installation and no metadata was imported, it is not necessary to rebuild the index.
- If the index becomes out-of-sync or corrupted, you must rebuild the index. This can happen when there is a loss of communication between one or more suite components or when one or more components are temporarily uninstalled or not working. If you notice that tables in the metadata repository are not visible in the clients, your index might be out-of-sync or corrupted.
- If you run analysis on InfoSphere Information Analyzer data sets in the InfoSphere Information Analyzer workbench, you must rebuild the data set index before you can use that analysis information to search for data sets in the thin client.
- If you import InfoSphere DataStage® assets by using InfoSphere DataStage.
- If you delete a high level or parent asset in a hierarchy. For example, if you delete a host asset that contains a database and a database schema.
- When some asset types are not available in catalog search in Information Governance Catalog New after installation, or import of assets.
If your browser times out while rebuilding the index, you can set a higher time-out setting for your browser. For example, you can use the cURL command line tool to increase the maximum wait time for your browser.
- Performance recommendations
- The reindex operation runs either on Information Server Enterprise Search host, or on a services tier. It processes queries on XMETA database and sends results to Solr microservice. Therefore, the performance of the reindex operation depends on factors like computing capacity (like the number of CPUs, speed, availability) of services tier or Enterprise Search host and XMETA database, available memory, read and write speed, network speed, or Solr JVM settings.
Procedure
Example
For your reference, see the example values for the parameters and the performance results. Note
that the results are only an example, and even with the same system configuration the results might
differ depending on asset types, the number of assets, relationships between assets, and types of servers.
- Test on InfoSphere Information Server with Enterprise Search and Db2
- System configuration:
- InfoSphere Information Server version 11.7.1
- 48 processors (@2.50GHz, 12 cores)
- 125 GB RAM
- Red Hat Enterprise Linux Server, release 7.4
- batchSize: 1000
- solrBatchSize: 1000
- threadCount: 4 (default)
- maxWaitTime: 240 (default)
- Solr heap size: 1 G (default)
- Test on InfoSphere Information Server without Enterprise Search and with Oracle 12c
- System configuration:
- InfoSphere Information Server version 11.7.1
- 48 processors (@2.50GHz, 12 cores)
- 125 GB RAM
- Red Hat Enterprise Linux Server, release 7.4
- General recommendations
- In general, when the server tier or Enterprise Search host,
and XMETA database are configured correctly, and aren't busy, you can use the following values for
the reindex operation:
- Installation with Enterprise Search
-
batchSize=500
solrBatchSize=500
maxWaitTime=600
- Installation without Enterprise Search
-
batchSize=6000
solrBatchSize=3000
threadCount =12
or16
maxWaitTime=600