09-27-2013 05:52 AM
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 ?
Solved! Go to Solution.
09-28-2013 01:09 PM
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.
09-27-2013 06:02 AM
The version of EV = Version: 9.0.4.1097
09-27-2013 06:08 AM
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?
09-27-2013 06:17 AM
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
09-27-2013 06:19 AM
Have a look at the journal* tables in your Vault Store databases, have they got MANY, MANY rows?
09-27-2013 06:48 AM
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
09-28-2013 01:09 PM
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.
09-29-2013 05:02 PM
So in this case, what is the recommended maintenance period for the EV with EVJournal enabled ?
10-02-2013 02:06 AM
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
10-02-2013 05:26 AM
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.
10-04-2013 03:22 AM
Is there anything else needed on this issue?