MSSQLSERVER_833

  • Artikel

Gilt für:SQL ServerAzure SQL Managed Instance

Details

attribute Wert
Produktname SQL Server
Ereignis-ID 833
Ereignisquelle MSSQLSERVER
Komponente SQLEngine
Symbolischer Name BUF_LONG_IO
Meldungstext Bei %d E/A-Anforderungen von SQL Server wurden mehr als %d Sekunden zum Abschließen des Vorgangs für die Datei [%ls] in der Datenbank [%ls] (%d) benötigt . Das Dateihandle des Betriebssystems lautet 0x%p. Der Offset des letzten langen E/A-Vorgangs lautet: %#016I64x.

Erklärung

Diese Meldung gibt an, dass SQL Server eine Lese- oder Schreibanforderung vom Datenträger ausgestellt hat und dass die Anforderung länger als 15 Sekunden dauerte, um zurückzugeben. Der SQL Server meldet diesen Fehler und weist auf ein Problem mit dem E/A-Subsystem hin. Ein Datenbankverwaltungssystem (DbMS), z. B. SQL Server, basiert auf den Zeitleiste von Dateieingabe- und Ausgabevorgängen (E/A). Eines der folgenden Elemente kann dazu führen, dass E/A-Vorgänge hängen bleiben oder hängen bleiben und sich negativ auf die Reaktionsfähigkeit und Leistung von SQL Server auswirken:

  • Fehlerhafte Hardware
  • Falsch konfigurierte Hardware
  • Firmwareeinstellungen
  • Filtertreiber
  • Komprimierung
  • Fehler
  • Andere Bedingungen im E/A-Pfad

Diese E/A-Probleme können dazu führen, dass das folgende Verhalten auftritt:

  • Blockieren.
  • Latch-Inhalte und Timeouts.
  • Langsame Reaktion.
  • Strecken von Ressourcengrenzen.
  • Sie können auch andere Symptome bemerken, die mit dieser Nachricht verbunden sind, z. B.:
    • Hohe Wartezeiten für PAGEIOLATCH-Wartezeiten.
    • Warnungen oder Fehler im Systemereignisprotokoll.
    • Hinweise auf Datenträgerlatenzprobleme in Systemmonitorzählern.

Wenn ein E/A-Vorgang 15 Sekunden oder länger aussteht, führt SQL Server die folgenden Schritte aus:

  1. Erkennt, dass ein Vorgang aussteht.

  2. Schreibt eine Informationsmeldung in das SQL Server-Fehlerprotokoll, wie im Abschnitt "Details" beschrieben.

    Erläuterungen zu verschiedenen Abschnitten dieser Informationsmeldung finden Sie in der folgenden Tabelle:

Meldungstext Beschreibung
<Anzahl> vorkommen(n) Die Anzahl der E/A-Anforderungen, die den Lese- oder Schreibvorgang nicht in weniger als 15 Sekunden abgeschlossen haben.
Dateiinformationen Der vollständige Dateiname, Der Datenbankname und die Datenbankidentifikationsnummer (DBID).
Handle Das Betriebssystemhandle der Datei. Sie können das Betriebssystemhandle mit Debuggern oder anderen Hilfsprogrammen verwenden, um I/O-Anforderungspakete (IRP)-Anforderungen nachzuverfolgen.
Abstand Der Offset des letzten hängen gebliebenen E/A-Vorgangs oder des letzten festgefahrenen E/A-Vorgangs. Sie können den Offset mit Debuggern oder anderen Hilfsprogrammen verwenden, um IRP-Anforderungen nachzuverfolgen.

Hinweis:
Wenn die Informationsmeldung in das SQL Server-Fehlerprotokoll geschrieben wird, bleibt der E/A-Vorgang möglicherweise nicht mehr hängen oder stagniert.

Mögliche Ursachen

Die Informationsmeldung gibt an, dass die aktuelle Last eine der folgenden Bedingungen aufweist:

  • Die Arbeitsauslastung überschreitet die E/A-Pfadfunktionen entweder aufgrund einer fehlkonfigurierten Konfiguration des E/A-Subsystems (SAN, NAS und direct attached), oder weil die Hardwarekapazität erreicht wurde.
  • Die Arbeitsauslastung überschreitet die aktuellen Systemfunktionen, z. B. E/A, CPUs und HBAs.
  • Der E/A-Pfad verfügt über fehlfunktionierende Software. Es kann sich um firmware- oder treiberproblem.
  • Der E/A-Pfad verfügt über fehlerhafte Hardwarekomponenten.
  • Leistungsproblem auf Betriebssystemebene.
  • Filtertreibereingriff im E/A-Prozess oder Speicherpfad von Datenbankdateien. Beispiel: Antivirenprogramm.

SQL Server zeichnet die Uhrzeit auf, zu der eine E/A-Anforderung initiiert wurde, und zeichnet die Uhrzeit auf, zu der die E/A abgeschlossen wurde. Wenn der Unterschied zwischen diesen beiden Zeitpunkten 15 Sekunden oder mehr beträgt, wird diese Bedingung erkannt. Dies bedeutet auch, dass SQL Server nicht die Ursache der verzögerten E/A-Bedingung ist, die diese Nachricht beschreibt und Berichte beschreibt. Diese Bedingung wird als blockierte E/A bezeichnet. Die meisten Datenträgeranforderungen erfolgen mit der typischen Geschwindigkeit des Datenträgers. Diese typische Datenträgergeschwindigkeit wird häufig als Datenträgersuchezeit bezeichnet. Die Datenträgersuchzeit bei den meisten Standarddatenträgern beträgt 10 Millisekunden oder weniger. Daher ist 15 Sekunden lange Zeit für den System-E/A-Pfad, um zu SQL Server zurückzukehren. Weitere Informationen finden Sie im Abschnitt "Weitere Informationen ".

Aktion des Benutzers

Beheben Sie diesen Fehler, indem Sie die folgenden Schritte ausführen:

  1. Überprüfen Sie das Systemereignisprotokoll auf hardwarebezogene Fehlermeldungen.
  2. Überprüfen Sie hardwarespezifische Protokolle, wenn sie verfügbar sind. Verwenden Sie die erforderlichen Methoden und Techniken, um die Ursache der Verzögerung im Betriebssystem, den Treibern oder der E/A-Hardware zu ermitteln.
  3. Aktualisieren Sie alle Gerätetreiber und Firmware, oder führen Sie andere Diagnose aus, die Ihrem E/A-Subsystem zugeordnet sind.
  4. Der Datenträgerzugriff kann durch Filtertreiber verlangsamt werden, z. B. ein Antivirenprogramm. Um die Zugriffsgeschwindigkeit zu erhöhen, schließen Sie die SQL Server-Datendateien aus, die in der Fehlermeldung von den aktiven Virenscans angegeben sind. Weitere Informationen finden Sie unter Auswählen von Antivirensoftware, die auf Computern ausgeführt werden soll, auf denen SQL Server (microsoft.com) ausgeführt wird.
    • Verwenden Sie das Befehlszeilenprogramm fltmc.exe, um alle auf dem System installierten Filtertreiber abzufragen und die Funktionen zu verstehen, die sie auf dem Speicherpfad der Datenbankdateien ausführt.
  5. Verwenden Sie die Leistungsmonitor, um die folgenden Leistungsindikatoren zu untersuchen:
    • Average Disk Sec/Transfer
    • Average Disk Queue Length
    • Current Disk Queue Length
  6. Sie können auch Einrichtungen wie storport ETW-Protokollierung verwenden, um die Latenz von Anforderungen zu messen, die an einer Datenträgereinheit vorgenommen werden. Ein weiteres ähnliches Kit für die Problembehandlung bei E/A-Vorgängen ist als integriertes Profil Windows Performance Recorder verfügbar.
  7. Überwachen Sie sys.dm_io_virtual_file_stats , und wählen Sie die entsprechende Speicherebene und IOPS für Ihren Speicherdurchsatz aus.

Eine geführte exemplarische Vorgehensweise zur Diagnose und Problembehandlung von SQL Server-Leistungsproblemen, die aufgrund von E/A-Problemen auftreten, finden Sie unter "Problembehandlung bei langsamer SQL Server-Leistung, die durch E/A-Probleme verursacht wird.

Weitere Informationen

Hängende E/A und E/A hängen

Hängen geblieben

Hängen bleibende E/A-Vorgänge werden als E/A-Anforderung definiert, die nicht abgeschlossen ist. Häufig weist hängen gebliebene E/A auf einen hängen gebliebenen IRP hin. Um eine hängende E/A-Bedingung zu beheben, müssen Sie den Computer in der Regel neu starten oder eine ähnliche Aktion ausführen. Eine hängen gebliebene E/A-Bedingung weist in der Regel auf eines der folgenden Probleme hin:

  • Fehlerhafte Hardware.
  • Ein Fehler in einer E/A-Pfadkomponente.

Blockierte E/A

Blockierte E/A-Vorgänge werden als E/A-Anforderung definiert, die abgeschlossen ist oder die zu viel Zeit in Anspruch nimmt. Das E/A-Verhalten tritt in der Regel aufgrund eines der folgenden Gründe auf:

  • Hardwarekonfiguration.
  • Firmwareeinstellungen.
  • Ein Filtertreiberproblem, das Unterstützung von der Hardware oder dem Softwareanbieter benötigt, um die Ablaufverfolgung und Lösung zu beheben.

SQL Server hat die E/A-Aufzeichnung und Berichterstellung hängen geblieben

Die SQL Server-Unterstützung behandelt viele Fälle jedes Jahr, die hängen gebliebene oder blockierte E/A-Probleme umfassen. Diese E/A-Probleme werden auf unterschiedliche Weise angezeigt. E/A-Probleme sind einige der schwierigsten Zu diagnostizieren und zu debuggen, und sie erfordern erhebliche Zeit und Ressourcen für das Debuggen von Microsoft und dem Kunden. Die Berichterstellung und Aufzeichnung von E/A-Anforderungen sind pro Datei konzipiert. Die Erkennung und Meldung von blockierten und hängen gebliebenen E/A-Anforderungen sind zwei separate Aktionen.

Aufzeichnung

Es gibt zwei Momente, in denen eine Datensatzaktion in SQL Server auftritt. Die erste ist der Zeitpunkt, an dem der E/A-Vorgang abgeschlossen ist. Der zweite Moment ist, wenn der faule Schriftsteller läuft. Wenn der faule Writer ausgeführt wird, überprüft er alle ausstehenden Daten und ausstehende Protokolldatei-E/A-Anforderungen. Wenn die E/A-Anforderung den Schwellenwert von 15 Sekunden überschreitet, tritt ein Datensatzvorgang auf.

Berichterstellung

Die Berichterstellung erfolgt in Intervallen, die fünf Minuten oder mehr voneinander entfernt sind. Berichterstellung tritt auf, wenn die nächste E/A-Anforderung in der Datei erfolgt. Wenn eine Datensatzaktion aufgetreten ist und fünf Minuten oder mehr seit dem letzten Bericht vergangen sind, wird die im Abschnitt "Details" Erwähnung e Informationsmeldung in das SQL Server-Fehlerprotokoll geschrieben.

Der Schwellenwert von 15 Sekunden ist nicht anpassbar. Sie können die E/A-Erkennung jedoch deaktivieren, indem Sie die Ablaufverfolgungskennzeichnung 830 verwenden, obwohl dies nicht empfohlen wird.

Sie können die Erkennung für blockierte und hängende E/A deaktivieren, indem Sie die Ablaufverfolgungskennzeichnung 830 verwenden. Wenn Sie dieses Kennzeichen jedes Mal aktivieren möchten, wenn SQL Server gestartet wird, verwenden Sie den Startparameter -T830. Verwenden Sie die folgende Anweisung, um die Erkennung für eine derzeit ausgeführte SQL Server-Instanz zu deaktivieren:

    dbcc traceon(830, -1)

Diese Einstellung ist nur für die Lebensdauer des SQL Server-Prozesses wirksam.

Hinweis

Eine E/A-Anforderung, die angehalten oder hängen bleibt, wird nur einmal gemeldet. Wenn beispielsweise die Meldung meldet, dass 10 E/A-Anforderungen angehalten sind, werden diese 10 Berichte nicht mehr auftreten. Wenn die nächste Meldung meldet, dass 15 E/A-Anforderungen angehalten sind, bedeutet dies, dass 15 neue E/A-Anforderungen angehalten wurden.

Nachverfolgen des E/A-Anforderungspakets (IRP)

SQL Server verwendet die standardmäßigen Microsoft Windows-API-Aufrufe zum Lesen und Schreiben von Daten. Sql Server verwendet z. B. die folgenden Funktionen:

  • WriteFile
  • ReadFile
  • WriteFileScatter
  • ReadFileGather

Die Lese- oder Schreibanforderung wird von Windows als E/A-Anforderungspaket (IRP) behandelt. Um den Status des IRP zu ermitteln, verwenden Sie beide der folgenden Features::

Es wird empfohlen, nach verfügbaren Updates für die folgenden Elemente zu suchen:

  • Das BIOS
  • Die Firmware
  • Alle anderen E/A-Pfadkomponenten

Wenden Sie sich an Ihre Hardwareanbieter, bevor Sie zusätzliche Debuggingaktionen ausführen. Die Debugsitzung umfasst wahrscheinlich eine Drittanbietertreiber-, Firmware- oder Filtertreiberkomponente.

Systemleistungs- und Abfrageplanaktionen

Insgesamt kann die Systemleistung eine wichtige Rolle bei der E/A-Verarbeitung spielen. Sie sollten die allgemeine Integrität des Systems berücksichtigen, während Sie Berichte über blockierte oder hängende E/A-Vorgänge untersuchen. Übermäßige Belastungen können dazu führen, dass das Gesamtsystem langsam ist, einschließlich der E/A-Verarbeitung. Das Verhalten des Systems, wenn das Problem auftritt, kann ein wichtiger Faktor bei der Ermittlung der Ursache des Problems sein. Wenn die CPU-Auslastung z. B. zunimmt oder um Standard hoch ist, während das Problem auftritt, kann es darauf hindeuten, dass ein Systemprozess so viel CPU verwendet, dass andere Prozesse negativ betroffen sind.

Leistungsindikatoren

Um die E/A-Leistung zu überwachen, untersuchen Sie die folgenden Leistungsindikatoren für bestimmte E/A-Pfadinformationen:

  • Average Disk Sec/Transfer
  • Average Disk Queue Length
  • Current Disk Queue Length

Die durchschnittliche Datenträger-Sek./Übertragungszeit auf einem Computer, auf dem SQL Server ausgeführt wird, beträgt in der Regel weniger als 15 Millisekunden. Wenn der Durchschnittliche Disk Sec/Transfer-Wert steigt, bedeutet dies, dass das E/A-Subsystem nicht optimal mit der E/A-Anforderung schritthält.

Achten Sie bei der Verwendung der Leistungsindikatoren darauf, dass SQL Server die asynchronen E/A-Funktionen nutzt, die die Länge der Datenträgerwarteschlange stark pushen. Daher deuten längere Datenträgerwarteschlangenlängen allein nicht auf ein Problem hin.

In Windows System Monitor können Sie den Zähler "Physischer Datenträger: Datenträgerbytes/Sek" für jeden betroffenen Datenträger überprüfen und die Aktivitätsrate mit den Leistungsindikatoren "Prozess: E/A-Datenbytes/Sek" und "Prozess: IO Andere Bytes/Sek" für jeden Prozess vergleichen. Damit können Sie ermitteln, ob eine bestimmte Gruppe von Prozessen übermäßige E/A-Anforderungen generiert. Verschiedene andere E/A-bezogene Leistungsindikatoren im Process-Objekt zeigen genauere Informationen an. Wenn Sie feststellen, dass eine SQL Server-Instanz für übermäßige E/A-Auslastung auf dem Server verantwortlich ist, lesen Sie den nächsten Abschnitt zu Indizes und Parallelität. Eine ausführliche Erläuterung zum Erkennen und Beheben von E/A-Engpässen finden Sie unter Problembehandlung bei langsamer SQL Server-Leistung, die durch E/A-Probleme verursacht wird.

Indizes und Parallelität

Häufig treten Brüche von E/A auf, da ein Index fehlt. Dieses Verhalten kann den E/A-Pfad stark pushen. Ein Pass, der den Indexdreh-Assistenten (ITW) verwendet, kann dazu beitragen, den E/A-Druck auf das System zu beheben. Wenn eine Abfrage von einem Index anstelle eines Tabellenscans profitiert oder wenn sie eine Sortierung oder einen Hash verwendet, kann das System die folgenden Vorteile erzielen:

  • Es wird eine Reduzierung der physischen E/A vorgenommen, die erforderlich ist, um die Aktion abzuschließen, die direkt Leistungsvorteile für die Abfrage erzeugt.
  • Weniger Seiten im Datencache müssen übernommen werden. Daher sind diese Seiten, die sich im Datencache befinden, für aktive Abfragen relevant Standard.
  • Sortierungen und Hashes werden verwendet, da ein Index möglicherweise fehlt oder dass Statistiken veraltet sind. Sie können die Tempdb-Verwendung und die Inhaltsverteilung reduzieren, indem Sie einen oder mehrere Indizes hinzufügen.
  • Eine Reduzierung erfolgt in Ressourcen, parallelen Vorgängen oder beiden. Da SQL Server keine parallele Abfrageausführung garantiert und die Auslastung des Systems berücksichtigt wird, empfiehlt es sich, alle Abfragen für die serielle Ausführung zu optimieren. Um eine Abfrage zu optimieren, öffnen Sie die Abfrageanalyse, und legen Sie den sp_configure Wert des maximalen Grads der Parallelitätsoption auf 1 fest. Wenn alle Abfragen so abgestimmt sind, dass sie prompt als serieller Vorgang ausgeführt werden, ist die parallele Ausführung häufig nur ein besseres Ergebnis. Die parallele Ausführung wird jedoch häufig ausgewählt, da die Datenmenge groß ist. Für einen fehlenden Index muss möglicherweise eine große Sortierung erfolgen. Mehrere Mitarbeiter, die den Sortiervorgang ausführen, erstellen eine schnellere Antwort. Diese Aktion kann jedoch den Druck auf das System erheblich erhöhen. Große Leseanforderungen vieler Mitarbeiter können zusammen mit einer erhöhten CPU-Auslastung zu einem E/A-Platz führen. Eine Abfrage kann häufig so optimiert werden, dass sie schneller ausgeführt wird und weniger Ressourcen verwendet wird, wenn ein Index hinzugefügt wird oder eine andere Optimierungsaktion auftritt.

Praktische Beispiele aus der SQL Server-Unterstützung

Die folgenden Beispiele wurden von SQL Server-Support und Windows-Eskalationsunterstützung behandelt. Diese Beispiele sollen einen Referenzrahmen bereitstellen und Dabei helfen, Ihre Erwartungen an festgefahrene und hängen gebliebene E/A-Situationen festzulegen. Sie bieten auch ein Framework, um zu verstehen, wie ein System betroffen sein kann oder reagieren kann. Keine bestimmte Hardware oder Gruppe von Treibern stellen ein bestimmtes Risiko oder ein erhöhtes Risiko für ein anderes dar. Alle Systeme sind in dieser Hinsicht gleich.

Beispiel 1: Ein Protokollschreibvorgang, der 45 Sekunden lang hängen bleibt

Ein Versuch, eine SQL Server-Protokolldatei in regelmäßigen Abständen zu schreiben, bleibt ungefähr 45 Sekunden lang hängen. Der Protokollschreibvorgang wird nicht rechtzeitig abgeschlossen. Dieses Verhalten erstellt eine Blockierungsbedingung, die zu 30 Sekunden Clienttimeouts führt.

Die Anwendung hat einen Commit an SQL Server übermittelt, und der Commit bleibt hängen, da ein Protokollschreibvorgang aussteht. Dieses Verhalten bewirkt, dass die Abfrage weiterhin Sperren hält und eingehende Anforderungen von anderen Clients blockiert. Dann beginnen andere Clients mit einem Timeout. Dies ist das Problem, da die Anwendung keine offenen Transaktionen zurückrollt, wenn ein Abfragetimeout auftritt. Dadurch werden Hunderte geöffneter Transaktionen erstellt, die Sperren halten. Daher tritt eine schwere Sperrsituation auf.

Weitere Informationen zum Behandeln und Blockieren von Transaktionen finden Sie im folgenden Microsoft Knowledge Base-Artikel: 224453 Grundlegendes und Beheben von PROBLEMEN beim Blockieren von SQL Server

Die Anwendung services eine Website mithilfe von Verbindungspooling. Wenn mehr Verbindungen blockiert werden, erstellt die Website mehr Verbindungen. Diese Verbindungen werden blockiert, und der Zyklus wird fortgesetzt.

Der Protokollschreibvorgang dauert ca. 45 Sekunden. Bis zu diesem Zeitpunkt werden jedoch Hunderte von Verbindungen gesichert. Die Blockierungsprobleme verursachen mehrere Minuten Wiederherstellungszeit für SQL Server und die Anwendung. In Kombination mit Anwendungsproblemen hat die festgefahrene E/A-Bedingung eine sehr negative Auswirkung auf das System.

Lösung

Das Problem wird auf eine hängende E/A-Anforderung in einem HBA-Treiber (Host Bus Adapter) nachverfolgt. Der Computer verfügt über mehrere HBA-Karte mit Failoverunterstützung. Wenn sich eine HBA hinter dem Speicherbereichsnetzwerk (Storage Area Network, SAN) befindet oder nicht kommuniziert, wird der Timeoutwert "Wiederholen vor Failover" auf 45 Sekunden konfiguriert. Wenn das Timeout überschritten wird, wird die E/A-Anforderung an die zweite HBA weitergeleitet. Der zweite HBA verarbeitet die Anforderung und wird schnell abgeschlossen. Um solche Standbedingungen zu verhindern, empfiehlt der Hardwarehersteller eine Einstellung "Wiederholen vor failover" von fünf Sekunden.

Beispiel 2: Filtertreibereingriff

Viele Antivirensoftwareprogramme und Sicherungsprodukte verwenden E/A-Filtertreiber. Diese E/A-Filtertreiber werden Teil des E/A-Anforderungsstapels und haben Zugriff auf die IRP-Anforderung. Microsoft-Produktsupportdienste haben verschiedene Probleme von Fehlern gesehen, die hängen gebliebene E/A-Bedingungen oder blockierte E/A-Bedingungen in einer Filtertreiberimplementierung erstellen.

Eine solche Bedingung ist ein Filtertreiber für die Sicherungsverarbeitung, der die Sicherung der Dateien ermöglicht, die geöffnet sind, wenn die Sicherung auftritt. Der Systemadministrator hat das SQL Server-Datendateiverzeichnis in die Dateisicherungsauswahl aufgenommen. Wenn die Sicherung auftritt, versucht die Sicherung, das richtige Image der Datei beim Start der Sicherung zu erfassen. Dadurch werden E/A-Anforderungen verzögert. Die E/A-Anforderungen dürfen jeweils nur einzeln abgeschlossen werden, da sie von der Software verarbeitet werden.

Wenn die Sicherung gestartet wird, sinkt die SQL Server-Leistung erheblich, da die I/Os von SQL Server einzeln abgeschlossen werden muss. Die einmalige Logik ist so, dass der E/A-Vorgang nicht asynchron ausgeführt werden kann, was das Problem miteinander in Verbindung setzt. Wenn SQL Server daher erwartet, dass eine E/A-Anforderung gestellt und fortgesetzt wird, bleibt der Worker im Lese- oder Schreibaufruf hängen, bis die E/A-Anforderung abgeschlossen ist. Die Aktionen des Filtertreibers deaktivieren die Verarbeitungsaufgaben wie SQL Server-Lesezugriff effektiv. Darüber hinaus verlässt ein anderer Fehler im Filtertreiber die einmaligen Aktionen im Prozess, auch wenn die Sicherung abgeschlossen ist. Die einzige Möglichkeit zum Wiederherstellen der SQL Server-Leistung besteht darin, SQL Server neu zu starten, sodass das Dateihandle freigegeben und ohne die Interaktion des Filtertreibers erneut abgerufen wird.

Lösung

Um dieses Problem zu beheben, werden die SQL Server-Datendateien aus dem Dateisicherungsprozess entfernt. Der Softwarehersteller hat das Problem behoben, das die Datei im Modus "einzeln" verlassen hat.

Beispiel 3: Ausgeblendete Fehler

Viele High-End-Systeme verfügen über Mehrkanal-E/A-Pfade zur Handhabung des Lastenausgleichs oder ähnlicher Aktivitäten. Der Microsoft-Produktsupport hat Probleme mit der Lastenausgleichssoftware gefunden, bei der eine E/A-Anforderung fehlschlägt, aber die Software behandelt die Fehlerbedingung nicht ordnungsgemäß. Die Software kann unendliche Wiederholungen versuchen. Der E/A-Vorgang bleibt hängen, und SQL Server kann die angegebene Aktion nicht abschließen. Ähnlich wie die zuvor beschriebene Protokollschreibbedingung können viele schlechte Systemverhalten nach einer solchen Bedingung auftreten.

Lösung

Um dieses Problem zu beheben, starten Sie den SQL Server neu. Manchmal müssen Sie das Betriebssystem jedoch neu starten, um die Verarbeitung wiederherzustellen. Außerdem wird empfohlen, ein Softwareupdate vom E/A-Anbieter zu erhalten.

Beispiel 4: Remotespeicher, Spiegel ing und Raid-Laufwerke

Viele Systeme verwenden Spiegel ing oder übernehmen ähnliche Schritte, um Datenverluste zu verhindern. Einige Systeme, die Spiegel ing verwenden, sind softwarebasiert und einige sind hardwarebasiert. Die Situation, die in der Regel von Microsoft-Support für diese Systeme ermittelt wird, ist eine erhöhte Latenz.

Eine Erhöhung der gesamten E/A-Zeit tritt auf, wenn die E/A abgeschlossen werden muss, bevor sie als abgeschlossen betrachtet wird. Bei Remote-Spiegel-Installationen können Netzwerkneuversuche einbezogen werden. Wenn Laufwerksfehler auftreten und das Raid-System neu aufgebaut wird, kann auch das E/A-Muster unterbrochen werden.

Lösung

Strenge Konfigurationseinstellungen sind erforderlich, um die Latenz auf Spiegel s oder die Raid-Neuerstellungsvorgänge zu reduzieren.

Beispiel 5: Komprimierung

Microsoft unterstützt keine SQL Server-Datendateien und Protokolldateien auf komprimierten Laufwerken. DIE NTFS-Komprimierung ist für SQL Server nicht sicher, da ntfs-Komprimierungsunterbrechungen beim Schreiben der Vorausschriftprotokollierung (WRITE Ahead Logging, WAL) unterbrochen werden. Die NTFS-Komprimierung erfordert auch eine erhöhte Verarbeitung für jeden E/A-Vorgang. Die Komprimierung erstellt "einzeln" wie das Verhalten, das zu schwerwiegenden Leistungsproblemen führt.

Lösung

Um dieses Problem zu beheben, heben Sie die Daten und die Protokolldateien auf.

Weitere Informationen finden Sie unter Support für Datenbanken auf komprimierten Volumes.

Weitere Datenpunkte

PAGEIOLATCH_* und Schreibprotokollwartevorgänge in sys.dm_os_wait_stats dynamischen Verwaltungsansichten (DYNAMIC Management Views, DMV) sind wichtige Indikatoren zur Untersuchung der E/A-Pfadleistung. Wenn lange PAGEIOLATCH-Wartezeiten vorliegen, bedeutet dies, dass SQL Server auf das E/A-Subsystem wartet. Eine bestimmte Menge von PAGEIOLATCH-Wartezeiten ist typisch und erwartet verhalten. Wenn die durchschnittliche PAGEIOLATCH-Wartezeit jedoch konsistent größer als 10 Millisekunden ist, sollten Sie untersuchen, warum das E/A-Subsystem unter Druck steht. Weitere Informationen finden Sie in den folgenden Dokumenten:

Informationsquellen

SQL Server erfordert, dass Systeme die "garantierte Übermittlung an stabile Medien" unterstützen, wie unter den SQL Server-I/O-Zuverlässigkeitsprogrammanforderungen beschrieben. Weitere Informationen zu den Eingabe- und Ausgabeanforderungen für das SQL Server-Datenbankmodul finden Sie unter Datenbank-Engine Eingabe-/Ausgabeanforderungen.

Weitere Informationen zu E/A-Fehlern finden Sie unter Microsoft SQL Server I/O Basics, Chapter 2 (E/A-Grundlagen von Microsoft SQL Server, Kapitel 2).