Di recente ho iniziato a lavorare con SQL Server 2008 come apprendista DBA. Devo calcolare le dimensioni del database, ma anche stimarne la crescita negli ultimi mesi e la crescita prevista per i prossimi 12 mesi.
Posso usare l'istruzione sp_spaceused per calcolare la dimensione effettiva, ma come posso calcolare tutto il resto?
Risposte:
Le altre risposte sono tecnicamente corrette, ma non corrette nel mondo reale. Ecco cosa devi chiedere all'azienda:
A che orizzonte sto puntando? Nel tuo caso, stai cercando un numero di 12 mesi.
Durante quel periodo, archiveremo i dati o li conserveremo? In alcune aziende, è consentito (o richiesto) conservare solo una determinata quantità di dati, come negli ultimi 12 mesi. In tal caso, dovrai capire la crescita dei dati (a cui risponderanno le domande successive) ma poi tornare indietro agli ultimi 12 mesi. Non puoi semplicemente dire "In questo momento la quantità di dati è di 100 GB", perché se il tuo volume di dati aumenta, anche gli ultimi 12 mesi aumentano. La quantità di tempo potrebbe essere costante, ma i dati non lo sono.
Aggiungeremo altri utenti? Ad esempio, l'azienda potrebbe espandersi in nuovi territori o acquisire nuovi clienti. Se raddoppiano la base di utenti, in alcuni casi anche i dati inizieranno a raddoppiare.
Prevediamo che il volume degli affari crescerà? Se stai monitorando le vendite su un sito Web, ad esempio, e inizi a pubblicare annunci Super Bowl o Coppa del Mondo, il tuo volume di dati può colpire la curva di crescita del bastone da hockey.
Aggiungeremo funzionalità aggiuntive nell'app? Se l'app inizia improvvisamente a memorizzare le immagini, ciò influirà notevolmente sulla dimensione del database.
Aggiungeremo dati da un'altra fonte o registreremo nuovi dati? Se si inizia a catturare i clic del sito Web o in un data warehouse, aggiungendo ulteriori fonti, il volume dei dati aumenterà.
Gli sviluppatori o gli amministratori di database saranno indici di ottimizzazione delle prestazioni? Se hai intenzione di consentire alle persone di creare indici, puoi facilmente raddoppiare (o triplicare o quadruplicare) la dimensione dei tuoi dati a seconda di quanto siano troppo zelanti.
E fintanto che stai ponendo queste domande, dovresti anche chiedere se le prestazioni dovrebbero rimanere invariate, peggiorare o migliorare. Mi piace mappare la crescita prevista su un grafico a linee, quindi confrontare gli investimenti in formazione hardware e personale su quella stessa linea temporale.
Non è possibile proiettare con precisione la crescita futura senza una storia di crescita precedente. Puoi tuttavia imbrogliare e ottenere una tendenza approssimativa utilizzando la cronologia dei backup, come dettagliato da Erin Stellato in Trending Growth Database From Backups .
Traccia l'output della seguente query in Excel:
SELECT
[Database] = [database_name]
, [Month] = DATEPART(month,[backup_start_date])
, [Backup Size MB] = AVG([backup_size]/1024/1024)
, [Compressed Backup Size MB] = AVG([compressed_backup_size]/1024/1024)
, [Compression Ratio] = AVG([backup_size]/[compressed_backup_size])
FROM
msdb.dbo.backupset
WHERE
[database_name] = N'YourDatabaseName'
AND [type] = 'D'
GROUP BY
[database_name]
, DATEPART(mm, [backup_start_date]);
Esistono molti modi per eseguire la pianificazione della capacità del database.
cronologia del backup msdb se viene regolarmente ritagliata, non avrai molti dati da analizzare
Come ha sottolineato Mark, può essere fatto usando il metodo descritto da Erin - trending crescita del database dal backup.
È anche possibile utilizzare PIVOT per scoprire la crescita del database in un periodo di 12 mesi dalla cronologia dei backup come di seguito:
DECLARE @startDate DATETIME;
SET @startDate = GetDate();
SELECT PVT.DatabaseName
,PVT.[0]
,PVT.[-1]
,PVT.[-2]
,PVT.[-3]
,PVT.[-4]
,PVT.[-5]
,PVT.[-6]
,PVT.[-7]
,PVT.[-8]
,PVT.[-9]
,PVT.[-10]
,PVT.[-11]
,PVT.[-12]
FROM (
SELECT BS.database_name AS DatabaseName
,DATEDIFF(mm, @startDate, BS.backup_start_date) AS MonthsAgo
,CONVERT(NUMERIC(10, 1), AVG(BF.file_size / 1048576.0)) AS AvgSizeMB
FROM msdb.dbo.backupset AS BS
INNER JOIN msdb.dbo.backupfile AS BF ON BS.backup_set_id = BF.backup_set_id
WHERE BS.database_name NOT IN (
'master'
,'msdb'
,'model'
,'tempdb'
)
AND BS.database_name IN (
SELECT db_name(database_id)
FROM master.SYS.DATABASES
WHERE state_desc = 'ONLINE'
)
AND BF.[file_type] = 'D'
AND BS.backup_start_date BETWEEN DATEADD(yy, - 1, @startDate)
AND @startDate
GROUP BY BS.database_name
,DATEDIFF(mm, @startDate, BS.backup_start_date)
) AS BCKSTAT
PIVOT(SUM(BCKSTAT.AvgSizeMB) FOR BCKSTAT.MonthsAgo IN (
[0]
,[-1]
,[-2]
,[-3]
,[-4]
,[-5]
,[-6]
,[-7]
,[-8]
,[-9]
,[-10]
,[-11]
,[-12]
)) AS PVT
ORDER BY PVT.DatabaseName;
C'è un altro modo che troverai davvero utile come descritto in modo eccellente da Chad Miller su SSC - Database Space Capacity Planning . Si concentra anche su ciò days remainingche è molto utile.
Esiste un altro metodo che prevede calcoli matematici e questo darebbe risultati accurati. Come backup già indicato sarebbe meglio fare riferimento alla crescita dei dati poiché hai detto che devi calcolare e prevedere la dimensione del database sotto i collegamenti Microsoft ti aiuterebbe
Stima delle dimensioni del database
Spero che questo codice aiuti:
Funziona in base alla cronologia delle dimensioni del backup (in MB), fornisce mese per mese min MB, avg MB, max MB e differenza rispetto agli altri mesi in MB.
Elenca tutti i database con backup ad eccezione dei database di sistema.
-- T-SQL script - Analyses database growth using backup information (Last (12) months in that case
-- Looks only to FULL backups information
-- Parameters: Date GetDate() and nr of months to analyse
SET NOCOUNT ON
DECLARE @endDate datetime, @months smallint;
SET @endDate = GetDate(); -- Data atual
SET @months = 12; -- Nr. de meses a analisar
;WITH HIST AS
(SELECT BS.database_name AS DatabaseName
,YEAR(BS.backup_start_date) * 100
+ MONTH(BS.backup_start_date) AS YearMonth
,CONVERT(numeric(10, 1), MIN(BS.backup_size / 1048576.0)) AS MinSizeMB
,CONVERT(numeric(10, 1), MAX(BS.backup_size / 1048576.0)) AS MaxSizeMB
,CONVERT(numeric(10, 1), AVG(BS.backup_size / 1048576.0)) AS AvgSizeMB
FROM msdb.dbo.backupset as BS
WHERE NOT BS.database_name IN
('master', 'msdb', 'model', 'tempdb')
AND BS.type = 'D'
AND BS.backup_start_date BETWEEN DATEADD(mm, - @months, @endDate) AND @endDate
GROUP BY BS.database_name
,YEAR(BS.backup_start_date)
,MONTH(BS.backup_start_date))
SELECT @@SERVERNAME
,MAIN.DatabaseName
,MAIN.YearMonth
,MAIN.MinSizeMB
,MAIN.MaxSizeMB
,MAIN.AvgSizeMB
,MAIN.AvgSizeMB
- (SELECT TOP 1 SUB.AvgSizeMB
FROM HIST AS SUB
WHERE SUB.DatabaseName = MAIN.DatabaseName
AND SUB.YearMonth < MAIN.YearMonth
ORDER BY SUB.YearMonth DESC) AS GrowthMB
FROM HIST AS MAIN
ORDER BY MAIN.DatabaseName
,MAIN.YearMonth
Penso che il post di Brent Ozar sia perfetto. Sono stato in un progetto DB enormemente gonfio e ho avuto esattamente lo stesso problema che fai qui, e non è poi così semplice.
Dal momento che è meglio fare almeno qualcosa - anche se non proprio così accurato -, imposto le tabelle richieste e un lavoro (o qualsiasi altro metodo tu voglia, qualsiasi cosa per semplicemente interrogare le dimensioni e memorizzarlo da qualche parte in modo affidabile) per tracciare le righe e lo spazio utilizzati per DB e tutte le sue tabelle su base settimanale e utilizzarlo per proiettare la curva di crescita più probabile. Anche l'utilizzo della cronologia dei backup è un'ottima idea. Ma indipendentemente dal metodo, è necessario del tempo per ottenere dati affidabili anche da remoto.
A parte questo, dipende davvero dalla tua situazione. Potrebbe essere l'uso% del tuo DB ora è solo una frazione di quello che sarà nei prossimi 6 mesi, ad esempio quando il tuo software guadagnerà più terreno, rendendo impossibile prevedere la crescita esplosiva che sta arrivando. Può darsi che ci siano trasferimenti di dati massicci annuali che raddoppieranno le dimensioni del DB, ma scoprirai quella massa solo dopo il fatto.
Ma come detto, se la crescita è una preoccupazione, allora dovresti assolutamente fare qualcosa per tenerne traccia. L'ultima cosa che vuoi è ritrovarti tra 6 mesi con un DB due volte più massiccio della sua proiezione a vita originale, dover spiegare ai tuoi clienti come o perché è successo, per non parlare del dover cominciare a indovinare quanto più crescerà nei prossimi 6 mesi. Ci sono anche alcuni ovvi benefici nel sapere dove sono andati i nuovi dati e qual è la crescita relativa di ogni tabella in un dato periodo di tempo, in quanto può fornire informazioni preziose su tendenze diverse, potenziali problemi del software ecc. Tutto per uno sforzo relativamente piccolo .