Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Our Small Business Server 2008 installation has recently run out of drive space on the C drive. While working to free up space I noticed that SharePoint_Config__log.LDF is 4.4GB. The associated database is only 5MB and the main content database is only 26MB. This SharePoint installation doesn't really get used at all (unless it's used by the SBS admin site or something that's automatically installed).

I have discovered that SharePoint uses SQL Embedded Edition and I can't connect to it using SQL Management Studio. I tried various methods I discovered online.

I tried to connect in SSMS using the server name "\.\pipe\MSSQL$MICROSOFT#SSEE\sql\query" which seemed to work for some people but not for me.

I tried to use SQL Server Client Network Utility to set up an alias to the named pipe but that didn't work either. Here's where I found the instructions to connect.

Of course I tried connecting directly to \MICROSOFT#SSEE and it didn't work.

All these attempts were from SSMS running on the server where SharePoint and the database reside while logged in as an admin so it shouldn't be a remote access issue with SSMS. Just to be sure it wasn't causing the problem I used the surface area configuration tool to enable named pipe remote connections for MICROSOFT##SSEE but it didn't help.

In all cases I get an error telling me that it can't connect because the server wasn't found or wasn't accessible. The error message are slightly different for the different methods but they all say basically the same thing.

Please help me out. In a single day I've gone from SharePoint-agnostic to SharePoint-annoyed and I'm heading toward anti-SharePoint. Option B for me is to remove SharePoint entirely but I don't know if any of the SBS features depend on it. At the moment we don't use it for anything at all.

If I can get SSMS to connect to the database I'm comfortable that I can deal with the log file but I just can't connect.

In addition to fixing the problem in the near term I would like to know how to stop it from happening again. Why would the config log file balloon up like that when SharePoint isn't even getting used?

Update: Suddenly I no longer got the error from SSMS about the server not existing I started getting a login error when using "\.\pipe\MSSQL$MICROSOFT#SSEE\sql\query". I can only assume it's because I deleted a bunch of IIS log files to free up space. After that I had to close SSMS and specifically open it using Run as Administrator and then I was able to connect to the SharePoint database. After that I was able to backup the log file and shrink it (with a minor change detailed in my comment on the accepted answer).

share|improve this question
add comment

3 Answers

up vote 2 down vote accepted

Use OSQL and make a backup of the database, then shrink the file

share|improve this answer
    
Actually I had to make a backup, shrink the file, make another backup and shrink the file again. After the first shrink it didn't shrink very much but I was able to drop it down to about 10MB after the second one. The reason is detailed at the end of this: technet.microsoft.com/en-us/library/ms178037.aspx –  Steve Hiner Aug 6 '11 at 0:48
add comment

This is not really a problem with SharePoint. It is the way SQL Server works.

If you have your database in FULL recovery mode, and do not backup the database and log files, it will keep recording transactions in the log file indefinitely. It only gets truncated when you back it up.

You have two options - change to SIMPLE recovery mode and accept that you won't be able to recover right up to the time of failure (you will only be able to restore to the last backup, which might be acceptable depending on circumstances). Or continue to use FULL recovery and backup your log files at frequent intervals.

When you do this your log files will be truncated but will still be full of "white space" so you will need to do a one-time SHRINK, as Wictor describes.

share|improve this answer
    
The thing that confuses me is that we don't use SharePoint on that server. I don't know why the log file is growing at all since there shouldn't be any activity. I was planning to set it up to backup - not sure why SBS didn't do that automatically. Seems odd that Microsoft would configure SBS out of the box in a way that would result in the log file growing out of control. We're using the SBS built in backup - would be nice if that automatically backed up the SP databases as well since SBS is designed to be usable by relatively normal people not expert sysadmins. –  Steve Hiner Aug 7 '11 at 6:51
    
Agreed - SBS is positioned as almost a no-admin solution with user-friendly management layer on top of very complex products. I think it works well for the small company server-under-the-desk scenario it is designed for. You'd have to ask an SBS expert to find out how they manage backups. –  SPDoctor Aug 8 '11 at 16:08
add comment

I had this issue - a 15Gb Sharepointxxx_log.LDF file despite not using Sharepoint. To reset it to the initial default size (Windows will recreate it):

  1. Stop the Service "Windows Internal Database (MICROSOFT##SSEE)"
  2. Delete the .LDF file in 'C:\windows\SYSMSI\MSSQL.2005\MSSQL\Data'
  3. Restart the service

I also deleted the other large file in there - forget which it was, All ok now.

share|improve this answer
add comment

Your Answer

 
discard

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.