Yes, SQL Server files do not shrink automatically. They remain the same size unless you explicitly shrink them, either through the SQL Server Management Studio or by using the DBCC SHRINKFILE command. While you can set files to autoshrink, this is widely advised against because shrinking/growing files is very resource intensive, especially when you're dealing with log files which don't have instant file initialization.
EDIT: In response to your edit: there is a difference between MAXSIZE and the size a file can get before running out of disk. You can set that in the Files section of the database properties, or with an ALTER DATABASE command.
File writes are distributed across files in the same file group proportionally based on the current size of each file in the file group. This is referred to as the "proportional fill algorithm" - look at http://sqlserver-performance-tuning.net/?p=2552 for some interesting details around that.
tempdb
can have only a single filegroup. If you attempt to create a filegroup in tempdb
you get the following:
Msg 1826, Level 16, State 1, Line 1
User-defined filegroups are not allowed on "tempdb".
If you have trace flag 1117 turned on, files within a group will autogrow simultaneously across files in the filegroup for each file that is not currently at its maximum size, and where space exists on the disk.
Does your instance have trace flag 1117 turned on? You'd probably want it off in this particular instance even though "best practices" often indicate having this turned on. There is an item on Microsoft Connect asking to have a setting like this that can be enabled/disabled on a per-database basis, here: https://connect.microsoft.com/SQLServer/feedback/details/781198/trace-flag-1117-autogrowth-of-data-files-is-instance-wide-would-like-a-flag-for-just-tempdb
Assuming the SSDs are devoted to tempdb, I agree with your assertion and suggest making the tempdb on the SSDs as big as possible (not 100% of the drive, perhaps leave 10% free). Make the tempdb files on disk as small as possible, say 1MB, with autogrowth, and maximum file size as big as you need. Monitor for tempdb filegrowth on the HDDs, and make the case for getting bigger SSDs if you think the company would benefit from it.
According to the documentation, SQL Server files can be created on raw partitions (partitions that haven't been formatted) by using just the drive letter of the partition in the ALTER DATABASE ... ADD FILE
syntax. This apparently removes the need to grow or shrink the file since it inherently uses the entire raw partition, as needed. I'm uncertain if this would help your situation or not; just thought I'd throw it out there as an interesting factoid. See "If the file is on a raw partition, os_file_name must specify only the drive letter of an existing raw partition. Only one file can be put on each raw partition."
Best Answer
I have written reports, and actually alerting with it, for clients to monitor multiple servers within their test and production environments. I basically used a SQL Agent Job with a PowerShell step to pull in disk information (
win32_volume
) into some tables.I then decided to create another PowerShell step that went back and checked if the free space was within a configured threshold (stored in a table). We went with this approach because it was just easier to setup and write fairly quickly. It was also cleaner code to write for a HTML report to be sent via email, than trying to do it in T-SQL.
You have DMVs in SQL Server to get disk space usage (e.g.
sys.dm_os_volume_stats
) but the PowerShell option above allowed us to monitor all drives found on a given server. Now caveat you will have to create a proxy account for the PowerShell execution and that account should have appropriate permissions.An example of just getting a HTML report on free disk space.
EDIT
Just realized from Mike's comment that I had a function in my profile to, it is written a bit different than his but this is just what worked for me: