When working on a project, my team and I ran into problems with the SharePoint auditing feature. The issue wasn’t so much about the feature itself but more about the data it was generating and the consequences it implied.
In our case, less than an hundred users accessed and worked on the site but the auditing was set up in such a way that all documents and items events as well as all list, libraries, and sites events were being audited. The company’s users did a massive amount of publishing work on a daily basis throughout the site and in several languages. All those processes were saved in the logs which are saved in the AuditData table in the content database. A few months after the site launched and auditing was still working in full mode, we saw the content database become an astonishing size and two third of that was logs.
Getting rid of the log entries is where it gets tricky. SharePoint doesn’t provide an interface to delete those logs. Directly removing them from the content database wouldn’t be supported by Microsoft. The only way left to remove those entries is to use the SharePoint object model using SPAuditQuery and SPAuditEntryCollection and this removal process can turn out to be a very slow process. When dealing with auditing in SharePoint, be sure you are logging information that you only require to capture. Ignoring some of the consequences could result in complications such as heavy backups, slower response time, and a gigantic content database.
