Grundlagen zur SQL Server-E/A

Gilt für:SQL ServerVerwaltete Azure SQL-InstanzSQL Server auf virtuellen Azure-Computern

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 in den aufrufenden Threads ausgestellt, es sei denn, die Affinitätsoption ist in Nutzung. 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. Dieser Prozess hilft dem Systemadministrator, zwischen SQL Server-Problemen und E/A-Subsystemproblemen zu 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.

Ein langer E/A-Vorgang kann entweder ein Lese- oder Schreibzugriff sein; die Nachricht gibt derzeit nicht an, welcher. 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 helfen dem Systemadministrator, die Ursache für schlechte SQL Server-Antwortzeiten schneller zu finden und Probleme zu unterscheiden, die außerhalb der Kontrolle von SQL Server liegen. 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 lange E/A-Nachricht kann darauf hinweisen, dass eine E/A dauerhaft blockiert ist und nie abgeschlossen wird (als verlorene E/A bezeichnet), oder nur, dass sie noch nicht abgeschlossen ist. Sie können aus der Meldung nicht erkennen, welches Szenario der Fall ist, obwohl eine verlorene Eingabe/Ausgabe häufig zu einem Riegeltimeout führt.

Langsame E/A weisen häufig auf eine SQL Server-Workload hin, die für das Datenträgersubsystem zu intensiv ist. 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.

Eine Komponente im E/A-Pfad (z. B. ein Treiber, Controller oder die Firmware) kann lange E/A verursachen, indem sie die Bearbeitung einer alten E/A-Anforderung kontinuierlich zugunsten der Bearbeitung neuerer Anfragen aufschiebt. Dieses Problem kann in miteinander verbundenen Umgebungen auftreten, z. B. in iSCSI- und Fibre Channel-Netzwerken (entweder aufgrund einer Fehlkonfiguration oder eines Pfadfehlers). Das Tool "Leistungsüberwachung" kann es erschweren, dieses Problem zu bestätigen, da die meisten Ein-/Ausgabeoperationen umgehend bearbeitet werden. Workloads, die große Mengen sequenzieller E/A ausführen, wie z. B. Datensicherung und -wiederherstellung, Tabellenscans, das Sortieren von Daten, das Erstellen von Indizes, Massendatenverarbeitung und das Zurücksetzen von Dateien, können lange E/A-Anforderungen verschärfen.

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 oder ordnungsgemäß mit Indizes und Statistiken abgestimmt wurden. 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 von 15 Sekunden E/A beschriebene Szenario mit Hardwarekomponenten häufiger auftritt, werden kürzere Verzögerungen bei E/A-Prozessen häufiger bei unoptimierten 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 keinen Cache verwenden, können erheblich länger dauern, aufgrund von Festplattendrehraten, der mechanischen Zeit, die benötigt wird, um die Laufwerkköpfe zu bewegen, und anderen Begrenzungsfaktoren. SQL Server-Installationen richten sich an Systeme, 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. Schreibzwischenspeicherungscontroller und Speichersubsysteme sind für SQL Server sicher, wenn sie für die Verwendung in einer datenkritischen Datenbankverwaltungsumgebung (DBMS) konzipiert sind. Diese Entwurfsfeatures müssen zwischengespeicherte Daten beibehalten, wenn ein Systemfehler auftritt. Die Verwendung einer externen uninterruptiblen Stromversorgung (USV) zum Erreichen dieses Schutzes reicht in der Regel nicht aus, da Fehlermodi auftreten können, die nicht mit Strom verbunden sind.

Important

SQL Server hängt von der garantierten Übermittlung an stabile Medien für transaktionsale Integrität und Wiederherstellung ab. Unsicheres Zwischenspeichern, das nicht sicherstellt, dass Daten bei Fehlern bewahrt werden, kann Datenbanken beschädigen, unabhängig von der Konsistenz der Transaktionsprotokolle. Stellen Sie immer sicher, dass jeder Schreibzwischenspeicherungsmechanismus volle Dauerhaftigkeitsgarantien bietet.

Zwischenspeicherungscontroller und Speichersubsysteme können von SQL Server sicher verwendet werden. Die meisten neuen speziell entwickelten Serverplattformen, die diese Controller enthalten, sind sicher. Sie sollten sich jedoch an Ihren Hardwareanbieter wenden, um sicherzustellen, dass das Speichersubsystem getestet und für die Verwendung in einer datenkritischen relationalen Datenbankverwaltungsumgebung (RDBMS) genehmigt wurde.

Sicherheitsrichtlinien für Cachesubsysteme

Write-Back-Cache-Controller können die Leistung verbessern, wenn sie bestimmte Sicherheitsanforderungen erfüllen.

  • Schließen Sie akkugestützten Cache oder nicht veränderliche Speicher ein, z. B. NVDIMM oder Superkondensator-gesicherten Flash.
  • Werden Sie vom Anbieter für datenkritische OLTP-Datenbankumgebungen zertifiziert.
  • Bieten Sie Schutz, der alle Fehlerbedingungen abdeckt, nicht nur Stromverlust.

Important

Verlassen Sie sich nicht allein auf ein externes UPS. Fehler, die nicht mit Strom verbunden sind, z. B. Firmwarefehler oder Hardwarefehler, können dennoch zu Cacheverlusten führen.

Write-Ahead-Protokollierung

SQL Server-Datenänderungsanweisungen generieren logische Seitenschreibvorgänge. Sie können diesen Schreibstrom an zwei Stellen darstellen: das Protokoll und die Datenbank selbst. Aus Leistungsgründen verzögert der SQL Server Schreibvorgänge in die Datenbank durch sein eigenes Cachepuffersystem. Das System verschiebt Schreibvorgänge in das Protokoll nur kurzzeitig bis zur COMMIT Zeit. Diese Schreibvorgänge 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 Schreib-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, aber es kann sie nicht auf träge Weise flushen. Weitere Informationen finden Sie unter CreateFileA.

Die FILE_FLAG_WRITE_THROUGH Option stellt sicher, dass die Daten korrekt im stabilen Speicher gespeichert werden, wenn ein Schreibvorgang erfolgreich abgeschlossen wird. Dieses Feature entspricht der Write-Ahead Protokollierungsprotokollspezifikation (WAL), um die Datenintegrität 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 sind 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 des Stroms wird die Serverhardware neu gestartet, Netzwerksoftware wird geladen und initialisiert, und SQL Server wird neu gestartet. Bei der Initialisierung von SQL Server wird der Wiederherstellungsvorgang automatisch basierend auf Daten im Transaktionsprotokoll ausgeführt. Dieser gesamte Prozess erfordert kein menschliches Eingreifen. Wenn Clientarbeitsstationen neu gestartet werden, finden Benutzer alle ihre Daten, 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 Schreibcache-Controller nicht ordnungsgemäß für die Verwendung in einer kritischen DBMS-Umgebung mit hohem Datenaufkommen konzipiert ist, kann das die Fähigkeit von SQL Server zur Wiederherstellung beeinträchtigen und möglicherweise die Datenbank beschädigen. Dieses Problem kann auftreten, wenn der Controller SQL Server-Transaktionsprotokoll-Schreibvorgänge abfängt und sie in einem Hardwarecache auf dem Controllerboard puffert, diese geschriebenen Seiten jedoch bei einem Systemausfall nicht beibehält.

Warning

Wenn zwischengespeicherte Schreibvorgänge aufgrund eines Systemneustarts verworfen werden, kann die Datenbankbeschädigung auch dann auftreten, wenn eine unterbrechungsfreie Stromversorgung vorhanden ist. Stellen Sie immer sicher, dass Schreibcaches durch Akku oder gleichwertige Technologie gesichert werden, um die Datenpersistenz zu gewährleisten.

Risiken beim Zwischenspeichern auf dem Datenträger

Die meisten Controller zur Speichervorrichtungszwischenspeicherung führen die Schreibzwischenspeicherung durch. Sie können die Schreibzwischenspeicherungsfunktion nicht immer deaktivieren.

Selbst wenn der Server eine UPS verwendet, garantiert das Gerät 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 schmutzigen Cachedaten berücksichtigt, was die Verwendung durch einen Datenbankserver sicher macht. Einige dieser Designfeatures umfassen das Abfangen des RST-Bussignals (Reset), um eine unkontrollierte Zurücksetzung des Cache-Controllers zu vermeiden, Batterie-Backup an Bord sowie gespiegelter oder fehlertoleranter Speicher (ECC). 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. Diese Eigenschaft wird häufig als die Eigenschaften ACID (Atomität, Konsistenz, Isolation und Haltbarkeit) bezeichnet.

In diesem Abschnitt werden die Auswirkungen von Speichercaches behandelt. Weitere Informationen zum Zwischenspeichern und alternativen Fehlermodusdiskussionen finden Sie in den folgenden Artikeln:

Überprüfen Sie außerdem die folgenden archivierten Inhalte:

Die Konzepte in diesen beiden Artikeln gelten weitgehend für aktuelle 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 dieser Systeme ermöglichen es Ihnen, einen Prozentsatz des Lese- und Schreibcaches einzurichten, um eine optimale Leistung zu erzielen. Einige Systeme enthalten große Speicherbereiche. Einige Hardwareanbieter bieten akkugestützte High-End-Laufwerk-Caching-Systeme mit mehreren Gigabyte Cache. Diese Systeme können die Datenbankleistung erheblich verbessern. Lösungen für die akkugestützte Zwischenspeicherung bieten die Haltbarkeit und Konsistenz von Daten, die SQL Server erwartet.

Implementierungen des Speichersubsystems

Speichersubsysteme sind in vielen Typen vorhanden. Zwei häufige Beispiele sind RAID (redundantes Array unabhängiger Datenträger) und SAN (Speicherbereichsnetzwerk). Diese Systeme verwenden in der Regel SCSI-basierte Laufwerke. Im folgenden Abschnitt werden Überlegungen zur Speicherung auf hoher Ebene beschrieben.

SCSI, SAS und NVMe

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

  • Sind in der Regel für den einsatzintensiven Einsatz konzipiert.
  • Werden in der Regel auf serverbasierte Mehrbenutzer-Implementierungen ausgerichtet.
  • In der Regel haben sie eine bessere mittlere Zeit zwischen Ausfällen als andere Implementierungen.
  • Enthalten anspruchsvolle Heuristiken, um bevorstehende Fehler vorherzusagen.

Hinweis

SQL Server unterstützt ISCSI-Technologiekomponenten (Internet Small Computer System Interface), die den Anforderungen des Windows-Hardwarekompatibilitätsprogramms entsprechen. Obwohl SQL Server nicht direkt mit iSCSI interagiert, funktioniert es nahtlos, da Windows iSCSI-Speicher als Standardlaufwerke darstellt. SQL Server kann dann von IP-Netzwerken aus lesen und in Remotespeicher auf Blockebene schreiben. Da iSCSI von Netzwerken abhängt, können Verzögerungen oder Engpässe auftreten. Stellen Sie sicher, dass die Leistung des Zwischenspeicherns des Servers optimal ist, und die Latenz wird minimiert. Weitere Informationen finden Sie unter iSCSI-Zielserver-Skalierbarkeitsgrenzwerte.

Nicht-SCSI

Andere Laufwerkimplementierungen wie IDE, ATA und SATA:

  • Sind in der Regel für den leichten bis mittleren Einsatz konzipiert.
  • Sind in der Regel auf Einzelbenutzeranwendungen ausgerichtet.

Nicht-SCSI-desktopbasierte Controller erfordern mehr CPU-Bandbreite, da sie häufig durch einen einzelnen aktiven Befehl begrenzt sind. 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. Diese Einschränkung lässt ein Laufwerk im Leerlauf, während das andere Laufwerk den ausstehenden Befehl bearbeitet. 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

Ein desktopbasiertes Laufwerk oder Array kann eine kostengünstige Lösung für einige Situationen sein. Wenn Sie beispielsweise eine schreibgeschützte Datenbank für die Berichterstellung einrichten, treten nicht viele der Leistungsfaktoren einer OLTP-Datenbank auf, wenn die Laufwerkzwischenspeicherung deaktiviert ist.

Die Größe von Speichervorrichtungen nimmt weiter zu. Preisgünstige Festplatten mit hoher Speicherkapazität können attraktiv sein. Berücksichtigen Sie sorgfältig beim Konfigurieren des Laufwerks für SQL Server und die Anforderungen Ihrer geschäftlichen Reaktionszeiten die folgenden Aspekte:

  • 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.

IDE- und ATA-basierte Systeme können Hostbefehle verschieben, wenn sie Aktivitäten ausführen, z. B. eine fehlerhafte Blockanpassung, was zu Perioden blockierter E/A-Aktivität führt.

SAS-Vorteile umfassen erweiterte Warteschlangen bis zu 256 Ebenen sowie Head-of-Queue- und Out-of-Order-Warteschlangen. 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, aber es ist anfällig für viele der gleichen Fehlermuster wie spinnende Medien. Sie können den Festkörperspeicher über verschiedene Schnittstellen wie NVM Express (NVMe), PCI Express (PCIe) und SATA mit Ihrem Server verbinden. 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 zeigen zufällige Bitfehler an.
  • Renn- + Flugspiele schreiben: Wohlgeformte Datensätze landen im falschen Bereich.
  • Shorn schreibt: Operationen werden teilweise auf einer Ebene unterhalb der erwarteten Sektorgröße ausgeführt.
  • Metadatenbeschädigung: Metadaten auf der Flash-Übersetzungsebene (Flash Translation Layer, FTL) sind beschädigt.
  • Reagiert nicht Gerät: Gerät funktioniert überhaupt nicht oder funktioniert meistens nicht.
  • Unserialisierbarkeit: Der Endzustand des Speichers resultiert nicht aus einer seriellen Operationsreihenfolge.

512e

Die meisten Speichergeräte mit festem Zustand melden 512-Byte-Branchengrößen, verwenden jedoch 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 Zwischenspeicher-Controller über die korrekte Seitengröße der Speichervorrichtung informiert ist und physische Schreibvorgänge ordnungsgemäß mit der Festkörperspeicher-Infrastruktur ausrichten kann.

0xFFFFFFFF

Ein neu formatiertes Laufwerk enthält in der Regel nur Nullen. Ein gelöschter Block eines Solid-State-Geräts besteht vollständig aus 1. Daher ergibt ein unformatierter Lesevorgang eines gelöschten Blocks alle 0xFF Zeichen. Es ist jedoch ungewöhnlich, dass ein Benutzer während normaler E/A-Vorgänge einen gelöschten Block liest.

Musterstempel

Eine in der Vergangenheit verwendete Technik besteht darin, ein bekanntes Muster auf das gesamte Laufwerk zu schreiben. Wenn die Datenbankaktivität dann mit demselben Laufwerk ausgeführt wird, kann ein falsches Verhalten (veraltetes Lesen, verlorenes Schreiben oder Lesen eines falschen Offsets) erkannt werden, 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 Garbage Collection (GC)-Aktivität von Solid-State-Speichern, Verschleißausgleich, proportionale und reservierte Listenblöcke und andere Optimierungen führen dazu, dass Schreibvorgänge unterschiedliche physische Standorte zugewiesen bekommen, im Gegensatz zur Sektorwiederverwendung bei drehenden 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 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. Dieser Prozess hilft, den Verschleiß des Laufwerks auszugleichen, verschiebt jedoch schreibgeschützte Daten an eine stärker abgenutzte Stelle und erhöht mathematisch die Ausfallwahrscheinlichkeit, auch wenn nur geringfügig.

Ein weiterer Nebeneffekt des Verschleißausgleichs 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ügt nicht über einen physischen Kopf, wodurch die Suchzeit beseitigt wird. Viele Festkörpergeräte sind so konzipiert, dass parallele Vorgänge auf verschiedenen Blöcken möglich sind. Die Defragmentierung von Festkörpermedien ist daher unnötig. 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. Diese Entscheidung kann die Leistung verbessern, den Verschleiß des Laufwerks reduzieren und 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 Einstellungen für das Dateiwachstum geeignet 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 Zielsetzung eines stabilen Speichers beibehält, kann die Komprimierung die Lebensdauer des Laufwerks verlängern und möglicherweise die Leistung verbessern. 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 Anleitung ihres Hardwareherstellers.

Laufwerkcachekonfiguration

Um ein Laufwerk mit SQL Server zu verwenden, deaktivieren Sie die Laufwerkzwischenspeicherung. Der Laufwerkcache ist standardmäßig aktiviert. Verwenden Sie in Windows Server die Registerkarte "Hardwarerichtlinie> für Datenträgereigenschaften>", um die Schreibzwischenspeicherung auf Betriebssystemebene zu deaktivieren.

Verlassen Sie sich nicht allein auf Einstellungen auf Betriebssystemebene. Einige Laufwerke ignorieren Windows-Einstellungen und erfordern vom Hersteller bereitgestellte Dienstprogramme oder Firmwareeinstellungen, um die Schreibzwischenspeicherung zu deaktivieren. Vergewissern Sie sich über Anbietertools, dass die Schreibzwischenspeicherung tatsächlich deaktiviert ist.

Hinweis

Auch wenn die Schreibzwischenspeicherung deaktiviert ist, kann die Laufwerkfirmware interne Optimierungen einführen, mit denen Leerungsbefehle verzögert werden. Überprüfen Sie immer den effektiven Cachestatus vor der Bereitstellung mithilfe von Testtools wie SQLIOSim.

Überlegungen zum Cache und SQLIOSim

Um transaktionsbezogene Haltbarkeitsgarantien zu bestätigen, überprüfen Sie Ihr E/A-Subsystem mithilfe von SQLIOSim , bevor Sie zur Produktion wechseln. Dieses Hilfsprogramm simuliert schwere asynchrone Lese- und Schreibaktivitäten auf einem simulierten Datengerät und Protokollgerät. Weitere Informationen finden Sie unter Verwenden des SQLIOSim-Hilfsprogramms zum Simulieren der SQL Server-Aktivität auf einem Datenträgersubsystem.

Hinweis

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

Viele PC-Hersteller bestellen die Laufwerke mit deaktiviertem Schreibcache. Tests zeigen jedoch, dass diese Bedingung möglicherweise nicht immer der Fall ist, daher sollten Sie sie immer vollständig testen. Wenn Sie Fragen zum Cachestatus Ihres Speichergeräts haben, wenden Sie sich an den Hersteller, und rufen Sie das entsprechende Hilfsprogramm ab, um Schreibzwischenspeicherungsvorgänge zu deaktivieren. Bei älteren Speichermedien brauchen Sie möglicherweise auch Jumper-Konfigurationen.

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).

Risiken durch fehlerhafte Schreibcache-Methoden

Wenn Sie die Schreibzwischenspeicherung ohne geeignete Schutzmaßnahmen aktivieren, bestätigen einige Speichersubsysteme Schreibvorgänge als abgeschlossen, bevor Daten sicher in dauerhafte Medien geschrieben werden. Wenn ein Stromausfall oder Systemausfall auftritt, kann dies zu folgendem Ergebnis führen:

  • Datenverlust, bei dem zugesicherte Transaktionen nie beibehalten werden.
  • Datenbankbeschädigung aufgrund fehlerhafter Schreibreihenfolgegarantien.

Important

Deaktivieren Sie die Schreibzwischenspeicherung für SQL Server-Daten- und Protokolllaufwerke, es sei denn, Sie bestätigen die Dokumentation des Hardwareanbieters, dass:

  • Der Cache wird batteriegesichert oder verwendet beständigen Flashspeicher.
  • Das Laufwerk gewährleistet Langlebigkeit trotz Stromausfällen und Systemabstürzen.

Externe UPS-Geräte sind nicht ausreichend, da sie möglicherweise nicht vor allen Fehlermodi schützen, z. B. ein Controller-Firmwarefehler.

Zugehöriger Inhalt

  • Last updated on