HELP URGENT. Out of disk space. Search DB huge. Over 270gb

Question

MOSS 2007.

Disk full on Data drive of SQL Cluster. Search DB over 270gb. DBs are set to simple mode so no transaction logs.

Seeing these event errors:

Event Type: Error
Event Source:   Office Server Search
Event Category: Gatherer 
Event ID:   10027
Date:       6/10/2013
Time:       11:04:20 AM
User:       N/A
Computer:   -----
Description:
Failed to update committed transaction in SQL, DocID is 142810797. 

Context: Application 'SharedServices1', Catalog 'Portal_Content'

Search Administration just says LOADING..

What are my options?

Answer 1

After trying my comment (see if you can shrink the DB from SSMS), check this MS article:

http://social.technet.microsoft.com/wiki/contents/articles/8217.sharepoint-2010-crawl-database-is-too-large.aspx

If nothing else, rebuilding the crawl will eliminate any fragmentation of the current crawl you've got going. Of course, search won't work properly until the new crawl is complete, but if you're out of space on your drive, then search isn't working properly anyway (and you may or may not be able to shrink the DB in that instance).

If you do have to go the route of removing the original DB and recrawling, you'll want to make sure you set the new one to Auto-Shrink. SharePoint has a bad habit of just leaving hard drive space allotted even after it doesn't really need it anymore.

Answer 2

A few points that I feel I should call out here:

• All SQL DBs have log files, regardless of the recovery model that has been configured. See Understanding Logging and Recovery in SQL Server
• I would strongly discourage setting up scheduled database data (.mdf) file shrinks. Shrinking the log files may be acceptable, but it's normally a symptom of an underlying problem. See Why you should not shrink your data files

If this were me, I would:

• Confirm that the recovery model is definitely set to simple, if that is appropriate for the database in question.

• Check the size of both the .MDF and .LDF files on the file system of the SQL server in question.

• Check the amount of available space in both the Data and Log files (you can do this within SQL Server Management studio).
• If the majority of either of these files is free space, then I would consider shrinking one or both files as a one-off operation.
• If the data file size is simply due to natural growth of the DB, I would consider adding some more disk space to my SQL server :-)

Ping me on Twitter if you are stuck.