OVERVIEW:
This document is to assist the Enterprise Vault Accelerator Administrator to properly monitor and maintain the Accelerator environment.


Step 1: Standard Maintenance

The number one action to perform in order to maintain a healthy Accelerator environment is to perform weekly Sql maintenance on the Accelerator customer database(s).  The recommended actions are:

- Rebuild Indexes
- Update Statistics
- Shrink databases

To monitor the overall effectiveness of the weekly maintenance, run the following SQL command against each of the Accelerator customer databases:

DBCC SHOWCONTIG

Examine the results for tables that have over 1,000 pages scanned.

- Extent Switches - Value should be 1 less then Extent Pages Scanned
The higher this value is above the Extent Pages Scanned, the more fragmented the page order
- Logical Scan Fragmentation - under 1%  
Latency occurs once logical scan fragmentation exceeds 10%
Once fragmentation exceeds 50%, indexes are no longer used
- Extent Scan Fragmentation - under 50%
- Avg. Page density (full) - over 90%

If the results exceed those limits, it is recommended to perform the action more frequently.
*** Note:  Active searches and productions lock tables from maintenance.  If there are active searches or productions during the maintenance routine the maintenance will skip those locked tables and complete.  The tables will remain fragmented and no performance gain will be realized.  It is recommended to STOP the Enterprise Vault Accelerator Manager service prior to performing the maintenance run.


Step 2: Transaction log growth

Tempdb and Accelerator customer database transaction logs grow rapidly in an active Accelerator environment.  Under nominal usage, running the weekly maintenance will avoid issues involving the transaction logs, but preemptive steps can be taken to accompany the weekly maintenance.

- Set the Autogrowth to Unrestricted File Growth and File Growth In Megabytes: 200
- Verify there is ample space for the transaction logs to grow.
- Verify the transaction logs for the Tempdb and Accelerator customer databases are able to grow.


Step 3: SQL utilization

Several Accelerator procedures such as Searching, Reviewing, Productions and Legal Hold processes require a considerable amount of SQL resources.  When a SQL server is over utilized deadlocks on the database tables can occur frequently and lead to SQL time outs.  If SQL time outs or Deadlocks are an issue and the first two steps in this document are being followed, it is recommended to move the Accelerator databases to a dedicated SQL server.

To monitor the SQL server for deadlocking issues, start and monitor a SQL Profiler while performing daily activities.

The Profiler should remain empty or very limited activity.  


Step 4: Active Accelerator Searches

Monitoring of active Accelerator searches is essential to Accelerator environmental health.  The following SQL script can be run against each of the Accelerator customer databases to show 'Active' processes:

SELECT tc.[Name] AS 'Case Name', tis.[Name] AS 'Search Name', tis.StatusID, tis.RunDate
FROM tblIntSearches tis
JOIN tblCase tc ON tc.CaseID = tis.CaseID
WHERE tis.StatusID IN (2, 5, 6)

-- Status Codes
-- 2 = Searching
-- 5 = Deleting
-- 6 = Accepting

The status 2, 5 and 6 are active  Inspect the Run Date.  If the Run Date is over 24 hours old there is an issue that needs to be investigated and resolved.


Step 5: Accelerator Search in Pending Status

Neglect by Department/Case owners can cause millions of items from searches to be backlogged in the customer database awaiting some action to be performed by the end user.  Run the following SQL script against the Accelerator customer database to determine if searches are awaiting action:  

SELECT tc.[Name] AS 'Case Name', tis.[Name] AS 'Search Name', tis.StatusID, tis.RunDate
FROM tblIntSearches tis
JOIN tblCase tc ON tc.CaseID = tis.CaseID
WHERE tis.StatusID IN (3, 10)

-- Status Codes
-- 3 = Pending Acceptance
-- 10= Pending Acceptance (with errors)

Status 3 and 10 need user action performed, either accept or reject the search.  


Step 6: Export/Production Runs

Monitoring of active Accelerator exports is essential to Accelerator environmental health.  Run the following SQL script against each of the Accelerator customer databases.

SELECT tc.[Name] AS 'Case Name', tp.[Name] AS 'Export Name', tp.StatusID, tp.CreateDate AS 'Create Date'
FROM tblProduction tp
JOIN tblCase tc ON tc.CaseID = tp.CaseID
WHERE tp.StatusID IN (50, 51, 56, 57, 190, 191)

-- Status Codes:
-- 50 = Preparing
-- 51 = Processing
-- 56 = Processing
-- 57 = Processing
-- 190 = To be Stopped
-- 191 = Stopping

The status of 50 and 51 are active.  If the Create Date is over 24 hours old a service call to Symantec technical support is suggested.  The other status codes refer to issues that need to be investigated by the Accelerator Administrator and resolved.  The problem might be a temporary communication issue  and can be resolved by restarting the Enterprise Vault Accelerator manager service and retrying the export.  

Step 7: Vault Service Account Temporary folder size

All transactions requests from the Accelerator environment to the Enterprise Vault (EV) server and the Accelerator server utilize the Vault Service Account (VSA) temporary folder for temporary storage.  This folder needs to be able to grow large enough to accommodate Batch processing on the Accelerator server and Index (Search) and Storage (Export) requests on the EV server.  Locating the VSA temporary folders on a hard drive with at least 20 gig free space availability is recommended for all EV and Accelerator servers.