SQL-Server prüfen

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ürfen

    • Bei 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:

  1. Vollständige Datenbanksicherung
  2. Transaktionsprotokoll Sicherungen (wird nur bei Recovery Mode = Full benötigt)
  3. 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) #

 

 

  1. Check Database Integrity Task : Stellt sicher dass keine Fehler in der Datenbank vorhanden sind.
  2. Back Up Database Task : Erstellt das vollständige Backup.
  3. Rebuild Index Task : Baut die Indexe neu auf.
  4. Update Statistics Task : Aktualisiert die Index-Statistiken.
  5. Maintenance Cleanup Task : Löscht ältere Backup Dateien (beim Beispiel älter als 1 Woche).
  6. Maintenance Cleanup Task 1 : Löcht ältere Wartungsplan Text Berichte.
  7. 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

High Quality Theme

There is a fine line between creating greatness and accomplishing awesomeness. This time, we worked to prove that sky is not the limit.

Fill out the form to subscribe to our newsletter.

[contact-form-7 404 "Nicht gefunden"]

High Quality Theme

There is a fine line between creating greatness and accomplishing awesomeness. This time, we worked to prove that sky is not the limit.

Fill out the form to subscribe to our newsletter.

[contact-form-7 404 "Nicht gefunden"]