TableSpace Update

The last post in the series on finding the sizes of your tables showed us how we could find that size via a set-based method similar to using sp_MStablespace.  In that post I showed you how to find the sizes using the SQL 2005 system objects rather than the scheduled to be deprecated objects.  You can read more about it here.

I needed to go back and revisit that post and perform a little spring cleaning on it.  I noticed after publication that the script had multiple columns by the same name that were unintended.  I discovered this as I was prepping and reviewing for my presentation at our SSSOLV (PASS UG) meeting last week.  During that review I came across another bug.  The script was not consistently returning the index size for the tables.  After reviewing the script more closely, against more databases, I found the problem and fixed it.  The change was rather simple – I changed the Join from the #indstats table to go directly to sys.partitions rather than through sys.dm_db_index_usage_stats.  I was able to spot this one due to running the query against one of my databases that is seldom used and thus the indexes were less likely to have statistics populated in that DMV.

So, here is the updated query.  Rather than breaking out into sections like I did in that last article, I am just pasting the script in its entirety.

[codesyntax lang=”tsql”]


At some point in the future, I intend on modifying this query to make it more flexible in output, as well as to make it into a stored procedure.

10 thoughts on “TableSpace Update”

    1. Yes, the information is available there and is coming up in the next article that discusses my version of sp_spaceused.

    1. They did enjoy it. There will be a few follow-ups that will basically show the rest of the presentation.

  1. Just a small hint, I’ve noticed the {529e71a51265b45c1f7f96357a70e3116ccf61cf0135f67b2aa293699de35170} of DB is based on the data file size rather than the used space of the DB. So my total used space is like 56{529e71a51265b45c1f7f96357a70e3116ccf61cf0135f67b2aa293699de35170} rather than 100{529e71a51265b45c1f7f96357a70e3116ccf61cf0135f67b2aa293699de35170}. Maybe a new column is in order…

  2. Remi,
    I thought about removing the system tables but decided to leave them. When I removed them I saw a difference in size of the total database size and wanted to make sure the size this script reported was consistent with the size in SSMS.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.