Why a content database grows abnormally?

  • Article

Welcome to my first blog post! 

Consider that you found your SharePoint content DB is showing with huge data size when checked it in the SQL 2000 / 2005/ 2008. However, if you use stsadm -o enumsites, the result may not be the same.

You may be wondering what is the reason for this abnormal size of the database.

Let us see how to find out the root cause ...

As a first step towards knowing the reasons, check if Audit is enabled

Enabling Auditing will consume lot of space on your SQL server. You may find the differential data occupied by the Audit Data.

Hence, verify if your AuditData table is showing this excess Data. If yes, auditing would be the root cause for the problem.

MORE INFORMATION:
=================

Following are the links which would be useful for you towards controlling the Audit logs.
a. Events audited when audit logging is enabled (Office SharePoint Server)
https://technet.microsoft.com/en-us/library/cc824909.aspx

b. Create a tool or an interface to delete the Audit log from Content DB of an auditing enabled SharePoint site
https://blogs.msdn.com/sowmyancs/archive/2008/05/29/create-a-tool-or-interface-to-delete-the-audit-log-from-content-db-of-an-auditing-enabled-sharepoint-site.aspx

c. Trimauditlog: Stsadm operation (Office SharePoint Server) à This command lets an administrator delete audit entries older than a certain date, as specified using the enddate parameter.

Ex: stsadm -o trimauditlog -enddate 20080704 -databasename WSSContent123456

Note: Please note that this operation is available after the Infrastructure Update for Microsoft Office Servers is installed. 

d. For more details you may, please refer the following URL
https://technet.microsoft.com/en-us/library/cc706879.aspx

e. We can turn on auditing everywhere programmatically.  We can even prune the audit logs as we harvest data from them to keep content databases from filling up. For more details, please check the following blog.

https://blogs.msdn.com/sharepoint/archive/2008/12/04/how-we-did-it-nintex-reporting.aspx