Questo non sembra poi così folle, ma nota che alcune delle finestre di dialogo dell'interfaccia utente potrebbero non avere informazioni completamente aggiornate (ecco perché abbiamo cose come DBCC UPDATEUSAGE ) e l'arrotondamento può anche essere coinvolto in alcune di quelle calcoli. Infine, le finestre di dialogo mostrano lo spazio totale per l' intero database , ma lo spazio non allocato viene calcolato solo per i file di dati , non per il registro.
Uniamo alcune cose.
- Le proprietà del database e il database di riduzione mostrano la stessa cosa (non che tu debba mai essere comunque nell'interfaccia utente del database di riduzione!).
- Le proprietà del file di database mostrano 17 + 75 = 92 che, con arrotondamento prima dell'aggiunta, è probabilmente lo stesso 91.31 in 1.
- Per lo spazio allocato, riduci per i singoli file mostra 16.38 + 74.94 = 91.32 - di nuovo, probabilmente alcuni arrotondamenti lì, altrimenti esattamente 1 corrispondente.
- Per lo spazio disponibile, la riduzione dei singoli file è l'unico posto in cui sospetto una reale discrepanza, e questo perché l'interfaccia utente non è coerente su dove ottiene i suoi dati e alcuni di questi luoghi sono soggetti alla memorizzazione nella cache che richiede DBCC UPDATEUSAGE.
Consentitemi di dare un'occhiata a cosa funzionano queste diverse finestre di dialogo per la mia copia locale di AdventureWorks2012 (con alcune tabelle ingrandite da questo script ).
EXEC sp_spaceused;
Questo restituisce (solo il primo set di risultati):
database_size unallocated space
------------- -----------------
1545.81 MB 6.67 MB
Esegue essenzialmente questo, che - ho confermato tramite trace - è all'incirca la stessa query eseguita dalle proprietà del database e dalle finestre di dialogo di riduzione del database (ho ricavato le parti irrilevanti dalla procedura memorizzata e ho aggiunto una query esterna per rappresentare la matematica che SSMS fa per la visualizzazione):
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;
Questo restituisce una corrispondenza:
database_size unallocated space
------------- -----------------
1545.8125 6.671875
Queste finestre di dialogo mostrano tutte queste informazioni correttamente. Finestra di dialogo Proprietà database:
Finestra di dialogo Riduci database:
Le finestre di dialogo per la riduzione dei file , d'altra parte, eseguono una query leggermente diversa (di nuovo questa è scolpita / adattata per comodità):
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;
Inoltre, oltre a ottenere dati sulle dimensioni da una funzione anziché da un DMV, i predicati non sono stati aggiornati per nuovi tipi di file, come filestream / hekaton.
risultati:
Currently allocated space Available free space
---- ------------------------- --------------------
Data 1517 7.9375 -- wrong
Log 28.8125 25.671875 -- wrong
Il problema è la FILEPROPERTY()funzione, che non è garantita per essere aggiornata (anche dopo l' DBCC UPDATEUSAGE(0);esecuzione, più sotto). Questo finisce con queste informazioni fuorvianti nelle finestre di dialogo:
Si noti, ancora, che 6,67 MB non sono mai stati molto precisi, poiché si tratta solo di misurare la dimensione totale del database, ovvero il numero di pagine allocate, ignorando completamente il registro.
In tutta onestà, se si desidera un reporting accurato dello spazio utilizzato nel database, smettere di usare le UI di Topolino che eseguono tutti i tipi di query diverse per capirlo, e smettere di usare le finestre di dialogo di riduzione dei file per recuperare informazioni. Questi sono chiaramente soggetti a problemi di dati obsoleti in alcuni casi. Esegui una query effettiva su una fonte di cui ti puoi fidare. Ecco cosa preferisco:
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;
Questa query restituisce tre numeri che dovrebbero apparire molto familiari e uno che non dovrebbe:
file_type size available
--------- ----------- ----------
data 1517.000000 6.6718750
log 28.812500 17.9008512
Si noti che DBCC SQLPERF è anche leggermente incline a problemi con l'utilizzo dello spazio, ad esempio dopo l'esecuzione:
DBCC UPDATEUSAGE(0);
La query sopra produce invece questo:
file_type size available
--------- ----------- ----------
data 1517.000000 8.0781250
log 28.812500 17.8669481
sp_spaceusedora produce anche numeri corrispondenti ( 1545.81 MB / 8.08 MB), anche se - ancora una volta - questo è solo lo spazio disponibile nei file di dati , e anche le finestre di dialogo di riduzione delle proprietà del database e del database sono "accurate" (ma le finestre di dialogo di riduzione dei file sono ancora lontano - FILEPROPERTY()non sembra essere UPDATEUSAGEaffatto influenzato ):
Oh, e potrebbe anche mostrare cosa ne pensa Windows Explorer di questi file, quindi puoi collegarti ai calcoli effettuati per determinare MB:
Quanto deve essere preciso tutto ciò, ovviamente, dipende da cosa hai intenzione di fare con le informazioni.