I don't understand well why the available space in database is 0% while in file is 98% available. Can you explain or advise? (SQL Server 2019, SSMS the newest, one datafile)
Sql-server – SQL Server : database free space vs data file free space
shrinksize;sql server
Related Solutions
To summarize the answers here and to inject my own advice:
1: Blindly shrinking a data file is not the best route. Your data is your data and it is characterized by this size. Unless you are planning on deleting large chunks of data, shrinking is not going to do much of anything. As @billinkc pointed out, simply shrinking the file will not give you any sort of appreciable gain.
2: Running this is going to make your log file grow. Apparently you have your data and log on the same drive. I'd recommend against this for many reasons including space and IO contention.
3: You can certainly create a new data file and put that on a different volume. You could "archive" old data to free space in the current .mdf, or you could leave the current data file as-is and it would become an archive, of sorts.
4: I'm guessing that there are other things on this volume as well. I would move those things as quickly as I could in order to free up space.
If this is enterprise data, I'd push for more disk. This would allow you to separate your data and log files. Additionally, outside of just deleting data, you're going to need more disk to implement Brandon's suggestion anyway.
This doesn't really seem all that crazy, but note that some of the UI dialogs might not have completely up-to-date information (this is why we have things like DBCC UPDATEUSAGE), and rounding can also be involved in some of those calculations. Finally, the dialogs show you total space for the whole database, but unallocated space is only calculated for the data files, not the log.
Let's coalesce some things.
- Database properties and shrink database show the same thing (not that you should ever be in the shrink database UI anyway!).
- Database file properties show 17 + 75 = 92 which, with rounding before addition, is probably the same 91.31 in 1.
- For space allocated, shrink for individual files show 16.38 + 74.94 = 91.32 - again, probably some rounding there, otherwise exactly matching 1.
- For space available, shrink for individual files is the only place where I suspect a real discrepancy, and this is because the UI is inconsistent about where it gets its data, and some of these places are subject to the caching that necessitates DBCC UPDATEUSAGE.
Let me take a look at what these different dialogs run for my local copy of AdventureWorks2012 (with certain tables enlarged from this script).
EXEC sp_spaceused;
This returns (first resultset only):
database_size unallocated space
------------- -----------------
1545.81 MB 6.67 MB
Essentially runs this, which - I've confirmed via trace - is roughly the same query executed from the database properties and database shrink dialogs (I've carved out the irrelevant parts from the stored procedure, and added an outer query to represent the math that SSMS does for display):
SELECT database_size = DbSize*8.0/1024 + LogSize*8.0/1024,
[unallocated space] = (DbSize-SpaceUsed)*8.0/1024
FROM
(
SELECT
(SELECT SUM(CAST(df.size as float)) FROM sys.database_files AS df
WHERE df.type in ( 0, 2, 4 ) ) AS [DbSize],
SUM(a.total_pages) AS [SpaceUsed],
(SELECT SUM(CAST(df.size as float)) FROM sys.database_files AS df
WHERE df.type in (1, 3)) AS [LogSize]
FROM sys.partitions p
join sys.allocation_units a on p.partition_id = a.container_id
left join sys.internal_tables it on p.object_id = it.object_id
) AS x;
This returns a match:
database_size unallocated space
------------- -----------------
1545.8125 6.671875
These dialogs all show this information correctly. Database Properties dialog:
Shrink Database dialog:
The shrink file dialogs, on the other hand, run a slightly different query (again this is carved/adapted for convenience):
SELECT SUBSTRING(name, CHARINDEX('_',name)+1, 4),
[Currently allocated space] = size/1024.0,
[Available free space] = (Size-UsedSpace)/1024.0
FROM
(
SELECT s.name,
CAST(FILEPROPERTY(s.name, 'SpaceUsed') AS float)*CONVERT(float,8) AS [UsedSpace],
s.size * CONVERT(float,8) AS [Size]
FROM sys.database_files AS s
WHERE (s.type IN (0,1))
) AS x;
Note, too, that in addition to getting size data from a function instead of a DMV, the predicates have not been updated for new file types, like filestream/hekaton.
Results:
Currently allocated space Available free space
---- ------------------------- --------------------
Data 1517 7.9375 -- wrong
Log 28.8125 25.671875 -- wrong
The problem is the FILEPROPERTY()
function, which is not guaranteed to be up to date (even after DBCC UPDATEUSAGE(0);
is run; more below). This ends up with this misleading information on the dialogs:
Note, again, that 6.67 MB was never really accurate, since this is only measuring the total database size - the number of pages allocated, completely disregarding the log.
In all honesty, if you want accurate reporting of space used in the database, stop using the mickey mouse UIs which run all kinds of different queries to figure this out, and stop using the shrink file dialogs for retrieving information. These are clearly subject to stale data problems in certain cases. Run an actual query against a source you can trust. Here is what I prefer:
DECLARE @log_used DECIMAL(19,7);
CREATE TABLE #x(n SYSNAME, s DECIMAL(19,7), u DECIMAL(19,7), b BIT);
INSERT #x EXEC('DBCC SQLPERF(LogSpace);');
SELECT @log_used = u FROM #x WHERE n = DB_NAME();
DROP TABLE #x;
DECLARE @data_used DECIMAL(19,7);
SELECT @data_used = SUM(a.total_pages)*8/1024.0
FROM sys.partitions AS p
INNER JOIN sys.allocation_units AS a
ON p.[partition_id] = a.container_id;
;WITH x(t,s) AS
(
SELECT [type] = CASE
WHEN [type] IN (0,2,4) THEN 'data' ELSE 'log' END,
size*8/1024.0 FROM sys.database_files AS f
)
SELECT
file_type = t,
size = s,
available = s-CASE t WHEN 'data' THEN @data_used ELSE @log_used END
FROM x;
This query returns three numbers that should look very familiar, and one that should not:
file_type size available
--------- ----------- ----------
data 1517.000000 6.6718750
log 28.812500 17.9008512
Note that DBCC SQLPERF is also slightly prone to issues with space usage, for example after running:
DBCC UPDATEUSAGE(0);
The above query yields this instead:
file_type size available
--------- ----------- ----------
data 1517.000000 8.0781250
log 28.812500 17.8669481
sp_spaceused
now yields matching numbers as well (1545.81 MB / 8.08 MB
), even though - again - that is only the space available in the data file(s), and the database property and database shrink dialogs are "accurate" as well (but the shrink file dialogs are still way off - FILEPROPERTY()
does not seem to be affected by UPDATEUSAGE
at all):
Oh, and might as well show what Windows Explorer thinks of these files, so you can relate to the calculations made to determine MB:
How accurate this all needs to be, of course, depends on what you're going to do with the information.
Related Question
- Sql-server – Monitoring free space in SQL Server data files
- SQL Server – Delete Query Does Not Free Up Space
- SQL Server Disk Space – Database Free Space Not Being Reused
- SQL Server – Free Space Management in SQL Server
- Sql-server – How are pages reallocated in a a data file after shrinkfile sql server
- Sql-server – SQL Server – Space Available
- Sql-server – SQL SERVER ERRORLOG FILE UTILIZING THE FREE SPACE
Best Answer
There are apparently errors in the calculations in SSMS.
Shrink Database dialog
Currently allocated space: show the allocated space for both data and log. Correct.
Available free space: show free space for only data, doesn't include log. Incorrect.
The calculating of the free space is off. It divides the full database size (including log) with the free space for the data file (only). Also, it presents the full database size (including log) and for free space, it only show free space for data.
Shrink File dialog
Referring to data file. This is inconsistent. For one of my databases, is show the correct info for the primary data and only file. For a different database (stack overflow 10 GB), it is way off with free space (both number and percentage). For the SO db, it shows only about 600 MB used, when in fact it is about 1.6 GB. My guess is that there is an overflow in a variable in the host language within SSMS causing a wraparound (if it were in TSQL you'd get an error instead)
I.e. disregard the GUI. Collect info from some more correct query/method (what Niels suggested for instance - I use my own sp_dbinfo for these things). and then use the DBCC SHRINK commands directly (preferably DBCC SHRINKFILE).
And, of course don't shrink unless you really really really need that disk space, it is a significant amount of disk space and you are willing to pay the price for shrinking.