Forum Discussion

ianG's avatar
ianG
Level 5
14 years ago
Solved

Deleted items waiting to be deleted from indexes - event 41022

Hi folks,

Recently upgraded from 8.0.3 to 8.0.4 and am liking the new features so far. One of which is the monitoring. Its come accross a situation whereby our environment appears to have items deleted from the vault store, but not deleted from the indexes. Event logged as follows:

Event Type:    Warning
Event Source:    Enterprise Vault
Event Category:    Monitoring
Event ID:    41022
Date:        25/05/2011
Time:        09:00:03
User:        N/A
Computer:    [evserver]
Description:
There are 26904 items that have been deleted from Vault Store '[vaultstorename]' but have not yet been deleted from the indexes.

There may be a problem with Enterprise Vault indexing.

You can use the System Status feature in the Administration Console to help you resolve this issue.

For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp

 

Ran through the errors accompaning 'How to fix' link on the monitoring page, but no joy

  1. Storage service is running
  2. No indexes marked as failed
  3. No vault stores in backup mode
  4. No accompaning indexing errors that I can see
  5. Rerun of the checks results in same error

Is there anyway to find out which archive(s) have these inaccurate indexes? If I could figure them out I could just target them with an index recreation?

Thanks

  • Sounds like a plan. Get all the DB's to the right level and I am 99.99% certain that will fix this :)

  • OK First of all, this has more to do with the Index Service being in backup mode and not the storage service, dont rebuild a an index for this, you need to just update it.

    The query you want would be the following


     

    SELECT A.ArchiveName "Archive Name", 
           COUNT(JD.IndexCommitted) "Items Awaiting Deletion"
    FROM   EnterpriseVaultDirectory.dbo.Archive A,
           EnterpriseVaultDirectory.dbo.Root R,
           yourVaultDB.dbo.JournalDelete JD
    WHERE JD.ArchiveId = R.VaultEntryId
      AND R.RootIdentity = A.RootIdentity
      AND JD.IndexCommitted = 0
    GROUP BY ArchiveName
    
    
  • Many thanks JW, that works a treat

     

    Unfortunately though, the index update doesnt appear to have any effect. Right click on the index, and update, it returns in about 4 seconds, and theres no change in the SQL result.

    Tried the same with rebuild (this time taking 40 odd seconds), but again no change in the SQL

     

    Looking at one archive in particular (test archive with 5380 items awaiting deletion), its index range is 1 - 11415, but when I go to search the archive, it looks like its only got 655 items in it. Which I thought was peculiar..

     

    /edit

    actually, have only just noticed you can scroll the index volumes detail panel to the right - according to the index, the test archive above has just the 655. So, to me, it doesnt appear that the archives index is out of date

  • This is looking to possibly be a SQL compatibilty level related issue alright, as suggested by http://www.symantec.com/docs/TECH51290

    As a quick glance at our EV directory database, and it appears to be in sql2000 compatibility mode. Will need to liase with our database team, and arrange outages, so might be a few weeks till I can say for certain that this resolves it (the joys of large companies..)

    Thanks guys

  • Sounds like a plan. Get all the DB's to the right level and I am 99.99% certain that will fix this :)