Config DB growing pretty large and truncate command not solving problem
There is a database called PROD_MOSS_Config that is using over 40 Gb of space. I ran a truncate log file job, but that only allocated about 2Gb. The reason this command doesn’t free up the space we expect is because there is a job running that fills this log at the same time the command runs. The only thing I can think of is we have our full crawl running at the time the truncate command runs. Can this be the cause of a file of this size being created? We have 10 content DBs and they are not super huge. No more than like 25Gb each or in that range. Is there some way to limit the size of the logs this crawl generates?
May 24th, 2010 5:51pm

Yes he had. But because that was a scheduled job and it was run during a full crawl, that log was not able to be truncated as it was actively growing at the time due to the running crawl, or at least that is how he described it to me.
Free Windows Admin Tool Kit Click here and download it now
June 4th, 2010 5:29pm

If you don't plan on doing a point in time recovery, you could change the recovery mode to simple, do a full backup of the db and then from SQL Studio right click on the db and select to shrink the db -- however you want to make sure you only shrink the Logs. Be sure to select to recovery empty space. As I said, this should work and simple mode will prevent the LDF from growing but will prevent the ability to do point in time recovery. For most organizations this isn't really an issue -- but it is important to understand the potential implications.John SharePoint911: SharePoint Consulting Blog: http://www.rossonmoss.com Twitter: JohnRossJr MOSS Explained: An Information Workers Deep Dive into Microsoft Office SharePoint Server 2007
June 5th, 2010 9:11pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics