Freigeben über

Grundlagen zu SQL Server-E/A

  • Artikel

Gilt für:SQL ServerAzure SQL Managed InstanceSQL Server auf Azure-VM

Der Hauptzweck einer SQL Server -Datenbank ist das Speichern und Abrufen von Daten. Daher stellt eine hohe Ein-/Ausgabe auf dem Datenträger ein Hauptmerkmal der Datenbank-Engine dar. Datenträger-E/A-Vorgänge beanspruchen ggf. viele Ressourcen und benötigen relativ viel Zeit für die Ausführung. Daher ist SQL Server so konzipiert, dass E/A-Vorgänge möglichst effizient gestaltet werden.

Speichersubsysteme für SQL Server werden in mehreren Formfaktoren bereitgestellt, einschließlich mechanischer Laufwerke und Festkörperspeicher. Dieser Artikel enthält Details zur Verwendung von Prinzipien zur Laufwerkzwischenspeicherung, um Datenbank-Engine-E/A zu verbessern.

SQL Server erfordert, dass Systeme die garantierte Übermittlung an stabile Medien unterstützen, wie unter den SQL Server-E/A-Zuverlässigkeitsprogrammanforderungen beschrieben. Weitere Informationen zu den Eingabe- und Ausgabeanforderungen für die SQL Server-Datenbank-Engine finden Sie unter SQL Server Datenbank-Engine Anforderungen für Datenträgereingabe/-ausgabe (E/A).

Datenträger-E/A

Mit dem Puffer-Manager werden nur Lese- und Schreibvorgänge für die Datenbank ausgeführt. Sonstige Datei- und Datenbankvorgänge, z. B. öffnen, schließen, erweitern und verkleinern) werden von den Datei- und Datenbank-Manager-Komponenten ausgeführt.

Datenträger-E/A-Vorgänge des Puffer-Managers weisen die folgenden Merkmale auf:

  • E/A-Vorgänge werden normalerweise asynchron ausgeführt, sodass der aufrufende Thread die Verarbeitung fortsetzen kann, während der E/A-Vorgang im Hintergrund ausgeführt wird. Unter bestimmten Umständen (z. B. falsch ausgerichtete Protokoll-E/A) können synchrone E/A-Vorgänge auftreten.

  • Alle E/A-Vorgänge werden an die aufrufenden Threads ausgegeben, sofern nicht die Option „affinity I/O“ verwendet wird. Die Option affinity I/O mask bindet die SQL Server-Datenträger-E/A an eine bestimmte Teilmenge von CPUs. In High-End-OLTP-Umgebungen (Online Transactional Processing, Onlinetransaktionsverarbeitung) für SQL Server kann diese Erweiterung die Leistung von SQL Server -Threads, die E/A verursachen, verbessern.

  • Mehrfachseiten-E/A wird durch Scatter-Gather-E/A erreicht; dadurch wird ermöglicht, dass Daten in nicht zusammenhängende Bereiche des Arbeitsspeichers oder aus diesen übertragen werden können. Damit kann der Puffercache von SQL Server problemlos gefüllt oder gelöscht werden; zugleich werden mehrere physische E/A-Anforderungen verhindert.

Lange E/A-Anforderungen

Vom Puffer-Manager werden alle seit mindestens 15 Sekunden ausstehenden E/A-Anforderungen gemeldet. Damit kann der Systemadministrator einfacher zwischen SQL Server-Problemen und Problemen im E/A-Subsystem unterscheiden. Es wird die Fehlermeldung MSSQLSERVER_833 angegeben. Im SQL Server-Fehlerprotokoll wird sie wie folgt angezeigt:

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

Eine lange E/A kann entweder ein Lese- oder ein Schreibvorgang sein; in der Meldung wird dies nicht angegeben. Bei Meldungen zu langen E/A-Vorgängen handelt es sich um Warnungen, nicht um Fehlermeldungen. Sie weisen nicht auf Probleme bei SQL Server sondern beim zugrundeliegenden E/A-System hin. Die Meldungen werden ausgegeben, damit der Systemadministrator die Ursache der langen Antwortzeiten von SQL Server leichter ermitteln kann und um Probleme, die nicht durch SQL Server verursacht werden, abgrenzen zu können. Die Meldungen erfordern keine bestimmte Vorgehensweise; der Systemadministrator sollte jedoch untersuchen, weshalb die E/A-Anforderung so viel Zeit beansprucht, oder ob die benötigte Zeit gerechtfertigt ist.

Ursachen für lange E/A-Anforderungen

Eine Meldungen zu langen E/A-Vorgängen kann darauf hinweisen, dass ein E/A-Vorgang dauerhaft blockiert ist und nicht beendet werden kann (dies wird auch als „verlorener E/A-Vorgang“ bezeichnet) oder dass der E/A-Vorgang noch nicht beendet wurde. Es kann anhand der Meldung nicht ermittelt werden, welches Szenario hier zutrifft. Eine verlorene E/A führt jedoch häufig zu einem Latchtimeout.

Lange E/A-Vorgänge sind häufig ein Hinweis auf eine zu hohe SQL Server-Arbeitsauslastung für das Datenträgersubsystem. Ein unzureichendes Datenträgersubsystem wird in folgenden Fällen angezeigt:

  • Bei starker SQL Server-Arbeitsauslastung werden mehrere Meldungen zu langen E/A-Vorgängen im Fehlerprotokoll angezeigt.
  • Leistungsmonitorindikatoren weisen auf eine lange Datenträgerwartezeit, lange Datenträgerwarteschlangen und eine fehlende Datenträger-Leerlaufzeit hin.

Lange E/A-Vorgänge können auch durch eine Komponente im E/A-Pfad verursacht werden (z. B. durch einen Treiber, einen Controller oder durch Firmware), bei der das Bedienen einer alten E/A-Anforderung kontinuierlich verschoben wird, anstatt neuere Anforderungen zu bedienen. Dies kann in miteinander verbundenen Umgebungen auftreten, z. B. iSCSI- und Glasfaserkanalnetzwerke (entweder aufgrund einer Fehlkonfiguration oder eines Pfadfehlers). Es ist möglicherweise schwierig, dies mithilfe des Leistungsmonitors zu prüfen, da die meisten E/A-Vorgänge direkt bedient werden. Lange E/A-Anforderungen werden durch Arbeitsauslastungen erschwert, bei denen viele sequenzielle E/A-Anforderungen (z. B. Sichern und Wiederherstellen, Prüfen von Tabellen, Sortieren, Erstellen von Indizes, Massenladen und Dateien auf Null setzen) ausgeführt werden.

Isolierte lange E/A-Anforderungen, die nicht mit einer der vorherigen Bedingungen verknüpft sind, können durch einen Hardware- oder Treiberfehler verursacht werden. Das Systemereignisprotokoll enthält möglicherweise ein ähnliches Ereignis, mit dem eine Problemdiagnose vorgenommen werden kann.

E/A-Leistungsprobleme, die durch ineffiziente Abfragen oder Filtertreiber verursacht werden

Langsame E/A-Vorgänge können durch Abfragen verursacht werden, die nicht effizient geschrieben wurden oder nicht ordnungsgemäß mit Indizes und Statistiken abgestimmt sind. Ein weiterer gängiger Faktor bei der E/A-Latenz ist das Vorhandensein von Antiviren- oder anderen Sicherheitsprogrammen, die Datenbankdateien überprüfen. Diese Software für Sicherheitsscans kann sich auf die Netzwerkschicht erstrecken, wodurch eine Netzwerklatenz eingeführt wird, die sich wiederum indirekt auf die Datenbanklatenz auswirkt. Obwohl das beschriebene Szenario über 15-Sekunden-E/A häufiger bei Hardwarekomponenten vorkommt, wird eine kleinere E/A-Latenz häufiger mit nicht optimierten Abfragen oder falsch konfigurierten Antivirenprogrammen beobachtet.

Ausführliche Informationen zur Behebung dieser Probleme finden Sie unter Problembehandlung bei langsamer SQL Server-Leistung, die durch E/A-Probleme verursacht wird.

Informationen zum Konfigurieren des Antivirenschutzes auf SQL Server finden Sie unter Konfigurieren von Antivirensoftware für die Arbeit mit SQL Server.

Schreibzwischenspeicherung in Speichercontrollern

E/A-Übertragungen, die ohne die Verwendung eines Caches ausgeführt werden, können aufgrund von Festplattendrehraten, der mechanischen Zeit, die zum Verschieben der Laufwerkköpfe und andere Begrenzungsfaktoren erforderlich ist, erheblich länger sein. SQL Server-Installationen sind auf Systeme ausgerichtet, die Zwischenspeicherungscontroller bereitstellen. Diese Controller deaktivieren die Caches auf dem Datenträger und stellen stabile Mediencaches bereit, um SQL Server-E/A-Anforderungen zu erfüllen. Sie vermeiden Leistungsprobleme im Zusammenhang mit der Speichersuche und Schreibzeiten mithilfe der verschiedenen Optimierungen des Zwischenspeicherungscontrollers.

Hinweis

Einige Speicheranbieter verwenden persistenten Speicher (PMEM) als Speicher anstelle eines Caches, wodurch die Gesamtleistung verbessert werden kann. Weitere Informationen finden Sie unter Konfigurieren von persistentem Speicher (PMEM) für SQL Server unter Windows und Konfigurieren von persistentem Speicher (PMEM) für SQL Server für Linux.

Die Verwendung eines Schreibcache-Speichercontrollers (auch als Zurückschreibcache bezeichnet) kann die Leistung von SQL Server verbessern. Schreibcache-Controller und Speichersubsysteme sind für SQL Server sicher, wenn sie für die Verwendung in einer datenbankkritischen Datenbankverwaltungssystem-Umgebung (Data Critical Transactional Database Management System, DBMS) konzipiert sind. Diese Entwurfsfeatures müssen zwischengespeicherte Daten beibehalten, wenn ein Systemfehler auftritt. Die Verwendung einer externen unterbrechungsfreien Stromversorgung (USV) ist in der Regel hierfür nicht ausreichend, da Fehlermodi auftreten können, die nicht mit Strom verbunden sind.

Zwischenspeicherungscontroller und Speichersubsysteme können von SQL Server sicher verwendet werden. Die meisten neuen zweckorientierten Serverplattformen, die diese integrieren, sind sicher. Sie sollten sich jedoch an Ihren Hardwareanbieter wenden, um sicherzustellen, dass das Speichersubsystem getestet und für die Verwendung in einer datenkritischen Transaktions-Managementsystem für relationale Datenbanken (RDBMS) genehmigt wurde.

Write-Ahead-Protokollierung

SQL Server-Datenänderungsanweisungen generieren logische Seitenschreibvorgänge. Dieser Datenstrom von Schreibvorgängen kann so dargestellt werden, dass er an zwei Stellen fließt: zum Protokoll und der Datenbank selbst. Aus Leistungsgründen verschärft SQL Server Schreibvorgänge in die Datenbank über ein eigenes Zwischenspeicherpuffersystem. Schreibvorgänge in das Protokoll werden nur vorübergehend bis zur COMMIT Zeit verzögert. Sie werden nicht auf die gleiche Weise zwischengespeichert wie Datenschreibvorgänge. Da Protokollschreibvorgänge für eine bestimmte Seite immer vor den Datenschreibvorgängen der Seite stehen, wird das Protokoll manchmal als Write-Ahead-Protokoll (WAL) bezeichnet.

WAL-Protokoll (Write-Ahead Logging)

Der Begriff Protokoll ist eine hervorragende Möglichkeit, WAL zu beschreiben. Das von SQL Server verwendete WAL wird als ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) bezeichnet. Weitere Informationen finden Sie unter Schnellere Datenbankwiederherstellung verwalten.

Es handelt sich um einen bestimmten und definierten Satz von Implementierungsschritten, die erforderlich sind, um sicherzustellen, dass Daten ordnungsgemäß gespeichert und ausgetauscht werden und im Falle eines Fehlers in einen bekannten Zustand wiederhergestellt werden können. Ebenso wie ein Netzwerk ein definiertes Protokoll zum Austausch von Daten auf konsistente und geschützte Weise enthält, beschreibt auch das WAL das Protokoll zum Schutz von Daten. Alle Versionen von SQL Server öffnen die Protokoll- und Datendateien mithilfe der Win32-Funktion CreateFile. Das dwFlagsAndAttributes-Mitglied enthält die FILE_FLAG_WRITE_THROUGH-Option, wenn es von SQL Server geöffnet wird.

FILE_FLAG_WRITE_THROUGH

SQL Server erstellt seine Datenbankdateien mithilfe des FILE_FLAG_WRITE_THROUGH Flags. Diese Option weist das System an, über jeden zwischengeschalteten Cache zu schreiben und direkt zum Speicher zu wechseln. Das System kann Schreibvorgänge weiterhin zwischenspeichern, sie aber nicht verzögert leeren. Weitere Informationen finden Sie unter CreateFileA.

Die FILE_FLAG_WRITE_THROUGH-Option stellt sicher, dass die Daten ordnungsgemäß im stabilen Speicher gespeichert werden, wenn ein Schreibvorgang erfolgreich abgeschlossen wird. Dies entspricht der Protokollspezifikation „Write Ahead Logging (WAL)“, um die Daten sicherzustellen. Viele Speichervorrichtungen (NVMe, PCIe, SATA, ATA, SCSI und IDE-basiert) enthalten Onboard-Caches von 512 KB, 1 MB und höher. Speichercaches basieren in der Regel auf einem Kondensator und nicht auf einer batteriegestützten Lösung. Diese Zwischenspeicherungsmechanismen können keine Schreibvorgänge über einen Stromzyklus oder einen ähnlichen Ausfallpunkt garantieren. Sie garantieren nur die Fertigstellung der Sektorschreibvorgänge. Da die Größe der Speichervorrichtungen weiterhin zunimmt, werden die Caches größer, und sie können größere Datenmengen während eines Fehlers verfügbar machen.

Weitere Informationen zur Unterstützung für FUA durch Linux-Distributionen und zu den Auswirkungen auf SQL Server finden Sie unter SQL Server On Linux: Forced Unit Access (FUA) Internals (SQL Server für Linux: Informationen zu FUA (Forced Unit Access)).

Transaktionsintegrität und SQL Server-Wiederherstellung

Transaktionsintegrität ist eines der grundlegenden Konzepte eines relationalen Datenbanksystems. Transaktionen gelten als atomare Arbeitseinheiten, die entweder vollständig angewendet oder vollständig zurückgesetzt werden. Das SQL Server-Transaktionsprotokoll mit Schreibschutz ist eine wichtige Komponente bei der Implementierung der Transaktionsintegrität.

Jedes relationale Datenbanksystem muss sich auch mit einem Konzept in engem Zusammenhang mit der Transaktionsintegrität befassen, bei dem es sich um eine Wiederherstellung von nicht geplanten Systemfehlern handelt. Mehrere nicht ideale, reale Effekte können diesen Fehler verursachen. Bei vielen Datenbankverwaltungssystemen kann ein Systemausfall zu einem langwierigen manuellen Wiederherstellungsprozess führen.

Im Gegensatz dazu ist der SQL Server-Wiederherstellungsmechanismus automatisch und funktioniert ohne menschliche Eingriffe. Beispielsweise könnte SQL Server eine unternehmenskritische Produktionsanwendung unterstützen und aufgrund einer vorübergehenden Stromschwankung einen Systemausfall erleben. Nach der Wiederherstellung der Stromversorgung würde die Serverhardware neu gestartet, Netzwerksoftware würde geladen und initialisiert, und SQL Server würde neu gestartet werden. Bei der Initialisierung von SQL Server wird der Wiederherstellungsvorgang automatisch basierend auf Daten im Transaktionsprotokoll ausgeführt. Dieser gesamte Prozess erfordert kein menschliches Eingreifen. Immer wenn die Clientarbeitsstationen neu gestartet wurden, waren alle Benutzerdaten vorhanden, bis zur letzten Transaktion, die sie eingegeben haben.

Transaktionsintegrität und automatische Wiederherstellung in SQL Server stellen eine leistungsstarke Zeit- und Arbeitseinsparungsfunktion dar. Wenn ein Controller zur Schreibzwischenspeicherung nicht ordnungsgemäß für die Verwendung in einer datenkritischen Transaktions-DBMS-Umgebung konzipiert ist, kann er die Wiederherstellungsfähigkeit von SQL Server kompromittieren, um somit die Datenbank beschädigen. Das kann auftreten, wenn der Controller SQL Server-Transaktionsprotokoll-Schreibvorgänge abfängt und sie in einem Hardwarecache auf dem Controllerboard puffert, behält diese geschriebenen Seiten jedoch während eines Systemfehlers nicht bei.

Schreibcaches und Speichervorrichtungscontroller

Die meisten Controller zur Speichervorrichtungszwischenspeicherung führen die Schreibzwischenspeicherung durch. Die Schreibzwischenspeicherungsfunktion kann nicht immer deaktiviert werden.

Selbst wenn der Server ein USV verwendet, garantiert dies nicht die Sicherheit der zwischengespeicherten Schreibvorgänge. Viele Arten von Systemfehlern können auftreten, die ein USV nicht adressiert. Beispielsweise kann ein Speicherparitätsfehler, ein Betriebssystem-Trap oder ein Hardwarefehler, der zu einer Systemzurücksetzung führt, eine unkontrollierte Systemunterbrechung verursachen. Ein Speicherfehler im Hardwareschreibcache kann auch zu einem Verlust wichtiger Protokollinformationen führen.

Ein weiteres mögliches Problem im Zusammenhang mit einem Schreibcachecontroller kann beim Herunterfahren des Systems auftreten. Es ist nicht ungewöhnlich, das Betriebssystem zu durchlaufen oder das System während Konfigurationsänderungen neu zu starten. Auch wenn ein sorgfältiger Operator der Betriebssystemempfehlung folgt, vor dem Neustart des Systems zu warten, bis alle Speicheraktivitäten abgeschlossen wurden, können zwischengespeicherte Schreibvorgänge weiterhin im Controller vorhanden sein. Wenn die Ctrl+Alt+Del Tastenkombination oder eine Hardware-Rücksetztaste gedrückt wird, können zwischengespeicherte Schreibvorgänge verworfen werden, was die Datenbank potenziell beschädigt.

Es ist möglich, einen Hardwareschreibcache zu entwerfen, der alle möglichen Ursachen für das Verwerfen von geänderten Cachedaten berücksichtigt, was somit für die Verwendung durch einen Datenbankserver sicher wäre. Einige dieser Designfeatures umfassen das Abfangen des RST-Bussignals, um eine unkontrollierte Zurücksetzung des Cachecontrollers, die integrierte Akkusicherung sowie gespiegelten oder ECC-Speicher zu vermeiden. Wenden Sie sich an Ihren Hardwareanbieter, um sicherzustellen, dass der Schreibcache diese und alle anderen Features enthält, die erforderlich sind, um Datenverluste zu vermeiden.

Verwenden von Speichercaches mit SQL Server

Ein Datenbanksystem ist in erster Linie für die genaue Speicherung und das Abrufen von Daten verantwortlich, auch bei unerwarteten Systemfehlern.

Das System muss die Unteilbarkeit und Haltbarkeit von Transaktionen garantieren, wobei die aktuelle Ausführung, mehrere Transaktionen und verschiedene Fehlerpunkte zu berücksichtigen sind. Dies wird häufig als die Eigenschaften ACID (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) bezeichnet.

In diesem Abschnitt werden die Auswirkungen von Speichercaches behandelt. Es wird empfohlen, die folgenden Artikel in der Microsoft Knowledge Base zu lesen, um weitere Erläuterungen zum Zwischenspeichern und alternativen Fehlermodusdiskussionen zu erhalten:

Die folgenden Dokumente werden ebenfalls empfohlen:

Diese beiden Dokumente gelten für alle derzeit unterstützten Versionen von SQL Server.

Lösungen für die akkugestützte Zwischenspeicherung

Verbesserte Zwischenspeicherungscontrollersysteme deaktivieren den Cache auf dem Datenträger und stellen eine funktionsfähige Lösung für die akkugestützte Zwischenspeicherung bereit. Diese Caches können die Daten im Cache mehrere Tage lang beibehalten und sogar zulassen, dass die Cachekarte auf einem zweiten Computer platziert wird. Wenn die Stromversorgung ordnungsgemäß wiederhergestellt wird, werden die nicht geschriebenen Daten vollständig geleert, bevor ein weiterer Datenzugriff zugelassen wird. Viele von ihnen ermöglichen die Einrichtung des Prozentsatzes von Lese- im Vergleich zu Schreibcaches, um eine optimale Leistung zu erzielen. Einige enthalten große Arbeitsspeicherbereiche. Einige Hardwareanbieter bieten akkugestützte High-End-Laufwerk-Caching-Systeme mit mehreren Gigabyte Cache. Diese können die Leistung der Datenbank erheblich verbessern. Die Verwendung von Lösungen für die akkugestützte Zwischenspeicherung bietet Dauerhaftigkeit und Konsistenz von Daten, die SQL Server erwartet.

Implementierungen des Speichersubsystems

Es gibt viele Arten von Subsystemimplementierungen. RAID (Redundant Array of Independent Disks) und SAN (Storage Area Network) sind zwei Beispiele für diese Typen von Subsystemimplementierungen. Diese Systeme werden in der Regel mit SCSI-basierten Laufwerken erstellt. Hierfür gibt es mehrere Gründe: Im folgenden Abschnitt werden allgemeine Überlegungen zum Speichern beschrieben.

SCSI, SAS und NVMe

SCSI-, SAS- und NVMe-Speichergeräte:

  • Werden in der Regel für intensiven Einsatz hergestellt.
  • Werden in der Regel auf serverbasierte Mehrbenutzer-Implementierungen ausgerichtet.
  • Haben in der Regel bessere Meantime-to-Failure als andere Implementierungen.
  • Enthalten anspruchsvolle Heuristiken, um bevorstehende Fehler vorherzusagen.

Nicht-SCSI

Andere Laufwerkimplementierungen wie IDE, ATA und SATA:

  • Werden in der Regel für den leichten und mittelschweren Einsatz hergestellt.
  • Werden in der Regel auf einzelne benutzerbasierte Anwendungen ausgerichtet.

Nicht-SCSI-, Desktop-basierte Controller erfordern mehr Hauptprozessor-Bandbreite (CPU) und sind häufig durch einen einzelnen aktiven Befehl begrenzt. Wenn beispielsweise ein Nicht-SCSI-Laufwerk einen beschädigten Sektor anpasst, erfordert das Laufwerk, dass der Hostbefehl wartet. Der ATA-Bus zeigt ein weiteres Beispiel: Der ATA-Bus unterstützt zwei Geräte, aber nur ein einzelner Befehl kann aktiv sein. Dadurch bleibt ein Laufwerk im Leerlauf, während das andere Laufwerk den ausstehenden Befehl bedient. RAID-Systeme, die auf Desktoptechnologien basieren, können diese Symptome erleben und stark vom langsamsten Reagierenden betroffen sein. Sofern diese Systeme keine erweiterten Designs verwenden, ist ihre Leistung nicht so effizient wie die Leistung von SCSI-basierten Systemen.

Überlegungen zum Speicher

Es gibt Situationen, in denen ein desktopbasiertes Laufwerk oder Array eine geeignete kostengünstige Lösung ist. Wenn Sie z. B. eine schreibgeschützte Datenbank für die Berichterstellung einrichten, sollten Sie nicht auf viele der Leistungsfaktoren einer OLTP-Datenbank stoßen, wenn die Laufwerkzwischenspeicherung deaktiviert ist.

Die Größe von Speichervorrichtungen nimmt weiter zu. Kostengünstige Laufwerke mit hoher Kapazität können attraktiv sein. Wenn Sie jedoch das Laufwerk für SQL Server und Ihre geschäftlichen Antwortzeitanforderungen konfigurieren, sollten Sie die folgenden Probleme berücksichtigen:

  • Zugriffspfad-Entwurf
  • Die Anforderung zum Deaktivieren des Caches auf dem Datenträger

Mechanische Festplatten

Mechanische Laufwerke verwenden rotierende magnetische Scheiben zum Speichern von Daten. Sie sind in mehreren Kapazitäten und Formfaktoren verfügbar, z. B. IDE, SATA, SCSI und Serial Attached SCSI (SAS). Einige SATA-Laufwerke umfassen Fehlervorhersagekonstrukte. SCSI-Laufwerke sind für anspruchsvollere Steuerzyklen und verringerte Ausfallraten ausgelegt.

Die Laufwerkzwischenspeicherung sollte deaktiviert werden, um das Laufwerk mit SQL Server zu verwenden. Der Laufwerkcache ist standardmäßig aktiviert. Verwenden Sie in Windows Server die Registerkarte Datenträgereigenschaften>Hardware, um auf die Registerkarte Eigenschaften>Richtlinie zuzugreifen, um die Einstellung für den Laufwerkcache zu steuern.

Hinweis

Einige Laufwerke berücksichtigen diese Einstellung nicht. Für diese Laufwerke ist ein bestimmtes Herstellerprogramm erforderlich, um den Cache zu deaktivieren.

IDE- und ATA-basierte Systeme können Hostbefehle verschieben, wenn sie Aktivitäten wie die Anpassung eines beschädigten Sektors ausführen. Das könnte zu Perioden mit blockierter E/A-Aktivität führen.

Zu den SAS-Vorteilen gehören komplexere Warteschlangen für bis zu 256 Ebenen sowie das Platzieren am Anfang der Warteschlange und das Abarbeiten der Warteschlange in der falschen Reihenfolge. Die SAS-Backplane ist so konzipiert, dass sowohl SAS- als auch SATA-Laufwerke im selben System verwendet werden können.

Ihre SQL Server-Installation hängt von der Fähigkeit des Controllers ab, den Cache auf dem Datenträger zu deaktivieren und einen stabilen E/A-Cache bereitzustellen. Das Schreiben von Daten in verschiedene Laufwerke in falscher Reihenfolge ist kein Hindernis für SQL Server, solange der Controller die richtigen stabilen Medienzwischenspeicherungsfunktionen bereitstellt. Die Komplexität des Controllerdesigns erhöht sich mit erweiterten Datensicherheitstechniken wie Spiegelung.

Festkörperspeicher

Festkörperspeicher hat Vorteile gegenüber mechanischen (sich drehenden) Festplatten, ist aber anfällig für viele der gleichen Fehlermuster wie sich drehende Medien. Festkörperspeicher sind über verschiedene Schnittstellen mit Ihrem Server verbunden, einschließlich NVM Express (NVMe), PCI Express (PCIe) und SATA. Behandeln Sie die SSD-Medien wie sich drehende Medien, und stellen Sie sicher, dass die geeigneten Schutzmaßnahmen für Stromausfälle vorhanden sind, z. B. ein akkugestützter Cachecontroller.

Häufige Probleme, die durch einen Stromfehler verursacht werden, umfassen:

  • Bitbeschädigung: Datensätze weisen zufällige Bitfehler auf.
  • Fliegende Schreibvorgänge: Wohlgeformte Datensätze enden an der falschen Stelle.
  • Shorn schreibt: Vorgänge werden teilweise auf einer Ebene unter der erwarteten Sektorgröße durchgeführt.
  • Metadatenbeschädigung: Metadaten in FTL sind beschädigt.
  • Nicht reagierendes Gerät: Das Gerät funktioniert überhaupt nicht oder funktioniert meist nicht.
  • Nicht serialisierbar: Der endgültige Speicherzustand ergibt sich nicht aus einer serialisierbaren Vorgangsreihenfolge.

512e

Die meisten Speicher im Festkörperbereich berichten 512-Byte-Sektorgrößen, verwenden aber 4-KB-Seiten innerhalb der 1-MB-Löschblöcke. Die Verwendung von 512-Byte-ausgerichteten Sektoren für das SQL Server-Protokollgerät kann mehr Lese-/Ändern-/Schreibzugriffsaktivitäten (RMW) generieren, was zu langsamerer Leistung und Laufwerkverschleiß beitragen kann.

Empfehlung: Stellen Sie sicher, dass der Controller zur Zwischenspeicherung die richtige Seitengröße der Speichervorrichtung kennt und physische Schreibvorgänge ordnungsgemäß an der Speicherinfrastruktur des Festkörperspeichers ausrichten kann.

0xFFFFFFFF

Ein neu formatiertes Laufwerk enthält in der Regel nur Nullen. Ein gelöschter Block eines Festkörpergeräts ist alle 1s, wodurch ein unformatierter Lesevorgang eines gelöschten Blocks alle 0xFFs erfolgt. Es ist jedoch ungewöhnlich, dass ein Benutzer während normaler E/A-Vorgänge einen gelöschten Block liest.

Musterstempel

Eine Technik, die wir in der Vergangenheit verwendet haben, ist das Schreiben eines bekannten Musters auf das gesamte Laufwerk. Wenn wir dann Datenbankaktivitäten für dasselbe Laufwerk ausführen, können wir falsches Verhalten erkennen (veralteter Lesevorgang / verlorener Schreibvorgang / Lesevorgang von falschem Offset / usw.), wenn das Muster unerwartet angezeigt wird.

Diese Technik funktioniert nicht gut beim Festkörperspeicher. Die Löschungs- und RMW-Aktivitäten für Schreibvorgänge zerstören das Muster. Die automatische Speicherbereinigung bei Festkörperspeichern, Wear-Leveling, proportionale und Set-Aside-Listenblöcke und andere Optimierungen führen dazu, dass Schreibvorgänge unterschiedliche physische Standorte erhalten, im Gegensatz zur Sektor-Wiederverwendung von rotierenden Medien.

Firmware

Die im Festkörperspeicher verwendete Firmware ist im Vergleich zu den Gegenstücken in rotierenden Medien tendenziell komplex. Viele Laufwerke verwenden mehrere Verarbeitungskerne, um eingehende Anforderungen und Garbage Collection-Aktivitäten zu verarbeiten. Stellen Sie sicher, dass Sie die Firmware Ihres Festkörpergeräts auf dem neuesten Stand halten, um bekannte Probleme zu vermeiden.

Schaden beim Lesen von Daten und Wear-Leveling

Ein gängiger Ansatz zu automatischer Speicherbereinigung für den Festkörperspeicher verhindert wiederholte Schäden beim Lesen von Daten. Beim wiederholten Lesen derselben Zelle ist es möglich, dass die Elektronenaktivität durchlecken und zu Schäden an benachbarten Zellen führen kann. Der Festkörperspeicher schützt die Daten mit verschiedenen Ebenen des Fehlerkorrekturcodes (ECC) und anderen Mechanismen.

Ein solcher Mechanismus bezieht sich auf Wear-Leveling. Der Festkörperspeicher verfolgt die Lese- und Schreibaktivität auf der Speichervorrichtung. Die automatische Speicherbereinigung (GC) kann Hotspots oder Orte bestimmen, die schneller als andere Orte verschleißen. Beispielsweise bestimmt die GC, dass sich ein Block für einen bestimmten Zeitraum in einem schreibgeschützten Zustand befindet und verschoben werden muss. Diese Verschiebung ist in der Regel von einem Block mit mehr Verschleiß, sodass der ursprüngliche Block für Schreibvorgänge verwendet werden kann. Das hilft, den Verschleiß auf dem Laufwerk auszugleichen, verschiebt jedoch schreibgeschützte Daten an einen Ort, der mehr Verschleiß hat und mathematisch die Fehlerchancen erhöht, wenn auch leicht.

Ein weiterer Nebeneffekt von Wear-Leveling kann mit SQL Server auftreten. Angenommen, Sie führen DBCC CHECKDB aus, und es meldet einen Fehler. Wenn Sie es ein zweites Mal ausführen, gibt es eine kleine Chance, dass DBCC CHECKDB zusätzliche oder ein anderes Fehlermuster meldet, da die GC-Aktivität im Festkörperspeicher möglicherweise Änderungen zwischen den DBCC CHECKDB Ausführungen vornehmen kann.

Betriebssystemfehler 665 und Defragmentierung

Rotierende Medien müssen Blöcke nahe beieinander halten, um die Lesekopfbewegung des Laufwerks zu reduzieren und die Leistung zu erhöhen. Festkörperspeicher verfügen nicht über den physischen Lesekopf, wodurch die Suchzeit beseitigt wird. Viele Festkörpergeräte sind so konzipiert, dass parallele Vorgänge auf verschiedenen Blöcken parallel ausgeführt werden können. Das bedeutet, dass die Defragmentierung von Festkörpermedien unnötig ist. Serielle Aktivitäten sind die besten E/A-Muster, um den E/A-Durchsatz auf Festkörperspeichergeräten zu maximieren.

Hinweis

Festkörperspeicher profitieren von dem Kürzungsfeature, einem Befehl auf Betriebssystemebene, der Blöcke löscht, die nicht mehr verwendet werden. Verwenden Sie in Windows das Tool Laufwerke optimieren, um einen wöchentlichen Zeitplan für die Optimierung von Laufwerken festzulegen.

Empfehlungen:

  • Verwenden Sie einen geeigneten, akkugestützten Controller, der zum Optimieren von Schreibaktivitäten entwickelt wurde. Das kann die Leistung verbessern, den Verschleiß des Laufwerks und die physische Fragmentierung verringern.

  • Erwägen Sie die Verwendung des ReFS-Dateisystems, um die Einschränkungen des NTFS-Attributs zu vermeiden.

  • Stellen Sie sicher, dass die Dateigrößen entsprechend angepasst sind.

Weitere Informationen zur Problembehandlung bei Betriebssystemfehler 665 im Zusammenhang mit Fragmentierung finden Sie unter Betriebssystemfehler 665 und 1450 werden für SQL Server-Dateien gemeldet.

Komprimierung

Solange das Laufwerk die Absicht eines stabilen Mediums aufrecht erhält, kann die Komprimierung die Lebensdauer des Laufwerks verlängern und die Leistung positiv beeinflussen. Einige Firmware kann jedoch Daten möglicherweise bereits unsichtbar komprimieren. Denken Sie daran, neue Speicherszenarien zu testen, bevor Sie sie in Ihrer Produktionsumgebung bereitstellen.

Zusammenfassung

  • Verwalten Sie ordnungsgemäße Sicherungs- und Notfallwiederherstellungsverfahren und -prozesse.
  • Halten Sie die Firmware auf dem neuesten Stand.
  • Achten Sie genau auf die Anleitungen Ihrer Hardwarehersteller.

Überlegungen zum Cache und SQLIOSim

Um Ihre Daten vollständig zu schützen, sollten Sie sicherstellen, dass alle Datenzwischenspeicherung ordnungsgemäß verarbeitet wird. In vielen Situationen bedeutet das, dass Sie die Schreibzwischenspeicherung des Laufwerks deaktivieren müssen.

Hinweis

Stellen Sie sicher, dass jeder alternative Zwischenspeicherungsmechanismus mehrere Arten von Fehlern ordnungsgemäß verarbeiten kann.

Microsoft hat mithilfe des SQLIOSim-Hilfsprogramms Tests auf mehreren SCSI- und IDE-Laufwerken durchgeführt. Dieses Hilfsprogramm simuliert schwere asynchrone Lese-/Schreibaktivitäten auf einem simulierten Datengerät und Protokollgerät. Weitere Informationen und Details zu SQLIOSim finden Sie unter Verwenden des SQLIOSim-Hilfsprogramms zum Simulieren der SQL Server-Aktivität auf einem Datenträgersubsystem.

Viele PC-Hersteller bestellen die Laufwerke mit deaktiviertem Schreibcache. Tests zeigen jedoch, dass das möglicherweise nicht immer der Fall ist, daher sollten Sie sie immer vollständig testen. Wenn Sie Fragen zum Zwischenspeicherungsstatus Ihres Speichergeräts haben, wenden Sie sich an den Hersteller, und rufen Sie die entsprechenden Hilfsprogramm- oder Jumper-Einstellungen ab, um Schreibzwischenspeicherungsvorgänge zu deaktivieren.

SQL Server erfordert, dass Systeme die garantierte Übermittlung an stabile Medien unterstützen, wie unter den SQL Server-E/A-Zuverlässigkeitsprogrammanforderungen beschrieben. Weitere Informationen zu den Eingabe- und Ausgabeanforderungen für die SQL Server-Datenbank-Engine finden Sie unter SQL Server Datenbank-Engine Anforderungen für Datenträgereingabe/-ausgabe (E/A).

Zugehöriger Inhalt