Ich habe vor kurzem angefangen, mit SQL Server 2008 als DBA-Auszubildender zu arbeiten. Ich muss die Größe der Datenbank berechnen, aber auch das Wachstum in den letzten Monaten und das prognostizierte Wachstum für die nächsten 12 Monate schätzen.
Ich kann die sp_spaceused-Anweisung verwenden, um die tatsächliche Größe zu berechnen, aber wie berechne ich alles andere?
Antworten:
Die anderen Antworten sind technisch korrekt, aber nicht korrekt. Folgendes müssen Sie dem Unternehmen fragen:
Welchen Zeithorizont strebe ich an? In Ihrem Fall suchen Sie eine 12-Monats-Nummer.
Werden wir in dieser Zeit Daten archivieren oder alle Daten behalten? In einigen Unternehmen dürfen (oder müssen) Sie nur eine bestimmte Datenmenge aufbewahren, wie in den letzten 12 Monaten. In diesem Fall müssen Sie das Datenwachstum herausfinden (das in den nachfolgenden Fragen beantwortet wird), dann aber wieder auf die letzten 12 Monate zurückgreifen. Sie können nicht einfach sagen: "Im Moment beträgt diese Datenmenge 100 GB", denn wenn Ihr Datenvolumen wächst, wachsen auch die letzten 12 Monate. Die Zeitmenge kann konstant sein, die Daten jedoch nicht.
Werden wir zusätzliche Benutzer hinzufügen? Zum Beispiel könnte das Geschäft in neue Gebiete wachsen oder neue Kunden gewinnen. Wenn sie die Benutzerbasis verdoppeln, werden in einigen Fällen auch die Daten verdoppelt.
Erwarten wir ein Wachstum des Geschäftsvolumens? Wenn Sie beispielsweise Verkäufe auf einer Website verfolgen und Super Bowl- oder Weltcup-Anzeigen schalten, kann Ihr Datenvolumen die Wachstumskurve des Hockeyschlägers beeinflussen.
Werden wir der App zusätzliche Funktionen hinzufügen? Wenn die App plötzlich Bilder speichert, wirkt sich dies dramatisch auf die Datenbankgröße aus.
Fügen wir Daten aus einer anderen Quelle hinzu oder protokollieren wir neue Daten? Wenn Sie mit der Erfassung von Website-Klicks beginnen oder in einem Data Warehouse zusätzliche Quellen hinzufügen, wächst das Datenvolumen.
Werden Entwickler oder Datenbankadministratoren Leistungsoptimierungsindizes sein? Wenn Sie zulassen, dass Benutzer Indizes erstellen, können Sie die Größe Ihrer Daten leicht verdoppeln (oder verdreifachen oder vervierfachen), je nachdem, wie übereifrig sie werden.
Und solange Sie diese Fragen stellen, sollten Sie auch fragen, ob die Leistung voraussichtlich gleich bleibt, sich verschlechtert oder besser wird. Ich mag es, das projizierte Wachstum in einem Liniendiagramm abzubilden und dann die Investitionen in Hardware und Personalschulung über denselben Zeitraum zu vergleichen.
Sie können zukünftiges Wachstum nicht genau projizieren, ohne eine Geschichte des vorherigen Wachstums. Sie können jedoch mithilfe des Sicherungsverlaufs betrügen und einen groben Trend erzielen, wie von Erin Stellato in Trending Database Growth From Backups beschrieben .
Zeichnen Sie die Ausgabe der folgenden Abfrage 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]);Es gibt viele Möglichkeiten, wie Sie die Datenbankkapazität planen können.
Wenn der MSDB-Sicherungsverlauf regelmäßig gekürzt wird, bleiben nicht mehr viele Daten für die Analyse übrig
Wie Mark betonte, kann dies mit der von Erin beschriebenen Methode erfolgen - Trenddatenbankwachstum aus dem Backup.
Sie können sogar PIVOT verwenden, um das Datenbankwachstum über einen Zeitraum von 12 Monaten aus dem Sicherungsverlauf wie folgt zu ermitteln:
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;Es gibt noch einen anderen Weg, den Sie wirklich nützlich finden werden, wie er von Chad Miller in SSC - Database Space Capacity Planning hervorragend beschrieben wurde . Er konzentriert sich auch darauf, days remainingwas sehr nützlich ist.
Es gibt andere Methoden, die mathematische Berechnungen beinhalten, und dies würde genaue Ergebnisse liefern. Wie bereits erwähnt, beziehen sich Backups am besten auf das Datenwachstum, da Sie sagten, Sie müssten die Größe der Datenbank unter Microsoft-Links berechnen und vorhersagen
Schätzen Sie die Größe der Datenbank
Schätzen Sie die Größe des Clustered Index
Hoffe dieser Code hilft:
Funktioniert basierend auf dem Verlauf der Sicherungsgröße (in MB) und gibt Monat für Monat minimale MB, durchschnittliche MB, maximale MB und Unterschiede zu anderen Monaten in MB an.
Listet alle Datenbanken mit Sicherungen mit Ausnahme der Systemdatenbanken auf.
-- 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.YearMonthIch denke, Brent Ozars Beitrag ist genau richtig. Ich war in einem massiv aufgeblähten DB-Projekt und hatte genau das gleiche Problem wie hier, und es ist einfach nicht so einfach.
Da es besser ist, zumindest etwas zu tun - auch wenn es nicht wirklich so genau ist -, würde ich die erforderlichen Tabellen und einen Job (oder eine andere gewünschte Methode, alles, um nur die Größen abzufragen und sie an einem zuverlässigen Ort zu speichern) einrichten, um sie zu verfolgen die Zeilen und den Speicherplatz, die wöchentlich für DB und alle seine Tabellen verwendet werden, und verwenden Sie diese, um die wahrscheinlichste Wachstumskurve zu projizieren. Die Verwendung des Sicherungsverlaufs ist ebenfalls eine gute Idee. Unabhängig von der Methode benötigen Sie jedoch Zeit, um auch aus der Ferne zuverlässige Daten zu erhalten.
Davon abgesehen hängt es wirklich von Ihrer Situation ab. Möglicherweise ist die Nutzung% Ihrer Datenbank nur noch ein Bruchteil der Nutzung in den nächsten 6 Monaten, beispielsweise wenn Ihre Software an Boden gewinnt, sodass es unmöglich ist, das bevorstehende explosive Wachstum vorherzusagen. Möglicherweise gibt es jährliche massive Datenübertragungen, die die Größe der Datenbank verdoppeln, aber Sie werden erst nachträglich von dieser Masse erfahren.
Aber wie gesagt, wenn Wachstum ein Problem ist, sollten Sie unbedingt etwas tun, um den Überblick zu behalten. Das Letzte, was Sie möchten, ist, sich in 6 Monaten mit einer DB zu befinden, die doppelt so massiv ist wie ihre ursprüngliche Lebensdauerprojektion, und Ihrem Kunden erklären zu müssen, wie oder warum dies passiert ist, ganz zu schweigen davon, dass Sie erraten müssen, wie viel mehr sie wachsen wird in den nächsten 6 Monaten. Es gibt auch einige sehr offensichtliche Vorteile, wenn Sie wissen, wohin die neuen Daten gegangen sind und wie das relative Wachstum jeder Tabelle in einem bestimmten Zeitraum ist, da sie mit relativ geringem Aufwand wertvolle Informationen zu verschiedenen Trends, potenziellen Softwareproblemen usw. liefern können .