I am trying to understand why we have such large transaction logs on our SharePoint server, specifically the content database Tlogs. The current DB size is around 8GB with the Tlogs being 5GB.
I can see in SQL management studio (2008) that both the DB and Tlog are being backed up by SMMOSS (22.214.171.124), but I am confused as to why the logs are not truncated following each SMMOSS backup.
This also leads me to another question... what should the recovery model (logging type) for the SharePoint databases be set to? at the moment they are set to Full. I know that in Snap manager for SQL you can use the transaction log backups to perform a 'point in time' restore, but I cant see this option in SMMOSS therefore should the DB recovery model be set to Simple?
This is a known issue for SMSP with SMSQL 5.1, which the log is not truncated by default. Another SMSQL log backup job with log truncation could be the workaround. Or you can wait for about 2-3 weeks for SMSQL 5.1P1 release, it will have the fix for this issue.
I was a little surprised also that the tlogs are not truncated. Makes me wonder how many people are using the product with ever expanding transaction logs!
I ended up changing the SQL db recovery model to simple as we take 3 snapshots throughout the day in SMMOSS, so don't really need point in time recoverability.
We will be upgrading our ontap version soon as it is holding us back on upgrading to SMSP 6. I might change the recovery model back to full if you manage to find a way to truncate the logs in this version.