Share via

Tip: The untold story of Audit Logs in SharePoint

  • Article

Auditing events is an important feature of SharePoint. Read this article to understand more around the list of events that can be audited when audit logging is enabled. Audit settings can be configured at the site collection level only. The logs are maintained in the dbo.AuditData table of the respective content database.

However, what is interesting to know is that these logs can bloaten the content database significantly especially for internet based WCM sites. If "Opening or downloading documents, viewing items in lists, or viewing item properties" audit setting has been turned on, then for every hit to a page more than 100 entries could be recorded in the dbo.AuditData table. This figure would typically depend on the count of images, stylesheets, UI elements that fetch data from lists, etc that are available on the page.

Some statistics around this!

The dbo.AuditData table can grow at a rate > 64 KB (approx) per page hit.

Assuming that we have 10,000 hits to the site(/page) in a day, the growth in size would be 10000 * 64 KB ~ 645 MB/day.

This means that even if we do not add any content to the site, the content database will still grow by 15 GB (approx) per month. This is quite a large growth and would impose manageability issues especially if there are constraints around database storage infrastructure.

Organizations planning to enable auditing for their internet facing sites should consider these statistics and come up with archival policies for audit logs.

Post Infrastructure Update release of MOSS, the TrimAuditLog STSADM command is available for farm administrators to truncate the audit logs. This command may be executed periodically to delete old entries from the audit logs.The content database should be shrunk (using DBCC SHRINKDATABASE command) post execution of this command to release the freed up space.

Comments