April 28, 2008 at 9:36 am
I have a SQL 2005 server that is running out of space on the C (10 GB) drive. I have moved all the db's off the C to the D (150 GB) drive. I have been monitoring the folders on the C drive and the only folder that is growing daily (by about 30Mb per day) is:
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Hotfix
It looks to me that this folder contains hot fixes that have been applied and the logs that go with them. Is there a way to have these saved to another location (in this case the D drive) or is it safe to manually move them over to the D drive?
April 28, 2008 at 9:56 am
My guess is no. It looks like the hotfix logs are stored in the folder created when you installed the SQL Server service.
Why did you only allocate 10 GB to C-Drive? If you dedicate this machine to SQL Server only, then I think 10GB should be OK in the long run.
Paul
April 29, 2008 at 3:20 pm
Thanks Paul. I guess I'll need to find another way to free up some space. As for only 10 GB, I was not involved with the setup of the server, rather I am just the lucky soul to have inherited it.
April 30, 2008 at 3:59 am
To keep an eye on the disk space, you could set up a job to alert you when the disk space is getting close to your comfort level. I have used the extended SP: master..xp_fixeddrives, but you might find something better on this site.
HTH
Paul
April 30, 2008 at 4:09 am
For SQL Server 2005, I normally allocate at least 10Gb on C drive. Even though you configure all the components to use another drive, the system drive requires roughly above 1Gb for its program components. To do the cleanups, do steps like removing the windows hotfix installation logs from C:\Windows, change the pagefile from C to any other drive, remove unnecessary user profile, moving the TEMP and TMP folders to the data drive etc. I had once tried removing the SQL bootstrap logs, but following to that, I got some errors during an upgrade. So, I would recommend to do some testing before you remove such logs.
May 1, 2008 at 4:43 am
Rajan has some good ideas, but I don't think the DBA should touch the Windows hotfix logs. These are the 'property' of the Windows infrastructure dudes, and they should be the only people who delete them, so raise a work ticket for them to do this. Would you as a DBA want the Windows people to delete files you thought you controlled?
I agree with Rajan on other points. The system /Temp folder and page file should be moved off the C: drive. The /Temp folder can end up with a lot of rubbish in it, none of which needs to be on C:. I also move the user /Temp folder away from C: for any account I have access to.
Also monitor space used in /Documents and Settings. All DBAs should move their /My Documents folder away from C:. It can be more complex to move the IE cache, but I have seen this take a few GB for some users. Even if your server has no web access, if an account is using any browser-based applications, or apps are using browser components, stuff can end up in the IE cache folders. The worst case I saw was the service account used for a report product.
Remember, a full C: drive is not just an inconvenience. In the worst case it can cause Windows to crash and refuse to reboot. Ideally the Windows tribe should monitor C: usage to prevent things getting too bad, but the impact of this problem is so high that it is worth spending DBA time on this.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
May 5, 2008 at 7:42 am
Thanks everyone for you comments and guidance here. Unfortunately, this is my beast to mange for now, the DBA and Windows guys want nothing to do with this box as it technically is not a production box even though it is running what is now a production database (this occurred long before I arrived). I am pressuring for it to be moved to a production server, but it is taking MUCH longer than one would think or have hoped.
I have managed to free up just over 1Gb, I will continue to monitor it and find out where IT is with the move.
June 23, 2008 at 12:15 pm
We finally figured out that the problem was with the HotFix logs. This was being caused by an old update for SQL Server Integration Services 2005 (SSIS) patch for a security vulnerability in the .Net Framework 2.0. Without this fix, any VB.Net scripts (Script Task or Script Component) in your SSIS packages may not execute, or work at design-time as expected.
The reason that this was causing a problem as that SQL Server Service Pack had been installed before this patch had been applied and so the system was attempting to apply the patch to a more recent build that it was intended for. This resulted in the patch failing and the logs being generated every time the system tried to apply the patch. The patch in question was KB 932557 and we had to remove the patch for the temporary download folder and from the registry – I do now know what the specific registry key was as this was handled by a sys admin. But hopefully this will be enough information to help someone else out.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply