Comments on: SQL Server: Use xp_fixeddrives Procedure to monitor the Disk Space of Server

By: Anvesh Patel

Anvesh Patel — Thu, 23 Mar 2017 18:23:04 +0000

In reply to Bruce. Hey Bruce, thanks for adding this, yes only problem with sysadmin level permission....

By: Bruce

Bruce — Wed, 22 Mar 2017 23:34:28 +0000

An alternate way to leverage this for automation, is to use it within a SQL Agent job. Depending on how you have setup security on your SQL Agent process, it likely runs as a SysAdmin equivalent.

If you create a job that runs xp_fixeddrives for you, you could have it write to a monitoring database on the server. Then any automation could poll that table.

I am going that route for my solution. I have added a simple integer identity column to my results (plus a datetime filed) that my automation can use as an ascending value to use in a reporting system import process. I can flush out old data when I feel it is getting to large.

By: Bruce

Bruce — Wed, 22 Mar 2017 22:22:58 +0000

I love when this one gets trotted out every couple of years. The biggest thing everyone avoids is the ugly truth: the call to xp_fixeddrives must run as a SysAdmin level security right. Otherwise you get no results.

Trying to use this in automation suddenly becomes a lot harder because you now have to give your automation access to a very dangerous set of rights on your server. It’s even worse if your automation doesn’t have a way to store encrypted passwords, and can not run in the context of a Windows domain user account.

If you are running on SQL 2008 R2 or later, then you have access to a DMV called: sys.dm_os_volume_stats

I have never used it because I am stuck on 2008 (pre R2) servers, but you can search Google to find lots of articles on this exact topic.

It’s not to say that this is not a really cool officially undocumented procedure. It is fast and simple. It just requires elevated rights to work.