Blockgröße für SQL Server richtig auswählen (Windows und Linux)

Einleitung: Die Wahl der optimalen Blockgröße (auch Allocation Unit Size oder Dateisystem-Blockgröße genannt) für Datenträger ist ein wichtiger, oft unterschätzter Faktor beim Betrieb von Microsoft SQL Server unter Windows und Linux. Die Blockgröße eines Dateisystems bestimmt die kleinste Zuordnungseinheit auf dem Datenträger und beeinflusst, wie effizient Daten gespeichert und abgerufen werden. Insbesondere bei leistungsintensiven Datenbankanwendungen wie SQL Server kann die Blockgröße Auswirkungen auf I/O-Leistung, Speicherplatzausnutzung und Fragmentierung haben. Historisch galt die Empfehlung, Volumes für SQL Server mit einer Blockgröße von 64 KB zu formatieren, da SQL Server seine Daten in 8-KB-Seiten verwaltet und diese seitenweise in sogenannten Extents zu 64 KB zusammenfasst. Moderne Speichertechnologien (SSD, NVMe) und aktuelle Betriebssysteme haben jedoch die Rahmenbedingungen verändert, sodass pauschale Empfehlungen neu bewertet werden müssen. In diesem Fachartikel werden die technischen Grundlagen erläutert und verschiedene Einsatzszenarien untersucht, um die Frage zu beantworten: Wie findet man die optimale Blockgröße für SQL Server unter Windows und Linux?

Wir betrachten zunächst die Funktionsweise relevanter Dateisysteme (NTFS, ReFS, ext4, XFS) und den Zusammenhang zwischen Blockgröße, Storage-Alignment und SQL-Server-I/O-Mustern. Anschließend gehen wir auf Unterschiede zwischen Windows und Linux ein – etwa Standard-Blockgrößen und die Bedeutung von Direct I/O bzw. des SQL Server Buffer Pools. Es folgen SQL-Server-spezifische Aspekte wie typische I/O-Profile (OLTP vs. OLAP/Datenwarehouse), Auswirkungen auf TempDB, Daten- und Log-Dateien sowie offizielle Empfehlungen und Erfahrungen aus der Praxis. Darauf aufbauend geben wir praxisorientierte Empfehlungen für verschiedene Szenarien – von OLTP-Systemen über Data-Warehouse-Umgebungen bis hin zu virtualisierten Szenarien und modernen Speichersystemen (SAN, NAS, Storage Spaces Direct, Cloud). Abschließend erläutern wir, wie sich die gewählte Blockgröße prüfen und ggf. anpassen lässt. Eine FAQ-Sektion mit 15 praxisnahen Fragen und Antworten rundet den Artikel ab.

1. Technische Grundlagen der Dateisystem-Blockgröße

1.1 Dateisysteme und Blockgrößen (NTFS, ReFS, ext4, XFS)

Moderne Dateisysteme organisieren die Speicherung von Dateien in Blöcken fester Größe (Cluster). NTFS (New Technology File System) – das Standard-Dateisystem unter Windows – verwendet standardmäßig 4 KB große Cluster, bietet aber optional Clustergrößen von 512 Byte bis 64 KB. ReFS (Resilient File System), der NTFS-Nachfolger für bestimmte Anwendungsfälle, unterstützt Clustergrößen von 4 KB (Standard) und 64 KB. Unter Linux sind die gängigen Dateisysteme ext4 und XFS weit verbreitet. Beide arbeiten in der Regel mit einer Blockgröße von 4 KB, was auf typische Speicherarchitekturen abgestimmt ist. Tatsächlich entspricht die Dateisystem-Blockgröße bei ext4/XFS oft der Seitengröße des Arbeitsspeichers (meist 4 KB auf x86_64-Systemen), was aus Effizienzgründen vorteilhaft ist. Eine Erhöhung der Blockgröße über 4 KB hinaus ist bei ext4 und XFS auf Standard-x86-Hardware nicht ohne Weiteres möglich, da das System zum Mounten voraussetzt, dass die Blockgröße nicht größer ist als die Speicher-Seitengröße.

Wie werden Dateien in Blöcken abgelegt? Das Dateisystem verwaltet eine Zuordnungstabelle (z. B. das Master File Table (MFT) bei NTFS), welche die Zuordnung von Dateiinhalten zu physischen Blöcken auf dem Datenträger beschreibt. Jeder Cluster repräsentiert einen oder mehrere physische Sektoren des Laufwerks und ist die atomare Einheit, mit der der Speicherplatz vergeben wird. Ist eine Datei kleiner als die Clustergröße, belegt sie dennoch einen vollen Cluster – dies kann bei sehr kleinen Dateien zu geringfügigem Speicherverlust durch internen Fragmentierungsanteil führen. Wächst die Datei, werden weitere Cluster zugewiesen, idealerweise in zusammenhängenden Runs, sodass die Datei möglichst sequentiell auf dem Datenträger liegt.

NTFS und ReFS: NTFS nutzt eine blockbasierte Allokierung mit der Möglichkeit, Cluster in verschiedenen Größen zu wählen. Ein 4-KB-Cluster ist hier allgemeiner Standard, da er einen guten Kompromiss zwischen effizienter Speichernutzung und Verwaltungsaufwand darstellt und zudem Kompatibilitätsgründe (u. a. NTFS-Kompression) berücksichtigt. ReFS wurde mit Blick auf Resilienz und moderne Storage-Features entwickelt (z. B. Integritätsprüfungen, tiered Storage). Standardmäßig verwendet ReFS ebenfalls 4 KB, da dies in den meisten Umgebungen die beste Performance und geringste Nebenwirkungen liefert. Größere Cluster (64 KB) können auf ReFS zwar formatiert werden, sind aber laut Microsoft nur in bestimmten Szenarien ratsam – insbesondere bei großen, sequentiellen Workloads – da kleinvolumige Schreibvorgänge ansonsten zu sogenannter I/O Amplification führen können. (Den Effekt der I/O Amplification betrachten wir gleich noch genauer.)

ext4 und XFS: Unter Linux sind ext4 (der Standard auf vielen Distributionen) und XFS (häufig für Datenbank- und Enterprise-Workloads empfohlen) die relevantesten Dateisysteme für SQL-Server-Daten. Beide verwenden per Default 4-KB-Blöcke, was zur typischen Sektorgröße moderner Laufwerke (4 KB physische Sektoren bei Advanced-Format-HDDs oder SSDs) passt und zudem mit der Speicherarchitektur harmoniert. Ext4 verwaltet Dateien mithilfe von Extents (zusammenhängenden Blockbereichen), was effizient mit Fragmentierung umgeht und große Dateien handhaben kann. XFS ist ebenfalls extent-basiert und auf hohe Parallelität und Performance ausgelegt. In beiden Systemen lassen sich bei üblicher x86-Hardware größere Blockgrößen nicht ohne Spezialkernel nutzen – der Normalfall bleibt also 4 KB. Allerdings können ext4 und XFS über die Formatierung und Montierung in anderer Hinsicht optimiert werden (z. B. Anpassung der Inode-Dichte, Nutzung von Optionen wie noatime, Ausrichtung an RAID-Stripes usw.), worauf wir noch eingehen.

1.2 Zusammenhang zwischen Blockgröße, Alignment und SQL Server I/O-Mustern

Die Blockgröße eines Dateisystems beeinflusst, wie I/O-Operationen mit dem physischen Speicher ausgerichtet sind (Storage Alignment). Storage Alignment bedeutet in diesem Kontext, dass die logischen Datei- und Partitionierungsgrenzen mit den physischen Sektoren des Laufwerks und den eventuell vorhandenen RAID-Stripe-Größen übereinstimmen. Ein korrektes Alignment ist wichtig, um zu vermeiden, dass scheinbar einzelne I/O-Operationen in Wirklichkeit zwei physische Blöcke betreffen (z. B. weil ein logischer 4-KB-Block über zwei 4-KB-physische Sektoren straddelt). Früher traten solche Fehlausrichtungen häufig auf, z. B. bei Windows-Versionen vor Windows Vista, wo Partitionen standardmäßig bei Sektor 63 begannen (31,5 KB Offset) und dadurch oft nicht auf 64-KB-Stripes ausgerichtet waren. Heutige Systeme legen Partitionen typischerweise mit 1 MB Offset an, sodass eine saubere Ausrichtung an üblichen Stripe-Größen (z. B. 64 KB, 128 KB) gewährleistet ist. Ein korrekt ausgerichtetes System stellt sicher, dass ein logischer Block nicht über zwei Stripe-Einheiten hinwegliegt – andernfalls könnte ein einziger Lese-/Schreibzugriff unnötig zwei Stripe-Bereiche und damit mehrere Laufwerke involvieren, was die I/O-Kosten erhöht.

Blockgröße vs. Stripe-Größe: In RAID-Systemen (z. B. RAID 0, 10, 5, 6) wird Daten auf mehrere Datenträger verteilt. Die Stripe Size (Streifenbreite) bestimmt, wie groß die auf einem einzelnen Datenträger zusammenhängend gespeicherten Datenblöcke sind, bevor zum nächsten Datenträger gewechselt wird. Beispielsweise bedeutet ein 64-KB-Stripe bei RAID 10, dass pro Schreibzugriff 64 KB am Stück auf einem Laufwerk geschrieben werden, bevor der nächste 64-KB-Block auf dem Spiegel oder nächsten Satz beginnt. Um optimale Leistung zu erzielen, sollte die Dateisystem-Blockgröße in einem sinnvollen Verhältnis zur Stripe-Größe stehen. Oft wird empfohlen, die Clustergröße dem Stripe anzupassen oder zumindest als Teiler der Stripe-Größe zu wählen (z. B. 64-KB-Cluster bei 256-KB-Stripe, da 4×64 KB = 256 KB). Wichtiger als die Clustergröße selbst ist jedoch die Partitionsausrichtung: Ist der Anfang des Volumes auf einen Stripe-Grenzwert ausgerichtet, werden I/O-Zugriffe in der Regel bereits optimal auf die Stripes abgebildet. Ein korrekt ausgerichtetes System kann so gewährleisten, dass eine einzelne 64-KB-Schreiboperation genau einen 64-KB-Stripe auf dem RAID bedient und nicht über Stripe-Grenzen hinausgeht, was sonst zusätzliche Lese-Schreib-Operationen (Read-Modify-Write bei RAID 5/6) verursachen würde.

SQL Server I/O-Muster: SQL Server greift auf seine Daten auf Ebene von Pages (8 KB) und Extents (8 zusammenhängende Pages = 64 KB) zu. Daraus könnte man folgern, dass SQL Server idealerweise 64-KB-E/A-Operationen nutzt und somit eine 64-KB-Clustergröße perfekt passen müsste. Tatsächlich aber zeigt die Praxis, dass die I/O-Größen bei SQL Server je nach Vorgang stark variieren – von sehr kleinen 512-Byte-Transfers (z. B. einzelne Protokollbuchungen) über die Standardseiten von 8 KB bis hin zu großen sequentiellen Zugriffen von mehreren Hundert Kilobyte oder sogar mehreren Megabytes (etwa bei Read-Ahead-Operationen oder Backups). Das I/O-Muster hängt vom Workload ab: Ein OLTP-System mit vielen kleinen Transaktionen erzeugt vor allem zufällige 8-KB-Lese-/Schreibzugriffe und Log-Schreibvorgänge um 8–60 KB. Ein Data-Warehouse- oder OLAP-System hingegen liest oft große Tabellen in Sequenz, wobei der SQL Server mittels Read-Ahead möglichst bis zu 512 KB an zusammenhängenden Seiten in einem Rutsch liest.

Warum ist dieser variable I/O-Mix wichtig für die Blockgröße? Wenn die Dateisystem-Blockgröße kleiner oder gleich den typischen I/O-Größen ist, können I/O-Zugriffe effizient erfolgen, da jeder logische Zugriff mindestens einen oder wenige physische Blöcke umfasst. Ist die Clustergröße jedoch wesentlich größer als die häufig auftretenden Zugriffe, kann es zu I/O-Überhang kommen: Das Dateisystem muss eventuell mehr Daten bewegen als angefordert, um den großen Cluster zu handhaben. Dieser Effekt wird I/O Amplification genannt – ein Beispiel dafür liefert ReFS mit 64-KB-Clustern: Eine einzelne 4-KB-Schreiboperation kann ReFS dazu zwingen, zunächst einen ganzen 64-KB-Block aus dem langsamen Speichertier einzulesen, um darin die 4 KB zu ändern, oder ganze 64 KB zu kopieren, wenn Block-Cloning oder Integritätsprüfungen aktiv sind. Solche unbeabsichtigten zusätzlichen I/Os kosten Zeit und Performance. Microsoft betont daher, dass man durch die Wahl von 4 KB statt 64 KB auf ReFS diese unnötigen Mehrfachzugriffe minimieren kann. Allgemeiner formuliert: Wenn die Clustergröße die typische I/O-Größe übersteigt, steigt das Risiko von I/O-Überschneidungen und zusätzlichem Overhead. In Workloads mit vorwiegend sehr kleinen Zugriffen (wie OLTP) kann daher eine kleinere Clustergröße vorteilhaft sein, um Schreib-Latenzen gering zu halten und Lese-Overhead zu vermeiden.

Umgekehrt kann eine sehr kleine Clustergröße (z. B. 4 KB) bei vorwiegend großen sequentiellen Zugriffen bedeuten, dass eine große Datei in enorm viele kleine Blöcke aufgeteilt wird. Zwar können moderne Betriebssysteme auch viele aufeinanderfolgende 4-KB-Blöcke in einem einzigen I/O lesen oder schreiben, sofern sie im Speicher zusammenhängen – doch das Dateisystem muss mehr Verwaltungsarbeit leisten, um Millionen kleiner Cluster zu verwalten. Besonders bei extrem großen Dateien (mehrere Terabyte) und sehr großen sequentiellen Transfers kann eine größere Blockgröße die Anzahl der verwalteten Extents reduzieren und potenziell minimalen Overhead sparen. Allerdings zeigen Messungen, dass der Performanceunterschied zwischen 4-KB- und 64-KB-Clustern selbst in solchen Fällen oft gering ist (siehe Abschnitt 3.3 und 4).

Zusammenfassend hängt der Einfluss der Blockgröße auf die I/O-Effizienz stark vom Zugriffsprofil ab. Wichtig ist vor allem, Fehlausrichtungen zu vermeiden (damit nicht ein logischer Zugriff zwei physische erzwingt) und die häufigsten I/O-Größen des SQL-Servers nicht wesentlich kleiner als die Clustergröße zu wählen. SQL Server nutzt variable I/O-Größen – eine starre 64-KB-These greift zu kurz. Im nächsten Abschnitt betrachten wir, wie Windows und Linux mit diesen Faktoren umgehen, insbesondere im Hinblick auf Caching-Strategien wie Direct I/O und den Buffer Pool.

1.3 Einfluss der Blockgröße auf Performance, Fragmentierung und Speicherverwaltung

Performance und IOPS: Die Wahl der Clustergröße hat theoretische Auswirkungen auf IOPS (Input/Output Operations per Second) und Durchsatz. Kleinere Blöcke bedeuten tendenziell mehr I/O-Operationen für die gleiche Datenmenge, während größere Blöcke weniger Operationen erfordern, dafür aber ggf. mehr Daten pro Operation bewegen. In einem idealisierten Beispiel würde eine 64-KB-Leseoperation auf einem 64-KB-Cluster als ein einziger Zugriff erfolgen, während dieselben 64 KB auf 4-KB-Clustern in 16 Einzellesevorgänge á 4 KB zerfallen könnten. Allerdings können moderne Betriebssysteme sequentielle kleine Blöcke zu größeren Transfers zusammenfassen, und viele Speicher-Controller erkennen aufeinanderfolgende I/Os und optimieren diese intern. In einem Benchmark-Vergleich ergab sich beispielsweise praktisch kein Unterschied in IOPS und Latenz zwischen einer Partition mit 4-KB-Clustersize und 64-KB-Clustersize, wenn 64-KB-Blöcke randomisiert gelesen/geschrieben wurden – entgegen der Erwartung, dass 64-KB-Cluster hier deutlich im Vorteil sein müssten. Die Erklärung dafür ist, dass die Messung auf moderner Hardware und mit optimierten Treibern erfolgte, die 16×4 KB-Zugriffe ähnlich effizient abwickeln konnten wie 1×64 KB. Solange die Zugriffe physisch zusammenhängend sind (d. h. die 16 kleinen Blöcke liegen hintereinander auf dem Datenträger), lässt sich der Unterschied durch Vorauslesen oder optimierte Controller puffern. In zufälligen OLTP-Workloads, wo die meisten Lesezugriffe ohnehin einzelne 8-KB-Seiten betreffen, zeigt sich in realen Tests ebenfalls kaum ein Unterschied in der Datenbank-Performance zwischen verschiedenen Clustergrößen. Eine aktuelle AWS-Untersuchung mit einem 8 TB OLTP-Benchmark etwa fand keine signifikanten Abweichungen der Transaktionsrate zwischen 16 KB-, 32 KB- und 64 KB-Blockgrößen – die Ergebnisse lagen innerhalb der statistischen Schwankungsbreite. Gleichzeitig wurde gemessen, dass die durchschnittliche Größe der Lese- und Schreiboperationen bei diesem OLTP-Test knapp über 8 KB lag – es wurden also überwiegend einzelne Datenbankseiten gelesen/geschrieben. Dies unterstreicht, dass für typische OLTP-Muster die Standardblockgröße von 4 KB keinen Flaschenhals darstellt, solange die I/O-Anforderungen der Anwendung im Rahmen liegen.

Fragmentierung: Fragmentierung bezeichnet die Aufsplitterung einer Datei in viele nicht zusammenhängende Blöcke auf dem Datenträger. Sie entsteht z. B., wenn Dateien wachsen und nicht genug zusammenhängender freier Speicher verfügbar ist. Eine größere Clustergröße kann Fragmentierung in zweierlei Hinsicht beeinflussen: Erstens verringert sie die Gesamtanzahl an Clustern, die eine Datei belegt – ein 64-KB-Cluster deckt ja den Inhalt von 16×4 KB ab. Zweitens können größere Cluster helfen, die Grenzen gewisser Dateisystem-Limitationen hinauszuschieben. Insbesondere NTFS hat (bedingt durch Abwärtskompatibilität und MFT-Struktur) ein Limit von ca. 1,5 Millionen Extents pro Datei. Das heißt, wenn eine Datei in mehr als ~1,5 Mio. fragmentierte Teile zerfällt, könnten Probleme auftreten (in der Praxis z. B. Fehler oder drastischer Performanceabfall). Bei 4-KB-Clustern entspricht diese Grenze einer potenziell fragmentierten Dateigröße von etwa 6 GB (1,5 Mio.×4 KB), wobei in realen Szenarien eine Datei selten so extrem fragmentiert ist. Dennoch: Anwendungen wie Datenbank-Dateien, die häufig wachsen, viele Änderungen durchlaufen oder Features wie Sparse Files bzw. Data Deduplication verwenden, können eine hohe Fragmentierung verursachen. Microsoft nennt explizit SQL-Server-Datenbanken als Beispiel für eine Umgebung, in der extrem viele Extents auftreten können. In solchen Fällen kann eine größere Clustergröße wie 64 KB das Risiko mindern, das Fragmentierungslimit zu erreichen, weil deutlich weniger Cluster benötigt werden, um dieselbe Dateigröße abzubilden. Ein weiterer Aspekt: NTFS hat eine Standard-Obergrenze von 16 TB für Volume- und Dateigröße bei 4-KB-Clustern. Mit 64-KB-Clustern lässt sich diese Grenze auf 64×16 TB = 1 PB erweitern. Für sehr große Datenbanken (im Dutzend-Terabyte-Bereich und darüber) ist dies relevant, da man mit 4-KB-Clustern sonst an die 16-TB-Grenze stoßen könnte. Fazit zur Fragmentierung: In den allermeisten Umgebungen mit ausreichend großem freien Speicherbereich und vernünftigen Autogrowth-Einstellungen tritt eine kritische Fragmentierung nicht ein. Sollte eine SQL-Server-Datei aber millionenfach fragmentiert sein (etwa bei intensiver Nutzung von NTFS-Deduplication auf einem Backup-Laufwerk oder unsachgemäßer Verwaltung), können größere Cluster hilfreich sein, um NTFS-internen Limits vorzubeugen. Generell gilt: Hat man nur eine (oder wenige) große Datenbank-Datei(n) pro Volume, bleibt diese meist in weiten Zügen zusammenhängend, sodass Fragmentierung im Sinne von Leistungsdegradation kaum ins Gewicht fällt. Anders ist es, wenn zahlreiche Dateien oder konkurrierende Wachstumsprozesse auf demselben Volume existieren – hier empfiehlt sich eher eine Aufteilung (z. B. getrennte Volumes für unterschiedliche Zwecke) als alleiniges Vergrößern der Cluster.

Speicherverwaltung und Overhead: Die Blockgröße beeinflusst auch den Speicherbedarf für Dateisystem-Metadaten. Viele kleine Cluster bedeuten z. B., dass die MFT (bei NTFS) oder die Extent-Listen (bei ext4/XFS) umfangreicher ausfallen, um alle Zuordnungen zu verzeichnen. Dies ist jedoch in modernen Systemen selten ein Engpass, da die Metadatenverwaltung effizient gestaltet ist und ausreichend Speicher vorausgesetzt werden kann. Ein Punkt zu beachten ist die Kompression: NTFS-Dateikompression funktioniert nur mit 4-KB-Clustern. Für SQL-Server-Datenfiles ist NTFS-Kompression allerdings ohnehin nicht gebräuchlich (und auch nicht empfohlen, da sie CPU-Overhead bringt und die I/O-Charakteristik verändert). Somit spielt dieser Aspekt in unserem Kontext keine Rolle außer man beabsichtigt, z. B. Datenbank-Backups auf komprimierten NTFS-Volumes zu lagern – dann müsste man ggf. 4 KB beibehalten.

Ein wichtiger Verwaltungspunkt ist die minimale Allokationseinheit: Bei 64 KB Clustergröße reserviert das Dateisystem stets 64 KB, selbst wenn nur 8 KB geschrieben werden. Allerdings bedeutet dies nicht, dass physisch immer 64 KB geschrieben werden – es wird lediglich der Adressraum reserviert. Bei ungepufferten (Direct I/O-)Schreibvorgängen muss die Anwendung typischerweise auf Vielfache der physischen Sektorgröße ausgerichtet schreiben (meist 512 B oder 4 KB), nicht unbedingt auf die volle Clustergröße. SQL Server schreibt seine 8-KB-Seiten auch auf 64-KB-Volumes, ohne diese künstlich auf 64 KB zu strecken. Dennoch: Sollte ein 64-KB-Cluster bereits teilweise Daten enthalten und eine weitere 8-KB-Seite soll darin platziert werden (z. B. weil zwei Datenbankseiten zufällig in denselben Cluster fallen könnten), müsste das Dateisystem den restlichen Clusterinhalt evtl. erst lesen und mit dem neuen Teil überschreiben – was den Vorteil von Direct I/O konterkarieren könnte. In der Praxis legt NTFS aber unterschiedliche Dateien in separate Cluster und versucht zusammenhängende Extents für ein Dateiobjekt zu nutzen, sodass eine 8-KB-Seite i. d. R. nicht mitten in einem bereits belegten 64-KB-Cluster einer anderen Seite landet. Vielmehr werden extents (bei NTFS 64 KB) auf dem Volume idealerweise auch physisch kontinuierlich abgelegt, insbesondere wenn die Clustergröße 64 KB beträgt. Dadurch wird sichergestellt, dass eine Extent (8 Seiten) innerhalb eines Clusters bleibt und physisch benachbart ist – ein Vorteil, der früher auf HDDs die Zugriffszeiten reduzieren konnte. Kurz gesagt: Im Normalfall entsteht durch 64-KB-Cluster kein erheblicher Lese-Overhead bei 8-KB-Schreibzugriffen innerhalb derselben Datei, solange die Allokation gut geplant ist. Problematisch sind eher Szenarien, in denen viele kleine Dateien (<64 KB) auf einem 64-KB-Cluster-Volume liegen – dort würde jede Datei dennoch 64 KB belegen, was zu Platzverschwendung führt. Für Datenbank-Dateien, die typischerweise groß sind, spielt dies kaum eine Rolle.

1.4 Einfluss von RAID-Leveln und SSD-/NVMe-Technologien

RAID-Level und Stripe Size: Unterschiedliche RAID-Level beeinflussen das I/O-Verhalten. RAID 1 (Mirroring) verdoppelt Schreibzugriffe auf zwei Platten, RAID 5/6 verwendet verteilte Parität, was vor allem bei Partial-Stripes (Schreibzugriff kleiner als ein kompletter Stripe) einen Read-Modify-Write-Vorgang erfordert: Das System muss die existierenden Daten und Paritätsblöcke lesen, modifizieren und zurückschreiben, wenn nicht der gesamte Stripe auf einmal geschrieben wird. Daher lautet eine altbewährte Empfehlung für RAID 5/6: Transaktionslog-Dateien oder andere Schreibmuster, die häufig kleine Schreibpakete senden, sollten nach Möglichkeit so ausgerichtet sein, dass ganzzahlige Vielfache der Stripe-Größe geschrieben werden, um RMW-Overhead zu vermeiden. Beispielsweise, wenn der RAID5-Stripe 128 KB beträgt, ist ein 64-KB-Write immer noch ein halber Stripe (wodurch ein RMW nötig ist), während ein 128 KB Write ein voller Stripe wäre. Allerdings puffern moderne RAID-Controller Schreibzugriffe häufig im Cache und können kleinere Writes sammeln, sodass der Unterschied in der Praxis abgefedert wird – insbesondere wenn ein Battery-Backed-Cache vorhanden ist. Die Blockgröße des Dateisystems spielt hier insofern eine Rolle, als dass sie die maximale Einheit ist, die das Dateisystem ohne Splitting in einem Rutsch an den RAID-Controller gibt. Mit 64-KB-Clustern kann SQL Server theoretisch zusammenhängende Extents in einem Zugriff schreiben, aber er kann das Gleiche auch auf 4-KB-Clustern tun (dann übergibt das System eben mehrere 4-KB-Blöcke direkt hintereinander, was der Controller idealerweise als 64 KB sequenziell verarbeitet). Wichtig ist eher, dass Partition und Cluster an den Stripe ausgerichtet sind (siehe oben). In einem korrekt konfigurierten System mit 64-KB-Stripes und 64-KB-Clustern würde z. B. ein typischer 64-KB-Extent-Schreibzugriff genau auf einen Stripe fallen – mit 4-KB-Clustern könnte derselbe 64-KB-Extent als zusammenhängende 16×4 KB geschrieben werden, was der RAID-Controller im günstigsten Fall als einen zusammenhängenden 64-KB-Block behandelt. Hier ergeben sich in moderner Hardware kaum messbare Unterschiede, sofern nichts misaligned ist. Die oft zitierte Empfehlung „RAID-Stripe 64 KB und Cluster 64 KB“ richtet sich vor allem daran aus, klare Verhältnisse zu schaffen und Fehlkonfigurationen zu vermeiden.

SSDs und NVMe: Solid-State-Drives unterscheiden sich in ihrer Arbeitsweise fundamental von herkömmlichen Festplatten. Zugriffszeiten sind auf SSDs um Größenordnungen geringer, und der Unterschied zwischen wahlfreien und sequentiellen Zugriffen ist deutlich geringer als bei HDDs. SSDs arbeiten intern mit Seiten (typischerweise 4 KB bis 16 KB groß) und bündeln Schreibzugriffe in Blöcken (meist 256 KB oder größer), die beim Löschen physisch gelöscht werden müssen. Moderne NVMe-SSDs können parallel tausende I/O-Operationen verarbeiten und bevorzugen oft sogar viele kleine, parallel verteilte Zugriffe, um ihren internen Controller zu saturieren. In diesem Licht relativiert sich die Bedeutung der Dateisystem-Clustergröße nochmals: Ob das OS 16 einzelne 4-KB-Operationen oder eine 64-KB-Operation absetzt, kann eine flinke NVMe über ihre Warteschlangen meist gleichermaßen effizient bedienen. Der Engpass verlagert sich vom physischen Medium zur Softwareebene – also zum Treiber, Betriebssystem und der CPU. Tatsächlich gibt es Hinweise darauf, dass auf schnellen NVMe-SSDs die CPU-Last für die Verarbeitung vieler kleiner I/Os höher ist als für weniger große I/Os. In diesen Fällen könnte eine größere Clustergröße minimal CPU einsparen, da pro logisch zusammengefasster I/O weniger Overhead entsteht. Allerdings sind auch hier die Unterschiede in praxi gering: In Benchmarks mit SSDs wurden Unterschiede von wenigen Prozent zwischen 4 KB und 64 KB Clustern gemessen, oft innerhalb der Messungenauigkeit. Ein Erfahrungswert aus der Praxis lautet: Auf SSD/NVMe ist die Blockgröße selten der limitierende Faktor – vielmehr sind es Queue-Tiefen, Treiberoptimierungen und die Parallelität der Zugriffe, die über die Performance entscheiden. Daher gilt für SSD-gestützte SQL-Server: Solange die Partitionierung sauber ausgerichtet ist und keine krassen Missverhältnisse auftreten, kann man mit dem Standard (4 KB unter Linux, 4 KB oder 64 KB unter Windows je nach Empfehlung) sehr gute Leistung erzielen. Für den Fall klassischer HDDs hingegen kann eine weise Wahl der Blockgröße dazu beitragen, die Zahl mechanischer Kopfbewegungen gering zu halten. Bei großen sequentiellen Zugriffen auf HDDs bieten 64-KB-Cluster den Vorteil, dass beim Lesen/Schreiben ganzer Extents der Kopf einen zusammenhängenden 64-KB-Block verarbeitet und nicht eventuell zwischen fragmentierten 4-KB-Stücken hin- und her springen muss. Bei zufälligen Zugriffen (wie OLTP auf HDD) hingegen helfen größere Blöcke wenig, denn dort bestimmt die Verteilung der Zugriffe die Bewegung – ob 8 KB oder 64 KB gelesen werden, der Kopf muss so oder so zu der entsprechenden Position. Wenn überhaupt, könnte ein größerer Block bei HDDs etwas Vorteile bringen, indem um einen angeforderten 8-KB-Bereich herum gleich mehr Daten gelesen werden (in der Hoffnung, sie werden gleich benötigt), aber diese Logik übernimmt SQL Server bereits selbst durch Read-Ahead-Strategien für sequentielle Muster.

Zusammengefasst: RAID- und SSD-Technologien stellen andere Anforderungen als früher üblich. Eine pauschale Optimierung allein über die Clustergröße greift zu kurz. Viel wichtiger sind richtiges Storage Alignment (Partitionen und Stripes), ausreichend große Controller-Caches bei RAID, sinnvolle Stripe- und Segmentgrößen in Speichersystemen sowie die Berücksichtigung der I/O-Muster der Anwendung. SSDs entschärfen viele Nachteile kleiner Blockgrößen, da sie ohnehin schnell und parallel arbeiten. Daher wird im Folgenden die Blockgrößen-Frage insbesondere im Zusammenspiel mit dem Betriebssystem und SQL Server betrachtet.

2. Betriebssystemabhängige Unterschiede

Windows und Linux unterscheiden sich in einigen Aspekten der Speicherverwaltung, was auch Einfluss auf die optimale Blockgrößenwahl für SQL Server haben kann. Hier betrachten wir die Standard-Blockgrößen, Caching-Mechanismen und Direct-I/O-Verfahren sowie spezifische Empfehlungen pro Plattform.

2.1 Windows: NTFS vs. ReFS – Standardwerte und Einstellungen

Unter Windows ist NTFS nach wie vor das am weitesten verbreitete Dateisystem für SQL-Server-Installationen. Standardmäßig formatiert Windows ein NTFS-Volume mit 4 KB Clustergröße. Diese Einstellung ist universell und wird vom System auch für viele verschiedene Workloads verwendet (von Betriebssystem-Dateien bis hin zu Benutzerdaten). Für spezielle Anwendungsfälle erlaubt Windows aber, beim Formatieren explizit eine andere Allocation Unit Size anzugeben (z. B. mit format /A:64K für 64 KB). ReFS, als moderneres Dateisystem, wird insbesondere in Verbindung mit neuen Features wie Storage Spaces Direct oder für bestimmte Anwendungen (z. B. Hyper-V VM-Speicher, Backup-Volumes) eingesetzt. ReFS verwendet per Default ebenfalls 4 KB, kann aber alternativ mit 64 KB initialisiert werden.

Die Standardempfehlungen von Microsoft für Windows sind nicht in Stein gemeißelt, haben sich aber in den letzten Jahren konkretisiert. Früher wurde administrativen Leitfäden oft empfohlen, SQL-Server-Daten- und Log-Volumes mit 64 KB zu formatieren, um „die Extents optimal auszunutzen“. Viele offizielle Dokumente und Best Practices trugen diese Empfehlung, die auf SQL Server 2005/2008 und drehenden Platten basierte, mit. So heißt es beispielsweise in einem Microsoft-Whitepaper (zitiert bei NetApp): „Always use the storage vendor’s recommended setting, but if your storage vendor does not have a recommendation, use 64KB.“. Und auch in aktuellen Cloud-Ratgebern, etwa von AWS, findet sich die Aussage: „Auf einem SQL-Server-System sollte die NTFS Allocation Unit Size für Datenbankdateien 64 KB betragen.“. Diese Leitlinie zielt darauf ab, für SQL-Server-Daten, Logs und TempDB eine konsistente, große Blockgröße zu verwenden, die mit der internen Extentgröße übereinstimmt.

Allerdings hat Microsoft selbst bei Einführung von ReFS in Windows Server 2016 gemerkt, dass 64-KB-Cluster nicht generell die beste Wahl sind. In einem TechNet-Blog wurde klargestellt, dass 4 KB für die meisten Deployment-Szenarien die bessere Option ist – insbesondere um I/O-Amplification zu vermeiden. Für NTFS wird ebenfalls generell 4 KB empfohlen, außer in bestimmten Fällen. Welche sind diese Fälle? Laut Microsoft sind Hyper-V, SQL Server, Deduplizierung und allgemein Volumes mit überwiegend großen Dateien prädestinierte Szenarien, wo 64 KB Sinn ergeben kann. Der Grund: Hier arbeitet man oft mit großen, sequenziellen I/Os (z. B. ein VHD/VHDX ist meist mehrere GB groß und wird in umfangreichen Blöcken gelesen/geschrieben, eine Datenbank-Datei ebenso) und man möchte die Fragmentierung gering halten. Hingegen bei gemischten Workloads und kleineren Dateien überwiegen die Vorteile kleinerer Cluster (geringerer Verschnitt, weniger unerwünschte Nebeneffekte bei kleinen Zugriffen).

Direct I/O und Buffering auf Windows: Microsoft SQL Server unter Windows nutzt für seine Daten- und Log-Dateien in der Regel ungepufferte I/O (über die WinAPI-Flags FILE_FLAG_NO_BUFFERING und FILE_FLAG_WRITE_THROUGH). Das bedeutet, dass Lese- und Schreibzugriffe direkt von der Anwendung in den Speicher erfolgen, ohne über den Dateisystem-Cache des Betriebssystems zu gehen. SQL Server übernimmt mit seinem Buffer Pool (dem internen Seiten-Cache) selbst die Caching-Aufgaben und vermeidet so eine doppelte Zwischenspeicherung, die nur unnötig RAM verbrauchen würde. Für ungepufferte I/O unter NTFS gelten gewisse Anforderungen: Die Zugriffspuffer müssen sektoral ausgerichtet und in Vielfachen der Sektorgröße erfolgen (bei klassischen HDDs 512 B, bei Advanced Format und den meisten SSDs 4096 B) – an die Clustergröße muss sich der I/O hingegen nicht zwingend halten. Das heißt, auch wenn das Volume mit 64 KB formatiert ist, kann SQL Server problemlos 8 KB große, ausgerichtete Blöcke direkt schreiben. Die Windows-API sorgt in diesem Modus dafür, dass ein 8-KB-Schreibvorgang genau die betroffenen Sektoren des Clusters modifiziert, ohne den Rest des Clusters (56 KB) unnötig zu bewegen. Dieses Verhalten unterscheidet Windows von ReFS’ internem Mechanismus bei bestimmten Features, da NTFS in Standardkonfiguration keine Prüfsummen oder Copy-on-Write-Mechanismen hat, die ein vollständiges Neuschreiben des Clusters erzwingen würden. Daher kann man unter Windows relativ gefahrlos auch größere Cluster einsetzen, ohne massive I/O-Amplification bei kleinen SQL-Server-Zugriffen zu erleiden – was einer der Gründe ist, warum 64 KB hier lange als Best Practice galten. Die Kehrseite: Sollte doch einmal gepufferter Zugriff stattfinden (etwa ein Virenscanner, Backup-Agent oder anderes Tool, das die Dateien ohne NO_BUFFERING öffnet), könnten bei 64 KB Cluster kleinere Zugriffe intern zu größeren Lesezugriffen führen. In SQL-Server-typischen Abläufen bleibt dies aber meist aus. Zusammengefasst lässt sich sagen, dass Windows flexibel im Umgang mit der Clustergröße ist: Der SQL-Server-Buffer-Pool übernimmt das Caching, und Direct I/O sorgt dafür, dass Datenbankzugriffe direkt auf dem Medium landen, wobei der Cluster als Allokations-, nicht aber als minimale Transfergröße dient (Diskettenlaufwerke ausgenommen, dort war es mal relevant).

2.2 Linux: ext4 vs. XFS – Blockgrößen und Direct I/O

Unter Linux ist SQL Server ein vergleichsweise neues Phänomen (SQL Server on Linux gibt es seit 2017). Microsoft hat für SQL Server auf Linux von Anfang an einige Empfehlungen ausgesprochen, die teils von Windows abweichen. So wird offiziell XFS als bevorzugtes Dateisystem für SQL-Server-Daten und -Logs empfohlen (zumindest für Kernel < 5.6; ab 5.6 kann auch ext4 verwendet werden, falls gewünscht). XFS und ext4 haben – wie oben beschrieben – in der Praxis eine feste Blockgröße von 4 KB auf gängigen Systemen. Eine Änderung dieser Blockgröße ist nicht trivial und wird von Standard-Distributionen nicht unterstützt (Versuche, XFS mit 64 KB zu formatieren, schlagen mit einem „Function not implemented“ fehl, weil der Kernel das Mounten solcher Dateisysteme verweigert). Dementsprechend stellt sich unter Linux die Frage „4 KB oder 64 KB?“ in der Praxis nicht – es bleibt bei 4 KB. Dennoch gibt es Stellschrauben: Bei der Einrichtung von Software-RAID (z. B. mit mdadm) kann man die Chunk-Größe (Stripe) angeben, und beim Anlegen des Dateisystems können z. B. bei XFS die Stripe-Unit und Stripe-Width passend gesetzt werden, um das Alignment zu optimieren. Beispiel: Sechs SSDs in RAID 10 mit 64 KB Stripe-Size – hier sollte man XFS mit einer Stripe Unit (sunit) von 16 Blöcken à 4 KB (16×4 KB = 64 KB) und einer Stripe-Width (swidth) von 48 Blöcken (3 Datenlaufwerke à 16 Blöcke) formatieren. Diese Parameter sorgen dafür, dass XFS seine Schreibmuster auf die RAID-Geometrie abstimmt. Für ext4 können beim Formatieren ähnliche Optionen genutzt werden (z. B. -E stride=<…>,stripe-width=<…>). Wichtig festzuhalten: Die tatsächliche Blockgröße des Dateisystems bleibt 4 KB; es werden lediglich interne Optimierungen vorgenommen.

Direct I/O auf Linux: SQL Server unter Linux nutzt ebenfalls einen eigenen Buffer Pool und vermeidet standardmäßig den Linux-Seitencache, um doppelte Caching-Ebenen zu umgehen. In frühen Versionen von SQL on Linux wurde anfangs der Weg über O_DSYNC (synchrones Schreiben) gewählt, inzwischen unterstützt das System auch O_DIRECT in Kombination mit so genanntem FUA (Forced Unit Access). Das bedeutet, dass Schreibzugriffe vom SQL Server direkt an das Blockdevice durchgereicht und bis auf das physische Medium persistiert werden, ohne im Cache hängen zu bleiben. Damit dies effizient funktioniert, muss das zugrundeliegende System FUA unterstützen (neue Kernel und moderne Storage-Geräte tun dies). In der Praxis heißt das: Ist SQL Server auf einem unterstützten System (z. B. RHEL8+, SLES12 SP5+, Ubuntu 18.04+ mit entsprechendem Kernel) und verwendet XFS oder ext4, dann konfiguriert man in mssql.conf in der Regel control.writethrough=1 und nutzt den Standard-Traceflag 3982 (bzw. schaltet 3979 aus), sodass das optimale I/O-Modell greift.

Für unser Thema – die Blockgröße – bedeutet dies: Auch unter Linux umgeht SQL Server weitgehend den Dateisystem-Cache und operiert mit direkten 8-KB-Lese-/Schreibzugriffen. Ext4 und XFS verlangen bei O_DIRECT ebenfalls, dass die I/O-Größen und Ausrichtungen zu ihrer internen Blockgröße passen. Da 8 KB ein Vielfaches von 4 KB ist, ist dies erfüllt. Wäre theoretisch ein Dateisystem mit 64 KB Blockgröße im Einsatz, würden 8 KB Zugriffe nicht den Anforderungen entsprechen und fehlschlagen oder müssten aufwändig gehandhabt werden – daher sieht man hier auch, warum Linux praktisch immer 4 KB nutzt.

Unterschiede in der Praxis: Zusammengefasst sind Windows und Linux in Bezug auf die Blockgröße auf unterschiedlichen Pfaden: Windows lässt Wahlfreiheit (4 KB vs. 64 KB) und historisch wurden 64 KB gern genutzt, Linux bleibt bei 4 KB. Dennoch berichtet die Praxis, dass SQL Server auf Linux keine Nachteile dadurch hat. Die I/O-Größen des SQL Servers werden auch auf Linux optimal gehandhabt, und Benchmarks zeigen gleichwertige Performance. Microsoft selbst gibt als Best Practice für Linux an, XFS zu verwenden und dort standardmäßig – implizit – 4 KB Blöcke zu nutzen, ohne einen Bedarf zur Änderung der Blockgröße zu sehen. Stattdessen wird der Fokus auf andere Optimierungen gelegt: noatime-Option setzen, genügend offene Dateien erlauben (Limits erhöhen), und die erwähnte Ausrichtung der RAID-Parameter. Die Blockgröße ist somit unter Linux ein fixes Fundament, auf dem man aufbaut, während sie unter Windows ein optionaler Tuning-Parameter ist.

Buffer Pool und Speicherverwaltung: Sowohl unter Windows als auch Linux gilt, dass der SQL Server den größten Teil des aktiven Datenbestands im Buffer Pool vorhält (sofern genügend RAM vorhanden ist). Die Effekte der Dateisystem-Blockgröße wirken sich also primär auf die physischen I/O-Vorgänge aus, die den Buffer Pool füllen oder entleeren, nicht jedoch auf die In-Memory-Verwaltung der Datenbankseiten. Der Buffer Pool organisiert sich in 8-KB-Seiten; die Blockgröße des darunterliegenden Volumes ist dafür transparent. Lediglich bei Aktionen wie der Initialisierung von Datenbanken, dem Wachstum von Dateien oder dem Auslagern sehr großer Datenmengen spielt die physische Ablageform eine Rolle.

Zwischenfazit OS-Ebene: Windows ermöglicht es, mit 64-KB-Clustern zu arbeiten und so theoretisch eine optimale physische Abbildung der SQL-Extent-Struktur zu erreichen, wohingegen Linux-konforme Dateisysteme auf 4 KB festgelegt sind. Die tatsächlichen Leistungsunterschiede sind aber gering, da beide Betriebssysteme Mittel bereitstellen, effizient mit den gegebenen Blockgrößen umzugehen. In keinem der beiden Fälle sollte man von den Standardwerten abweichen, ohne triftigen Grund und gründliche Tests – zu diesem Schluss kommen wir auch im Lichte der SQL-Server-spezifischen Betrachtungen im nächsten Abschnitt.

3. SQL Server-spezifische Aspekte der Blockgröße

In diesem Abschnitt beleuchten wir, wie verschiedene I/O-Muster von SQL Server mit der Blockgröße interagieren, und welche Überlegungen sich für Daten-, Log- und TempDB-Dateien ergeben. Außerdem betrachten wir, was Microsoft offiziell empfiehlt und was Erfahrungen aus der Praxis zeigen.

3.1 Typische I/O-Muster: OLTP vs. OLAP/DW

OLTP (Online Transaction Processing): OLTP-Datenbanken sind durch viele gleichzeitige, kleine Transaktionen gekennzeichnet – z. B. Banking-Systeme, Onlineshops, Ticketing usw. Die I/O-Charakteristik eines OLTP-Workloads besteht aus überwiegend zufälligen Lese- und Schreibzugriffen kleiner Größe. Bei Lesevorgängen sind es oft einzelne 8-KB-Seiten (Index- oder Datenseiten), die benötigt werden, weil eine Abfrage punktuell auf einen Datensatz zugreift. Mehrseitige Read-Aheads kommen zwar auch vor (z. B. beim Scannen eines kleinen Indexes oder Vorladen von Seiten bei Bereichsanfragen), aber dominierend sind die Random 8K IOPS. Schreibvorgänge im OLTP erfolgen zunächst im Speicher (Änderungen an Seiten im Buffer Pool) und werden asynchron auf Disk geschrieben (durch Checkpoints, Lazy Writer, etc.), aber jede Transaktion erzeugt auch einen Log-Eintrag. Der Transaction Log wird sequentiell beschrieben, allerdings in variabler Größe: kleine Transaktionen können Log Records von wenigen hundert Byte verursachen, große Transaktionen (etwa eine Massenänderung) füllen ggf. mehrere zig Kilobyte. SQL Server bündelt Logeinträge in sogenannten Logblöcken, typischerweise bis zu 60 KB groß, bevor sie auf den Datenträger geschrieben werden. Daher beobachten Monitoring-Tools beim Logfile meist Schreibgrößen zwischen 512 B und 60 KB – mit einem Peak um die 60 KB. Aufgrund dieses Musters wird oft argumentiert, dass 64-KB-Cluster ideal sind: Sie decken den größten Log-Schreibvorgang ab und sind groß genug, um alle 8-KB-Seiten eines Extents in einem Stück zu beherbergen. Kritiker wenden jedoch ein, dass ein 64-KB-Cluster nicht verhindert, dass SQL Server auch mal nur 8 KB liest oder schreibt. Das System kann weiterhin random auf Einzelpages zugreifen, und es wird das auch tun, wenn ein bestimmter Index-Lookup genau eine 8-KB-Seite benötigt – ungeachtet der Clustereinstellung. Tatsächlich zeigen Telemetriedaten, dass selbst bei 64-KB-Clustern im OLTP-Betrieb die meisten I/Os um 8 KB groß bleiben. Die Blockgröße wirkt sich also im OLTP-Szenario vor allem auf den Overhead aus: Mit 4-KB-Clustern könnte man befürchten, dass ein 64-KB-Extent physisch nicht zusammenhängend liegt und deshalb 8 separate I/Os erfordert – die Realität ist jedoch, dass NTFS (bei Windows) Extents in zusammenhängende Runs legt und bei Linux ext4/XFS interne Extents ebenfalls sequentiell sind. Somit werden 8 aufeinander folgende 4-KB-Blöcke meistens als ein größerer Transfer gelesen, sofern das System dies anfordert. Im OLTP-Einzelfall fordert es das aber gar nicht an, sondern liest die 8 KB und fertig. Ergo: OLTP-Leistung wird primär von Faktoren wie Latenz des Speichers, IOPS-Kapazität und Buffer-Hitratio bestimmt. Die Clustergröße spielt eine untergeordnete Rolle, solange keine extrem unpassende Wahl getroffen wurde (z. B. 64 KB auf einem System, das dadurch I/O-Amplification erfährt – etwa ReFS auf einem tiered Space). Die meisten OLTP-Installationen auf Windows laufen dennoch traditionell mit 64-KB-NTFS-Clustern, weil dies ein “Best Practice” war, das selten schadet und im Einzelfall leicht Vorteile bringen konnte (z. B. minimal weniger NTFS-Metadatenlast). Auf Linux bleiben OLTP-Systeme bei 4 KB und erreichen ebenfalls Spitzenleistungen.

OLAP/DW (Analytische Workloads, Data Warehouse): Ein Data Warehouse oder OLAP-System ist darauf optimiert, große Datenmengen zu laden und abzufragen, oft in Form von komplexen Aggregationen, Scans über ganze Tabellen oder Partitionen, und unter Nutzung von Spaltenindizes (Columnstores) etc. Die I/O-Muster hier sind stark von sequentiellen Lesezugriffen geprägt. Wenn ein Report etwa alle Verkäufe des letzten Jahres summiert, liest die Datenbank (vereinfacht gesagt) eine große Faktentabelle seitenweise durch. SQL Server nutzt dabei Read-Ahead Reads: Er erkennt den sequentiellen Zugriff und initiiert vorausschauend Leseoperationen von bis zu 512 KB am Stück. Das heißt, solange die Daten auf dem Volume physisch einigermaßen zusammenhängend liegen, wird SQL Server 64 KB, 128 KB oder noch größere Blöcke pro I/O laden, um effizient zu sein (er kann bis zu 512 KB pro Einzel-Leseoperation und pro Datendatei abfragen). Auch Bulk-Loads, Index-Builds oder Backups arbeiten mit großen Blockgrößen (meist 1 MB bei Backups). In solchen Fällen kann eine größere Dateisystem-Blockgröße hilfreich sein: Zum einen reduziert sie – wie erwähnt – die Anzahl der Extents, die eine große Datei besitzt, und verringert damit die Notwendigkeit, häufig zwischen Extents zu springen. Zum anderen passt sie gut zu dem Muster, dass ohnehin große Brocken übertragen werden. Wenn eine Datenbankabfrage z.B. 256 KB auf einmal lesen möchte, muss das Betriebssystem bei 4-KB-Clustern sicherstellen, dass 64 zusammenhängende Cluster vorhanden sind. Sind sie physisch fragmentiert, könnte das mehrere einzelne I/Os bedeuten (was die Latenz erhöht). Bei 64-KB-Clustern hingegeben wären es nur 4 Cluster, die für 256 KB gelesen werden – ist auch davon vielleicht einer fragmentiert, steigt die Chance, dass der Großteil immer noch an einem Stück kommt. Insgesamt aber gilt: Sequentielle Zugriffe profitieren vor allem von physischer Kontiguität, und diese wird eher durch gute Datenpflege (z. B. Rebuilding von Indexes oder Partitionierung) und geeignete Volume-Zuordnung erreicht als durch die Clustergröße allein. Die Clustergröße kann maximal dazu beitragen, dass ein zusammenhängender logischer Extent auch zusammenhängend physisch abgebildet wird. Auf modernen Speichersystemen (insbesondere SSD/NVMe) ist das Sicherheitsnetz, das 64-KB-Cluster einst für HDDs boten, jedoch weniger relevant, weil wie bereits ausgeführt die Medien anders arbeiten. Nichtsdestotrotz entscheiden sich viele Admins bei reinen Data-Warehouse-SQL-Servern unter Windows für 64 KB, in der Annahme, damit nichts falsch machen zu können, was durch Microsofts Nennung dieses Szenarios als Beispiel untermauert wird.

In der Kombination mehrerer Workloads – etwa ein OLTP-System mit zusätzlichen Reporting-Abfragen oder ein Mischbetrieb – sieht man gemischte I/O-Muster. Hier laufen sowohl kleine zufällige als auch große sequentielle I/Os. Eine gewählte Clustergröße von 64 KB hat in so einem Fall den Vorteil, große I/Os gut abzubilden, und den möglichen Nachteil, kleine I/Os mit etwas mehr Overhead zu behandeln (was aber, wie wir sahen, meist minimal ist). 4 KB wiederum hätte den Vorteil für kleine, aber könnte in absoluten Ausnahmefällen sequentielle Abläufe minimal bremsen – wobei auch das oft nur theoretisch ist, sofern die OS und Hardware die Sequenzen erkennen.

3.2 TempDB, Daten- und Log-Dateien: Besondere Überlegungen

TempDB: Die TempDB ist eine Systemdatenbank, die temporäre Objekte und Zwischenresultate aufnimmt. Sie wird oft intensiv genutzt – beispielsweise für Sortiervorgänge, Hash-Joins, temporäre Tabellen, Versionierungsinformationen (Snapshot Isolation) u.v.m. TempDB zeichnet sich durch hochgradig zufällige und konkurrierende I/O-Zugriffe aus, da viele Sessions parallel darauf zugreifen. Zudem wird TempDB bei jedem SQL-Server-Neustart geleert und neu initialisiert. In puncto Blockgröße gilt für TempDB dasselbe wie für OLTP-ähnliche Workloads: die meisten Zugriffe sind klein (Seitenzugriffe), aber es können auch bursts von größeren sequentiellen I/Os auftreten (z. B. wenn ein großer Sort eine Temp-Tabelle schreibt und dann sequentiell ausliest). Microsoft empfiehlt – analog zu Datenfiles – auf Windows tendenziell auch TempDB-Volumes mit 64 KB zu formatieren. Da TempDB kein Persistenzziel im klassischen Sinn ist und man sie üblicherweise nicht mit NTFS-Kompression o. ä. betreibt, spricht nichts gegen 64 KB. Viele Admins behandeln TempDB sogar priorisiert, indem sie dieser eine eigene, schnelle Speicher-LUN mit 64-KB-NTFS geben. Unter Linux verbleibt es bei 4 KB (da XFS), was ebenfalls in vielen internen Benchmarks gut performt hat. Wichtig für TempDB ist eher die Konfiguration an sich (mehrere Datenfiles, Verteilung auf Storage-Devices etc.) als die Clustergröße – diese hat keine speziellen Auswirkungen über das bereits Besprochene hinaus.

Daten-Dateien (.mdf/.ndf): Dies sind die Hauptdatenbanken-Dateien, in denen Tabellen, Indizes, etc. gespeichert sind. Sie werden gemischt gelesen und geschrieben. In Datenfiles spielen sowohl die random I/Os (z. B. Indexzugriffe) als auch die sequentiellen (z. B. Table-Scans, Indexwartung) eine Rolle. Ein Aspekt bei Datenfiles: Autogrowth-Ereignisse. Wenn eine Datenbank-Datei wächst, reserviert SQL Server neuen Speicherplatz im Dateisystem. Bei Instant File Initialization (die bei entsprechender Rechtevergabe meistens aktiv ist) geht das ohne das neue Segment mit Nullen zu füllen – es wird einfach dem Dateisystem signalisiert, dass die nächsten X MB dem Dateiobjekt gehören. Diese neu allokierten Bereiche sind in NTFS jeweils mindestens einen Cluster groß. Mit 64-KB-Clustern wächst die Datei also in 64-KB-Schritten (oder einem ganzzahligen Vielfachen davon) auf Dateisystemebene. Mit 4-KB-Clustern entsprechend in 4-KB-Schritten. SQL Server selbst wächst typischerweise in MB-Schritten (konfigurierbar), sodass in beiden Fällen viele Cluster auf einmal hinzukommen. Hier kann 64 KB minimal helfen, die Anzahl Einträge in der MFT für den neuen Bereich zu reduzieren (ein 8 MB Wachstum sind 128 Cluster à 64 KB statt 2048 Cluster à 4 KB). Das ist aber ein sehr geringer Effekt und spiegelt sich selten in spürbarer Performance wider.

Log-Dateien (.ldf): Transaktionslog-Dateien werden sequentiell beschrieben und (bei Sicherungen oder Replikation) sequentiell gelesen. Sie profitieren am stärksten von guter Schreiblatenz und Durchsatz. Eine 64-KB-Clustergröße passt exakt zur maximalen üblichen Log-Schreibgröße (~60 KB). Daher ist hier der Konsens, dass 64 KB eine sinnvolle Wahl auf Windows ist – es gibt keine kleinen random Reads im Log (außer evtl. bei Wiederherstellung oder wenn der Log mal von bestimmten Tools gescannt wird, was aber selten ist). Der Lesemodus beim Backup liest oft in größeren Blöcken (z. B. 4 MB am Stück). Mit 4-KB-Clustern macht das auch keine Umstände, solange die Datei nicht fragmentiert ist. Mit 64-KB-Clustern ist es analog. Tests von Speicherherstellern (wie NetApp) haben ergeben, dass bei 8-KB-Zugriffen (simuliert für random I/O) und 64-KB-Zugriffen (für sequenzielle I/O) der Unterschied zwischen 4-KB und 64-KB-Cluster praktisch vernachlässigbar war – im Bereich weniger Prozentpunkte. Dennoch: Da das Transaktionslog tendenziell linear gefüllt wird und oft auf dedizierten Volumes liegt, kann man es unter Windows ohne Bedenken mit 64 KB formatieren. Microsoft betont auch diese Empfehlung in vielen Best Practices. Der Sicherheitsaspekt (z. B. Ausfallsicherheit, dass kein RMW bei RAID5 stört) kommt hinzu – falls ein logisches Log-Schreibpaket auf zwei physische Sektoren verteilt wäre (durch Missalignment), hätte das negative Folgen. Mit 64-KB-Clustern stellt man sicher, dass – sofern das Volume auf 4-KB-Sektoren ausgerichtet ist – solche Schreibpakete schön im Block bleiben.

In Summe lassen sich für Windows diese SQL-File-Typ-Empfehlungen geben: Datenfiles und TempDB – 64 KB bevorzugt, aber 4 KB geht auch (unterschiedliche Empfehlungen je nach Quelle); Logfiles – 64 KB bevorzugt. Für Linux gilt: Alles bleibt auf 4 KB, da ext4/XFS und das System das so handhaben. Microsoft erwähnt hier keinen Workaround, sondern zeigt durch Benchmarks und Vorgaben, dass man sich auf die Standardwerte verlassen kann.

3.3 Empfehlungen von Microsoft und praktische Erfahrungswerte

Microsoft-Empfehlungen: Offiziell kommuniziert Microsoft in verschiedenen Dokumentationen ein etwas differenziertes Bild. Für Windows/NTFS gibt es Dokumente (z. B. im Zusammenhang mit Exchange oder SQL) mit dem Tenor: „Wenn der Speicheranbieter keine anderslautende Empfehlung hat, formatieren Sie mit 64 KB“. Speziell für SQL Server auf Azure VMs oder AWS EC2 wird häufig 64 KB angeraten. Hingegen hat das Windows Storage-Team wie erwähnt klargestellt, dass 4 KB generell vorzuziehen sind, außer in Fällen großer Dateien/Sequenz-I/O. Die SQL Server Produktsparte hat selbst keine aktuelle Publikation, die 4 vs 64 KB ausführlich diskutiert – man verlässt sich teils auf überlieferte Best Practices. Allerdings finden sich in neueren Performance-Tunings (z. B. SentryOne oder Pure Storage Blogs) Stimmen, die sagen: Die meisten modernen SQL Server I/Os passieren nicht in 64-KB-Blöcken, daher ist die alte 64K-Empfehlung nicht mehr so ausschlaggebend. Microsoft selbst streicht aber die Empfehlung nicht völlig – vielmehr sagt man, es schadet nicht, 64 KB zu nutzen, um gewisse theoretische Vorteile (Extent-Abbildung, weniger NTFS-Fragmente) zu haben, und in anderen Fällen sollte man dem Storage Vendor vertrauen. Beispielsweise formatieren gewisse Storage-Management-Tools von NetApp automatisch mit 4 KB (Standard), worauf Microsoft erwidert hat: „Das widerspricht nicht unseren Empfehlungen – wenn der Hersteller 4 KB vorschlägt, folgt dem; sonst 64 KB.“. Für Linux findet sich in Microsoft Learn und Release Notes keine Aufforderung, an der Blockgröße zu drehen – vielmehr eben die Empfehlung XFS nutzen, noatime setzen und ggf. ab Kernel 5.6 ext4 als Alternative. Hier steht also 4 KB indirekt außer Frage.

Praktische Erfahrungen: Aus der Praxis – insbesondere aus Datenbank-Foren und Expertenblogs – lassen sich folgende Erkenntnisse ziehen:

• Minimale Performanceunterschiede: Wie bereits angeführt, zeigen Tests in echter Umgebung oft keinen signifikanten Unterschied zwischen 4 KB und 64 KB Cluster bei SQL-Workloads auf moderner Hardware. Viele Administratoren berichten, dass beim Umstellen eines bestehenden Systems von 4 KB auf 64 KB (oder umgekehrt) keine messbare Verbesserung oder Verschlechterung auftrat, solange alle anderen Faktoren unverändert blieben. In Einzelfällen konnte eine leichte Reduktion der CPU-Last festgestellt werden, wenn 64-KB-Transfers statt vieler 4-KB-Transfers genutzt wurden – dies hängt aber stark vom Storage-Subsystem und dessen Treibern ab.
• HDD vs. SSD: In Umgebungen mit rein mechanischen Festplatten (z. B. ältere SANs, lokal gebundene HDD-JBODs für Archivsysteme o. ä.) konnten größere Cluster geringfügige Vorteile bei sequentiellen Auswertungen bringen, weil die Daten tendenziell zusammenhängender lagen und der Plattenkopf seltener übers MFT flattern musste. Mit dem Wechsel auf SSDs sind diese Unterschiede nahezu obsolet geworden, da der Hauptkostentreiber – die Positionierungszeit – wegfällt, und SSD-Controller frei logische LBA-Bereiche abarbeiten.
• Fragmentierung und Stabilität: Einige Administratoren großer Datenbanken (>10 TB) haben berichtet, dass NTFS-Volumes mit 4-KB-Clustern nach Jahren intensiver Nutzung und vielen Autogrowth-Zyklen eine erhebliche Anzahl Fragmente in den MDFs aufwiesen. In seltenen Fällen stieß man wohl sogar ans erwähnte 1,5-Millionen-Extent-Limit, was sich durch merkwürdige Fehlermeldungen oder Inconsistencies äußerte. Nach Reformatierung mit 64 KB traten diese Probleme nicht mehr auf, da die Struktur robuster war (weniger Extents). Dies sind jedoch sehr spezielle Fälle und oft in Umgebungen, wo Datenbanken nicht regelmäßig neu organisiert oder gewartet wurden. Für die Mehrzahl der Produktionssysteme ist das kein Thema.
• Backup und Maintenance: Beim Sichern großer Datenbanken (z. B. 1 TB Backup auf ein NAS) hat man mit 64-KB-Volumes beobachtet, dass die Auslastung etwas gleichmäßiger war. Das kann aber auch Zufall oder caching-bedingt sein. SQL Server Backups nutzen 1 MB Transfers, die vom OS dann in entsprechend viele Cluster unterteilt werden. Ein 1-MB-Backup-Lesezugriff würde auf 4-KB-NTFS 256 Cluster umfassen, auf 64-KB-NTFS 16 Cluster. Beide Varianten kann Windows in einem einzelnen IO anfordern, solange sie fortlaufend sind. Hier hat allenfalls NTFS intern weniger Verwaltungsarbeit bei 16 Clustern vs. 256. In Summe sind Unterschiede minimal. Tools wie SQLIO oder DiskSpd wurden oft bemüht, um 4K vs 64K zu vergleichen; die Ergebnisse waren meist unspektakulär, außer man hat unrealistische Extreme getestet (z. B. Millionen winziger Dateien, wo 64 KB viel Platz verschwendet hätte, oder ein vollkommen fragmentiertes Volume, wo 64 KB noch ein wenig half).
• Heutiger Trend: Immer mehr Expertenmeinungen gehen dahin, dass die Blockgröße eine untergeordnete Rolle spielt und man sich mehr auf IOPS-Kapazität, Latenzen, NVMe-Nutzung und Datenbankdesign konzentrieren sollte. Das heißt nicht, dass man die Frage ignorieren soll – aber wenn ein System mit Standard 4 KB problemlos läuft, gibt es selten einen zwingenden Grund, alles auf 64 KB umzuformatieren. Umgekehrt, wenn man neu aufsetzt und Best Practices folgen will, schadet 64 KB auf Windows nicht, sofern keine Nutzung von NTFS-Kompression, Volume Shadow Copy o. ä. geplant ist. Wichtig ist: Konsistenz und Vermeidung von Fehlkonfigurationen. Beispielsweise sollte man nicht für ein 2-Volume-Setup (Daten und Logs getrennt) eines mit 4 KB und eines mit 64 KB formatieren ohne Grund – das erzeugt unnötige Varianz und potentielle Verwirrung beim Performance-Troubleshooting. Besser ist, eine Linie zu fahren, es sei denn es gibt einen klaren Anlass, differenziert vorzugehen.

Nach dieser allgemeinen Einordnung richten wir den Blick nun auf konkrete Empfehlungen für bestimmte Szenarien.

4. Praxisorientierte Einsatzszenarien

In diesem Abschnitt übertragen wir die bisherigen Erkenntnisse auf typische Einsatzszenarien und geben Empfehlungen, welche Blockgrößen-Einstellung jeweils sinnvoll ist. Dabei betrachten wir OLTP-Systeme, Data-Warehouse/Analytics-Systeme, virtualisierte Umgebungen sowie den Betrieb mit spezialisierten oder verteilten Speichersystemen (SAN, NAS, Storage Spaces Direct, Cloud Storage).

4.1 Optimale Blockgröße für OLTP-Systeme

Charakteristik: OLTP-Datenbanken (z. B. für ERP, CRM, E-Commerce) stellen hohe Anforderungen an Antwortzeiten und Transaktionsdurchsatz. I/O ist meist Random-I/O, lotsenweise in 8 KB Schritten, wie zuvor dargelegt.

Empfehlung: Für OLTP-Workloads kann man im Prinzip mit der Standard-Blockgröße von 4 KB arbeiten – sowohl unter Windows als auch unter Linux. Die feinkörnige Allokation verhindert unnötige I/O-Amplification, da viele kleine Writes (typisch für OLTP) so nur kleine Einheiten betreffen. Microsoft betont bei ReFS (das in einigen S2D-Szenarien auch für OLTP empfohlen wird) ausdrücklich, dass 4 KB Standard sein soll, um die Kosten kleiner Schreibzugriffe gering zu halten. Unter NTFS hat sich zwar historisch 64 KB durchgesetzt, aber aktuelle Untersuchungen (z. B. von AWS für OLTP auf EC2) zeigen keinen Vorteil davon. Daher ist es legitim, auch auf Windows-Servern, die reinen OLTP-Workload tragen, 4 KB zu formatieren.

Aber: Wenn bereits eine Umgebung mit 64 KB existiert (viele ältere Installationen), muss man keineswegs panisch zurück ändern – 64 KB funktioniert ebenfalls gut für OLTP, wie die Praxis beweist. Es gibt keinen Hinweis, dass 64 KB Cluster bei OLTP messbare Nachteile bringen, solange keine speziellen ReFS-Szenarien vorliegen. Eher im Gegenteil, anekdotisch berichten manche Administratoren minimal bessere CPU-Last-Werte bei 64 KB, weil weniger File System Overhead pro I/O-Einheit anfällt. Diese Unterschiede sind jedoch meist gering.

Vorgehen bei Neuimplementierung: Wenn man ein neues OLTP-System aufsetzt und volle Kontrolle hat, kann man unter Windows entweder dem konservativen Pfad folgen und 64 KB setzen („das machen wir immer so bei SQL“), oder dem progressiven Pfad und 4 KB belassen (nach dem Motto „vor Problemen gefeit und von MS Storage empfohlen“). Wichtig ist konsequentes Handeln: Formatiert man z. B. C: (System) mit 4 KB und D: (SQL-Daten) mit 64 KB, sollte man aufpassen, dass TempDB oder andere DB-Komponenten, sofern sie mal auf C: ausgelagert werden, nicht durcheinander geraten. In der Regel liegen aber alle DB-relevanten Dateien auf separaten Volumes. Unter Linux ist die Frage obsolet – ext4/XFS bleiben bei 4 KB, was sich in Tests als völlig ausreichend erwiesen hat. Als DBA sollte man hier lediglich sicherstellen, dass genügend IOPS vom Storage bereitgestellt werden und die Latenz niedrig ist; die Blockgröße selbst kann man getrost dem Standard überlassen.

Monitoring-Tipp: Beobachten Sie ein OLTP-System mit PerfMon (Windows) oder iostat/blktrace (Linux) bezüglich der I/O-Größen. In vielen Fällen werden Sie sehen, dass der Großteil der Reads/Writes bei ~8 KB liegt. Daraus lässt sich schließen, dass eine größere Clustergröße nicht ausgenutzt wird (weil selten 64 KB am Stück angefordert werden). Falls Sie feststellen, dass doch sehr häufig größere I/Os auftreten (z. B. wegen periodischer Reports), könnten Sie dies berücksichtigen – aber das wäre dann eher ein hybrider Workload.

4.2 Optimale Blockgröße für Data Warehouse / Analytics

Charakteristik: Data-Warehouse-Systeme (OLAP) verarbeiten Massendaten, typischerweise in Batch-Läufen, ETL-Prozessen und großen analytischen Abfragen. Sie nutzen oft Features wie Partitionierung, Columnstore-Indizes und haben relativ wenige gleichzeitige User, aber hohe Einzelabfrage-Last.

Empfehlung: Für reine DW/OLAP-Server kann eine größere Clustergröße (64 KB) vorteilhaft sein, insbesondere unter Windows. Gründe: Die vorherrschenden Zugriffe sind sequentiell und groß, so dass 64-KB-Cluster keinerlei Nachteile bei Random-I/O bringen (es gibt kaum random Writes kleiner 64 KB) und potenziell die Fragmentierung des großen Datenbestands reduzieren. Microsoft nennt große, sequentielle Workloads explizit als Einsatzgebiet für 64K-Cluster, gerade auch bei ReFS/NTFS. Praktisch bedeutet das: Wenn Sie einen Server betreiben, der primär als Datenmart oder Reporting-DB fungiert, können Sie die Volumes für Fakten- und Dimensionsdatenbanken mit 64 KB formatieren.

Linux-seitig bleibt es bei 4 KB (XFS), aber hier sei erwähnt, dass XFS sehr gut mit großen Dateien umgehen kann und ext4 ab Kernel 5.6 auch in Ordnung ist. Sie werden auf Linux DWH-Systemen ebenfalls gute Performance mit Standard 4 KB erleben, solange andere Faktoren stimmen (etwa mount-Option noatime, genügend Disk-Bandbreite). Sollte Linux auf die Idee bringen, in Zukunft größere Blockgrößen zuzulassen (z. B. auf Systemen mit 64-KB-Pages), könnte man neu evaluieren, aber Stand 2025 ist das kein verbreitetes Szenario.

Besondere Überlegungen: Wenn Ihre DWH-Datenbank extrem groß ist (mehrere zig Terabyte), prüfen Sie die NTFS 16-TB-Limit-Thematik – ab 4 KB könnte man an Grenzen stoßen, ab 64 KB hebt man sie auf 64 TB pro Datei. Ist Ihr DWH z. B. 20 TB groß, müssten Sie bei 4 KB Cluster die Partition womöglich mit format /L (große MFT) formatieren, oder gleich 64 KB nehmen, um über 16 TB zu kommen. Auch Partitionierung der DB selbst (in mehrere Dateien) wäre eine Option, aber mit 64 KB umgeht man elegant das Problem.

Columnstore-Indizes in DWH lesen intern auch in recht großen Einheiten (segmentweise). Hier könnte man argumentieren, 64 KB sei „natürlicher“. Allerdings fehlen uns konkrete Daten, dass 4 KB dort schaden – Columnstore-Zugriffe werden sequentiell als large I/O ausgeführt, also kann NTFS auch mit 4 KB Clustern 256 KB am Stück liefern, wenn die Segmente contiguous sind.

Conclusion für DW: Unter Windows: Tendenz zu 64 KB, unter Linux: 4 KB (Standard, keine Wahl). Letztlich gilt aber: Wichtiger als die Clustergröße sind genügend Durchsatz (MB/s) und I/O-Parallelität. Ein DWH sollte auf breite Speicherpfade (z. B. RAID 10 mit vielen Spindeln oder entsprechende SSD-RAIDs) setzen. Die Clustergröße allein wird kein Bottleneck sein, sofern Alignments passen.

4.3 Virtualisierte Umgebungen (z. B. VMware, Hyper-V)

Herausforderung: In virtualisierten Umgebungen gibt es oft mehrere Ebenen von „Dateisystemen“ bzw. Abstraktionen. Beispielsweise bei VMware ESXi liegt ein VMFS-Dateisystem auf dem Shared Storage, darauf eine VMDK-Datei als virtueller Datenträger, innerhalb der VM ein NTFS, und darin der SQL Server. Bei Hyper-V ähnlich: eine CSV oder ein NTFS auf dem Host, darin VHDX-Dateien, in der VM wiederum NTFS. Dieses Stacking erfordert Sorgfalt bei Alignment und kann die Blockgrößenfrage komplex machen.

Empfehlung VM-Seitig: Generell sollte man sich an folgende Prinzipien halten:

• Guest-Dateisystem: Behandeln Sie das Dateisystem innerhalb der VM so, als wäre es ein physischer Server. Für einen Windows-SQL-Server-VM bedeutet das: erwägen Sie 64 KB Cluster auf den virtuellen Datenträgern für Daten, Logs, TempDB – analog zu physischen Empfehlungen. Für Linux-VMs gilt analog: ext4/XFS, Standard 4 KB. Virtuelle Umgebungen ändern nichts an den SQL-I/O-Mustern, daher gelten die gleichen Überlegungen wie oben für OLTP/OLAP. Viele Hersteller (VMware, Microsoft) empfehlen in ihren Best Practices ebenfalls, innerhalb der VM die gleiche Clustergröße wie physisch vorzunehmen, also häufig 64 KB für SQL-Volumes.
• Host-Seite: Falls Sie Einfluss haben auf das Host-Dateisystem (z. B. Hyper-V auf Windows kann NTFS oder ReFS auf dem CSV nutzen): Achten Sie dort ebenso auf sinnvolle Clustergrößen. Bei Hyper-V-Host-Volumes mit VHDs empfiehlt Microsoft 4 KB bei ReFS (wegen Hyper-V-Granularität), während bei NTFS-Host-Volumes oft 64 KB empfohlen wurde (da die VHDX selbst eine große Datei ist, die eher sequenziell genutzt wird). Neuere Erkenntnisse deuten an, dass 4 KB auf ReFS sogar bevorzugt sind, um Overhead bei dynamisch wachsenden VHDs zu vermeiden. In VMware-VMFS hat man als Admin in der Version 6 keine Wahl mehr – VMFS6 nutzt eine Granularität von 1 MB mit Sub-Block-Features für kleine Files, das meiste geschieht automatisch.
• Alignment in VMs: Meistens kümmern sich moderne Hypervisoren darum, dass die virtuellen Disks (VMDK/VHDX) selbst auf dem Host aligned sind. Wichtig ist aber, innerhalb der VM die Partition an 1 MB Grenze zu beginnen (Standard bei Windows ab 2008/Vista, Linux ohnehin). Sollte man Legacy-Systeme (ältere Windows-Versionen) virtualisieren, muss man evtl. manuell alignen.

Double Caching vermeiden: Bei VMs ist darauf zu achten, dass kein doppeltes Caching auftritt. Z. B. Hyper-V kann auf dem Host mit sogenannten host cache settings arbeiten. Für SQL-Server-VMs empfiehlt man, den Host-Cache (z. B. „Schreibcache“) eher zu deaktivieren bzw. auf passthrough zu stellen, damit die VM (SQL Server darin) selbst mit ihren Mechanismen (Buffer Pool, FUA, etc.) die Konsistenz steuert. Das hat indirekt Einfluss auf die Blockgrößen-Thematik: Wenn Host-Caching aktiv wäre, könnte ein 4-KB-Cluster-Write in der VM vom Host zusammengefasst werden – man verlässt sich aber typischerweise nicht darauf, sondern lässt die VM direkt schreiben. Folglich gelten wieder dieselben Gedanken wie bei physisch.

Beispiel: Sie haben einen Hyper-V Host mit NTFS-formatiertem Volume auf einem SAN-LUN. Der LUN ist 64 TB, NTFS Cluster 64 KB, darin eine VHDX 1 TB. In der VM ist diese VHDX als Laufwerk D: eingebunden und NTFS mit 64 KB formatiert. Der SQL Server in der VM schreibt nun 8 KB an Offset 0 seiner D:-Datenbank. Die VM OS übersetzt das zu einem Write in der VHDX (8 KB im VHDX-Datei-Kontext). Der Hyper-V Host sieht das als 8 KB Write in eine große Datei (VHDX) auf seinem 64-KB-NTFS. Nun wird der Host das umsetzen müssen: 8 KB in einem 64-KB-Cluster schreiben. NTFS-Host muss also den 64-KB-Cluster lesen-modifizieren-schreiben, sofern er nicht bereits im Cache gepinnt ist. Wenn Host-Caching aus ist (Direct I/O zur LUN), muss der Host tatsächlich 64 KB vom SAN-LUN lesen, die 8 KB ändern, 64 KB zurückschreiben – I/O-Amplification! Das ist ein durchaus realistisches Szenario, das man beachten sollte. Es erklärt, warum Microsoft für Hyper-V-Host-Volumes eher 4 KB Cluster empfiehlt (zumindest auf ReFS): Weil Hyper-V viele kleine 4K-Hypervisor-I/Os hat (speziell bei Dynamischen VHDX). In obigem Beispiel hätte 4-KB-Host-NTFS die 8 KB als zwei Cluster behandelt, vermutlich in zwei 4 KB Writes oder, falls contiguous, in einem 8 KB Write.

Konsequenz: In Virtualisierung ist die Sachlage verzwickter: Eine 64-KB-Cluster-Einstellung innerhalb der VM kann auf dem Host unbeabsichtigte Effekte haben, wenn Host und VM nicht identische Blockgrößen nutzen. Daher lautet eine pragmatische Empfehlung: Halten Sie die Blockgrößen nach Möglichkeit durchgängig konsistent. Wenn Host-Volume 64 KB, dann VM-Volume auch 64 KB, um Situationen wie oben zu vermeiden. Oder Host 4 KB und VM 4 KB (was aber bei SQL Windows nicht üblich war). In hyperkonvergenten Systemen (S2D) hat man z. T. gar nicht die Wahl – S2D formatiert ReFS 4 KB für CSVs. Dann sollte man in den VMs vielleicht auch 4 KB belassen. (In vielen Dokuquellen wird allerdings nicht klipp und klar gesagt, dass die Guest-Clustergröße die gleiche sein muss wie Host – aber der Gedanke drängt sich technisch auf, wie wir sehen.)

Fazit VM: Für virtualisierte Umgebungen ist die erste Priorität, korrekte Ausrichtung und Minimierung von Caching-Inconsistenzen sicherzustellen. Die Clustergröße sollte idealerweise auf allen Ebenen abgestimmt sein. Wenn Sie Zweifel haben, ist es sicher nicht verkehrt, die Standard-Blockgrößen (4 KB) überall zu verwenden – das garantiert maximal Kompatibilität, vor allem in gemischten Workloads (VMs mit vielen kleinen Files, etc.). Wenn Ihre VM jedoch isoliert auf dediziertem Storage liegt und Sie optimieren wollen, können Sie Host und Guest mit 64 KB formatieren, um dem SQL-Server-VM die theoretischen Vorteile zu geben. Testen Sie aber Performance und achten Sie auf eventuelle hidden costs (wie im Beispiel der 8 KB Write auf Host 64 KB Volume).

4.4 Einsatz mit Storage Spaces Direct / SAN / NAS / Cloud Storage

Storage Spaces Direct (S2D): S2D ist Microsofts Software-Defined-Storage für clusterkonvergente Systeme. Hier werden interne Disks über Clusterknoten zu einem gemeinsamen Storage Pool zusammengefasst. S2D nutzt in der Regel ReFS als Dateisystem auf den sogenannten CSV (Cluster Shared Volumes). Microsoft empfiehlt für ReFS im Kontext S2D klar 4 KB als Standard. Dies hängt auch damit zusammen, dass S2D viele intelligente Mechanismen (Tiering, Mirror-Accelerated-Parity etc.) hat, die kleine Blockgrößen bevorzugen, um flexibel zu bleiben. Außerdem laufen auf S2D oft Hyper-V-VMs (wiederum VHDX), wo – wie oben diskutiert – 4 KB ReFS sinnvoll ist. Für einen SQL Server, der direkt auf S2D deployed wird (z. B. ein FCI – Failover Cluster Instance – auf S2D) gilt daher: man bleibt bei 4 KB, da ReFS dort gesetzt ist. Alternativ kann man auch CSVs mit NTFS nutzen, aber ReFS ist standard. Wenn man NTFS auf CSV brächte, könnte man 64 KB erwägen, aber das ist unüblich.

SAN (Storage Area Network): In klassischen SAN-Umgebungen (Fiber Channel/iSCSI mit externem Disk-Array) bekommt der Server LUNs präsentiert, die er mit NTFS formatiert. Hier hat sich das Vorgehen etabliert, SQL-Volumes mit 64 KB NTFS zu formatieren, sofern der SAN-Hersteller nichts anderes empfiehlt. Manche Enterprise-SANs haben intern eine Segmentgröße (z. B. 32 KB oder 64 KB), aber in der Regel werden auch hier kleine Zugriffe vom Controller gemanagt. Hersteller wie Pure Storage schreiben in ihren Guides, 64 KB für NTFS und ReFS sei Best Practice für SQL Server. NetApp, wie gesehen, ließ SnapDrive standardmäßig 4 KB formatieren, fand aber raus, dass es keinen großen Unterschied macht. Also: Stimmen Sie sich mit Ihrem Storage-Team oder Lieferanten ab. Falls keine speziellen Vorgaben kommen, sind Sie mit 64 KB auf Windows-SAN-LUNs auf der „sicheren Seite“, weil es dem altbewährten Muster entspricht und mögliche Extent-Limits entschärft. Achten Sie aber vor allem auf Partition-Alignment (zum Glück meistens automatisch korrekt) und RAID-Stripe-Settings in Abstimmung mit Ihrem SAN-Layout. Viele SANs haben heute Virtualisierungslayer, wo diese Dinge abstrahiert sind.

NAS (Network Attached Storage): NAS-Protokolle wie SMB3 (z. B. ein SQL Server nutzt eine freigegebene Datei auf einem SMB-Share) oder NFS (für SQL auf Linux) abstrahieren die darunterliegende Blockgröße. Bei SMB Direct kann man z. B. mit FSx (AWS) oder Azure Files Premium arbeiten. FSx for Windows z. B. setzt, wie AWS in einem Blog beschrieb, standardmäßig 16 KB als Clustergröße ein. Einige Kunden waren besorgt, da 16 KB vom „heiligen“ 64 KB abweicht. Die AWS-Tester konnten jedoch nachweisen, dass für OLTP-ähnliche Workloads kein Leistungsunterschied zwischen 16, 32 und 64 KB auf FSx messbar war. Daher lautet hier die Empfehlung: Verwenden Sie das, was der NAS-Provider vorgibt. Wenn Sie beispielsweise Azure Files nutzen, haben Sie ohnehin keinen Einfluss auf die remote Clustergröße. Wichtiger ist, dass Latenz und Durchsatz über das Netzwerk stimmen und das Protokoll (SMB3 mit Multichannel, RDMA etc.) optimiert ist. Sollte man selbst ein NAS (z. B. Windows Server basierter File-Server) hosten, könnte man die Partitionen dort mit 64 KB formatieren, wenn sie ausschließlich SQL-Daten enthalten, oder 4 KB belassen, falls gemischte Nutzung. In jedem Fall: Da der SQL-Server hier “über das Netz” zugreift, ist die physische Blockgröße eine Ebene tiefer verborgen und nicht so unmittelbar einstellbar vom SQL-Administrator.

Cloud Storage (IaaS): Wenn Sie SQL Server in der Cloud auf IaaS (Infrastructure as a Service) betreiben – z. B. auf einer Azure VM oder AWS EC2 – dann gilt ähnlich wie on-prem: Sie bekommen virtuelle Festplatten (Managed Disks, EBS-Volumes etc.), die Sie innerhalb des OS formatieren können. Folgen Sie hier den gleichen Überlegungen: Für Windows-VMs kann man 64 KB für SQL-Volumes nehmen, und einige Cloud-Dokumentationen (Azure Well-Architected Framework, AWS Prescriptive Guidance) nennen dies explizit. Vergewissern Sie sich aber, dass Ihr VM-Image mit dem Format klarkommt – z. B. beim Ändern eines existierenden Volumes müsste man neu formatieren, was Ausfallzeit bedeuten kann. Bei Linux-Cloud-VMs natürlich 4 KB (Standard ext4/XFS). Achten Sie in Cloud-Umgebungen auf andere Limits wie max IOPS per Disk, Throughput-Limits per Disk oder VM. Eine größere Blockgröße hat keinen Einfluss darauf, außer dass bei sehr großen I/Os man schneller das Throughput-Limit erreichen kann, aber gleichermaßen weniger IOPS verbraucht (I/O wird oft in 256 KB Einheiten auf die Limits gerechnet). Dies nur am Rande: z. B. Azure sagt eine P30 Disk kann 5000 IOPS oder 200 MB/s – wenn man 1 MB Blöcke schreibt, sind das rechnerisch 200 IOPS = 200 MB/s Limit; wenn man 4 KB schreibt, könnte man 5000 solcher schreibt, was nur ~20 MB/s ist – aber man hat in OLTP nie 5000 nur 4 KB, sondern mischlast.

Abschließend zu Szenarien: Es gibt kein One-Size-Fits-All. Für die meisten konservativen Admins lautet die Faustregel: Windows + SQL = 64 KB, Linux + SQL = 4 KB. Dieses Motto deckt sich mit vielen offiziellen Best Practices und wird Ihre Systeme nicht in Schwierigkeiten bringen. Wer jedoch genauer hinsieht, erkennt, dass auch 4 KB auf Windows vollkommen in Ordnung sein können und dass neuere Empfehlungen differenzierter sind. Unsere Anleitung wäre: Schauen Sie sich Ihren Workload an, beurteilen Sie, ob kleine oder große I/Os dominieren, berücksichtigen Sie die Storage-Schicht (RAID, SSD, Tiering) und entscheiden Sie dann. Und falls Sie unschlüssig sind – testen Sie es. Führen Sie einen Diskspd-/FIO-Test mit 4 KB vs 64 KB Format durch und vergleichen Sie die Ergebnisse in Ihrer Umgebung, um fundiert zu entscheiden. Oft wird der Unterschied minimal sein, dann können andere Faktoren (z. B. administrative Einfachheit, Standardisierung) den Ausschlag geben.

5. Konfigurations- und Prüfmethoden

Abschließend widmen wir uns der praktischen Seite: Wie stellt man fest, welche Blockgröße ein vorhandenes Volume hat? Welche Tools können I/O-Profile analysieren? Und wie geht man vor, wenn man die Blockgröße ändern will?

5.1 Tools zur Analyse der Blockgröße und I/O-Parameter

Unter Windows: Um die Clustergröße eines NTFS- oder ReFS-Volumes herauszufinden, gibt es mehrere Methoden. Grafisch kann man im Werkzeug Datenträgerverwaltung die Volume-Eigenschaften einsehen – dort steht die „Zuordnungseinheit“. Schneller geht es per PowerShell oder Eingabeaufforderung. Mit PowerShell lässt sich z. B. via WMI abfragen:

Get-WmiObject -Class Win32_Volume | Select Label, BlockSize

Dies listet für alle Volumes die BlockSize in Bytes (z. B. 4096 oder 65536). Alternativ liefert der Befehl fsutil fsinfo ntfsinfo <Laufwerk>: viele Informationen; in der Ausgabe findet man „Bytes per Cluster“, was die gesuchte Größe ist. Ein Beispiel: Ausgabe zeigt „Bytes Per Cluster : 4096 (4 KB)“ – für SQL-Volumes sollte hier idealerweise 65536 (64 KB) stehen, falls man die 64K-Einstellung wollte. Der SQL Server selbst hat keine direkte Funktion, um die Dateisystem-Blockgröße zu ermitteln, aber via xp_cmdshell könnte man einen der obigen Befehle ausführen, oder mit dem Sysinternal-Tool du.exe (Disk Usage) kann man indirekt Clustergrößen sehen (Option -v).

Unter Linux: Hier hängt es vom Dateisystem ab. Für ext4 kann man mit tune2fs -l /dev/<Gerät> zahlreiche Parameter auflisten; die Zeile „Block size“ zeigt die Blockgröße an (meist 4096). Für XFS liefert der Befehl xfs_info /mountpunkt Informationen; dort steht z. B. bsize=4096 in der Ausgabe. Alternativ kann man stat -f <Datei> ausführen – das gibt die Fundamentalblockgröße des Dateisystems aus (Achtung, das ist oft identisch mit der Clustergröße). df -T verrät es nicht, da stehen nur Gesamtblöcke in 1K-Einheiten. Ein universeller Weg: blockdev –getbsz /dev/<device> gibt die Blockgröße zurück, mit der das Gerät gemountet ist (für O_DIRECT relevant). Für ext4 sollte das 4096 zeigen. Sollte man jemals ein ext4 mit 8192 oder 16384 Blockgröße haben (theoretisch ginge das auf einem System mit entsprechend großer PAGE_SIZE), würde es dort erscheinen.

I/O-Muster analysieren: Um festzustellen, welche I/O-Größen ein SQL Server tatsächlich nutzt, kann man Performance-Monitor (Windows) bzw. iostat/sar (Linux) heranziehen. In PerfMon sind die wichtigen Counter unter PhysicalDisk: Avg. Disk Bytes/Transfer (Durchschnittliche Bytes pro Transfer) und Disk Transfers/sec (I/O-Operationen pro Sekunde). Wenn man diese für das SQL-Daten-Laufwerk loggt, erkennt man typische Muster. Auch Tools wie Process Monitor können auf Prozess-Ebene mitloggen, in welchen Größen SQLSERVR.exe liest und schreibt. Für Linux steht iostat -x zur Verfügung, das die avgqu-sz (Durchschnittliche Request-Größe in Sektoren) ausgibt – daraus kann man die KB ableiten. Feingranularer geht es mit blktrace und blkparse, was aber sehr tiefgehend ist. Einfacher: Der SQL Server selbst bietet im DMV sys.dm_io_virtual_file_stats Felder für num_of_reads, num_of_bytes_read etc., woraus man über alle Reads einen Durchschnitt berechnen kann. Das kann Hinweise geben, ob eher 8 KB oder 64 KB Reads dominieren.

Storage-Tools: Für gezielte Performance-Tests gibt es DiskSpd (Microsoft, Nachfolger von SQLIO) und FIO (Linux) als flexible Werkzeuge, um verschiedene Blockgrößen-Szenarien zu simulieren. Damit könnte man z. B. testweise einen sequentiellen Read von 64 KB Blöcken vs. 4 KB Blöcken messen, um zu sehen ob die Disk/RAID-Kombi einen Unterschied zeigt.

5.2 Vorgehen zur Umstellung der Blockgröße

Änderung der Blockgröße = Neuformatierung: Leider gibt es kein On-the-fly-Konvertierungstool, um die Clustergröße eines bestehenden Dateisystems zu ändern. Unter Windows bedeutet eine Änderung immer: Daten sichern, Volume neu formatieren mit gewünschter Allocation Unit, Daten zurückspielen. Das erfordert Downtime für die SQL-Daten, weshalb ein solcher Schritt gut überlegt sein will. Für Systemlaufwerke (C:) ist eine Änderung der Clustergröße praktisch nicht machbar ohne Neuinstallation, da Windows selbst darauf läuft. Glücklicherweise betrifft uns das meist nicht, denn SQL-Daten sollten nicht auf C: liegen.

Planung: Bevor man eine Umstellung vornimmt, sollte man klar die Motivation und den erwarteten Nutzen abwägen. Liegt ein konkretes Performanceproblem vor, das auf die Blockgröße zurückgeführt wurde? Oder ist es eine präventive Maßnahme (z. B. bevor die DB >16 TB wächst)? Im Zweifel konsultieren Sie den Microsoft-Support oder verlässliche Quellen, um sicherzugehen, dass es notwendig ist. Der NetApp-Test zeigte z. B., dass der Performanceunterschied gering war – sprich, man sollte keinen dramatischen Gewinn erwarten.

Durchführung unter Windows: Man erstellt am besten zunächst ein Wartungsfenster, in dem die Datenbank heruntergefahren oder in den OFFLINE-Modus gebracht wird. Dann kopiert oder sichert man die Daten weg (Backup to disk/tape, oder detach und File-Copy, je nach Volumengröße). Anschließend formatiert man das Volume neu: über die Datenträgerverwaltung GUI (dort kann man bei Formatieren die Zuordnungseinheit wählen) oder mittels format-Kommando im CLI. Beispiel CLI: format E: /FS:NTFS /L /Q /A:64K /V:SQLData formatiert Laufwerk E: als NTFS mit großer MFT ( /L für mehr Fragmente) und 64K AllocationUnit (/A:64K), Quickformat, Volume-Label „SQLData“. Beachten: /L (large FRS) setzt 4K Cluster voraus, wenn man 64K Cluster nutzt, ist /L eigentlich nicht nötig, da 64K das Fragmentlimit sowieso entschärft. Nach Format spielt man die Daten zurück (Backup einspielen oder Files re-attachen). Tipp: Falls man Backup/Restore macht, kann man auch in Erwägung ziehen, auf Dateiebene zu komprimieren während Transfer, da 64K Volumes keine NTFS-Kompression unterstützen – aber das erübrigt sich meist, man hat ja Platz extern.

Durchführung unter Linux: Hier ähnlich: Datenbank herunterfahren (oder wenn möglich alle Dateien zu einem anderen Volume bewegen, falls genug Platz). Dann umount das Dateisystem, mit mkfs.xfs oder mkfs.ext4 neu erstellen (inkl. passender Optionen). Da wir die Blockgröße nicht wirklich ändern (bleibt 4K), könnte es eher um andere Parameter gehen wie Stripe-Unit. Aber falls man von ext4 zu XFS wechseln will o. ä., wäre das der Schritt. Danach mounten und Daten zurückkopieren bzw. DB wieder online nehmen.

Validierung: Nach der Umstellung unbedingt prüfen, ob die Blockgröße tatsächlich wie gewünscht ist (mittels Tools aus 5.1). Außerdem kurz die DB-Funktionalität testen (integrity check, ein paar Abfragen) und Performance-Monitoring durchführen, um zu sehen ob irgendwelche Kennzahlen sich verändert haben (z. B. höhere IOPS oder niedrigere Latency). In aller Regel sollte alles normal weiterlaufen.

Risiken: Achten Sie auf bestimmte Anwendungen/Features, die evtl. nicht mit 64K klarkommen. Ein Beispiel: NTFS-Kompression geht nicht mit 64K – aber die sollte man für SQL DB ohnehin nicht verwenden. Eher relevant: Einige ältere Backup-Softwares oder Virenscanner hatten manchmal Annahmen über 4K Sektoren – das ist selten ein Problem, aber man kann in entsprechenden Dokumentationen nachsehen.

Rollback: Wenn nach der Umstellung (seltener Fall) negative Effekte auftreten, müsste man theoretisch wieder zurück formatieren. Daher lohnt es sich, einen Test auf einer vergleichbaren Staging-Umgebung im Vorfeld zu machen.

Besonderheit: Mischcluster: Wenn Sie in einem Windows-Failover-Cluster mehrere Knoten haben, sollte natürlich das geteilte Storage (Cluster Disk) bei allen als gleiche Clustergröße gemountet sein – was normalerweise gewährleistet ist, da es nur ein Volume gibt. Anders ausgedrückt: In konsistenten Umgebungen tritt nichts Überraschendes auf. Problematisch wäre es, wenn jemand z. B. eine Partition verkleinert und eine neue Partition hintendran erstellt mit anderer Clustergröße – aber das ist sehr unüblich.

Wir haben damit den Rundumschlag zur Blockgröße abgeschlossen. Zum Schluss fassen wir die wichtigsten Punkte noch in einer Frage-Antwort-Runde (FAQ) zusammen, um praxisnah typische Unklarheiten zu beseitigen.

FAQ – Häufige Fragen zur Blockgröße bei SQL Server (15 Fragen)

Frage 1: Was ist mit „Blockgröße“ bzw. „Allocation Unit Size“ genau gemeint?
*Antwort: Die Blockgröße (Allocation Unit Size) eines Dateisystems ist die kleinste Einheit, in der das Dateisystem Speicherplatz zuteilt. Sie wird oft auch Clustergröße genannt. Beispielsweise bedeutet eine 4-KB-Blockgröße, dass jeder Datei in 4-KB-Schritten Platz zugewiesen wird. 8 KB in einer Datei belegen also zwei Blöcke à 4 KB. Diese Größe beeinflusst, wie das Betriebssystem Lese- und Schreibzugriffe vom logischen Dateisystem auf die physischen Sektoren abbildet.

Frage 2: Warum hört man oft, dass für SQL Server 64 KB als Blockgröße empfohlen wird?
*Antwort: Diese Empfehlung stammt aus der Tatsache, dass SQL Server intern mit 8-KB-Seiten und 64-KB-Extents arbeitet. Acht 8-KB-Seiten ergeben genau 64 KB. Man nahm lange an, dass SQL Server bevorzugt in 64-KB-Blöcken I/O durchführt (eine Extent auf einmal) und man mit 64-KB-Clustern das Dateisystem optimal darauf abstimmt. Zudem reduziert 64 KB die Fragmentierungsanfälligkeit bei sehr großen Dateien und umgeht das 16-TB-Limit von NTFS bei 4-KB-Clustern. In heutigen Systemen stimmt es allerdings nur bedingt, dass SQL ausschließlich 64 KB I/Os macht – SQL Server nutzt je nach Vorgang auch kleinere und größere I/Os. Dennoch ist „64K für SQL“ ein verbreitetes Best Practice, das in vielen Microsoft-Dokumenten steht, und es schadet in der Regel nicht, solange man die Rahmenbedingungen beachtet.

Frage 3: Bringt 64 KB Blockgröße wirklich mehr Performance als 4 KB?
Antwort:* In vielen Fällen nein, kaum messbar**. Zahlreiche Tests – sowohl von Herstellern wie NetApp als auch Cloud-Anbietern wie AWS – haben gezeigt, dass der Unterschied in IOPS, Durchsatz und Latenz zwischen 4 KB und 64 KB bei SQL-Workloads sehr gering ist (oft < 5%). Das gilt insbesondere auf SSD/NVMe-Speicher. Theoretisch kann 64 KB bei großen sequentiellen Transfers minimal effizienter sein und die CPU-Last senken, während 4 KB bei vielen kleinen Zufallszugriffen minimal weniger „Leerarbeit“ (I/O Amplification) erzeugt. Insgesamt gleichen moderne Systeme das aber gut aus. Wichtiger ist, dass Partitionen richtig ausgerichtet sind und genügend physische Ressourcen vorhanden sind. Kurz: 64 KB ist kein Turbo, aber auch kein Performance-Killer – es ist meist neutral.

Frage 4: Unter Linux kann ich keine 64 KB Blockgröße einstellen – ist SQL Server auf Linux deswegen im Nachteil?
*Antwort: Nein. SQL Server auf Linux (mit ext4 oder XFS) hat in der Praxis keine Nachteile dadurch, dass das Dateisystem 4 KB Blöcke nutzt. Die I/O-Subsysteme von Linux sind sehr leistungsfähig und SQL Server verteilt seine Zugriffe über O_DIRECT so, dass die 4 KB Blöcke effizient genutzt werden. Die meisten SQL-I/Os sind sowieso 8 KB, 64 KB oder größer – ext4/XFS können zusammenhängende 4-KB-Blöcke problemlos in größeren Transfers liefern. Microsoft hat viele Performance-Bestpractices für Linux publiziert, aber die Clustergröße zu ändern gehört nicht dazu. Das liegt auch daran, dass man sie technisch nicht ändern kann (4 KB ist fest auf x86_64). Zusammengefasst: SQL Server auf Linux erreicht vergleichbare Performance wie auf Windows, obwohl (oder gerade weil) man bei 4 KB bleibt.

Frage 5: Wie überprüfe ich, welche Blockgröße mein bestehendes SQL-Server-Laufwerk hat?
*Antwort: Unter Windows z.B. mit fsutil fsinfo ntfsinfo X: – dort findet man „Bytes Per Cluster“. Alternativ in PowerShell Get-Volume oder die WMI-Abfrage nach Win32_Volume (BlockSize). Unter Linux für XFS xfs_info /mountpunkt (Ausgabe enthält bsize=4096), für ext4 tune2fs -l (Block size: 4096). Siehe Abschnitt 5.1 oben für Details.

Frage 6: Meine Datenbank ist 2 TB groß und wächst weiter. Sollte ich auf 64 KB umformatieren, um das NTFS-16TB-Limit frühzeitig zu umgehen?
*Antwort: Das 16-TB-Dateigrößenlimit bei 4 KB-NTFS greift erst ab 16 TB (oder 16 TB Volumegröße). Wenn Sie absehen können, dass Ihre DB in einigen Jahren diese Größenordnung erreicht, können Sie vorsorglich tatsächlich 64 KB einsetzen, um den Spielraum zu erhöhen auf bis ~64 TB. Alternativ können Sie format /L mit 4 KB nutzen, was das Limit auf ~64 TB anhebt – dabei bleibt aber die Fragmente-Obergrenze (6 Mio. Extents) irgendwann ein Thema. Bei 2 TB besteht noch kein akuter Handlungsbedarf. Viele 20-30 TB Data Warehouses laufen allerdings bereits mit 64 KB, einfach um sicherzugehen. Es kommt auch darauf an, wie schnell das Wachstum ist und ob eine Reorganisation (z.B. Partition Split auf mehrere Dateien) möglich ist. Wenn kein Downtime-freies Verfahren in Sicht ist, könnte man lieber früher als später umstellen (in einem geplanten Wartungsfenster).

Frage 7: Hat die Blockgröße einen Einfluss auf die TempDB-Performance?
*Antwort: Indirekt ja, aber nicht gravierend. TempDB erzeugt viele kleine I/Os; bei 64 KB könnte es mehr internen Overhead geben, falls kleine Schreibmuster auftreten – aber unter NTFS sind diese handhabbar. Viele Admins formatieren TempDB-Volumes standardmäßig mit 64 KB, analog zu Daten und Logs. Unter Linux bleibt es 4 KB. Es gibt keine Berichte, dass TempDB spezifisch von 4 KB vs 64 KB groß beeinflusst würde. Viel wichtiger für TempDB-Performance sind ausreichend IOPS und separate Spindeln/SSDs, mehrere Dateien zur Verteilung und Konfiguration (z. B. Trace Flag 1118 für uniform extends etc.). Die Clustergröße ist eher neutral, solange wie immer Alignments passen.

Frage 8: Unser Server ist virtualisiert. Sollte ich im vDisk auch 64 KB wählen oder lieber 4 KB belassen?
*Antwort: Idealerweise halten Sie die Konfiguration konsistent zwischen Host und Gast. Wenn der Hypervisor-Host ein Volume mit 64 KB bereitstellt (z.B. ein RAW LUN in VMware), können Sie im Gast auch 64 KB formatieren. Wenn der Host allerdings mit 4 KB arbeitet (z.B. S2D ReFS oder ein generell 4 KB NAS), ist es meist besser, im Gast auch 4 KB zu lassen, um I/O-Amplification auf Hostebene zu vermeiden. In Hyper-V-Szenarien mit VHDX auf ReFS (4 KB) empfiehlt MS auch 4 KB, weil Hyper-V viele 4K-IO macht. Bei VMware mit VMFS (1 MB Subblocks) ist es unkritischer, dort kann man dem Gast 64 KB geben, wie viele es tun. Grundregel: Virtualisierung ändert die Empfehlung nicht grundlegend, aber es kommen zusätzliche Schichten hinzu. Wer auf Nummer sicher gehen will, bleibt bei 4 KB überall, wer optimieren will, stellt host=64 KB, guest=64 KB ein (insbesondere bei dedizierten SQL-Hosts).

Frage 9: Kann ich die Blockgröße einer bestehenden Partition ohne Datenverlust ändern?
*Antwort: Nicht direkt, nein. Weder Windows noch Linux bieten eine direkte on-the-fly-Konvertierung. Man muss Daten anderweitig sichern, Volume neu formatieren und Daten zurückspielen. Tools wie Partition Magic o. ä. funktionieren auf Dateisystem-Ebene dafür nicht. Es gibt Workarounds wie dass man ein neues Volume anlegt und SQL-Dateien per ALTER DATABASE … MODIFY FILE (NAME=…, FILENAME=’…‘) darauf verschiebt, aber intern läuft es auf das gleiche hinaus: das Volume wird neu erstellt. Daher ist eine Umstellung mit Ausfallzeit verbunden und sollte gut geplant sein.

Frage 10: Was passiert, wenn ich kleine Dateien auf einem 64-KB-Cluster-Volume speichere?
*Antwort: Jede Datei belegt mindestens 64 KB, auch wenn sie z.B. nur 5 KB groß ist. Das kann zu Platzverschwendung führen (interne Fragmentierung). Für SQL Server ist das meist kein Problem, da Datenbankdateien sehr groß sind und Logfiles auch kontinuierlich größer. Aber wenn Sie z.B. Backups (im Schnitt mehrere hundert MB) drauflegen, stört es nicht. Wenn allerdings auf dem gleichen Volume auch viele kleine Dateien liegen (z.B. Tausende von 1-KB-XML-Dateien), geht mit 64K-Clustern viel Platz verloren, und man sollte dort eher 4 KB nutzen. In einem reinen SQL-Volume ist das selten relevant, außer vielleicht, Sie aktivieren Filestream und speichern Millionen Kleinstdateien – dann könnte 4 KB günstiger sein.

Frage 11: Unser Storage-Anbieter empfiehlt pauschal 4 KB für alles – sollen wir uns dem widersetzen für SQL?
*Antwort: In der Regel: Folgen Sie dem Storage-Anbieter. Wenn z. B. NetApp sagt „SnapDrive formatiert NTFS 4 KB und wir haben damit gute Erfahrungen“, dann ist das valide. Microsoft selbst sagt ja: Vendor-Empfehlung geht vor, ansonsten 64K. Speicherhersteller kennen ihre System-Interna (Cache-Verhalten, Alignment, Coalescing) am besten. Es kann sein, dass in deren Lösungen 4 KB keinerlei Nachteil hat und ihr eigenes Management damit konsistenter arbeitet. Beispielsweise verwenden einige SANs „thin provisioning“ auf 4K-Basis – da könnte 64K unnötig große Allokationsschritte auslösen. Also: lieber abstimmen. Wenn keine klare Aussage vom Hersteller kommt und Sie freie Hand haben, dann können Sie die SQL-BPs (64K) anwenden.

Frage 12: Ist die Partition Alignment Thematik heute noch wichtig?
*Antwort: In den meisten Fällen wird Partition Alignment automatisch korrekt gehandhabt. Moderne Windows-Versionen (seit Windows Vista/2008) richten neue Partitionen standardmäßig an 1 MiB Grenzen aus, womit gängige RAID-Stripes und physische Sektoren sauber abgedeckt sind. Unter Linux machen Tools wie fdisk oder parted das ebenso seit Langem automatisch (z.B. Start bei Sektor 2048). Wichtig wird es nur, wenn man sehr alte Systeme oder geklonte Partitionen im Einsatz hat. Nicht ausgerichtete Partitionen können Performance kosten (ein 4K-Cluster überlappt zwei 4K-physische Sektoren). Prüfen kann man das unter Windows z. B. mit wmic partition get StartingOffset. Wenn dort Offsets auftauchen, die nicht durch 4096 teilbar sind, hat man ein Problem. In der Regel ist aber alles sauber. Fazit: Alignment ist weiterhin fundamental, aber neue Installationen machen es automatisch richtig.

Frage 13: Wir nutzen ReFS für unsere SQL Server (z.B. auf S2D). Sollten wir eher 4 KB oder 64 KB wählen?
Antwort:* Microsoft empfiehlt für ReFS im Allgemeinen 4 KB**. 64 KB ist nur in Sonderfällen sinnvoll (große sequentielle Workloads ohne kleine Updates). Da ReFS spezielle Mechanismen wie Integrity Streams und Copy-on-Write (bei Block Cloning, Snapshots) hat, verursachen kleine Änderungen in einem 64K-Cluster mehr Overhead. Typischerweise ist ReFS erste Wahl für S2D (Hyper-V) und Backup-Volumes – beides Szenarien, wo 4K Standard ist. Für einen SQL Server direkt auf ReFS würde man auch 4K nehmen, außer man weiß genau, dass es ein Data-Warehouse ist mit riesigen sequentiellen I/Os und Integrity Streams aus sind etc. Im Zweifel: 4K.

Frage 14: Hat die SSD-Sektorgröße (512e vs. 4Kn) Einfluss auf meine Wahl der Clustergröße?
Antwort: Nicht direkt auf die Wahl, aber auf die Notwendigkeit korrekter Einstellung. Heutige SSDs kommen oft als 512-Byte-emulierte (512e) mit 4K physisch. Das Betriebssystem sieht 512 B Sektoren, aber intern sind es 4 KB. Wenn man hier z.B. 512 B Cluster nutzen würde (theoretisch möglich mit NTFS), führt das immer* zu 8× so vielen physischen Zugriffen – daher wird <4K ja auch abgeraten. Bei 4K oder 64K Clustern ist es aber egal, beide sind Vielfache von 4K und damit ausrichtungsmäßig okay (vorausgesetzt Partition alignment stimmt). 4Kn SSDs präsentieren dem OS gleich 4096 Byte als Sektor – Windows kann damit umgehen (seit Win8). Für uns bedeutet das: niemals Cluster kleiner als physischer Sektor nutzen. Da physisch meist 4K, ist 4K schon Minimum. 64K umfasst 16 physische Sektoren, was kein Problem ist. Kurz: Solange >=4K, keine Sorge.

Frage 15: Wenn der Unterschied so gering ist, warum dann überhaupt 64K in Erwägung ziehen?
Antwort: 64K-Cluster haben – zusammengefasst – folgende potenzielle Vorteile: Sie reduzieren die Anzahl an Clustern (und damit Verwaltungseinheiten) für große Dateien, was das Risiko extremer Fragmentierung mindert und ggf. minimal CPU sparen kann. Sie passen genau zur SQL Extent-Größe, sodass im Idealfall ein Extent in einem physisch zusammenhängenden Cluster liegt. Und sie erlauben größere Volumes/Dateien (>16 TB auf NTFS). Die potenziellen Nachteile: kleine Writes könnten theoretisch I/O Amplification erzeugen (unter Windows aber mitigiert), bei vielen Mini-Dateien gibt’s Platzverschwendung, und es ist unflexibel (NTFS-Kompression off, etc.). Letztlich zieht man 64K oft heran nach dem Motto „viel hilft viel“ bzw. „schaden tut’s nicht und es entspricht dem SQL-Layout“*. Viele Admins fühlen sich damit wohler, weil „man es halt so macht(e)“. Und wirklich falsch ist es nicht – es gibt ja Szenarien, wo es messbar besser war (wenn auch nicht dramatisch). Zusammengefasst: Wenn Sie ohne großen Aufwand 64K einsetzen können, tun Sie es ruhig für SQL-Volumes – erwarten Sie nur kein Wunder. Wenn Sie Standard 4K belassen, dürfen Sie ebenso beruhigt sein, dass Sie kaum etwas verschenken.

 

Weitere Beiträge zum Thema SQL Server