Been doing a routine check of my servers, and noticed that our SharePoint server was lacking some free space. A little unusual, given our SharePoint installation is quite small. And although this server also acts as a Streaming Media server using Windows Media Services, I didn’t think that we had that much streaming media.
Turns out that the SharePoint_Config_Log file size was 78gb. This is around 80% of the drive that it is stored on. This meant that we had only 6gb remaining.
In this situation a full backup was not possible to truncate the logs. Symantec Backup Exec was still backing up the databases every night though. To cure this problem, a quick little fix:
- Open up Microsoft SQL Server Management Studio
- New Query
- Type in the following and press execute.
USE [master]
GO
ALTER DATABASE[SharePoint_Config] SET RECOVERY SIMPLE WITH NO_WAIT
GO
USE [SharePoint_Config]
GO
DBCC SHRINKFILE ('SharePoint_Config_Log')
GO
Database size magically down from 78gb to 10mb.
Server is now happy, and running better.
DAYUM, dude!!! This worked awesome!!!! 101GB….down to 504KB…Nice work!
Shrunk 850GB log Sharepoint_config_log file to 13GB. Awesome!
I troubleshot this issue off and on for about 7 hours… and I know how to use Google, I WISH I had found your site first…this fixed it right away. Mad props to you…genius.
-RS
Really Works great, Got the file size reduced to last then 10mb in a few minutes.
Thx there are many posts out there about this issue. But for me only this one worked thx a million.
Gz Koen
SharePoint Config database log file too big. Solve it
USE SharePoint_Config
GO
ALTER DATABASE SharePoint_Config SET RECOVERY SIMPLE
DBCC SHRINKFILE(N’SharePoint_Config_log’, 1)
ALTER DATABASE SharePoint_Config SET RECOVERY FULL
GO
Like this – not tried it though. Should be a cleaner command to run.
With SharePoint services enabled the log file grows by about 75 – 80GB a day. Event Viewer – Application revealed an error relating to SharePoint but Googling it revealed it to be very generic and was not much help. Clearing the application log I found out fills with around 33,000 error logs in about 4 seconds with every entry being identical.
I went on to plan B and followed the procedure to shrink the log file, then proceeded to disable all SharePoint services. That was a week ago and success, No more errors in the event log and the log file remains at 504KB. Although it has fixed the issue I never did get the bottom of the cause of the issue.
Just though I would give an update!!!
I have managed to shrink it down to 504KB. For whatever reason after multiple detach and attachment of the database suddenly I was able to go into areas I couldn’t before and the shrink command gave me more options. But the big question is, will this be likely to be an ongoing issue?
I have never had to do it again – but I did add it in to my weekly checklist. I have no idea why it would suddenly allow you to shrink it though. Glad you got sorted.
I have tried restarting the server with all other servers and workstations off. Then trying the shrink command again. It managed to free up another couple of MB’s. This file is starting to get dangerously close to filling ALL of C Drive. Have also attempted a repair of .NET4 and WSS with no success. Just noticed it has suddently grown another 60GB within the last hour.
Wish this method worked better for me. The server is 3 weeks old and have nearly finished configuring it when this morning noticed the SharePoint Config LDF is approaching 1TB (yes, terabyte). This company doesn’t even use SharePoint. They are nearly out of space on their server. Running the above command and shrinking the log file recovered 0.19MB of free space.
Wow. Thats the largest I’ve heard of. Have you tried restarting the database instance and then running the command. That should release any locks on the database.
Wow – 13.5GB log file went to 504KB in seconds. Scary but nice – Thanks!!
loool, same here dude
my heart fall down, my database reduced from 322GB to 540KB i thought i lost all my data :D
wonderful solution, thanks
Something’s not right… Isn’t there something in SQL management about regularly shrinking the logs? Failing that, MAINTENANCE TASK!
Go to SQL2008, shrink the log, change the recovery mode to simple like Capita recommends for SIMS. Won’t ever grow!!
You should really back it up regularly, then it’ll shrink the log file!!
That’s the annoying thing – I have been!!
Symantec doing full backup nightly, and to prove that I could even do the test restore to a new server. It just wasn’t shrinking.
Seems to be shrinking fine now though. Maybe just required this to be run to kick start it?