Sessions: 67 The postings on this site are my own and do not represent my Employer's positions, advice or strategies.


  Wednesday, May 29, 2024
Wider View Login

IBM - AS400
Performance Counters
Service Broker
SQL Server
Windows OS
     Standard Terminal Se...
     Managing Terminal Se...
     Recovering Space on ...

Will be added as a sub-category of, Windows OS
Recovering Space on a Windows Server

Recovering space on a windows server

We often run into issues where a SQL Server (obviously this means a windows based operating system) begins to run out of space.  Most space issues are database related, but some machines actually begin to run critically low on operating system space, the C Drive usually.  This usually happens on older machines that were designed with a much smaller "foot print" of an operating system, over time Operating system "foot print" size has increased, so have program files, log files generated by utilities installed on the OS Partition etc. 

It is usually possible to recover much of this space by carefully analyzing the usage and programs on a machine, this can often lead to large amounts of recovered space (sometimes several gigabytes) [refer to the examples].  As a last resort it is also possible to compress non-critical parts of the operating system drive, though this is an absolute last step.

These are the steps to take to recover space from the C drive.  Caution: this should never be done on a production machine without consulting the Windows team; a PCR may or may not be needed.  If the space issue is so critical that stability of the server is an issue the maintenance should be completed with an emergency PCR.

Areas to look to recover disk space:

  1. VSP Files
  2. OTM Files
  3. Recycle Bin Files
  4. Temporary Files
  5. Service Pack Files
  6. CCM Cache Files
  7. Excessive Log Files
  8. Uninstall Files from OS patches
  9. Un-needed Program Files
  10. Files not belonging on OS Partition
  11. Compress unnecessary files
  12. C:\windows\installer files

VSP Files

VSP Files are snapshot files created by the netbackup process.  Occasionally this process is interrupted through a reboot or program error and leaves the temporary files on the disk.  These are hidden files and usually in the root directory of a drive.  An example file name is VSPCache2.VSP.  On a server with a large file system, these files can be in excess of several gigabytes and can easily use up a significant amount of space.  A windows engineer should definitely be involved if significant VSP files are occurring on a regular basis, as there may be a configuration problem with the server or netbackup.

OTM Files

OTM Files are created by netbackup, Open Transaction Manager.  These files are usually found in the c:\temp or c:\windows\temp directory.  They have a naming convention that will include OTM in the file name, 12OTM.tmp.  They can range in size from very small to several gigabytes in size.  It is usually and indication of a problem with netbackup when these exist and a windows engineer should be contacted to check the server.

Recycle Bin Files

The recycle bin stores deleted files.  When deleting large files it is necessary to ensure that these are not “deleted to the recycle bin”.  If disk space is low always ensure that the recycle bin has been deleted.  Also check the configuration of the recycle bin.  It is not necessary to enable the recycle bin for certain drives.  The recycle bin configuration usually reserves a certain percentage of disk space, if the recycle bin is not needed this “reserved” space can be recaptured by modifying the configuration.

Temporary files.

Many programs create temporary files that are never removed.  Ensure to check all locations and delete these files; c:\temp; c:\tmp; c:\windows\temp; c:\windows\system32\temp etc.  To find temporary locations check the system environmental variable for the path of temp and tmp.

Service Pack Files

Often service pack source files are left on the machine, these source installation files are often unnecessary and can be removed.  Examples are SQL Server, Office and Operating system service packs (c:\sqlsp4; c:\i386; c:\winnt\i386 etc).

CCM Cache Files

CCM Cache Files are created and maintained as a function of the SMS Client.  The location of the CCM Cache file is usually based off the windows directory; example:  \WINDOWS\System32\CCM\Cache\.  This cache file can easily use several 100mb of space.  The CCM Cache folder and files are used by the SMS Advanced Client Installer.  The directory and folders are used by the advanced client to store packages that are downloaded before they are run.    The default size is 250mb. 

Refer to the following link on CCM:

Files can be deleted out of the cache by starting the control panel applet for SMS and there is an advanced tab with the cache setting and the ability to delete the existing cache.

Excessive Log Files

Many programs create log files on the C Drive that are never deleted.  Over a long period of time these log files can use a lot of space.  They can often be deleted.  Look for log files with the common extensions of log and txt etc.  Common logging issues of SQL Server and IIS: c:\program files\Microsoft sql server\mssql\logs and c:\winnt\system32\logs\iis\.

Uninstall Files from OS Patches

Many windows hotfixes and service packs create uninstall directories.  These directories and files may be using up a large amount of space that can be recovered.  These files are usually in the windows directory.  Before deleting these files check to ensure that they are already compressed, if the compression does not save enough disk space, it may be necessary to delete them. 

Un-needed Program Files

Many programs are often installed that are not needed.  If the OS Partition is extremely low on space, some of these programs may be removed or uninstalled and re-installed to proper partitions.  Look for programs like Microsoft Office, Exchange, etc.

Files not belonging on OS Partition.

Many servers may contain files on the OS Partition that are not meant to be stored there, inadvertently using up much of the space.  Zip Files, Log Files, Backups, SQL Server database  files, etc.  Many of these files can be stored on other partitions or are not necessary.

Compress unnecessary or rarely used files.

Space can be recovered on the operating system partition by compressing files.  Compressing files is the least desirable option for recovering space.  Compressing files may slow the operating system down.  Files that are compressed should be files that are rarely accessed.  The unix directory under the windows system folders is probably not used often and could be compressed; but not deleted as it is part of the operating system.  Compressing logging folders used by IIS etc are valid options.


Windows\Installer Files (The Patch Cache).


The Windows root directory usually contains a folder, c:\windows\installer; we have noticed over time that this folder can grow to consume a significant amount of space, 2-6 gigabytes of space.  Many of these installer files are “dead” and can be moved, not removed !  Moving them to another partition may free up space.  Be careful as some installtion programs or modifications to existing programs will reference this directory, and if you can not move the files back, you have a very big problem.  Specifically installations of SQL Server 2005 require this directory for adding additional instances or options not selected, and if the files are not found in c:\windows\installer, you can not install or modify the programs.

The Patch Cache and Freeing Space


When you install a patch using Windows Installer, the .msp file is cached in the %WINDIR%\Installer directory. This accounts for some of the space required by Visual Studio 2005 Service Pack 1.  A single patch is cached only once regardless to how many products the patch applies.

Starting with Windows Installer 3.0, any patches that contain the MSIPatchSequence table cause the Windows Installer service to cache any of the original files being replaced into the baseline cache.  Any files being replaced in the latest minor upgrade by small update patches with this table are also cached. It is this baseline cache that consumes a lot of drive space on the system drive after installing VS 2005 SP1. The baseline cache facilitates patch uninstall by storing the original files so that they can be copied back to the target locations. Files in existing patches do not need to be cached because they are contained within the cached .msp files. For this reason and because Windows Installer will require these patches during repair and future patch scenarios, the .msp files should not be deleted except by uninstalling the patch from each product to which it's applied. The baseline cache also improves performance when using binary deltas.

Baseline caches are created separately for per-user unmanaged installations, and for both per-user managed and per-machine installations. If you enable Windows Explorer to display system files or type dir /a:s under %WINDIR%\Installer you'll find a directory structure like the following:

  • %WINDIR%\Installer
    • $PatchCache$
      • UnManaged
        • {UserSID}
          • {Squished ProductCode}
            • {ProductVersion}
      • Managed
        • {Squished ProductCode}
          • {ProductVersion}

Be careful doing any modifications under %WINDIR%\Installer. Like registry changes, making mistakes here could cause problems that may require the difficult task of rebuiling the Windows Installer cache or even reinstalling Windows.

To free up space, you can remove the baseline cache for Visual Studio 2005 under %WINDIR%\Installer\$PatchCache$\Managed by deleting the directory with the squished GUID representing the ProductCode for whichever Visual Studio 2005 products you have installed. The squished GUID is a transformed ProductCode. Attached you'll find a list of product names, product codes, product languages, product editions, and squished GUIDs for Visual Studio 2005 and the .NET Framework 2.0.

Again, be aware that by removing the baseline cache for a product, future repair, patch install, and patch uninstall scenarios may require your original installation media. If you have the drive space it is recommended that you keep the baseline caches available.