Windows unter dem Datenbankserver

TL;DR — Auf Windows entscheidet weniger die Datei mit den Einstellungen als die Frage, was das Dienstkonto darf, was der Virenschutz anfasst und ob die Firmware dem Betriebssystem die Kontrolle über den Takt überhaupt überlässt. Drei der meistgegebenen Ratschläge — TCP Chimney abschalten, alles auf 64 KB formatieren, den Energieplan auf Höchstleistung stellen — sind heute gegenstandslos, nur für eine Datenbank begründet oder deutlich enger als früher. Und was oft übersehen wird: ein Teil der Einstellungen bedeutet für SQL Server und PostgreSQL etwas Verschiedenes — dasselbe Windows-Recht dient hier dem Auslagerungsschutz und dort den großen Speicherseiten. Dieser Artikel trennt das Wirksame vom Weitergereichten, sagt zu jeder Einstellung, für welches System sie gilt, und nennt den Befehl, mit dem du den Ist-Zustand abliest.

Stand: August 2026 — geprüft gegen die Microsoft-Dokumentation zu Energie- und Leistungsoptimierung, SQL Server 2022/2025 und die PostgreSQL-Dokumentation in der Fassung 18. Herstellervorgaben ändern sich; lies vor jedem Setzen den Ist-Wert.

Vorab. Alle Werte hier sind Ausgangspunkte, keine Vorgaben. Was zu deinem Server passt, hängt von Arbeitslast, Speicherausstattung und Datenträger ab. Einige Eingriffe betreffen Dienstrechte und den Virenschutz und damit die Sicherheit deiner Anlage — probiere sie zuerst auf einem Testsystem und nur mit einer aktuellen, wiederherstellbar geprüften Sicherung. Ändere eine Sache pro Schritt, miss davor und danach, und sorge dafür, dass du jeden Eingriff zurücknehmen kannst. Für den Betrieb deiner Systeme bist du verantwortlich.

Prüfen kommt vor Setzen. Windows-Optimierungslisten haben eine lange Halbwertszeit und werden selten zurückgezogen. Ein Teil dessen, was dort als Pflicht steht, ist längst Vorgabe, ein anderer Teil lässt sich gar nicht mehr einschalten. Zu jeder Einstellung steht deshalb der Befehl dabei, mit dem du den Ist-Zustand abliest. Lies ihn zuerst.

Warum Windows anders eingestellt wird als Linux

Unter Linux dreht sich das Betriebssystem-Tuning um Kernel-Parameter: Auslagerungsneigung, Zurückschreib-Schwellen, Ein-/Ausgabe-Planer. Das ist im Gegenstück zu diesem Artikel ausführlich beschrieben. Unter Windows liegen die wirksamen Hebel woanders, und das hat zwei Gründe.

Erstens hat Windows deutlich weniger frei einstellbare Kernel-Schrauben. Der Speicher-Manager regelt seine Schwellen selbst, und wo es Parameter gibt, sind sie meist über Richtlinien statt über eine Konfigurationsdatei erreichbar. Zweitens ist der Datenbankdienst hier ein Dienstkonto mit einem Rechteprofil — und zwei der wirksamsten Einstellungen unter Windows sind keine Leistungsparameter, sondern Benutzerrechte.

Dazu kommt eine Schicht, die es unter Linux in dieser Form auf Servern selten gibt: ein Virenschutz mit Dateisystem-Filtertreiber, der auf Windows Server seit 2016 standardmäßig aktiv ist. Er sitzt zwischen Datenbank und Datenträger und wird bei der Fehlersuche regelmäßig übersehen.

Was für welches Datenbanksystem gilt

Ein Teil der Windows-Einstellungen wirkt unabhängig davon, welche Datenbank darauf läuft. Ein anderer Teil ist an das jeweilige System gebunden — und bei zwei Einstellungen bedeutet dasselbe Windows-Recht bei beiden Systemen etwas völlig Verschiedenes. Genau dort entstehen die Fehler: ein Rat wird aus einem SQL-Server-Text übernommen und auf PostgreSQL angewandt, wo er nichts bewirkt oder etwas anderes tut als gedacht.

Zwei Einordnungen dazu, bevor du danach handelst.

Die Tabelle vergleicht ausschließlich Windows-Betriebssystemhebel. Auf diesem Feld ist SQL Server als Windows-eigenes Produkt naturgemäß enger mit dem Betriebssystem verzahnt — eine Bewertung der beiden Systeme insgesamt ist die Tabelle ausdrücklich nicht, und dieser Artikel spricht keine Empfehlung für das eine oder andere aus.

⚠ Und: die beiden Zeilen zu den Windows-Rechten — Seiten im Speicher sperren und Volumewartungsaufgaben — sind die, die in der Praxis schiefgehen. Beide haben einen Preis, der in eine Tabellenzelle nicht hineinpasst: das Volumewartungsrecht lässt gelöschte Plattendaten lesbar, und das Sperren von Seiten setzt eine gesetzte Speicherobergrenze voraus, sonst verlagert es den Engpass nur. Vergib keines der beiden allein nach dieser Tabelle — beide stehen unten ausführlich.

Rechte: was das Dienstkonto darf

Beide folgenden Einstellungen sind Benutzerrechte-Zuweisungen. Du findest sie in der lokalen Sicherheitsrichtlinie (secpol.msc) unter Lokale Richtlinien → Zuweisen von Benutzerrechten, in einer Domäne meist per Gruppenrichtlinie.

Durchführen von Volumewartungsaufgaben

Ohne dieses Recht füllt Windows jede neu angelegte oder vergrößerte Datenbankdatei zuerst vollständig mit Nullen, bevor die Datenbank sie nutzen darf. Bei einer Wiederherstellung im dreistelligen Gigabyte-Bereich ist das der Unterschied zwischen Minuten und deutlich mehr. Mit dem Recht entfällt dieser Schritt für Datendateien: der Platz wird belegt, der alte Inhalt erst beim tatsächlichen Schreiben überschrieben.

Betroffen sind das Anlegen einer Datenbank, das Hinzufügen von Dateien, jedes Vergrößern einschließlich automatischem Wachstum und das Wiederherstellen.

Bei SQL Server prüfst du den Ist-Zustand nicht in der Richtlinie, sondern in der Instanz:

SELECT servicename
     , instant_file_initialization_enabled
  FROM sys.dm_server_services;

Beim Dienststart steht dieselbe Auskunft im Fehlerprotokoll. Drei Einschränkungen gehören dazu, und sie werden regelmäßig unterschlagen:

⚠ Das Transaktionslog ist größtenteils außen vor. Historisch wurde es immer genullt. Seit SQL Server 2022 profitieren Autogrowth-Schritte des Logs — aber nur bis 64 MB je Schritt, was zufällig dem Vorgabewert für neue Datenbanken entspricht. Wer die Schrittweite größer stellt, verliert den Vorteil wieder. Und wer einen langsamen Dienststart mit „das Log wächst ja instant“ erklärt, sucht an der falschen Stelle.

⚠ Transparente Datenverschlüsselung schließt es für Datendateien aus. Ist TDE aktiv, werden Datendateien wieder genullt. Für das Transaktionslog gilt diese Sperre seit SQL Server 2022 nicht, weil das Log seriell geschrieben wird.

⚠ Es hat einen Preis, und der ist real. Gelöschte Plattendaten bleiben lesbar, bis sie überschrieben werden. Solange die Datei am Dienst hängt, schützt die Zugriffssteuerungsliste. Wird sie abgehängt oder gesichert, gilt dieser Schutz nur, wenn die Rechte an Datei und Sicherung stimmen. Microsoft empfiehlt das Recht trotzdem — mit der Auflage, abgehängte Dateien und Sicherungen sauber zu berechtigen. Für Umgebungen mit hohem Schutzbedarf ist das eine bewusste Abwägung, keine Formalie.

Vergib das Recht an die Dienst-SID, nicht an das Dienstkonto. Dann überlebt es einen Kontowechsel. Bei einer Neuinstallation lässt es sich direkt im Setup mitgeben.

Für PostgreSQL ist dieses Recht gegenstandslos. Es ruft die zugrunde liegende Windows-Funktion nicht auf und legt seine Dateien auch nicht in einem Zug in Endgröße an: Datendateien wachsen in kleinen Schritten, Transaktionslog-Segmente umfassen 16 MB und werden anschließend wiederverwendet, statt immer neu zu entstehen. Die Wartezeit, gegen die das Recht bei SQL Server hilft, entsteht dort also gar nicht erst. Wer eine PostgreSQL-Installation nach einer SQL-Server-Anleitung härtet, vergibt hier ein Recht ohne Gegenwert — und ein Recht, das nichts bringt, sollte man nicht vergeben.

Sperren von Seiten im Speicher — dasselbe Recht, zwei Bedeutungen

Hier liegt der wichtigste Unterschied zwischen den beiden Systemen, und er wird regelmäßig übersehen, weil das Recht in der Richtlinie genau gleich heißt. Was der Dienst damit anfängt, ist grundverschieden.

Bei SQL Server: Schutz des Arbeitssatzes

SQL Server sperrt damit seinen Arbeitsspeicher gegen Auslagerung. Das klingt nach Geschwindigkeit und ist es nicht: es ist eine Stabilitätsmaßnahme gegen einen bestimmten Fehlerfall — dass Windows unter Speicherdruck den Arbeitssatz des Dienstes zusammenkürzt und dessen Puffer auf die Auslagerungsdatei schiebt.

Der Befund kommt vor der Maßnahme. Der Eintrag 17890 im Fehlerprotokoll ist der Hinweis, dass genau das passiert ist. Ohne diesen Befund gibt es keinen Grund, das Recht zu setzen.

⚠ Gesetzt ohne Speicherobergrenze im Dienst wird es zum Problem. Sperrt der Datenbankdienst Speicher, den das Betriebssystem selbst braucht, verlagerst du den Engpass nur — dann hungern Dienste, Anmeldungen und im Zweifel das Verwaltungswerkzeug, mit dem du das Problem beheben wolltest. Die Obergrenze gehört gesetzt, bevor das Recht vergeben wird.

Die frühere Sonderregel für die Standard-Edition — ein zusätzliches Ablaufkennzeichen — gilt seit SQL Server 2012 nicht mehr.

Bei PostgreSQL: Voraussetzung für Large Pages

PostgreSQL nutzt dasselbe Recht für einen anderen Zweck. Es ist dort die Bedingung dafür, dass große Speicherseiten überhaupt angefordert werden können — unter Windows heißen sie Large Pages, in der Konfiguration steht huge_pages. Große Seiten verkleinern die Adressumsetzungstabellen und senken den Verwaltungsaufwand.

Der Unterschied liegt in der Absicht, nicht in jeder Wirkung: dass große Seiten unter Windows technisch ebenfalls nicht ausgelagert werden können, ist der Grund, warum überhaupt dieses Recht verlangt wird — es ist hier aber Nebenwirkung statt Ziel, und es betrifft nur den gemeinsamen Puffer, nicht den übrigen Speicher der Verbindungsprozesse. Wer bei PostgreSQL das Recht vergibt, um denselben Auslagerungsschutz wie bei SQL Server zu bekommen, bekommt also weniger, als er denkt.

Das Recht bekommt das Konto, unter dem der Dienst läuft. Beim Standard-Installationsweg ist das nicht das eigene Anmeldekonto — nachsehen, welches es tatsächlich ist, bevor die Richtlinie angefasst wird.

⚠ Der Vorgabewert verschweigt den Fehlschlag. huge_pages steht ab Werk auf try: PostgreSQL versucht große Seiten anzufordern und fällt ohne Meldung auf normale Seiten zurück, wenn das Recht fehlt. Der Dienst läuft, die Einstellung steht in der Konfiguration, und wirksam ist sie nicht — dasselbe stille Muster wie beim Energieplan unter fremder Firmware-Steuerung. Wer es verbindlich haben will, setzt huge_pages = on; dann verweigert der Dienst den Start, statt still zurückzufallen. Das ist die ehrlichere Einstellung, sobald man weiß, dass das Recht sitzt.

⚠ Startest du den Server ausnahmsweise von Hand statt als Dienst, entzieht eine normale Eingabeaufforderung das Recht wieder — die Benutzerkontensteuerung nimmt es beim Start heraus. Dann läuft die Instanz ohne große Seiten, obwohl das Konto sie hätte.

Für die Linux-Seite desselben Themas — samt Berechnung der nötigen Seitenzahl und der Abgrenzung zu Transparent Huge Pages — gibt es unsere Anleitung zu HugePages für PostgreSQL.

Speicher: die Auslagerungsdatei nicht abschaffen

Ein hartnäckiger Rat lautet, die Auslagerungsdatei auf einem Datenbankserver ganz abzuschalten — schließlich soll nichts ausgelagert werden. Das verwechselt zwei Dinge. Auslagerung verhindern ist das Ziel; die Datei entfernen nimmt dem System zusätzlich die Ablage für Absturzabbilder. Nach einem Absturz steht dann kein Abbild zur Verfügung, und die Ursachenanalyse beginnt mit einer Lücke.

Der sinnvolle Weg ist der umgekehrte: dafür sorgen, dass nicht ausgelagert wird — über eine passende Speicherobergrenze im Datenbankdienst und, falls nachgewiesen nötig, über das Sperren der Seiten. Die Datei bleibt.

Was der Datenbankdienst selbst an Speicher nehmen darf, ist Datenbankseite und steht nicht in diesem Artikel. Für PostgreSQL behandelt das unser Überblick der Performance-Settings; bei SQL Server ist es die Obergrenze für den Serverspeicher, die auf einem gemeinsam genutzten Rechner ohnehin nie auf dem Vorgabewert bleiben sollte.

Ein- und Ausgabe: die Schicht mit dem Filtertreiber

Der Virenschutz

Das ist der Abschnitt mit dem größten Verhältnis von Wirkung zu Aufwand — und der am häufigsten übersehene, weil die Bremse in keiner Datenbankstatistik auftaucht.

Windows Server aktiviert den mitgelieferten Virenschutz seit 2016 selbst. Sein Filtertreiber hängt im Ein-/Ausgabe-Pfad und sieht jeden Zugriff auf die Datenbankdateien. Zwei verbreitete Annahmen sind falsch:

⚠ „Das macht der Virenschutz automatisch.“ Die Automatikausschlüsse richten sich nach installierten Windows-Server-Rollen. SQL Server ist eine Anwendung, keine Rolle — für seine Dateien entsteht damit kein automatischer Ausschluss. Microsoft weist in der eigenen Anleitung ausdrücklich darauf hin, die Ausschlüsse einzurichten.

⚠ „Automatikausschlüsse decken alles ab.“ Sie gelten nur für den Echtzeitschutz. Eine Schnellprüfung, eine vollständige Prüfung und jede benutzerdefinierte Prüfung halten sich nicht daran. Ein nächtlicher Vollscan fasst die Datenbankdateien also an, auch wenn der Echtzeitschutz sie in Ruhe lässt.

Bevor die Liste kommt, gehört der Preis dazu — er ist keine Formalie:

⚠ Ein Ausschluss ist eine Sicherheitsentscheidung, keine Optimierung. Was ausgeschlossen ist, wird nicht geprüft; eine dort abgelegte Schadsoftware bleibt unentdeckt. Besonders wägen solltest du beim Sicherungsverzeichnis: .bak- und .trn-Dateien vom Echtzeitschutz auszunehmen bedeutet, genau das Verzeichnis ungeprüft zu lassen, auf das Verschlüsselungstrojaner zuerst zielen. Wenn du dort ausschließt, sollte der Schutz auf einem anderen Weg stehen — getrennte Ablage, eingeschränkte Rechte, unveränderliche Sicherungskopien. Beachte außerdem den Unterschied zwischen den Ausschlussarten: ein Datei- oder Ordnerausschluss nimmt einen festen Ort aus, ein Prozessausschluss dagegen alles, was dieser Prozess anfasst — er ist deutlich weitreichender und gehört entsprechend sparsam gesetzt.

Prüfen statt vermuten — dieser Befehl zeigt, welche Filtertreiber auf welchen Datenträgern tatsächlich hängen:

fltmc instances

Taucht dort der Treiber deines Virenschutzes mit dem Datenverzeichnis der Datenbank auf, hast du deinen Kandidaten. In Frage kommen bei SQL Server die Datendateien (.mdf, .ldf, .ndf), die Sicherungen (.bak, .trn), die Volltextkataloge, die Ablaufverfolgungs- und Überwachungsdateien sowie — als weitergehendes Mittel — die Prozesse sqlservr.exe, sqlagent.exe und sqlbrowser.exe. Bei PostgreSQL sind es das Datenverzeichnis samt Transaktionslog-Verzeichnis und der Prozess postgres.exe.

Im Failovercluster gehören zusätzlich das Quorum-Laufwerk und das Cluster-Verzeichnis dazu, wobei der Virenschutz clusterfähig sein muss.

Enthält die Datenbank personenbezogene Daten, ist ein solcher Ausschluss eine Änderung der technisch-organisatorischen Maßnahmen im Sinne von Art. 32 DSGVO und gehört entsprechend dokumentiert — er ist keine reine Betriebseinstellung.

Zuordnungseinheit beim Formatieren

Hier ist der verbreitete Rat richtig, aber die Begründung wird meist weggelassen — und ohne sie wendet man ihn falsch an.

Für SQL Server lautet die Empfehlung, Datenträger für Daten, Protokolle und tempdb mit einer Zuordnungseinheit von 64 KB zu formatieren. Der Grund ist die interne Einheit: SQL Server belegt Platz in Blöcken aus acht Seiten zu je 8 KB, zusammen genau 64 KB. Die Formatierung folgt also einer Struktur, die die Datenbank ohnehin verwendet.

Für PostgreSQL trägt diese Herleitung nicht. Dort gibt es keinen Extent-Begriff in dieser Form; die Seitengröße beträgt 8 KB. Wer den 64-KB-Rat unbesehen überträgt, wendet eine SQL-Server-Begründung auf eine andere Datenbank an. Das ist nicht automatisch schädlich, aber es ist eben auch nicht begründet.

⚠ Die Einstellung wird beim Formatieren festgelegt und lässt sich später nicht ändern, ohne den Datenträger neu anzulegen. Und: mit mehr als 4 KB entfällt die Möglichkeit der NTFS-Komprimierung auf diesem Datenträger — was auf einem Datenbank-Datenträger ohnehin nichts zu suchen hat, aber man sollte es wissen.

Welchen Wert ein bestehender Datenträger hat:

fsutil fsinfo ntfsinfo C:

Die Zeile mit der Bytegröße je Cluster ist die gesuchte. Steht dort 4096 und läuft der Server zufrieden, ist das kein Anlass für eine Neuformatierung — es ist ein Punkt für die nächste Neuinstallation.

Prozessor: Takt, Kerne, Speichernähe

Der Energieplan — und warum der Standardrat wackelt

Kaum ein Rat wird so oft weitergereicht wie „stell den Energieplan auf Höchstleistung“. Er war lange richtig. Heute ist er zumindest unvollständig, und das aus einem Grund, den Microsoft selbst dokumentiert.

Seit Windows Server 2016 überlässt Windows auf Intel-Prozessoren ab der Broadwell-Generation die Frequenzwahl der Hardware. Die Prozessorlogik passt den Takt dabei im Millisekundenbereich an, während das Betriebssystem in seinem Prüfintervall gerechnet deutlich träger nachregelt. Microsoft nennt in der eigenen Übersicht Ausbalanciert die empfohlene Vorgabe und schreibt, dass die Mehrheit der Serverhardware und Arbeitslasten überhaupt keine Anpassung der Energieeinstellungen braucht.

Dazu kommt ein Mechanismus, der genau den Fall abdeckt, um den es bei Datenbanken geht. Windows erkennt Phasen mit vielen aufgeschobenen Prozeduraufrufen — typisch für Ein-/Ausgabe- und netzwerklastige Arbeit — und hebt den Frequenzboden dann von sich aus auf den Höchstwert an. Das ist ab Werk so eingestellt.

Was heißt das praktisch? Nicht, dass Höchstleistung falsch wäre. Der Plan sperrt den Takt konstant oben und nimmt jede Regelverzögerung aus dem Spiel; für Systeme mit harten Latenzanforderungen bleibt das die einfachste Antwort. Es heißt, dass der Unterschied auf moderner Hardware kleiner geworden ist und dass es einen gezielteren Hebel gibt: die Vorliebe zwischen Energie und Leistung, ein Wert zwischen 0 und 100 mit dem Vorgabewert 50. Auf 0 gesetzt, weist er die Hardware an, durchgehend Leistung vor Sparsamkeit zu stellen — ohne den Rest des Plans anzufassen.

Erst ablesen, was gilt:

powercfg /getactivescheme
powercfg /q scheme_current sub_processor

⚠ Die wichtigste Falle steht in derselben Microsoft-Quelle und wird fast immer übersehen: Viele Serverhersteller bringen eigene Energieverwaltung in der Firmware mit. Behält die Firmware die Kontrolle, ändert der Energieplan im Betriebssystem gar nichts — die Einstellung wird angenommen, sie wird angezeigt, und sie wirkt nicht. Wer am Plan dreht und keine Wirkung misst, sollte zuerst dort nachsehen, statt weiter im Betriebssystem zu suchen. Der Leistungsindikator für den Anteil der Höchstfrequenz zeigt, was der Prozessor tatsächlich tut.

Kernparken

Beim Kernparken schaltet Windows unter geringer Last Kerne schlafen. Der Höchstleistungsplan hebt das auf. Für sich genommen ist das selten der entscheidende Punkt: Microsoft schreibt, dass das Vorgabeverhalten für die meisten Server einen vernünftigen Ausgleich bietet und auf Prozessoren, bei denen es wenig bringt, ohnehin ab Werk abgeschaltet ist. Ein Fall, in dem es ungünstig wirkt, ist Arbeit, die fest an bestimmte Kerne gebunden ist — dann kann die Auswahllogik Kerne aufwecken, die gar nicht genutzt werden.

NUMA

Auf Maschinen mit mehreren Prozessorsockeln ist Arbeitsspeicher nicht gleich Arbeitsspeicher: jeder Sockel hat eigenen, direkt angebundenen Speicher, und der Zugriff auf den des Nachbarsockels ist langsamer. SQL Server erkennt die Topologie von sich aus und richtet seine internen Strukturen daran aus; in aller Regel ist das die bessere Wahl als eine Zuweisung von Hand.

Der praktisch häufigere Fall ist die virtuelle Maschine. Wird sie so ausgelegt, dass sie nicht mehr in einen Knoten passt, entsteht ein Zugriffsmuster über Knotengrenzen hinweg, auf das die Datenbank keinen Einfluss hat. Das ist eine Entscheidung in der Virtualisierung, nicht im Gastsystem — und sie gehört mit den Verantwortlichen dafür besprochen, bevor im Gast optimiert wird.

Auf Maschinen mit einem Sockel ist der ganze Abschnitt gegenstandslos, und das sind die meisten.

Netzwerk: was nicht mehr gilt

Ältere Optimierungslisten enthalten fast immer den Rat, TCP Chimney Offload abzuschalten. Der Rat hatte seinen Grund: die Auslagerung des TCP-Stapels auf die Netzwerkkarte galt als fehleranfällig — Microsoft hat die Funktion deshalb mit Windows Server 2016 für veraltet erklärt und ab Werk abgeschaltet.

⚠ Heute ist der Rat gegenstandslos. Ab Windows Server 2019 lässt sich die Funktion nicht mehr aktivieren; der entsprechende Befehl schlägt fehl. Wer ihn in eine Anleitung schreibt, schickt Leser auf eine Fehlermeldung und weckt den Eindruck, es sei etwas zu tun.

Was stattdessen zählt, ist unspektakulär: aktuelle Treiber der Netzwerkkarte, und bei mehreren Karten die Frage, ob die Empfangslast überhaupt auf mehrere Kerne verteilt wird. Beides ist Herstellersache und lässt sich nicht pauschal einstellen. Das Feintunen von TCP-Puffergrößen bewegt bei einer Datenbank im lokalen Netz in aller Regel nichts Messbares — das gilt unter Windows genauso wie unter Linux.

Wenn PostgreSQL auf Windows läuft

PostgreSQL läuft auf Windows, und es läuft ordentlich. Zwei Eigenheiten sind oben schon behandelt: das Recht zum Sperren von Seiten dient hier in erster Linie den Large Pages, nicht dem Auslagerungsschutz, und das Volumewartungsrecht ist gegenstandslos. Drei weitere Unterschiede solltest du kennen.

Verbindungen sind teurer als unter Linux. PostgreSQL startet je Verbindung einen eigenen Prozess. Unter Linux geschieht das über einen Mechanismus, der den bestehenden Prozess kopiert und dabei Speicherseiten erst bei Änderung wirklich vervielfältigt — das ist sehr günstig. Unter Windows gibt es diesen Mechanismus nicht; jeder neue Prozess wird vollständig aufgebaut. Das macht eine Verbindungsverwaltung auf Windows wichtiger als auf Linux. Anwendungen, die für jede Anfrage eine neue Verbindung öffnen, zahlen den Unterschied bei jedem Aufruf. SQL Server hat diesen Prozessanteil nicht: dort bedient ein einzelner Prozess alle Verbindungen über Threads. Anmelde- und Verschlüsselungsaufwand fallen allerdings auch dort an, weshalb Verbindungspooling in beiden Welten Standard ist.

Der Speicher wird anders aufgeteilt. SQL Server verwaltet einen eigenen Puffer, dessen Obergrenze du setzt, und gibt bei Druck von sich aus Speicher zurück — deshalb ist die Obergrenze dort die zentrale Einstellung. PostgreSQL hält einen vergleichsweise kleinen eigenen Puffer und überlässt den Rest bewusst dem Dateicache des Betriebssystems; eine Datenseite liegt damit im Regelfall zweimal im Arbeitsspeicher. Das ist kein Fehler, sondern Absicht — es bedeutet aber, dass der freie Speicher in der Anzeige nicht der ungenutzte Speicher ist, und dass ein zu großer eigener Puffer die Datenbank bremsen kann, statt sie zu beschleunigen.

Für NUMA gibt es keine eigene Steuerung. SQL Server erkennt die Topologie und richtet seine internen Strukturen daran aus. PostgreSQL bringt dafür nichts mit — unter Linux löst man das über die Dienstverwaltung, unter Windows bleibt als Hebel im Wesentlichen die Auslegung der virtuellen Maschine. Auf Ein-Sockel-Maschinen, und das sind die meisten, ist der Punkt gegenstandslos.

Dazu ein Rat, den du finden wirst: auf Windows solle man den Datenbank-Cache klein halten. Er stammt aus Diskussionen der späten 2000er-Jahre. Die aktuelle PostgreSQL-Dokumentation trägt ihn nicht mehr — sie nennt als Startwert ein Viertel des Arbeitsspeichers und hält mehr als vierzig Prozent für unwahrscheinlich sinnvoll, ohne dabei zwischen Betriebssystemen zu unterscheiden. Das ist kein Beweis, dass es keinen Unterschied gibt; es ist ein Grund, den alten Rat nicht ungeprüft zu übernehmen. Miss es an deiner Last, statt eine Zahl aus einem fünfzehn Jahre alten Beitrag zu setzen.

Alles Weitere zur Datenbankseite steht in unserem Überblick der Performance-Settings; die Wartungsarbeiten, die unabhängig vom Betriebssystem anfallen, behandelt unser Beitrag zu VACUUM, REINDEX und CLUSTER.

Messen statt raten

Der wichtigste Abschnitt, und der am häufigsten übersprungene. Jede Einstellung oben ist eine Hypothese, bis du sie an deiner Arbeitslast geprüft hast.

Was du erhebst, hängt davon ab, was du vermutest:

Zwei Fallstricke, die Messungen regelmäßig entwerten. Erstens: ein Vergleich zwischen Montagvormittag und Sonntagnacht misst den Wochentag, nicht die Einstellung. Zweitens: ein Standard-Lastwerkzeug misst das Lastwerkzeug, nicht deine Anwendung — mit deren Zugriffsverteilung hat es meist wenig gemein.

Wer diese Systematik nicht nebenbei aufbauen will, findet sie im Seminar Datenbankübergreifendes Performance-Tuning als eigenes Thema: Performance-Optimierung relationaler Datenbanken, unabhängig vom eingesetzten System.

Was dieser Artikel nicht behandelt

Bewusst ausgeklammert bleibt die Datenbankseite: Speicherobergrenzen, Parallelitätsschwellen, tempdb-Aufteilung, Indizes und Abfragen. Das ist eigene Arbeit, und sie kommt zuerst — die Reihenfolge lautet Abfragen, dann Datenbankeinstellungen, dann Betriebssystem. Wer umgekehrt anfängt, optimiert die Unterlage eines schiefen Tisches.

Ebenfalls nicht behandelt: Hochverfügbarkeit, Sicherungsstrategie und Virtualisierung im Detail. Das sind Architekturfragen. Sie werden relevant, nachdem die Grundlagen hier stimmen.

Für die Linux-Seite derselben Fragen — Auslagerungsneigung, Zurückschreib-Schwellen, Ein-/Ausgabe-Planer und die Tücken der systemd-Unit — gibt es das Gegenstück zu diesem Artikel.

Häufige Fragen

Bringt das alles zusammen mehr als ein besserer Index?

In aller Regel nicht. Ein fehlender Index verändert den Aufwand einer Abfrage strukturell; die Einstellungen hier verändern ihn nicht, sie nehmen Reibung und Ausreißer heraus. Zwei Ausnahmen bestätigen das eher, als sie es widerlegen: ein Virenschutz, der die Datendateien mitprüft, und ein ausgelagerter Datenbank-Cache kosten im Einzelfall sehr viel mehr — aber das sind Störungen, keine Optimierungen. Die Reihenfolge ist deshalb: erst Abfragen und Indizes, dann die Datenbankeinstellungen, dann das Betriebssystem.

Muss ich nach jeder Änderung neu starten?

Unterschiedlich. Energieeinstellungen greifen sofort. Virenschutz-Ausschlüsse ebenfalls. Die beiden Benutzerrechte werden dagegen beim Dienststart gelesen — sie wirken erst nach einem Neustart des Datenbankdienstes, und genau das wird oft vergessen, weshalb die Einstellung dann als wirkungslos gilt. Die Zuordnungseinheit lässt sich gar nicht nachträglich ändern; sie wird beim Formatieren festgelegt.

Gilt das auch in einer virtuellen Maschine?

Teilweise, und der Unterschied ist größer als unter Linux. Die Rechte, der Virenschutz und die Zuordnungseinheit wirken im Gast genauso. Die Energieeinstellungen meist nicht — dort entscheidet der Wirt, und der Wert im Gast ist Zierde. Bei NUMA kommt hinzu, dass die Auslegung der virtuellen Maschine bestimmt, ob sie in einen Knoten passt; das ist eine Entscheidung in der Virtualisierung, nicht im Gastsystem.

Woran erkenne ich, dass der Virenschutz die Bremse ist?

Am Muster: die Datenbank ist bei Arbeit mit vielen Dateizugriffen deutlich langsamer als die reine Datenträgerleistung erwarten lässt — typischerweise bei Sicherungen, Wiederherstellungen und Massenimporten —, ohne dass Abfragen oder Sperren das erklären. fltmc instances zeigt, ob der Filtertreiber auf dem betroffenen Datenträger hängt. Der Gegenbeweis ist einfach: Ausschlüsse setzen, dieselbe Arbeit noch einmal messen.

Ist das Recht für die Volumewartung ein Sicherheitsproblem?

Es ist eine Abwägung mit einem konkreten Preis. Gelöschte Plattendaten bleiben lesbar, bis sie überschrieben werden — relevant wird das, wenn eine Datenbankdatei abgehängt oder gesichert wird und dann jemand darauf zugreifen kann, der es nicht dürfte. Microsoft empfiehlt das Recht trotzdem, weil der Nutzen in den meisten Umgebungen überwiegt, und knüpft es an eine Bedingung: abgehängte Dateien und Sicherungen müssen sauber berechtigt sein. Enthält die Datenbank personenbezogene Daten, ist das Setzen des Rechts eine Änderung der technisch-organisatorischen Maßnahmen und gehört entsprechend dokumentiert — nicht nebenbei entschieden.

Sollte ich den Energieplan jetzt auf Höchstleistung stellen oder nicht?

Wenn dein Server harte Latenzanforderungen hat und du den einfachsten Weg willst: ja, der Plan ist dafür gemacht. Wenn du es genauer haben willst: prüfe zuerst, ob die Firmware dem Betriebssystem die Steuerung überhaupt überlässt — sonst ist die Frage ohnehin gegenstandslos. Danach ist die Vorliebe zwischen Energie und Leistung der feinere Hebel. Und in beiden Fällen gilt: miss den Anteil der Höchstfrequenz vorher und nachher, sonst weißt du nicht, ob sich etwas geändert hat.

Kann ich eine SQL-Server-Anleitung auf PostgreSQL anwenden?

Nur teilweise, und die Ausnahmen sind genau die teuren. Energieplan, Firmware-Steuerung, Kernparken und die Auslagerungsdatei gelten für beide gleich — das ist reine Betriebssystem-Ebene. Drei Punkte unterscheiden sich: Das Recht „Seiten im Speicher sperren“ schützt bei SQL Server den Arbeitssatz, ist bei PostgreSQL dagegen die Voraussetzung für große Speicherseiten — gleicher Name, anderer Zweck. Das Recht „Durchführen von Volumewartungsaufgaben“ nutzt PostgreSQL gar nicht. Und die 64-KB-Zuordnungseinheit ist über den SQL-Server-Extent begründet, den es bei PostgreSQL so nicht gibt. Die Übersichtstabelle weiter oben stellt das nebeneinander.

Warum steht in älteren Anleitungen so viel, was heute nicht mehr gilt?

Weil Optimierungslisten weitergereicht und selten zurückgezogen werden. Ein Rat, der 2012 richtig war, steht 2026 noch in Dutzenden Blogbeiträgen — auch dann, wenn die Funktion inzwischen entfernt wurde. Das ist der Grund, warum in diesem Artikel zu jeder Einstellung ein Prüfbefehl steht: der Ist-Zustand deines Servers ist die einzige Quelle, die nicht veraltet.

In welcher Reihenfolge gehe ich vor, wenn ich heute anfange?

Erst lesen: fltmc instances, powercfg /getactivescheme, fsutil fsinfo ntfsinfo <Laufwerk>, und bei SQL Server zusätzlich die Abfrage auf die Dienstübersicht.

Danach der erste Eingriff, der für beide Systeme gleich gilt: Virenschutz-Ausschlüsse setzen — mit der Abwägung zum Sicherungsverzeichnis aus dem Virenschutz-Abschnitt im Blick. Das ist der Punkt mit dem besten Verhältnis aus Aufwand und Wirkung.

Ab da trennen sich die Wege. Bei SQL Server: das Recht für die Volumewartung vergeben und die Speicherobergrenze prüfen. Bei PostgreSQL: prüfen, ob große Speicherseiten tatsächlich in Benutzung sind — der Vorgabewert try verschweigt den Fehlschlag —, und die Verbindungsverwaltung ansehen, weil Verbindungsaufbau hier teurer ist als unter Linux.

Das ist jeweils an einem Vormittag erledigt und lässt sich einzeln zurücknehmen. Alles Weitere — Energieplan, NUMA, bei SQL Server das Sperren der Seiten — lohnt erst, wenn eine Messung dafür spricht.

Quellen

Die Angaben in diesem Artikel stammen aus den Herstellerdokumentationen, nicht aus zweiter Hand. Wer eine einzelne Aussage nachschlagen will, findet sie hier:

• Energie- und Leistungsoptimierung für Windows Server — Energieplan-Vorgabe, hardwaregesteuerte Frequenzwahl, Kernparken, Firmware-Vorbehalt
• Sofortige Dateiinitialisierung für Datenbanken — betroffene Operationen, Transaktionslog ab SQL Server 2022, Sicherheitsabwägung
• Antivirensoftware für SQL Server konfigurieren — auszuschließende Verzeichnisse, Endungen und Prozesse, Failovercluster
• Automatische Ausschlüsse von Microsoft Defender auf Windows Server — Bindung an Serverrollen, Geltung nur für den Echtzeitschutz
• PostgreSQL: Resource Consumption — huge_pages und Large Pages unter Windows, shared_buffers

Wer diese Zusammenhänge nicht nur nachlesen, sondern systematisch aufbauen will: das Seminar Datenbankübergreifendes Performance-Tuning behandelt die Systematik hinter dem Messen und Optimieren — unabhängig davon, welche Datenbank bei dir läuft. Für die jeweilige Produktseite gibt es PostgreSQL Administration und, für die SQL-Server-Welt, SQL Server T-SQL Programmierung. Alle finden als Inhouse-Veranstaltung statt, die Übungsumgebung bringe ich als vorbereitete virtuelle Maschinen mit: kein Einrichtungsaufwand für deine IT, und niemand übt an einem Produktivsystem.