Monday, April 16, 2012 12:46 PM
I am having an issue at the moment with our SP SQL transaction logs. They tend to bloat very quickly over a short period of time which has been overcome by AvePoint support now. The DocAve agents on each SharePoint servers have been configured to shrink the logs after backup:
I have a full platform backup running over a weekend which shrinks all the logs by around 10GB but over the week the logs can bloat upto 20GB.
I have been told by AvePoint support to play with the threshold between 0.5 to 0.8 but I am still gettting this steady increase in total log file sizes especially in the search service logs, which means I have to manually shrink the transaction logs in the SQL magament studio every so often.
I am no SharePoint or SQL guru so I suppose my question is, is there any easier method of automatically shrinking the logs or any other tool out there that can give me peace of mind on this matter?
Wednesday, April 18, 2012 3:10 AM
According to my analysis, recovery model is very important in the way log truncation occurs. Recovery model for Search service application Property database should be set to SIMPLE. Log truncation occurs under the simple recovery model, after a checkpoint When the checkpoint is performed, the inactive portion of the transaction log is marked as reusable. Thereafter, the inactive portion can be freed by log truncation.
In addition, for more information about how to maintain SharePoint 2010 databases, check out the following white paper:
Rock Wang TechNet Community Support
Wednesday, April 18, 2012 11:47 AM
Thanks for the reply,
We have an SQL mirror in place and can't have a recovery model of simple with SQL mirror. We need transaction logs to be able to ship them to the other SQL server for replay.
Wednesday, April 18, 2012 11:55 AMDid you check out: http://technet.microsoft.com/en-us/library/ff621098.aspx It discusses the back up and archiving of SharePoint transaction logs.
Friday, April 20, 2012 11:45 AM
Thanks for your input,
Thats great, however, unless i missed something I was after something that would schedule a database backup with truncation in the event that AvePoint ever fails or if the original problem remains where AvePoint is not shrinking the logs enough each week.