Isso realmente não parece tão louco, mas observe que algumas das caixas de diálogo da interface do usuário podem não ter informações completamente atualizadas (é por isso que temos coisas como DBCC UPDATEUSAGE ) e o arredondamento também pode estar envolvido em algumas dessas cálculos. Por fim, as caixas de diálogo mostram o espaço total para todo o banco de dados , mas o espaço não alocado é calculado apenas para os arquivos de dados , não para o log.
Vamos unir algumas coisas.
- As propriedades do banco de dados e o banco de dados de redução mostram a mesma coisa (não é necessário que você esteja na interface do banco de dados de redução de qualquer maneira!).
- As propriedades do arquivo de banco de dados mostram 17 + 75 = 92 que, com o arredondamento antes da adição, é provavelmente o mesmo 91,31 em 1.
- Para o espaço alocado, a redução para arquivos individuais mostra 16,38 + 74,94 = 91,32 - novamente, provavelmente alguns arredondamentos, caso contrário, exatamente corresponde a 1.
- Para o espaço disponível, a redução de arquivos individuais é o único lugar em que suspeito uma discrepância real, e isso ocorre porque a interface do usuário é inconsistente sobre onde obtém seus dados e alguns desses locais estão sujeitos ao cache que requer DBCC UPDATEUSAGE.
Deixe-me ver o que essas caixas de diálogo diferentes executam para minha cópia local do AdventureWorks2012 (com determinadas tabelas ampliadas a partir deste script ).
EXEC sp_spaceused;
Isso retorna (apenas o primeiro conjunto de resultados):
database_size unallocated space
------------- -----------------
1545.81 MB 6.67 MB
Essencialmente, isso é executado, o que - confirmei por rastreamento - é aproximadamente a mesma consulta executada nas propriedades do banco de dados e nas caixas de diálogo de redução do banco de dados (eu esculpi as partes irrelevantes do procedimento armazenado e adicionei uma consulta externa para representar a matemática que o SSMS faz para exibição):
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;
Isso retorna uma correspondência:
database_size unallocated space
------------- -----------------
1545.8125 6.671875
Todas essas caixas de diálogo mostram essas informações corretamente. Caixa de diálogo Propriedades do Banco de Dados:
Caixa de diálogo Encolher banco de dados:
As caixas de diálogo de arquivo de redução , por outro lado, executam uma consulta um pouco diferente (mais uma vez, esta foi esculpida / adaptada para maior comodidade):
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;
Observe também que, além de obter dados de tamanho de uma função em vez de uma DMV, os predicados não foram atualizados para novos tipos de arquivo, como filestream / hekaton.
Resultados:
Currently allocated space Available free space
---- ------------------------- --------------------
Data 1517 7.9375 -- wrong
Log 28.8125 25.671875 -- wrong
O problema é a FILEPROPERTY()função, que não é garantida como atualizada (mesmo após a DBCC UPDATEUSAGE(0);execução; mais abaixo). Isso acaba com essas informações enganosas nas caixas de diálogo:
Observe, novamente, que 6,67 MB nunca foram realmente precisos, pois isso está medindo apenas o tamanho total do banco de dados - o número de páginas alocadas, desconsiderando completamente o log.
Com toda a honestidade, se você deseja gerar relatórios precisos do espaço usado no banco de dados, pare de usar as UIs do mickey mouse que executam todos os tipos de consultas diferentes para descobrir isso e pare de usar as caixas de diálogo de arquivos compactados para recuperar informações. Estes estão claramente sujeitos a problemas de dados obsoletos em certos casos. Execute uma consulta real em uma fonte em que você possa confiar. Aqui está o que eu prefiro:
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;
Esta consulta retorna três números que devem parecer muito familiares e um que não deve:
file_type size available
--------- ----------- ----------
data 1517.000000 6.6718750
log 28.812500 17.9008512
Observe que o DBCC SQLPERF também é um pouco propenso a problemas com o uso de espaço, por exemplo, após a execução:
DBCC UPDATEUSAGE(0);
A consulta acima gera isso:
file_type size available
--------- ----------- ----------
data 1517.000000 8.0781250
log 28.812500 17.8669481
sp_spaceusedagora produz números correspondentes, bem como ( 1545.81 MB / 8.08 MB), embora - mais uma vez - que é apenas o espaço disponível na dados de arquivo (s), ea propriedade da base de dados e encolher banco de dados de caixas de diálogo são "precisos", bem como (mas os diálogos de arquivo encolher ainda são longe - FILEPROPERTY()não parece ser afetado por UPDATEUSAGE):
Ah, e também pode mostrar o que o Windows Explorer pensa desses arquivos, para que você possa se relacionar com os cálculos feitos para determinar o MB:
A precisão de tudo isso depende, é claro, do que você fará com as informações.