Vault Store Database Log Space is low

[Baron164]

I have a vault store database log that continously says it's using 90+% of it's allocated space. I have a SQL Maitenance plan setup to backup the transaction logs. The maintenance plan is running properly. I have it set to run while EV is in backup mode. It runs at 8:30pm but for some reason at 9am the following morning I see Event ID 41205 and 42013 pop up saying the transaction logs have used 90+ % of their allocated space. I tried to simply change the log to unrestricted growth but it does not keep the change and keeps reverting back to restricted growth. If I run the maintenance plan manually the error goes away until the following day.

[Pradeep-Papnai]

Can you check the information supplied in other forum thread.

http://www.symantec.com/connect/forums/space-vault-store-fingerprint-database-log-alarm#comment-6333391

http://www.symantec.com/connect/forums/critical-alerts-space-directory-database-log-vault-store-database-log#comment-6856931

[GabeV]

Do you know if something was changed or added to the mailbox policies? If a new message class was added to the archiving policy (such as calendar items) or moved items was enabled, for instance, that might cause the transaction log to grow really quick during the archiving schedule since there are a lot of updates operations on the database, specially if you never had these options enabled before. You can run DBCC SHRINK or run the maintenance every day buy you might want to confirm if something was change in the policies. Another reason could be that the archiving task was modified increasing the concurrent connections to the Exchange servers.

I hope this helps.

[Baron164 · Accepted solution]

I changed the databases to simple recovery instead of full so I'm hoping that resolves it.

[EV_Ajay]

I think you are having very data / transaction which is daily write into SQL databases. I think for this your decision to change to simple should help.

[Rob_Wilcox1]

I wouldn't advise going to simple recovery mode.

[GabeV]

That could be a workaround, but it wouldn't fix this issue. If switching the recovery model to simple is not a concern for you, then it might work. Just wanted to bring to your attention the difference between full and simple:

http://msdn.microsoft.com/en-us/library/ms189275%28v=sql.105%29.aspx

[Rob_Wilcox1]

Do you need any more help with this issue?

[Baron164]

No, enabling simple recovery appears to have resolved my issue.

[Rob_Wilcox1]

Ok. Well, like I said - I don't recommend that ... at all. You've sold one issue, but potentially opened the door to a worse one, but it is your choice.