An EVSVR ArchivesDirectory Repair operation fails to change the ArchivePoint type from Shared to Mailbox

Problem

EVSVR is used to help in repairing Enterprise Vault (EV) SQL Database Inconsistencies, for example following a Disaster Recovery scenario involving a restore of an older version of the SQL Database.
The ArchivesDirectory repair option helps in synchronizing the  Archive (ArchivePoint) and ArchiveFolder (Vault) records between the EnterpriseVaultDirectory and VaultStore Databases.

When configuring the options for a ArchivesDirectory Repair, the ArchiveType needs to be specified. I.e.:

1. ExchangeMailbox
2. FileSystem

As part of an upgrade since EV10.0.0 , archives which are inconsistent across the EnterpriseVaultDirectory and Vaultstores databases will be marked as Shared. During an ArchivesDirectory Repair, EVSVR will validate if the Archive is really a Shared Archive, and reset the type accordingly.
However, recreating Archives may mail as EVSVR fails to change the ArchiveType if:

1. There is more than one Archive to repair,
2. More than 1 thread has been configured for the repair

Error Message

EVSVR Log Snippets

1.  During Step 1 of the EVSVR Repair a summary of Archives present in the Vaultstore but missing in the EnterpriseVaultDirectory Database will be provided:

Archive records found:                          5000
Archive records missing:                        25

 

If there are any Shared archives, this will be reported in the EVSVR log as shown below:
 

Name                        Extended Type                                                              Type  Enabled  Custom  Count
----                              -------------                                                                        ----      -------       ------        -----
Exchange Mailbox    {597EC7E0-B36C-4C94-8891-509754ABEA76}      9         1              0            5000
Shared                      {84704288-97B1-4519-B46B-7B4CCEA5ACC7}     5         1              0            25

 

 

2. During the EVSVR Repair Step 5 where the missing Archive are recreated, the following error will be logged:

 Step 5 - Recreate missing Archive records

Error changing ArchivePoint Type, Error: <0x80040e14>
Archive EntryId: 1EB78F15DCDFE024D89F5FD7C68FABCC51d10000EV-Server
Event Output: An error was detected while accessing the Vault Database 'EVVaultStore' (Internal reference: {CADODataAccess::ExecuteSQLCommand} [.\ADODataAccess.cpp, lines {1317,1319,1338,1356}, built Nov 19 15:44:06 2014]):     Description:      Enterprise Vault top level Stored Procedure : dbo.[ChangeArchiveType], Error Procedure: usp_ReRaiserror, Line 36, Error 50000, Level 16, State 0, Message: Enterprise Vault top level Stored Procedure : dbo.[AdjustContentProviderUsageStatsForArchivePoint], Error Procedure: AdjustContentProviderUsageStatsForArchivePoint, Line 21, Error 1750, Level 16, State 0, Message: Could not create constraint. See previous errors.        SQL Command:    ChangeArchiveType        Additional Microsoft supplied information:     Source:       Microsoft OLE DB Provider for SQL Server   Number:       0x80040e14   SQL State:    42000   Native Error: 00050000   HRESULT  0x80040e14       For more information, see Help and Support Center at http://entced.symantec.com/entt?product=ev&language=english&version=11.0.1.0&build=11.0.1.3527&error=V-437-13360  (0xc0043430)
Event Output: A COM exception has been raised.   <0x80040e14>   Internal reference   {CVaultStoreDB::ChangeArchiveType} [.\VaultStoreDB.cpp, lines {16467,16476,16478,16479,16481}, built Feb 20 15:20:02 2015]      An exception is raised when a process encounters an unexpected fault.     For more information, see Help and Support Center at http://entced.symantec.com/entt?product=ev&language=english&version=11.0.1.0&build=11.0.1.3527&error=V-437-6796  (0xc0041a8c)


 

Cause

The problem occurs because a named constraint is used in a Stored Procedure when creating a Temporary table. As a result, only one instance of the Temporary table can exist at any one time.

Workaround
Running the Repair using one thread will complete successfully. This ensures that there will not be any attempts by another thread to create the temporary table with a Constraint name that already exists, and hence cause the failure.

Solution

This issue has been addressed in the following release:
 
Enterprise Vault 11.0.1 Cumulative Hotfix 4 Release
https://www.veritas.com/docs/000097959

 
Enterprise Vault 12
The following link contains information about Enterprise Vault 12
https://www.veritas.com/docs/000099905

Note: For information on how to obtain Enterprise Vault 12 see: How to obtain the license key and installation download for Veritas products
 

Etrack : 3782779