1

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).

Improve this question
3
  • I had exactly the same problem Sharepointxxx_log.ldf file was 30 GB and it was taking up space on my C drive. I followed your instructions and deleted the file but windows did not create a new one. I checked Event Viewer and I get lots of errors. SQL Database 'SharePoint_Config_29c26fca-17b8-48c1-9704-b869932abcb6' on SQL Server instance 'COOPERCOSERVER\Microsoft##SSEE' not found. Additional error information from SQL Server is included below. What do I need to do to recreate the file.
    – user38528
    Commented Jan 9, 2015 at 15:37
  • I just noticed last night that I have the same errors in my error log. In this case I don't really care because we don't use Sharepoint for anything. I'll probably eventually try to get rid of that but it isn't high on my priority list. I suggest you ask a new question and let the experts chime in.
    – Steve Hiner
    Commented Jan 22, 2015 at 0:53
  • PLEASE, do NOT delete eñ ldf file of ANY Relational Database SQL. Take a backup of the LOG schrink the file and retake a backup
    – Claudia Rebeca Valderrama Vill
    Commented May 23, 2023 at 10:23

3 Answers 3

Reset to default
3

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

Improve this answer
1
  • 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
    Commented Aug 6, 2011 at 0:48
2

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.

Improve this answer
2
  • 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
    Commented Aug 7, 2011 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
    Commented Aug 8, 2011 at 16:08
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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