cancel
Showing results for 
Search instead for 
Did you mean: 

Eventlog errors on source server after Archive move

SutterKane
Level 4

 

Hello all.

 

After moving two archives from one EV server to another server (in the same EV site), the Eventlog of the source server is full off error entries.

 

Those entries are repeating every some minutes and starting with:

 


An error was detected while accessing the Vault Database 'EnterpriseVaultDirectory' (Internal reference: CADODataAccess::ExecuteSQLCommand .\ADODataAccess.cpp [lines {1407,1409,1424,1447}], built Mar 14 10:54:54 2011):

Description:  

The [Root] table is inconsistent for VaultEntryId 13C8B927079EFB94EABD0839C67247EB11110000dcearcevrdr01
 
 
SQL Command:
 GetObjectSecurity
 
 
Additional Microsoft supplied information:
 
Source:       Microsoft OLE DB Provider for SQL Server
Number:       0x80040e14
SQL State:    42000
Native Error: 00050000
HRESULT        0x80040e14


The next entry is:


The EnterpriseVault.DirectoryService object reported an error.
The error code was 0x80040e14
For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp


And finally:


The EnterpriseVault.DirectoryConnection object reported an error.
0x80040e14 Internal references: Error 0x80040e14 CDirectoryConnectionObject::GetArchiveOrArchiveFolderSecurity .\DirectoryConnectionObject.cpp [lines {3616,3624,3626}], built Apr 6 13:31:09 2011
For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp


What Google told me was, that the source server is still trying to access the "old" archive (which has been removed after the migration ended successfully after Step5). In the Administration console I press Strg + Shift and then right-click on "Archives" and then Choose "Find Archive". I entered the Archive ID which I get from the Eventlog but the server told me that the archive could not be found.
Strange to me is, that the ID is pointing to the destination server the archive(s) have been moved to.

 

Can someone support me with an idea what the cause of these errors is and how to get rid of them ?

 

 

Thanks,

 

SK

1 ACCEPTED SOLUTION

Accepted Solutions

Prone2Typos
Moderator
Moderator
Partner    VIP    Accredited Certified

Last I checked this was still an open request for an update on EVSVR. I would log a case and throw you name on top of the ETrack so taht it shows the extent to which a solution to an Out of step directory and VSDB is needed.

 

The issue is . . .I am not sure of a naturally occuring EV process that causes this issue to happen. . and even if it did occur naturally it would be identified after a period of time and the dots would likely never be corrected. Being an error on the backup Admin/EV Admin's side, the solution from support typically takes a back seat to defects/enhancements that do occur due to product design.

View solution in original post

5 REPLIES 5

JesusWept3
Level 6
Partner Accredited Certified

Short Answer:
So what i believe this is , is that you have an out of sync Directory database and Vault store database.
There is most likely a folder that exists in the Vault Stores "Vault" table that does not exist in the Directory "Root" table (and ArchiveFolder table)

Long Answer:
So in the Vault Store you have three tables
Saveset, ArchivePoint and Vault

In the Directory Database you have three tables
Root, Archive and ArchiveFolder

The Saveset table has two columns which link a particular email to an ArchivePoint and a Vault
A "Vault" is a folder within an archive, and an "ArchivePoint" is an actual archive

Both the ArchivePoint and Vault table have an ID that links back to the Root folder in the EnterpriseVaultDirectory database.
The Root table contains all archive ID's and Vault ID's for archives and folders.
The Root table then links to the Archive table using the ArchivePointID
And also to the ArchiveFolder table using the Vault ID

So for instance say you have a saveset ID and wanted to know what use it belongs to and in what folder
The query would be

 

SELECT TOP 10 S.IdTransaction, S.ArchivedDate, A.ArchiveName, AF.FolderName, AF.FolderPath
FROM   yourVaultStoreDB.dbo.Saveset S,
       yourVaultStoreDB.ArchivePoint AP,
       yourVaultStoreDB.dbo.Vault V,
       EnterpriseVaultDirectory.dbo.Root R1,
       EnterpriseVaultDirectory.dbo.Root R2,
       EnterpriseVaultDirectory.dbo.Archive A,
       EnterpriseVaultDirectory.dbo.ArchiveFolder AF
WHERE  S.ArchivePointIdentity = AP.ArchivePointIdentity
  AND  S.VaultIdentity = V.VaultIdentity
  AND  AP.ArchivePointId = R1.VaultEntryId
  AND  V.VaultId = R2.VaultEntryId
  AND  R1.RootIdentity = A.RootIdentity
  AND  R2.RootIdentity = AF.RootIdentity
https://www.linkedin.com/in/alex-allen-turl-07370146

JesusWept3
Level 6
Partner Accredited Certified

Can you try running the following queries also?

USE EnterpriseVaultDirectory
SELECT * FROM Root WHERE VaultEntryId = '13C8B927079EFB94EABD0839C67247EB11110000dcearcevrdr01'

USE yourVaultStoreDB
SELECT * FROM ArchivePoint WHERE ArchivePointID = '13C8B927079EFB94EABD0839C67247EB11110000dcearcevrdr01'

SELECT * FROM Vault WHERE VaultId = '13C8B927079EFB94EABD0839C67247EB11110000dcearcevrdr01'
 

https://www.linkedin.com/in/alex-allen-turl-07370146

SutterKane
Level 4

USE EnterpriseVaultDirectory
SELECT * FROM Root WHERE VaultEntryId = '13C8B927079EFB94EABD0839C67247EB11110000dcearcevrdr01'

 

Returns no results

 

USE EVVSEV04MBX01_7 <<<<<< this is the source server of the archive move
SELECT * FROM ArchivePoint WHERE ArchivePointID = '13C8B927079EFB94EABD0839C67247EB11110000dcearcevrdr01'

 

Returns no result

 

SELECT * FROM Vault WHERE VaultId = '13C8B927079EFB94EABD0839C67247EB11110000dcearcevrdr01'

Returns no result

 

WiTSend
Level 6
Partner

Did we ever get a way to clear up these entries?  I'm having the same issue here.

Prone2Typos
Moderator
Moderator
Partner    VIP    Accredited Certified

Last I checked this was still an open request for an update on EVSVR. I would log a case and throw you name on top of the ETrack so taht it shows the extent to which a solution to an Out of step directory and VSDB is needed.

 

The issue is . . .I am not sure of a naturally occuring EV process that causes this issue to happen. . and even if it did occur naturally it would be identified after a period of time and the dots would likely never be corrected. Being an error on the backup Admin/EV Admin's side, the solution from support typically takes a back seat to defects/enhancements that do occur due to product design.