Forum Discussion

JTaaaaaaaa's avatar
JTaaaaaaaa
Level 3
14 years ago

Watchfile table and remove safety copies immediately

Hi

I have a vault store which is set to remove safety copies immediately after archive.  According to Usage.asp this vault store has several hundred thousand items awaiting backup.  Not really a problem, but that means there are several hundred thousand rows in the watchfile table that don't need to be there.  Database size is an issue at the moment.

Am I right in thinking that if a vault store is set to remove saftey copies immediately, then the watchfile table/storage file watch proces is not used.  In which case I am safe to manually update the itemssecured value to 1 for all entries?

 

Enterprise Vault
Information Governance
  • JesusWept3's avatar
    JesusWept3
    14 years ago

    just as a matter of interest, what are the dates on those items? are they recent or from some time ago?
    this can happen if someone changes it from immediately after archiving back to awaiting back up and then switch it back, those items that were archived under an After Backup scenario will be put in to the Watch File table and the JournalArchive table


    In EV7 and below if an item is stored in an Immediately After Archive scenario, it would
    1. Create an entry in the JournalArchive table and set BackupComplete to 1
    2. It would then await for Indexing to index the email then set IndexCommited to 1
    3. As soon as both indexCommited = 1 and  BackupComplete = 1 it would then remove the entry

    In EV2007 it would work the same as above, but it would keep the transaction for 14 days
    In EV8 it would put the item in to the WatchFile table and it would await for the item to be backed up properly, even in an Immediately After Archive scenario, it would still await those items to be backed up, and also any SIS parts from other vaults stores.


    So for instance if you have an item where the DVS file is in Vault Store 1, and you're backing that up, and it gets SIS'd to an attachment item in Vault Store 2 and thats not being backed up, if it detects that the VS2 item is still awaiting backup, then it won't do anything until all parts of the message have been properly backed up.

    I wrote more about this here:
    https://www-secure.symantec.com/connect/pt-br/articles/changes-backup-procedures-enterprise-vault-8

8 Replies

Sort By
  • Mohawk_Marvin's avatar
    Mohawk_Marvin
    Level 6
    14 years ago

    It depends on the Version of EV. From EV 8 (vanilla I think) EV will remove items from Exchange, however they will stay in SQL until it sees a back up has been performed. So you should do a backup resetting the a attribute, or do a trigger file back up of the location. Or if its a Centera... check the replication.

  • JTaaaaaaaa's avatar
    JTaaaaaaaa
    Level 3
    14 years ago

    Thanks for the reply.  It's EV 7.

    I'm just wondering how the Awaiting Backup process changes if a vault store is set to remove safety copies immediately. 

    If I manually archive an item from my mailbox, the saveset entry in the JournalArchive table is immediately set to to BackupComplete 1.  Is this something to do with the storgae (netApp)?

     

     

  • Mohawk_Marvin's avatar
    Mohawk_Marvin
    Level 6
    14 years ago

    If its EV7 it should just clear down. However, I think if those items were pending before you made the chage to safety copy setting they may cue up, dont know that just an assumption and I dont have a v7 image to hand.

    You could perform a trigger file backup, or if you are happy the backups have taken place set backupcomplete to 1.

  • JTaaaaaaaa's avatar
    JTaaaaaaaa
    Level 3
    14 years ago

    Backups are done using NetApp snapshots so trigger files/read only mode is never used.

    If those entries exist in JournalArchive with backupComplete set to 0, then there must be a process which is monitoring that table to see if the value has changed to 1 yet, right?   That explain why this database is using more resources on the SQL server than all other databases put together.

    I just want somone to confirm what I am assuming is right, then hold my hand and whisper softly 'it is OK to change the values to 1 manually'.

     

     

  • Mohawk_Marvin's avatar
    Mohawk_Marvin
    Level 6
    14 years ago

    You are correct, and setting the flag to 1 will do no damage, but you should still take a backup first just in case smiley

  • JesusWept3's avatar
    JesusWept3
    Level 6
    14 years ago

    just as a matter of interest, what are the dates on those items? are they recent or from some time ago?
    this can happen if someone changes it from immediately after archiving back to awaiting back up and then switch it back, those items that were archived under an After Backup scenario will be put in to the Watch File table and the JournalArchive table


    In EV7 and below if an item is stored in an Immediately After Archive scenario, it would
    1. Create an entry in the JournalArchive table and set BackupComplete to 1
    2. It would then await for Indexing to index the email then set IndexCommited to 1
    3. As soon as both indexCommited = 1 and  BackupComplete = 1 it would then remove the entry

    In EV2007 it would work the same as above, but it would keep the transaction for 14 days
    In EV8 it would put the item in to the WatchFile table and it would await for the item to be backed up properly, even in an Immediately After Archive scenario, it would still await those items to be backed up, and also any SIS parts from other vaults stores.


    So for instance if you have an item where the DVS file is in Vault Store 1, and you're backing that up, and it gets SIS'd to an attachment item in Vault Store 2 and thats not being backed up, if it detects that the VS2 item is still awaiting backup, then it won't do anything until all parts of the message have been properly backed up.

    I wrote more about this here:
    https://www-secure.symantec.com/connect/pt-br/articles/changes-backup-procedures-enterprise-vault-8

  • JTaaaaaaaa's avatar
    JTaaaaaaaa
    Level 3
    14 years ago

    Ok, so I changed the BackupComplete value to 1 for all of the entries in the JournalArchive table.  Now, the next time StorageCrawler does tries to do its thing, it logs an event:

    Event Type: Error
    Event Source: Enterprise Vault
    Event Category: Storage Crawler
    Event ID: 13360
    Date:  2/17/2011
    Time:  2:44:48 PM
    User:  N/A
    Computer: EV01
    Description:
    An error was detected while accessing the Vault Database 'EVDB1' (Internal reference: .\ADODataAccess.cpp (CADODataAccess::ExecuteSQLCommand) [lines {1378,1380,1395,1418}] built Jul 22 16:55:29 2008):
     
    Description: 
     
    The DELETE statement conflicted with the REFERENCE constraint "FK_TransactionId_WatchFile". The conflict occurred in database "EVDB1", table "dbo.WatchFile", column 'ArchiveTransactionId'.
     
     
    SQL Command:
     uspu_JournalsCommit
     
     
    I guess this is saying it cannot remove the entry in the JournalArchive table while a corresponding entry exists in the Watchfile table.  Normally StorageFileWatch would have deleted it. 
     
    Am I OK to just remove all rows in the Watchfile table?
     
    What will happen when it comes to update the pending item shortcuts, which must have timed out by now?