SharePoint Audit Log

I noticed our SharePoint content database growing at a rate that didn’t match the content being added. I decided to look at some table storage and ran the SQL Server 2008 reports from Management Studio and ran the Disk Usage report. Fantastic report detailing table size, number of records, etc…

One table that stood out was the AuditData table which was 50Gb in size. SharePoint Auditing can take up so much database space especially if you are auditing an entire site collection. Auditing was capturing data since late 2007 and wasn’t being used at the company, so the decision to disable this functionality. Great…save space and system resources.

So I turned it off at the site collection in site settings.

So the next step moved to how do we remove these logs?

• Truncate the table – fast but unsupported and I am not sure what state this will leave you in
• Object Model – write code to remove entries
• stsadm trimauditlog- only available after SP2 – This is the one I selected

Stsadm trimaudtilog
http://technet.microsoft.com/en-us/library/cc706881(office.12).aspx

 I used the –url parameter instead of the -database parameter. I was receiving an object reference not set to an instance of an object error when using the -database parameter. I am not sure if it was because the site collection was migrated to a different database server and the audit logs was stored against a different database server.

I ran this command in 1 monthly intervals (which was painful) as there was a lot of data to clean up and the SQL database log file wouldn’t consume all the disk space. I would then manually shrink the log file DBCC ShrinkFile after every trim to free up space. I performed this action until the entire AuditData table was cleared.

So if your Content database is growing at an alarming rate then make sure you check your AuditData table and assess if you really need auditing enabled, especially for the entire site collection.