SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We'd enabled all types of audit events for our production web-application and ended up with an issue with DB as auditData table grown to 50GB. Now, we want to reduce the size of the AuditData table.

We already executed stsadm -o trimauditlog and it just helped us to reduce 5GB however stil would like to reduce the size of the table, so thought of deleting all "opening or downloading..." event type entries (now, we disabled the same event). Please let me the best possible way for the same.

also, have you ever faced an issue with DB instance due the size of a table, if so, how did you resolve the issue?

share|improve this question
up vote 2 down vote accepted

I always recommend that you carefully consider what you want to log and where before enabling audit logs on SharePoint.

This is both due to direct performance impact from logging, and databases / log files growing out of control.

You should consider what you need the data for, and expecially now that you have logged for some time, what parts of the data was used for anything relevant, and adjust the logging accordingly.

Here is a list of the different events you could log.

share|improve this answer

What date did you use to purge date until?

You may want to only keep 2 weeks or a month's worth of audit logging, depending on your business requirement, and upgrade your storage to cope.

How many users has your environment, and over which timescale has it grown to 50GB?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.