1. Konfiguration SQL-Server

a) SQL-Server-Version

Gemäß den bewährten Verfahren wird empfohlen, die SQL Server-Instanz mit den neuesten kumulativen Updates auf dem neuesten Stand zu halten. Kumulative Updates enthalten sowohl neue Funktionalitäten als auch Sicherheitsbehebungen für die Datenbank-Engine. Der Mainstream-Support für SQL Server 2022 läuft bis zum 11. Januar 2028, während der erweiterte Support bis zum 11. Januar 2033 läuft.

b) Laufwerke

Nach bewährten Verfahren sollten für die Protokolldateien der Benutzerdatenbanken, die tempdb-Systemdatenbank und die Datendateien der Benutzerdatenbanken separate Laufwerke vorhanden sein. Diese Konfiguration minimiert das Risiko eines gleichzeitigen Festplattenzugriffs und verbessert die E/A-Leistung.

c) SQL Server-Dienstkonten

Die SQL Server-Engine und der Agentendienst werden mit Standardkonten gestartet. Gemäß den bewährten Verfahren sollte jeder dieser Dienste über ein eigenes Domänenkonto verfügen.

d) SQL Server-Dienste - Startmodus

Gemäß den Best Practices sollte für alle SQL Server-Dienste der Startmodus auf Automatisch konfiguriert werden, um einen automatischen Start der Datenbankdienste nach einem ungeplanten Neustart des Betriebssystems zu gewährleisten.

e) Konfiguration der SQL Server-Instanz - RAM-Speicher

Dem Server sind z.B. 64 GB RAM zugewiesen, während auf der SQL Server-Instanz die Werte in der Option Minimaler Serverspeicher auf 0 MB und in der Option Maximaler Serverspeicher auf 2147483647 MB eingestellt sind; dies sind die Standardwerte. Gemäß den bewährten Verfahren sollte die Option Minimaler Serverspeicher auf 0 MB und die Option Maximaler Serverspeicher auf 59392 MB gesetzt werden, so dass 6 GB für das Betriebssystem übrig bleiben. In der Standard-Edition können einer SQL Server-Instanz maximal 128 GB zugewiesen werden.

f) Konfiguration der SQL Server-Instanz - TempDB-Datenbank

Die TempDB-Datenbank verfügt über 2 Datendateien mit einer Größe von jeweils 8 MB, wobei die
automatische Erweiterung auf 64 MB konfiguriert ist. Für beste Leistung empfehlen wir:

Hinzufügen von 6 Datendateien zur tempdb-Datenbank.
Erweiterung der Größe jeder tempdb-Datenbankdatei auf 1024 MB.
Erweiterung der Größe der tempdb-Protokolldatei auf 3072 MB.
Ändern Sie das automatische Wachstum jeder tempdb-Datendatei und Logdatei von 64 MB auf 512 MB.

Durch diese Änderungen wird der verfügbare Speicherplatz auf Laufwerk C um 11240 MB verringert.
Nach bewährten Verfahren sollten tempdb-Datendateien nach der folgenden Regel konfiguriert werden: Für jeden CPU-Kern sollte es eine tempdb-Datendatei geben, höchstens jedoch 8. Mehr tempdb-Datendateien, auch unter Berücksichtigung der Anzahl der CPU-Kerne, sollten sorgfältig in einer Bühnenumgebung getestet werden. Eine angemessene Anzahl von tempdb-Datendateien verringert die Zuweisungskonflikte.

g) Konfiguration der SQL Server-Instanz - Komprimierung der Sicherung

Derzeit ist die Backup-Komprimierung auf der SQL Server-Instanz deaktiviert. Wenn diese Option auf der Seite der Drittanbieterlösung konfiguriert ist, ist keine Änderung erforderlich. Andernfalls empfehlen wir, sie zu aktivieren.

Vorteile der Aktivierung der Backup-Komprimierung:

Durch die Komprimierung wird der für die Speicherung von Sicherungskopien benötigte Speicherplatz erheblich reduziert.
Kleinere Sicherungsgrößen reduzieren die Netzwerkbelastung bei der Übertragung an entfernte Standorte.

Nachteile der Aktivierung der Backup-Komprimierung:

Der Komprimierungsprozess stellt eine zusätzliche Belastung für die CPU dar, verursacht aber in der Regel nur einen geringen Anstieg der CPU-Auslastung.

Bevor Sie die Backup-Komprimierung aktivieren, empfehlen wir Ihnen, diese Änderung in einer Testumgebung zu testen.

h) SQL Server-Instanzkonfiguration - Optimieren für AdHoc-Arbeitsbelastungen

Diese Funktion von SQL Server ermöglicht eine bessere Verwaltung des Ausführungsplan-Cache-Speichers. Wir empfehlen, diese Option auf True zu setzen.

i) SQL Server-Instanzkonfiguration - Kostenschwellenwert für Parallelität

Dieser Parameter der SQL Server-Instanz bestimmt, wann eine einzelne Abfrage parallel ausgeführt werden soll.
Der Wert 5 ist der Standardwert für diesen Parameter und ist für Produktionsarbeitslasten zu klein. Mit dem aktuellen Wert wird der SQL Server-Optimierer die Parallelität ineffizient nutzen. Wir empfehlen, diese Option auf 50 zu setzen.

j) SQL Server-Instanzkonfiguration - Maximaler Grad an Parallelität

Dieser Parameter der SQL Server-Instanz bestimmt die maximale Anzahl der Prozessorkerne, die für die
Ausführung einer einzelnen Abfrage verwendet werden können. Nach bewährten Verfahren sollte der maximale Parallelitätsgrad nach folgender Regel konfiguriert werden: Der Wert für den maximalen Parallelitätsgrad sollte mit der Anzahl der Prozessorkerne übereinstimmen, bis zu 8. Ein höherer Wert für den maximalen Parallelitätsgrad, bei dem auch die Anzahl der CPU-Kerne berücksichtigt wird, sollte sorgfältig in einer Bühnenumgebung getestet werden. Mit dem aktuellen Wert ist SQL Server nicht in
der Lage, sein Leistungspotenzial zu nutzen. Wir empfehlen, diese Option auf 8 zu setzen.

k) Konfiguration der SQL Server-Instanz - sa-Konto

Derzeit ist das "sa"-Konto auf der SQL Server-Instanz aktiviert, was ein potenzielles Sicherheitsrisiko darstellt. Das "sa"-Konto ist das Standard-Administratorkonto in SQL Server, das über die höchsten Berechtigungen zur Verwaltung des Servers und aller Datenbanken verfügt. Wenn es aktiv bleibt, kann dies zu unberechtigtem Zugriff führen, insbesondere wenn das Passwort schwach ist oder seit der Installation des Servers nicht geändert wurde.
Aus diesen Gründen empfehlen wir, es zu deaktivieren.
Bevor Sie ein Konto deaktivieren, sollten Sie überprüfen, ob potenzielle Benutzerprozesse das betreffende Konto nicht verwenden.

l) Konfiguration der SQL Server-Instanz - Wiederherstellungsmodell

Derzeit ist das Wiederherstellungsmodell für Benutzerdatenbanken (One200_2025 und One200_Customer) auf Voll, was ein empfohlener Wert ist.

Das Wiederherstellungsmodell ist eine Einstellung, die bestimmt, wie SQL Server das Transaktionsprotokoll verwaltet und welche Möglichkeiten der Datenbankwiederherstellung es gibt.
Das einfache Modell minimiert die Anzahl der gespeicherten Transaktionsprotokolle, was den Aufwand für die Protokollverwaltung verringert (es ist keine Sicherung erforderlich, da die Datei nach Abschluss der Transaktion bereinigt wird), aber auch die Möglichkeiten der Datenwiederherstellung einschränkt.
Im Full-Modell werden alle Transaktionen vollständig protokolliert, so dass Sie die Datenbank zu einem bestimmten Zeitpunkt wiederherstellen können. Dies ist besonders wichtig für Produktionsdatenbanken, bei denen die Minimierung des Risikos von Datenverlusten entscheidend ist. Im Falle eines Ausfalls können Sie Ihre Daten mit größerer Präzision wiederherstellen.
Es gibt auch ein Bulk-Logged-Wiederherstellungsmodell, das die Massenprotokollierung minimiert und die Leistung verbessert. Dieses Modell ist jedoch nicht für Produktionsumgebungen geeignet, da die Punkt-zu-Zeit-Wiederherstellung in diesem Wiederherstellungsmodell nur unter bestimmten Umständen funktioniert.

m) Konfiguration der SQL Server-Instanz - Kompatibilitätsebene

Die Kompatibilitätsebene ist eine Option in SQL Server, die bestimmt, welche Funktionen der Datenbank-Engine für eine bestimmte Datenbank verfügbar sind. Derzeit ist die Kompatibilitätsebene für Benutzerdatenbanken auf den empfohlenen Wert 160 eingestellt.

n) SQL Server-Instanzkonfiguration - Statistiken automatisch aktualisieren

Wenn diese Option aktiviert ist, aktualisiert SQL Server automatisch die Spalten- und Indexstatistiken, wenn sich genügend Zeilen in einer Tabelle geändert haben. Mit aktuellen Statistiken erstellt der SQL Server-Optimierer genaue Ausführungspläne. Die Option ist auf Benutzerdatenbanken auf True gesetzt, was ein empfohlener Wert ist.

o) SQL Server-Instanzkonfiguration - Automatische Erstellung von Statistiken

Wenn diese Option aktiviert ist, erstellt SQL Server automatisch Statistiken für die in Abfragen verwendeten Spalten, wenn dies erforderlich ist. Die Option ist bei Benutzerdatenbanken auf True gesetzt, was der empfohlene Wert ist.

2. Aktueller Stand von Windows Server

2.1 Aktuelle Konfiguration von Windows Server

a) Konfiguration von Festplattenlaufwerken

Es gibt nur eine Festplatte im Betriebssystem. Wie bereits erwähnt, sollten für die Datendateien der
Benutzerdatenbank, die tempdb-Datenbank und die Protokolldateien der Benutzerdatenbank separate Festplatten vorhanden sein. Die Zuweisungseinheit dieser Festplatten sollte auf 64 KB eingestellt sein. Dies kann durch einen Blick auf "Bytes pro Cluster" überprüft werden. Auf der Festplatte C ist die Zuweisungseinheit auf 4 KB eingestellt.
Dies ist der Standardwert, der für die Festplatte, auf der das Betriebssystem gespeichert ist, nicht geändert werden sollte.

Abgesehen von der Zuweisungseinheit sollte gemäß den Best Practices auch die Dateiindizierung auf Festplatten deaktiviert werden, auf denen die tempdb-Datenbank, die Benutzerdatenbank-Datenfiles und die Benutzerdatenbank-Protokolldateien gespeichert sind. Diese Option ist in den Festplatteneigenschaften verfügbar.

b) Administratorrechte für Dienstkonten

Das Fehlen vollständiger administrativer Rechte (lokaler Administrator) für die Konten der SQL-Engine und des SQL-Agenten ist eine empfohlene Sicherheitspraxis, die das Risiko übermäßiger Privilegien verringert. Diese Konten sollten nur den notwendigen Zugriff auf Dateien und Festplatten haben, um das ordnungsgemäße Funktionieren der Dienste zu ermöglichen.

c) Richtlinie zur Durchführung von Volume Maintenance-Aufgaben

Die Einstellung "Perform Volume Maintenance Tasks" (SeManageVolumePrivilege) ermöglicht die so genannte Instant File Initialization, die den Zeitaufwand für die Erstellung und Erweiterung von Datenbankdateien reduziert.
Dies macht Festplattenoperationen schneller und effizienter. Wir empfehlen, das SQL Server-Dienstkonto zu dieser Richtlinie hinzuzufügen.

d) Richtlinie zum Sperren von Seiten im Speicher

Die Gewährung des Privilegs "Seiten im Speicher sperren" (SeLockMemoryPrivilege) für das SQL Server-
Dienstkonto ermöglicht es, den zugewiesenen physischen Speicher im RAM zu halten, wodurch das Risiko des Auslagerns von Seiten auf die Festplatte verringert wird. Dies trägt zur Aufrechterhaltung einer stabilen Instanzleistung bei, insbesondere in speicherintensiven Umgebungen. Wir empfehlen, das SQL Server-Dienstkonto zu dieser Richtlinie hinzuzufügen.

e) Netzwerkprotokolle

Die Option "Named Pipes" für SQL Server ist derzeit deaktiviert. Wir empfehlen Ihnen, diese Option zu aktivieren, um ein zusätzliches Netzwerkkommunikationsprotokoll zu aktivieren, das die Verbindungsflexibilität und die Kompatibilität mit verschiedenen Clientanwendungen verbessern kann. Die Aktivierung dieses Protokolls erfordert einen Neustart von SQL Server.

f) Energieplan

Derzeit ist der Energiesparplan auf Hochleistung eingestellt, was in Datenbankumgebungen der empfohlene Wert ist. Diese Konfiguration stellt sicher, dass die CPU-Leistung auf einem konstanten Niveau gehalten wird und minimiert das Risiko von Latenzzeiten aufgrund einer dynamischen Skalierung der CPU-Frequenz.

3. Aufträge zur Datenbankpflege

3.1 Wartungsarbeiten an der Datenbank

Auf der analysierten SQL Server-Instanz wurde keine Lösung verwendet, um:

Indizes neu aufbauen / reorganisieren
Datenbankstatistiken aktualisieren
Überprüfung der Konsistenz der Datenbankstrukturen
Datenbanken sichern

Wir empfehlen die Implementierung von Ola Hallengren Maintenance Jobs - SQL Server Maintenance Solution Downloads

Alle gespeicherten Prozeduren, die für Wartungsaktivitäten verantwortlich sind, sollten in der Master-Datenbank zusammen mit der Tabelle dbo.CommandLog implementiert werden.
In den folgenden Abschnitten werden empfohlene Vorgehensweisen beschrieben.

3.2 Index neu aufbauen/reorganisieren

Zunächst wurde die Fragmentierung der Indizes überprüft. Die folgende Abbildung zeigt die Fragmentierung der Top-Indizes nach Seitenzahl in der Datenbank One200_Customer. In der Datenbank One200_2025 wurden keine Indizes gefunden. Wenn Indizes stark fragmentiert sind, benötigen sie zusätzlichen Speicherplatz in der Datenbank und beeinträchtigen die Leistung von Abfragen.

Um sie zu optimieren, empfehlen wir folgende Vorgehensweise:

EXECUTE dbo.IndexOptimize @Databases=
'USER_DATABASES', @FragmentationLow
= NULL,
@FragmentationMedium ='INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationLevel1 = 10,
@FragmentationLevel2= 30, @LogToTable
= 'Y'

Dieser Job baut den Index neu auf, wenn die Fragmentierung mehr als 10 Prozent und weniger als 30 Prozent beträgt. Wenn die Fragmentierung des Index über 30 Prozent liegt, wird der Index neu erstellt. Dieser Auftrag gilt für alle Benutzerdatenbanken auf der SQL Server-Instanz. Außerdem werden alle an Indizes vorgenommenen Änderungen in der Tabelle dbo.CommandLog in der Master-Datenbank aufgezeichnet. Es wird empfohlen, diesen Auftrag einmal pro Woche auszuführen.

3.3 Aktualisierung der Datenbankstatistiken

Die Statistiken wurden für die Datenbanken One200_2025 und One200_Customer überprüft. Die Bilder unten zeigen die 30 größten Statistiken für jede Benutzerdatenbank. Die Spalten Rows und Rows_sampled zeigen, ob die Datenbankstatistiken aktuell sind. Wenn die Zahl in der Rows_sampled-Spalte nicht mindestens 20 % der Zahl in der Rows-Spalte ausmacht, bedeutet dies, dass diese Statistiken nicht mehr aktuell sind. Die Datenbankstatistiken werden vom SQL Server-Optimierer verwendet, um die bestmöglichen Ausführungspläne für Abfragen zu erstellen.

Um sie zu optimieren, empfehlen wir folgende Vorgehensweise:

EXECUTE dbo.IndexOptimize @Databases=
'USER_DATABASES', @FragmentationLow
= NULL, @FragmentationMedium = NULL,
@FragmentationHigh = NULL,
@UpdateStatistics = 'ALL'

Mit diesem Auftrag werden alle möglichen Statistiken in einer Datenbank mit einer Stichprobe von 20 % aktualisiert.
Er gilt für alle Benutzerdatenbanken auf der SQL Server-Instanz und es wird empfohlen, diesen Auftrag einmal pro Woche zu verwenden.

3.4 Konsistenzprüfung der Datenbank

Der Verlauf der Datenbankkonsistenzprüfungen wurde sowohl für die Systemdatenbanken als auch für die
Benutzerdatenbanken überprüft. Diese Aufgabe ist wichtig, um sicherzustellen, dass die in Datenbanken
gespeicherten Daten nicht beschädigt werden. SQL Server sucht nach Fehlern sowohl auf physischer als auch auf logischer Ebene. Abbildung 29 zeigt die Tabelle dbo.suspect_pages, die in der Systemdatenbank msdb gespeichert ist. Wenn diese Tabelle leer ist, bedeutet dies, dass SQL Server keine beschädigten Datenseiten gefunden hat, was ein sehr gutes Zeichen ist.

In dieser Situation empfehlen wir die folgende Vorgehensweise:

a) SQL Agent-Auftrag zur Überprüfung von Benutzerdatenbanken.

Er durchsucht alle Benutzerdatenbanken und schreibt die Ausgabe in die Tabelle dbo.CommandLog, die in der Master-Datenbank gespeichert ist. Es wird empfohlen, diesen Auftrag mindestens einmal pro Woche auszuführen.

EXECUTE dbo.DatabaseIntegrityCheck
@Databases= 'USER_DATABASES',
@CheckCommands= 'CHECKDB',
@LogToTable = 'Y'

b) SQL Agent-Auftrag zur Überprüfung der Systemdatenbanken.

Er durchsucht alle Systemdatenbanken und schreibt die Ausgabe in die Tabelle dbo.CommandLog, die in der Master-Datenbank gespeichert ist. Es wird empfohlen, diesen Auftrag täglich zu verwenden, da die SQL Server-Systemdatenbanken nur eine geringe Größe haben und keine zusätzliche Belastung für die Produktionssysteme darstellen.

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'SYSTEM_DATABASES',
@CheckCommands= 'CHECKDB',
@LogToTable = 'Y'

3.5 Datenbank-Backups

Die Historie der Datenbanksicherungen wurde sowohl für die Systemdatenbanken als auch für die
Benutzerdatenbanken überprüft. Es ist von entscheidender Bedeutung, dass im Falle von Datenbankausfällen (Hardware-/Softwarefehlfunktionen oder menschliches Versagen) die Möglichkeit besteht, die Datenbank wiederherzustellen.

In dieser Situation empfehlen wir die folgende Vorgehensweise:

a) SQL Agent-Aufträge für die Sicherung von Benutzerdatenbanken.

Diese Aufträge erstellen Datenbanksicherungen und schreiben die Ausgabe in die Tabelle dbo.CommandLog, die in der Master-Datenbank gespeichert ist. Es wird empfohlen, den folgenden Zeitplan für Datenbanksicherungen für Benutzerdatenbanken zu verwenden:

Vollständige Datenbanksicherung - Einmal pro Woche.
Differenzielle Datenbanksicherung - Jeden Tag außer dem Tag, an dem die Vollsicherung durchgeführt wird.
Sicherung des Transaktionsprotokolls - Alle 30 Minuten.

Auftrag des SQL-Agenten zur vollständigen Sicherung der Datenbank:

EXECUTE dbo.DatabaseBackup
@Databases= 'USER_DATABASES',
@Directory = 'Disk_Path', @BackupType =
'FULL',
@Verify = 'Y', @Compress =
'Y', @CleanupTime= 192,
@LogToTable = 'Y'

Dieser Auftrag des SQL-Agenten erstellt eine komprimierte VOLLSTÄNDIGE Datenbanksicherung auf dem
angegebenen Festplattenpfad und überprüft außerdem die Integrität der Datenbanksicherung. Alte Backups werden nach 192 Stunden gelöscht. Der SQL-Agent schreibt auch die Ausgabe in die Tabelle dbo.CommandLog, die in der Master-Datenbank gespeichert ist.

SQL Agent-Auftrag für die differentielle Datenbanksicherung:

EXECUTE dbo.DatabaseBackup
@Databases= 'USER_DATABASES',
@Directory = 'Disk_Path', @BackupType =
'DIFF',
@Verify = 'Y', @Compress =
'Y', @CleanupTime= 192,
@LogToTable = 'Y'

Dieser Auftrag des SQL-Agenten erstellt eine komprimierte differentielle Datenbanksicherung auf dem angegebenen Festplattenpfad und überprüft die Integrität der Datenbanksicherung. Die alten Sicherungen werden nach 192 Stunden gelöscht. Der SQL-Agent schreibt auch die Ausgabe in die Tabelle dbo.CommandLog, die in der Master-Datenbank gespeichert ist.

SQL Agent-Auftrag für Transaktionsprotokoll-Backups:

EXECUTE dbo.DatabaseBackup
@Databases= 'USER_DATABASES',
@Directory = 'Disk_Path', @BackupType =
'LOG',
@Verify = 'Y', @Compress =
'Y', @CleanupTime= 192,
@LogToTable = 'Y'

Dieser Auftrag des SQL-Agenten erstellt ein komprimiertes Transaktionsprotokoll-Backup auf dem angegebenen Festplattenpfad und prüft außerdem die Integrität des Transaktionsprotokoll-Backups. Alte
Transaktionsprotokollsicherungen werden nach 192 Stunden gelöscht. Der SQL-Agent schreibt auch die Ausgabe in die Tabelle dbo.CommandLog, die in der Master-Datenbank gespeichert ist.

b) Auftrag des SQL-Agenten für die Sicherung der Systemdatenbanken.

EXECUTE dbo.DatabaseBackup
@Databases = 'SYSTEM_DATABASES',
@Directory = 'Disk_Path', @BackupType =
'FULL',
@Verify = 'Y', @Compress =
'Y', @CleanupTime= 192,
@LogToTable = 'Y'

Dieser Auftrag des SQL-Agenten erstellt eine komprimierte vollständige Datenbanksicherung der Systemdatenbanken auf dem angegebenen Festplattenpfad und überprüft die Integrität der Datenbanksicherung. Alte Backups werden nach 192 Stunden gelöscht. Der SQL-Agent schreibt auch die Ausgabe in die Tabelle dbo.CommandLog, die in der Master-Datenbank gespeichert ist. Es wird empfohlen, diesen Auftrag täglich zu verwenden.