SQL-Server Umgebung

SQL-Server Umgebung

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:
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
    • Related Articles

    • SQL Server - Datenbankordner verkleinern, Logging anpassen und Server optimieren

      1. Transaktionsprotokoll verkleinern Es gibt 2 Dateien. MDF: Datenbank LDF: Transaktionsprotokoll Meist ist die LDF-Datei deutlich größer.  Diese kann wie folgt verkleinert werden: 2. Log Model anpassen Anschließend kann man das Log-Modell umstellen ...
    • 1. Installation Datenbank

      SQL Management Studio öffnen Einen SQL Benutzer (alternativ einen Active Directory Benutzer) anlegen. Hinweis: Wenn man einen SQL Benutzer anlegt, muss auf die Mix-Authentifizierung aktivieren Import der Datenbank:   Rechtsklick auf "Datenbank" und ...
    • Package Share auf einem Windows Server / Ort für eigene Softwarepakete

      Der Ort muss kein IIS sein. Es reicht auch ein FTP oder Apache-Server. Wichtig ist nur, dass der Speicherort von extern per Webrequest erreichbar ist. Voraussetzung:  Der Pfad zu dem Ort wo die Pakete abgelegt werden, ist in den Einstellungen ...
    • Voraussetzungen für die Installation

      Voraussetzungen: Windows Server Mind: 2 vCPU 16 GB, .Net 5.0, mindestens SQL Server 2016 Sizing Empfehlung: Bei 1.600 Geräten: 8 vCPU, 32 GB RAM mit SQL Umgeleitete Domain/Subdomain wie bspw. RMM.Systemhaus.de Gültiges SSL-Zertifikat Microsoft SQL ...
    • Supremo Fernwartung - Meldung Passwort ist leer

      Wenn diese Meldung nach bereits erfolgten Fernwartungen erscheint kann man das Problem wie folgt beheben. 1. Prüfen ob das Gastmodul beim Client auf automatische Updates eingestellt ist. Dies sollte standardmäßig der Fall sein. 2. auf dem SQL-Server ...