Während sich das Jahr 2014 dem Ende zuneigt, starte ich eine Reihe von Beiträgen zu proaktiven SQL Server-Zustandsprüfungen, basierend auf einem Beitrag, den ich Anfang dieses Jahres geschrieben habe – Leistungsprobleme:Die erste Begegnung. In diesem Beitrag habe ich besprochen, wonach ich bei der Behebung eines Leistungsproblems in einer unbekannten Umgebung zuerst suche. In dieser Beitragsserie möchte ich darüber sprechen, wonach ich suche, wenn ich mich bei meinen langjährigen Kunden erkundige. Wir bieten einen Remote-DBA-Service an, und eine unserer regelmäßigen Aufgaben ist ein monatliches „Mini“-Gesundheitsaudit ihrer Umgebung. Wir haben eine Überwachung eingerichtet und normalerweise arbeite ich an Projekten, also bin ich regelmäßig in der Umgebung. Aber als zusätzlichen Schritt, um sicherzustellen, dass uns nichts entgeht, gehen wir einmal im Monat dieselben Daten durch, die wir bei unserem Standard-Gesundheitsaudit sammeln, und suchen nach ungewöhnlichen Dingen. Das kann vieles sein, oder? Ja! Beginnen wir also mit dem Leerzeichen.
Wow, Platz? Ja, Platz. Keine Sorge, ich komme zu anderen Themen. ☺
Was zu überprüfen ist
Warum sollte ich mit dem Weltraum beginnen? Weil es etwas ist, das ich oft vernachlässigt sehe, und wenn Ihnen der Speicherplatz für Ihre Datenbankdateien ausgeht, werden Sie in Ihren Möglichkeiten in Ihrer Datenbank extrem eingeschränkt. Sie müssen Daten hinzufügen, können die Datei aber nicht vergrößern, weil die Festplatte voll ist? Tut mir leid, jetzt können Benutzer keine Daten hinzufügen. Aus irgendeinem Grund keine Protokollsicherungen erstellen, sodass das Transaktionsprotokoll das Laufwerk füllt? Tut mir leid, jetzt können Sie keine Daten ändern. Platz ist entscheidend. Wir haben Jobs, die den freien Speicherplatz auf der Festplatte und in den Dateien überwachen, aber ich überprüfe dennoch bei jedem Audit Folgendes und vergleiche die Werte mit denen des Vormonats:
- Größe jeder Protokolldatei
- Größe jeder Datendatei
- Freier Speicherplatz in jeder Datendatei
- Freier Speicherplatz auf jedem Laufwerk mit Datenbankdateien
- Freier Speicherplatz auf jedem Laufwerk mit Sicherungsdateien
Wachstum der Protokolldatei
Die meisten Probleme, die ich im Zusammenhang mit dem Speicherplatz sehe, sind auf das Wachstum der Protokolldatei zurückzuführen. Das Wachstum tritt normalerweise aus einem von zwei Gründen auf:
- Die Datenbank befindet sich in der VOLLSTÄNDIGEN Wiederherstellung und es werden aus irgendeinem Grund keine Sicherungen des Transaktionsprotokolls erstellt
- Jemand führt eine einzelne, sehr große Transaktion aus, die den gesamten vorhandenen Protokollspeicherplatz verbraucht und die Datei zum Wachsen zwingt
Ich habe auch gesehen, wie die Protokolldatei im Rahmen der Indexwartung wächst. Bei Neuerstellungen wird jede Zuweisung protokolliert und bei großen Indizes kann dies eine beträchtliche Menge an Protokoll generieren. Selbst bei regelmäßigen Sicherungen des Transaktionsprotokolls kann das Protokoll immer noch schneller wachsen als die Sicherungen erfolgen können. Um das Protokoll zu verwalten, müssen Sie die Sicherungshäufigkeit anpassen oder Ihre Indexverwaltungsmethode ändern.
Sie müssen feststellen, warum die Protokolldatei gewachsen ist, was schwierig sein kann, es sei denn, Sie verfolgen sie. Ich habe einen Job, der stündlich ausgeführt wird, um die Größe und Nutzung der Protokolldatei zu erfassen:
USE [Baselines];
GO
IF (NOT EXISTS (SELECT *
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'dbo'
AND TABLE_NAME = 'SQLskills_TrackLogSpace'))
BEGIN
CREATE TABLE [dbo].[SQLskills_TrackLogSpace](
[DatabaseName] [VARCHAR](250) NULL,
[LogSizeMB] [DECIMAL](38, 0) NULL,
[LogSpaceUsed] [DECIMAL](38, 0) NULL,
[LogStatus] [TINYINT] NULL,
[CaptureDate] [DATETIME2](7) NULL
) ON [PRIMARY];
ALTER TABLE [dbo].[SQLskills_TrackLogSpace] ADD DEFAULT (SYSDATETIME()) FOR [CaptureDate];
END
CREATE TABLE #LogSpace_Temp (
DatabaseName VARCHAR(100),
LogSizeMB DECIMAL(10,2),
LogSpaceUsed DECIMAL(10,2),
LogStatus VARCHAR(1)
);
INSERT INTO #LogSpace_Temp EXEC('dbcc sqlperf(logspace)');
INSERT INTO Baselines.dbo.SQLskills_TrackLogSpace
(DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus)
SELECT DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus
FROM #LogSpace_Temp;
DROP TABLE #LogSpace_Temp; Ich verwende diese Informationen, um festzustellen, wann die Protokolldatei zu wachsen begann, und ich beginne, die Protokolle und den Jobverlauf zu durchsuchen, um zu sehen, welche zusätzlichen Informationen ich finden kann. Das Protokollwachstum sollte statisch sein – das Protokoll sollte eine angemessene Größe haben und durch Sicherungen verwaltet werden (wenn es in der VOLLSTÄNDIGEN Wiederherstellung ausgeführt wird), und wenn die Datei größer werden muss, muss ich verstehen, warum, und die Größe entsprechend ändern.
Wenn Sie mit diesem Problem zu tun haben und Dateiwachstumsereignisse nicht bereits proaktiv nachverfolgt haben, können Sie möglicherweise immer noch herausfinden, was passiert ist. Ereignisse der automatischen Vergrößerung werden von SQL Server erfasst; Aaron Bertrand von SQL Sentry hat darüber bereits 2007 einen Blog geschrieben, in dem er zeigt, wie man herausfinden kann, wann diese Ereignisse aufgetreten sind (solange sie neu genug waren, um noch in der Standardablaufverfolgung vorhanden zu sein).
Größe und freier Speicherplatz in Datendateien
Sie haben wahrscheinlich schon davon gehört, dass Ihre Datendateien eine voreingestellte Größe haben sollten, damit sie nicht automatisch wachsen müssen. Wenn Sie diese Anleitung befolgen, haben Sie wahrscheinlich noch nie das Ereignis erlebt, bei dem die Datendatei unerwartet wächst. Aber wenn Sie Ihre Datendateien nicht verwalten, kommt es wahrscheinlich regelmäßig zu einem Wachstum – ob Sie es bemerken oder nicht (insbesondere mit den Standardwachstumseinstellungen von 10 % und 1 MB).
Es gibt einen Trick, um Datendateien vorab zu dimensionieren – Sie möchten eine Datenbank nicht zu groß dimensionieren, denn denken Sie daran, wenn Sie beispielsweise in einer Entwicklungs- oder QA-Umgebung wiederherstellen, haben die Dateien die gleiche Größe, auch wenn sie re nicht voll von Daten. Aber Sie möchten das Wachstum trotzdem manuell verwalten. Ich finde, dass DBAs die schwierigste Zeit mit neuen Datenbanken haben. Die Geschäftsanwender haben keine Ahnung von Wachstumsraten und wie viele Daten hinzugefügt werden, und diese Datenbank ist in Ihrer Umgebung eine Art lose Kanone. Sie müssen diese Dateien genau beobachten, bis Sie die Größe und das erwartete Wachstum im Griff haben. Ich verwende eine Abfrage, die Informationen über die Größe und den freien Speicherplatz gibt:
SELECT
[file_id] AS [File ID],
[type] AS [File Type],
substring([physical_name],1,1) AS [Drive],
[name] AS [Logical Name],
[physical_name] AS [Physical Name],
CAST([size] as DECIMAL(38,0))/128. AS [File Size MB],
CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128. AS [Space Used MB],
(CAST([size] AS DECIMAL(38,0))/128) - (CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128.) AS [Free Space],
[max_size] AS [Max Size],
[is_percent_growth] AS [Percent Growth Enabled],
[growth] AS [Growth Rate],
SYSDATETIME() AS [Current Date]
FROM sys.database_files; Jeden Monat überprüfe ich die Größe der Datendateien und den verwendeten Speicherplatz und entscheide dann, ob die Größe erhöht werden muss. Ich überwache auch den Standard-Trace auf Wachstumsereignisse, da dies mir genau sagt, wann Wachstum auftritt. Mit Ausnahme neuer Datenbanken kann ich dem automatischen Dateiwachstum immer einen Schritt voraus sein und es manuell handhaben. Okay, fast immer. Kurz vor den Feiertagen im letzten Jahr wurde ich von der IT-Abteilung eines Kunden über wenig freien Speicherplatz auf einem Laufwerk benachrichtigt (halten Sie diesen Gedanken für den nächsten Abschnitt fest). Jetzt basiert die Benachrichtigung auf einem Schwellenwert von weniger als 20 % kostenlos. Dieses Laufwerk hatte über 1 TB, also waren ungefähr 150 GB frei, als ich das Laufwerk überprüfte. Es war noch kein Notfall, aber ich musste verstehen, wo der Platz geblieben war.
Als ich die Datenbankdateien für eine Datenbank überprüfte, konnte ich sehen, dass sie voll waren – und im Vormonat hatte jede Datei über 50 GB frei. Ich habe mich dann mit Tabellengrößen befasst und festgestellt, dass in einer Tabelle in den letzten 16 Tagen über 270 Millionen Zeilen hinzugefügt wurden – insgesamt über 100 GB an Daten. Es stellte sich heraus, dass es eine Codeänderung gegeben hatte und der neue Code mehr Informationen protokollierte als beabsichtigt. Wir haben schnell einen Job eingerichtet, um die Zeilen zu löschen und den freien Speicherplatz in den Dateien wiederherzustellen (und sie haben den Code repariert). Ich konnte jedoch keinen Speicherplatz wiederherstellen – ich müsste die Dateien verkleinern, und das war keine Option. Dann musste ich bestimmen, wie viel Speicherplatz auf der Festplatte übrig war, und entscheiden, ob es eine Menge war, mit der ich zufrieden war oder nicht. Mein Komfortniveau hängt davon ab, wie viele Daten pro Monat hinzugefügt werden – die typische Wachstumsrate. Und ich weiß nur, wie viele Daten hinzugefügt werden, weil ich die Dateinutzung überwache und abschätzen kann, wie viel Speicherplatz für diesen Monat, für dieses Jahr und für die nächsten zwei Jahre benötigt wird.
Speicherplatz
Ich habe bereits erwähnt, dass wir Jobs haben, um den freien Speicherplatz auf der Festplatte zu überwachen. Dabei handelt es sich um einen Prozentsatz, nicht um einen festen Betrag. Meine allgemeine Faustregel war, Benachrichtigungen zu senden, wenn weniger als 10 % der Festplatte frei sind, aber für einige Laufwerke müssen Sie dies möglicherweise höher einstellen. Bei einem 1-TB-Laufwerk beispielsweise werde ich benachrichtigt, wenn weniger als 100 GB frei sind. Bei einem 100-GB-Laufwerk werde ich benachrichtigt, wenn weniger als 10 GB frei sind. Mit einem 20-GB-Laufwerk … nun, Sie sehen, wohin ich damit gehe. Dieser Schwellenwert muss Sie warnen, bevor ein Problem auftritt. Wenn ich auf einem Laufwerk, das eine Protokolldatei hostet, nur 10 GB frei habe, habe ich möglicherweise nicht genug Zeit, um zu reagieren, bevor es als Problem für die Benutzer angezeigt wird – je nachdem, wie oft ich den freien Speicherplatz überprüfe und was das Problem ist ist.
Es ist sehr einfach, xp_fixeddrives zu verwenden, um freien Speicherplatz zu überprüfen, aber ich würde dies nicht empfehlen, da es undokumentiert ist und die Verwendung von erweiterten gespeicherten Prozeduren im Allgemeinen veraltet ist. Es meldet auch nicht die Gesamtgröße jedes Laufwerks und möglicherweise nicht alle Laufwerkstypen, die Ihre Datenbanken verwenden. Solange Sie SQL Server 2008R2 SP1 oder höher ausführen, können Sie das viel bequemere sys.dm_os_volume_stats verwenden, um die benötigten Informationen zu erhalten, zumindest über die Laufwerke, auf denen Datenbankdateien vorhanden sind:
SELECT DISTINCT vs.volume_mount_point AS [Drive], vs.logical_volume_name AS [Drive Name], vs.total_bytes/1024/1024 AS [Drive Size MB], vs.available_bytes/1024/1024 AS [Drive Free Space MB] FROM sys.master_files AS f CROSS APPLY sys.dm_os_volume_stats(f.database_id, f.file_id) AS vs ORDER BY vs.volume_mount_point;
Ich sehe oft ein Problem mit dem Speicherplatz auf Volumes, die tempdb hosten. Ich habe aufgehört zu zählen, wie oft ich Kunden mit unerklärlichem tempdb-Wachstum hatte. Manchmal sind es nur ein paar GB; Zuletzt waren es 200 GB. Tempdb ist ein kniffliges Biest – es gibt keine Formel für die Dimensionierung, und zu oft wird es auf einem Laufwerk mit wenig freiem Speicherplatz abgelegt, das das verrückte Ereignis nicht bewältigen kann, das vom Rookie-Entwickler oder DBA verursacht wird. Die Dimensionierung der tempdb-Datendateien erfordert, dass Sie Ihre Workload für einen „normalen“ Geschäftszyklus ausführen, um festzustellen, wie stark tempdb verwendet wird, und sie dann entsprechend zu dimensionieren.
Ich habe kürzlich einen Vorschlag gehört, wie man vermeiden kann, dass auf einem Laufwerk der Speicherplatz knapp wird:Erstellen Sie eine Datenbank ohne Daten und dimensionieren Sie die Dateien so, dass sie so viel Speicherplatz verbrauchen, wie Sie „reservieren“ möchten. Wenn Sie dann auf ein Problem stoßen, löschen Sie einfach die Datenbank und Viola, Sie haben wieder freien Speicherplatz. Ich persönlich denke, dass dies alle möglichen anderen Probleme verursacht und würde es nicht empfehlen. Aber wenn Sie Speicheradministratoren haben, die es nicht mögen, Hunderte von ungenutzten GB auf einem Laufwerk zu sehen, wäre dies eine Möglichkeit, ein Laufwerk „voll aussehen“ zu lassen. Es erinnert mich an etwas, das ich einen guten Freund von mir sagen hörte:„Wenn ich nicht mit dir arbeiten kann, arbeite ich um dich herum.“
Sicherungen
Eine der Hauptaufgaben eines DBA ist der Schutz der Daten. Backups sind eine Methode, um sie zu schützen, und daher sind die Laufwerke, auf denen diese Backups gespeichert sind, ein wesentlicher Bestandteil des Lebens eines DBA. Vermutlich halten Sie ein oder mehrere Backups online, um sie bei Bedarf sofort wiederherzustellen. Ihr SLA- und DR-Runbook bestimmt, wie viele Backups Sie online aufbewahren, und Sie müssen sicherstellen, dass Sie diesen Speicherplatz zur Verfügung haben. Ich plädiere dafür, dass Sie auch alte Backups nicht löschen, bis das aktuelle Backup erfolgreich abgeschlossen wurde. Es ist viel zu einfach, in die Falle zu tappen, alte Backups zu löschen und dann das aktuelle Backup auszuführen. Aber was passiert, wenn die aktuelle Sicherung fehlschlägt? Und was passiert, wenn Sie die Komprimierung verwenden? Moment mal … komprimierte Backups sind kleiner, oder? Sie sind am Ende kleiner. Aber wussten Sie, dass die Größe der .bak-Datei normalerweise größer beginnt als die Endgröße? Sie können das Ablaufverfolgungsflag 3042 verwenden, um dieses Verhalten zu ändern, aber Sie sollten bedenken, dass Sie bei Sicherungen viel Speicherplatz benötigen. Wenn Ihr Backup 100 GB groß ist und Sie 3 Tage lang online bleiben, benötigen Sie 300 GB für die 3 Tage Backups und dann wahrscheinlich eine gesunde Menge (das Zweifache der aktuellen Datenbankgröße) für das nächste Backup. Ja, das bedeutet, dass Sie auf diesem Laufwerk jederzeit mehr als 100 GB frei haben. Das ist okay. Es ist besser, als wenn der Löschjob erfolgreich ist und der Sicherungsjob fehlschlägt und Sie drei Tage später feststellen, dass Sie überhaupt keine Sicherungen haben (das ist mir bei einem Kunden bei meinem vorherigen Job passiert).
Die meisten Datenbanken werden mit der Zeit einfach größer, was bedeutet, dass auch die Backups größer werden. Vergessen Sie nicht, regelmäßig die Größe der Sicherungsdateien zu überprüfen und bei Bedarf zusätzlichen Speicherplatz zuzuweisen – eine „200 GB frei“-Richtlinie für eine Datenbank, die auf 350 GB angewachsen ist, wird nicht sehr hilfreich sein. Wenn sich die Platzanforderungen ändern, stellen Sie sicher, dass Sie auch alle zugehörigen Warnungen ändern.
Leistungsratgeber verwenden
In diesem Beitrag sind mehrere Abfragen enthalten, die Sie zum Überwachen des Speicherplatzes verwenden können, wenn Sie Ihren eigenen Prozess ausführen müssen. Aber wenn Sie SQL Sentry Performance Advisor in Ihrer Umgebung haben, wird dies mit benutzerdefinierten Bedingungen viel einfacher. Standardmäßig sind mehrere Aktienkonditionen enthalten, aber Sie können auch Ihre eigenen erstellen.
Öffnen Sie im SQL Sentry-Client den Navigator, klicken Sie mit der rechten Maustaste auf Shared Groups (Global) und wählen Sie Benutzerdefinierte Bedingung hinzufügen → SQL Sentry aus. Geben Sie einen Namen und eine Beschreibung für die Bedingung an, fügen Sie dann einen numerischen Vergleich hinzu und ändern Sie den Typ in Repository-Abfrage. Geben Sie die Abfrage ein:
SELECT MIN(FreeSpace*100.0/Size) FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk;
Ändern Sie „Gleich“ in „Ist kleiner als“ und legen Sie einen expliziten Wert von 10 fest. Ändern Sie schließlich die „Standardauswertungshäufigkeit“ auf weniger als alle 10 Sekunden. Einmal am Tag oder einmal alle 12 Stunden ist wahrscheinlich ein guter Wert – Sie sollten den freien Speicherplatz nicht öfter als einmal am Tag überprüfen müssen, aber Sie können ihn so oft überprüfen, wie Sie möchten. Der folgende Screenshot zeigt die endgültige Konfiguration:
Nachdem Sie für die Bedingung auf Speichern geklickt haben, werden Sie gefragt, ob Sie Aktionen für die benutzerdefinierte Bedingung zuweisen möchten. Die Option zum Senden an Alerting-Kanäle ist standardmäßig ausgewählt, aber Sie möchten vielleicht andere Aufgaben ausführen, wie z>
Wie ich bereits erwähnt habe, ist ein Standard von 10 % freiem Speicherplatz für alle Laufwerke wahrscheinlich nicht für jedes Laufwerk in Ihrer Umgebung geeignet. Sie können die Abfrage für verschiedene Instanzen und Laufwerke anpassen, zum Beispiel:
SELECT Alert = MAX(CASE WHEN Name = N'C:' AND [FreeSpace%] < 10 THEN 1 WHEN Name = N'S:' AND [FreeSpace%] < 25 THEN 1 WHEN Name = N'T:' AND [FreeSpace%] < 20 THEN 1 ELSE 0 END) FROM ( SELECT d.Name, d.FreeSpace * 100.0/d.Size AS [FreeSpace%] FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk AS d INNER JOIN SQLSentry.dbo.EventSourceConnection AS c ON d.DeviceID = c.DeviceID WHERE c.ObjectName = N'HANK\SQL2012' -- replace with your server/instance ) AS s;
Sie können diese Abfrage nach Bedarf für Ihre Umgebung ändern und erweitern und dann den Vergleich in der Bedingung entsprechend ändern (grundsätzlich als wahr auswerten, wenn das Ergebnis immer 1 ist):
Wenn Sie Performance Advisor in Aktion sehen möchten, können Sie gerne eine Testversion herunterladen.
Beachten Sie, dass Sie für diese beiden Bedingungen nur einmal benachrichtigt werden, selbst wenn mehrere Laufwerke unter Ihren Schwellenwert fallen. In komplexen Umgebungen sollten Sie eher auf eine größere Anzahl spezifischerer Bedingungen setzen, um flexiblere und individuellere Warnmeldungen zu bieten, als auf weniger „allgemeine“ Bedingungen.
Zusammenfassung
In einer SQL Server-Umgebung gibt es viele kritische Komponenten, und der Speicherplatz muss proaktiv überwacht und verwaltet werden. Mit nur ein wenig Planung ist dies einfach zu bewerkstelligen und lindert viele Unbekannte und reaktive Problemlösungen. Unabhängig davon, ob Sie Ihre eigenen Skripte oder ein Tool eines Drittanbieters verwenden, stellen Sie sicher, dass genügend freier Speicherplatz für Datenbankdateien und Sicherungen vorhanden ist, ein Problem, das leicht lösbar ist und sich lohnt.
