SQL-Server Umgebung
Über den Task Manager Arbeitsspeicher-Auslastung prüfen. Diese sollte unter 90% liegen. Ab 94% ist es besonders kritisch.
Durch den Explorer die Festplatten prüfen. Keine darf voll sein.
SQL-Server Konfiguration (benötigt SSMS)
Um die Konfiguration des SQL-Servers zu öffnen, wird beim Objekt-Explorer ein Rechtsklick auf den SQL-Server gemacht und die Einstellungen geöffnet.
Tab „Memory“ Wert bei „Maximum server memory (in MB)” prüfen.Der Wert sollte kleiner sein als maximaler Arbeitsspeicher des SQL-Servers.
Wenn z.B. der Server 30 GB hat. Sollte hier um die 20 GB stehen.
Tab „Advanced“ Wert „Cost Threshold for Parallelism” prüfen. Standardwert: 5
Tab “Advanced” Wert “Max Degree of Parallelism” prüfen. Standardwert: 0
* Diese Einstellung gibt an, wie viele CPU’s maximal für eine SQL-Operation verwendet werden dürfenBei vielen gleichzeitigen Zugriffen auf den SQL-Server, könnte hier ein anderer Wert wie zum Beispiel 2 oder 4 getestet werden.
Datenbankkonfiguration
Um die Einstellungen einer Datenbankkonfiguration zu prüfen, rechtsklick auf die Datenbank und Einstellungen öffnen.
Tab „Files“ den „Autogrowth / Maxsize“ Wert prüfen. (Daten und Log Datei).Dieser sollte immer eine fixe Größe haben (kein In Percent verwenden).
Die fixe Größe sollte mindestens 1000 MB sein.
Tab „Files“ den Wert „Size (MB)“ für die Log Datei prüfen.Sollte diese viel zu groß sein (z.B. > 50 GB), deutet es drauf hin dass etwas mit dem Wartungsplan nicht stimmen könnte.
Tab „Options“ den Wert bei „Recovery model“ prüfen.Wenn „Full“ eingestellt, wird empfohlen einen guten Wartungsplan zu haben, sonst Gefahr, dass die LOG Datei von der Größe her eskalieren könnte.
Wenn „Simple“ eingestellt, wird der Speicher in der LOG Datei automatisch freigegeben, sobald die Transaktion beendet wird.
Tab „Options“ den Wert bei „Compatibility level“ prüfen. Dieser sollte der installierten SQL-Server Version entsprechen.
Tab „Options“ folgende Werte sollten eingestellt sein:Auto Create Statistics : True
Auto Shrink : False
Auto Update Statistics : True
Wartungsplan
Selbst wenn die Datenbanksicherungen durch andere Tools gemacht werden (zum Beispiel VEEAM), wird trotzdem empfohlen mindestens einen Wartungsplan zu besitzen (der sich um die Datenbankpflege kümmert).
Wir können die Hauptaufgaben der Wartungspläne in 3 Teile spalten:
Vollständige Datenbanksicherung
Transaktionsprotokoll Sicherungen (wird nur bei Recovery Mode = Full benötigt)
Pflege der Datenbanken
Prüfen ob Wartungspläne vorhanden sind
Prüfen ob der SQL Server Agent aktiv ist (dieser führt die Wartungspläne aus)
Die Konfiguration der Wartungspläne prüfen
Sicherstellen, dass keine „Shrink Database Task“ Bausteine vorhanden sind!Bei einer richtig eingestellten DB nicht notwendig.
Shrink-Jobs führen nur zur unnötigen Fragmentierung der DB.
Beispielwartungsplan für Datenpflege
Bei der Datenpflege sind vor allem die beiden Bausteine „Rebuild Index Task“ und „Update Statistics Task“ wichtig. Der Task „Reorganize Index Task“ wird nicht benötigt, weil Rebuild sich bereits um alles kümmert.
Beispielwartungsplan für Datenbanksicherung
An erster Stelle sollte „Check Database Integrity Task“ stehen! Dieser stellt sicher, dass keine Fehler in der Datenbank vorhanden sind.
Beim „Back Up Database Task” sollte “Verify backup integrity” aktiviert warden, damit sichergestellt wird dass keine Fehler in der Backup Datei sind.
Beispielwartungsplan für Transaktionslog Backup
Wenn der Recover-Mode auf „Full“ steht, wird empfohlen einen extra Job für regelmäßige Transaktionsprotokoll Backups zu erstellen. In dem Beispiel wird jede Stunde ein Backup erstellt.
Beispiel für vollständigen Wartungsplan (Recover-Mode Simple)
Check Database Integrity Task : Stellt sicher dass keine Fehler in der Datenbank vorhanden sind.
Back Up Database Task : Erstellt das vollständige Backup.
Rebuild Index Task : Baut die Indexe neu auf.
Update Statistics Task : Aktualisiert die Index-Statistiken.
Maintenance Cleanup Task : Löscht ältere Backup Dateien (beim Beispiel älter als 1 Woche).
Maintenance Cleanup Task 1 : Löcht ältere Wartungsplan Text Berichte.
History Cleanup Task : Löscht ältere Historie Einträge.
Dieser Wartungsplan funktioniert gut wenn der Datenbank Recover-Mode auf Simple steht. Wenn der Modus auf „Full“ wäre, könnte ein Tag zwischen den vollständigen Backups zu lang sein, was zu einer sehr großen LOG-Datei führen könnte.
WICHTIG: Wenn Recovery-Mode auf „Simple“ steht, führt ein Backup des Transaktionslogs zu einem Fehler.
Erweiterte Prüfungen
Um die Gesundheit der Datenbank zu prüfen, können detaillierte Prüfungen mit SQL-Statements gemacht werden.
Fragmentierung der Indexe
SELECT S.name as ‘Schema’,
T.name as ‘Table’,
I.name as ‘Index’,
DDIPS.avg_fragmentation_in_percent,
DDIPS.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS DDIPS
INNER JOIN sys.tables T on T.object_id = DDIPS.object_id
INNER JOIN sys.schemas S on T.schema_id = S.schema_id
INNER JOIN sys.indexes I ON I.object_id = DDIPS.object_id
AND DDIPS.index_id = I.index_id
WHERE DDIPS.database_id = DB_ID()
and I.name is not null
AND DDIPS.avg_fragmentation_in_percent > 0
AND DDIPS.page_count > 1000
ORDER BY DDIPS.avg_fragmentation_in_percent desc
Sollten hier mehrere / viele Tabellen eine Fragmentierung > 30% haben, deutet es drauf hin, dass kein Wartungsplan vorhanden ist.
Index-Statistiken
SELECT sp.stats_id,
stat.name,
filter_definition,
last_updated,
rows,
rows_sampled,
steps,
unfiltered_rows,
modification_counter
FROM sys.stats AS stat
CROSS APPLY sys.dm_db_stats_properties(stat.object_id, stat.stats_id) AS sp
INNER JOIN sys.tables t ON t.object_id = stat.object_id
WHERE t.type = ‘U’
AND last_updated IS NOT NULL
ORDER BY last_updated
Hier sollten keine Tabellen mit einem älteren last_updated Wert vorhanden sein. Ansonsten deutet es darauf hin, dass entweder kein Wartungsplan vorhanden ist. Oder der vorhandene nicht läuft, bzw. kein Job für Statistik Updates vorhanden ist.
[1] SSMS = Microsoft SQL-Server Management Studio