cancel
Showing results for 
Search instead for 
Did you mean: 

setting or clearing backup mode hangs

mjscreen1
Level 4

Been running the same backup script - pre + and post for several years and has been running successfully until... this week


Tracked down problem -

When trying to put the Vault stores into or out of Backup mode - the process hangs

either from powershell or from gui
 

from the gui - the message box reports:

"updating Vault Stores Backup mode..."

 

and there it stays


a look at the message queues - apart from the A5 - all else is zeros, no journaling is done

Placing the indexes into and out of backup mode works all okay

problem remains AFTER restarting the EV database server and EV server
no errors in event logs
by 'killing' the gui or powershell - shows the backup mode HAS changed - so I am guessing the there is some other activity as part of the setting or clearing the vault store backup mode that is causing the hang

Any thoughts ?

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

Rob_Wilcox1
Level 6
Partner

Hopefully after some SQL maintenance it won't be too bad - you certainly don't have 'alot' of records in the journal* tables, so the slow down is likely to come from SQL.

Working for cloudficient.com

View solution in original post

10 REPLIES 10

mjscreen1
Level 4

The version of EV = Version: 9.0.4.1097

Pradeep-Papnai
Level 6
Employee Accredited Certified

What is the version of EV in your environment?, Are you running SQL maintenance regularly, database should not be fragmented.

What's the size of JournalArchive & watch file for Vault store database?

Do you have any error/warning in event viewer?

mjscreen1
Level 4

Hi,

Version: 9.0.4.1097
we do not have journaling enabled
 

no sql maintenance is done - we backup the SQL databases and logs whilst in backup mode

There are no errors in the event log to give additional clues

 

 

Rob_Wilcox1
Level 6
Partner

Have a look at the journal* tables in your Vault Store databases, have they got MANY, MANY rows?

Working for cloudficient.com

mjscreen1
Level 4

Here ae the figures:

JournalArchive
1055811


JournalDelete
1589545


JournalRestore
0

 

I see that journaling is different to Journal - hey ho - live and learn...

"Enterprise Vault 8 introduced a new feature called Transaction history. The Transaction history is used to determine how long to record updates to archives. Updates include adding new items, deleting items and moving items. The update records significantly improve the performance of vault cache synchronization by providing records of the changes to an archive since the last vault cache synchronization. If a user has not synchronized their vault cache within the transaction history period, then Enterprise Vault will process the archive to determine the updates."

also

Thank you for the maintenance clue

discovered the sql agent on the SQL server has been set to manual startup
last time the EVDBPlan was run April 2011

have started the EVDBPlan SQL job

 

will await progress of the job and review the row count in the journal* tables in the SQL vault store database 0
thank you

 


 

Rob_Wilcox1
Level 6
Partner

Hopefully after some SQL maintenance it won't be too bad - you certainly don't have 'alot' of records in the journal* tables, so the slow down is likely to come from SQL.

Working for cloudficient.com

John_Santana
Level 6

So in this case, what is the recommended maintenance period for the EV with EVJournal enabled ?

mjscreen1
Level 4

The original problem has gone away - can stop and start the backup mode of the vault stores withou having to wait an excessive amount of time

Coming back to the number of rows in the Journal* tables within the database - these have not changed much
 

So I assume the reindexing done as part of the Symantec created maintenance job EVDBPlan helped.

I see the reindex part generates enough SQL transaction log entries to match the size of the vault store SQL databases - so we have increased the disk capacity of the drive holding the sql transaction logs.

 

Coming back to John Santana question above - recommended maintenace period - what I found on our server was that the job was set to run once a week -  or would have done if the SQL agent had not been diasbled :)

This is not a recommendation - it is an observation on our server - have not done any reading up on what is a good value




 

 

A_J1
Level 6
Employee Accredited Certified

The count in Journal delete will go down once the retain transcation history set under the site properties is over.

By default retain transaction history is set to 32 days.

 

Rob_Wilcox1
Level 6
Partner

Is there anything else needed on this issue?

Working for cloudficient.com