How to determine which SQL tables to use for Indexing issues
|Article:HOWTO56248|||||Created: 2011-07-27|||||Updated: 2014-12-10|||||Article URL http://www.symantec.com/docs/HOWTO56248|
The following document aims to highlight the views that are available to the admin through SQL and discusses what each table provides.
Directory Database Views
This view contains entries for each Index Administration Task, including the Site and Computer that it is located on. Each Indexing Server will have an Index Administration Task, which controls the processing of indexing tasks on the server.
The IndexingSubTaskGroupSummariesView contains summary information for each indexing task that has been created. Information includes how many subtasks have been associated with the task and what state they are currently in e.g. how many verify subtasks are running, how many rebuild subtasks have failed.
For each entry in the IndexingSubTaskGroupSummariesView, there will be an entry containing information for each subtask. Information includes the subtask state, archive name, Indexing Server and the subtask’s current progress.
The State column is useful when you want to search for specific issues. The numeric column state values are as follows:
8. Controller is not running
11. Completed with warnings
13. Not in schedule
14. Waiting for user interaction
Information about all of the index volumes in the directory, including the archive that they are associated with.
• Index volume type e.g. 32bit or 64bit
• Indexing Levels
• Index volume location
• Index foldername – This is known as the collection name for 64bit index volumes
• Date of the oldest/youngest archived items
• Whether the index volume is offline/online/failed
• The number of items currently in the index volume
• The number of failed items for the index volume
• The number of extra items in the index volume
• Whether the index volume is currently hidden. If it is, it will not be available for searching
• Preview length for item and attachment content
• The WorkPending column is set to 1 when there are archived items that have been added/updated/deleted and the changes have not been updated in the index
This View contains information about Index Locations in the Directory. The main uses of this view is to find the physical path of each index location, determine the index location status (open/closed), Index Server name and confirming if backup mode has been successfully enabled/disabled on a specific index location.
Lists all index servers and the index group that they belong to. Where the IndexGroupName and IndexGroupEntryId are NULL, the index server is not associated with an index group.
This View contains information about each index volume in the Directory. This includes the index volume location and the name of the indexing server that uses that location to store its indexes.
Summary information relating to each indexing server. This includes the total number of index locations that are:
• Open and not in backup mode
• Open and in backup mode
• Closed and not in backup mode
• Closed and in backup mode
Directory Database Tables
Each EV Server and the cache location for each server. The setting of a cache location is compulsory for an indexing server.
This table contains all of the properties of Index groups that have been created.
This table stores information about all of the Vault Stores belonging to an Index Group.
This table stores all of the shareable resources, for example the Index Services that make up an Index Group.
Information on EV Servers that have a local indexing service. The information includes the location of the metadata corresponding to the Indexing Engine is stored on disk. If DR is performed and the EV location is altered, then this needs to be updated to reflect that as well.
Introduced to support the new indexing level settings in V10. This table contains the settings that are applied to each archive in the form of the Indexing Snippet Length, Indexing Level, Indexing Attachment Snippets and Enabling Faceted Results.
This table contains a row for each indexing subtask. A corresponding record will exist in the subtask table for each indexing subtask.
This table contains a row for each indexing task created via the wizard. One row in this table can contain multiple rows in the IndexingSubTask/SubTask tables. The information includes the time that the task was created, the type of task that it is and the total number of subtasks associated with the task.
Finding which index root path is associated with an index service and which indexing group this is associated with.
Contains the unique Identity of an Index root path.
Contains information relating to each index volume in the directory database. Searches can be formed based on whether they are 32bit, 64bit, hidden, have an optimum root path, are being deleted, are read-only, approximate size of an index volume or the failed volume reason.
Lists all index volumes that are to be deleted from the indexing engine. This will be used when an index volume is successfully rebuilt and when index volumes are deleted as part of archive deletion.
Contains the port on which EV service will be listening for client requests. Information also includes the number of days before indexing subtasks in the completed states are automatically deleted. Default is 7 days.
Contains the report information that is reported for each indexing subtask. Note that this is separated out so that each major event e.g. Retrying failed items is given its own entry in the database.
Vault Store Database Tables
Tables that are used when indexing new items (additions)
This table contains information about items that have been archived. If the item has not yet been sent for indexing, the IndexCommited flag is set to 0. Conversely, if the item has been sent for indexing and has been acknowledged by the indexing engine, then the IndexCommited flag is set to 1. When the flag is set to 1, the item could either have been successfully indexed or could have failed to be indexed.
This table contains records for items that are currently being added to the index. Successfully indexed items are removed from the table, except those that have missing content, which remain in the ItemAdditionStatusLog with the missing content reason stated in the ErrorNumber column. If there are items that have failed to be indexed, these will remain in the ItemAdditionStatusLog, until a subsequent retry is successful. After two further failed retry attempts, the poison pilled flag for the item will be set and the item will no longer be retried. Poison pilled additions will be retained in this table and will be retried when the index is repaired or rebuilt.
Tables that are used when deleting indexed items (deletions)
This table contains information about items that have been deleted from the archive. If the item has not yet been sent for deletion from the index, the IndexCommited flag is set to 0. Conversely, if the deletion has been sent to the index and has been acknowledged by the indexing engine, then the IndexCommited flag is set to 1. When the flag is set to 1, the item could either have been successfully deleted from the index or could have failed to be deleted from the index.
This table contains records for items that are currently being deleted from the index. Successfully deleted items are removed from the table. If there are items that have failed to be deleted from the index, these will remain in the ItemDeletionStatusLog, until a subsequent retry is successful. After two further failed retry attempts, the poison pilled flag for the item will be set and the item will no longer be retried. Poison pilled deletions will be retained in this table and will be retried when the index is repaired or rebuilt.
Tables that are used when indexed items are updated (updates)
This table contains information about items that have been updated in the archive. This includes when items have been moved to a different folder in the archive or the retention category has changed. If the item update has not been sent for updating in the index, the IndexCommited flag is set to 0. Conversely, if the item has been sent for updating in the index or the update will be ignored as a future update exists for the same item, then the IndexCommited flag is set to 1.
This table contains records for items that are currently being updated in the index. Successfully updated items are removed from the table. If there are items that have failed to be updated in the index, these will remain in the ItemUpdateStatusLog. These items will remain in a failed state until a subsequent update of the same item succeeds, the item is deleted or the index volume is rebuilt.
Article URL http://www.symantec.com/docs/HOWTO56248