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

Mit dieser Meldung wird angegeben, dass von SQL Server eine Lese- oder Schreibanforderung vom Datenträger ausgegeben wurde und dass die Rückgabe der Anforderung länger als 15 Sekunden gedauert hat. Der SQL Server meldet diesen Fehler und weist auf ein Problem mit dem E/A-Subsystem hin. Ein Datenbankmanagementsystem (DBMS), z. B. SQL Server, basiert auf der Zeitachse von Dateieingabe- und Ausgabevorgängen (E/A). Eines der folgenden Elemente kann zu hängenden oder blockierten E/A-Vorgängen führen und sich negativ auf SQL Server Reaktionsfähigkeit und Leistung auswirken:

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

Diese E/A-Probleme können das folgende Verhalten verursachen:

  • Blockieren.
  • Latch-Konflikte und Timeouts.
  • Langsame Reaktion.
  • Dehnung von Ressourcengrenzen.
  • Möglicherweise bemerken Sie auch andere Symptome, die mit dieser Nachricht verbunden sind, z. B.:
    • Hohe Wartezeiten für PAGEIOLATCH-Wartezeiten.
    • Warnungen oder Fehler im Systemereignisprotokoll.
    • Hinweise auf Probleme mit der Datenträgerwartezeit in Systemmonitorindikatoren.

Wenn ein E/A-Vorgang mindestens 15 Sekunden 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 den verschiedenen Abschnitten dieser Informationsmeldung finden Sie in der folgenden Tabelle:

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

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

Mögliche Ursachen

Die Informationsmeldung gibt an, dass bei der aktuellen Auslastung möglicherweise eine der folgenden Bedingungen auftritt:

  • Die Workload überschreitet die E/A-Pfadfunktionen entweder aufgrund einer Fehlkonfiguration des E/A-Subsystems (SAN, NAS und direkt angefügt) oder weil die Hardwarekapazität erreicht wurde.
  • Die Workload überschreitet die aktuellen Systemfunktionen, z. B. E/A, CPUs und HBAs.
  • Der E/A-Pfad weist eine fehlerhafte Software auf. Es kann sich um Firmware oder ein Treiberproblem handelt.
  • Der E/A-Pfad weist fehlerhafte Hardwarekomponenten auf.
  • Leistungsproblem auf Betriebssystemebene.
  • Filtertreibereingriff in den E/A-Prozess oder Speicherpfad von Datenbankdateien. Beispiel: Antivirenprogramm.

SQL Server zeichnet die Zeit auf, zu der eine E/A-Anforderung initiiert wurde, und zeichnet den Zeitpunkt der E/A-Fertigstellung auf. 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 für die verzögerte E/A-Bedingung ist, die in dieser Nachricht beschrieben und gemeldet wird. Diese Bedingung wird als verzögerte 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 sind 15 Sekunden eine lange Zeit für die Rückkehr des System-E/A-Pfads zu SQL Server. Weitere Informationen finden Sie im Abschnitt Weitere Informationen .

Benutzeraktion

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

  1. Untersuchen Sie das Systemereignisprotokoll auf hardwarebezogene Fehlermeldungen.
  2. Überprüfen Sie hardwarespezifische Protokolle, ob 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 Diagnosen aus, die Ihrem E/A-Subsystem zugeordnet sind.
  4. Der Zugriff auf Datenträger kann durch Filtertreiber verlangsamt werden, z. B. durch ein Antivirenprogramm. Um die Zugriffsgeschwindigkeit zu erhöhen, schließen Sie die in der Fehlermeldung angegebenen SQL Server Datendateien von den aktiven Virenscans aus. Weitere Informationen finden Sie unter Auswählen von Antivirensoftware für die Ausführung auf Computern, auf denen SQL Server (microsoft.com) ausgeführt wird.
    • Verwenden Sie das Befehlszeilenhilfsprogrammfltmc.exe , um alle auf dem System installierten Filtertreiber abzufragen und die Funktionen zu verstehen, die für den Speicherpfad zu den Datenbankdateien ausgeführt werden.
  5. Verwenden Sie die Leistungsmonitor, um die folgenden Indikatoren zu untersuchen:
    • Average Disk Sec/Transfer
    • Average Disk Queue Length
    • Current Disk Queue Length
  6. Sie können auch Funktionen wie die Storport ETW-Protokollierung verwenden, um die Latenz von Anforderungen zu messen, die an eine Datenträgereinheit gesendet 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 SQL Server Leistungsproblemen, die aufgrund von E/A-Problemen auftreten, finden Sie unter Problembehandlung für langsame SQL Server Leistung, die durch E/A-Probleme verursacht wird.

Weitere Informationen

Hängende E/A und verzögerte E/A

Hängen gebliebene E/A-Vorgänge

Hängende E/A-Vorgänge werden als E/A-Anforderung definiert, die nicht abgeschlossen ist. Hängen gebliebene E/A-Vorgänge weisen häufig auf einen hängenden IRP hin. Um eine hängende E/A-Bedingung zu beheben, müssen Sie normalerweise den Computer 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.

Verzögerte E/A

Verzögerte E/A-Vorgänge werden als E/A-Anforderung definiert, die abgeschlossen ist oder die übermäßige Zeit in Anspruch nimmt. Verzögertes E/A-Verhalten tritt in der Regel aus einem der folgenden Gründe auf:

  • Hardwarekonfiguration.
  • Firmwareeinstellungen.
  • Ein Filtertreiberproblem, das Unterstützung der Hardware oder des Softwareherstellers erfordert, um nachzuverfolgen und zu beheben.

SQL Server verzögerte E/A-Aufzeichnung und -Berichterstellung und hängen gebliebene E/A-Aufzeichnungen

SQL Server Support behandelt jedes Jahr viele Fälle, die zu hängenden oder verzögerten E/A-Problemen führen. Diese E/A-Probleme treten auf unterschiedliche Weise auf. E/A-Probleme sind einige der am schwierigsten zu diagnostizieren und zu debuggenden Probleme, und sie erfordern viel Zeit und Ressourcen für das Debuggen von Microsoft und dem Kunden. Die Berichterstellung und Aufzeichnung von E/A-Anforderungen erfolgt dateibezogen. Die Erkennung und Berichterstellung von blockierten und hängenden E/A-Anforderungen sind zwei separate Aktionen.

Aufzeichnung

Es gibt zwei Momente, in denen eine Datensatzaktion in SQL Server. Die erste ist, wenn der E/A-Vorgang abgeschlossen ist. Der zweite Moment ist, wenn der lazy Writer ausgeführt wird. Wenn der verzögerte Writer ausgeführt wird, überprüft er alle ausstehenden Daten und ausstehenden Protokolldatei-E/A-Anforderungen. Wenn die E/A-Anforderung den Schwellenwert von 15 Sekunden überschreitet, wird ein Datensatzvorgang ausgeführt.

Berichterstellung

Die Berichterstellung erfolgt in Intervallen, die mindestens fünf Minuten voneinander entfernt sind. Die Berichterstellung erfolgt, wenn die nächste E/A-Anforderung für die Datei gestellt wird. Wenn eine Datensatzaktion aufgetreten ist und seit dem letzten Bericht mindestens fünf Minuten vergangen sind, wird die im Abschnitt Details erwähnte Informationsmeldung in das SQL Server Fehlerprotokoll geschrieben.

Der Schwellenwert von 15 Sekunden ist nicht einstellbar. Sie können die Erkennung von verzögerten oder hängenden E/A-Vorgängen jedoch mithilfe des Ablaufverfolgungsflags 830 deaktivieren, obwohl wir dies nicht empfehlen.

Sie können die Erkennung von blockierten und hängenden E/A-Vorgängen mithilfe des Ablaufverfolgungsflags 833 deaktivieren. Um dieses Flag jedes Mal zu aktivieren, wenn SQL Server gestartet wird, verwenden Sie den Startparameter -T830. Verwenden Sie die folgende Anweisung, um die Erkennung für eine instanz von SQL Server zu deaktivieren, die derzeit ausgeführt wird:

    dbcc traceon(830, -1)

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

Hinweis

Eine E/A-Anforderung, die zum Stillstand kommt oder nicht mehr vorhanden ist, wird nur einmal gemeldet. Wenn die Meldung beispielsweise meldet, dass 10 E/A-Anforderungen angehalten sind, werden diese 10 Berichte nicht mehr auftreten. Wenn die nächste Nachricht meldet, dass 15 E/A-Anforderungen blockiert sind, bedeutet dies, dass 15 neue E/A-Anforderungen zum Stillstand gekommen sind.

Nachverfolgen des E/A-Anforderungspakets (IRP)

SQL Server verwendet die Standardmäßigen Microsoft Windows-API-Aufrufe zum Lesen und Schreiben von Daten. Beispielsweise verwendet SQL Server die folgenden Funktionen:

  • WriteFile
  • ReadFile
  • WriteFileScatter
  • ReadFileGather

Die Lese- oder Schreibanforderung wird von Windows als E/A-Anforderungspaket (IRP) behandelt. Verwenden Sie die beiden folgenden Features, um den Status des IRP zu bestimmen:

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

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

Wenden Sie sich an Ihre Hardwareanbieter, bevor Sie zusätzliche Debugaktionen ausführen. Die Debugsitzung umfasst wahrscheinlich einen Treiber, eine Firmware oder eine Filtertreiberkomponente eines Drittanbieters.

Aktionen für Systemleistung und Abfrageplan

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 verzögerte oder hängende E/A-Vorgänge untersuchen. Übermäßige Belastungen können dazu führen, dass das gesamte System langsam ist, einschließlich der E/A-Verarbeitung. Das Verhalten des Systems, wenn das Problem auftritt, kann ein wichtiger Faktor bei der Bestimmung der Grundursache des Problems sein. Wenn beispielsweise die CPU-Auslastung steigt oder hoch bleibt, während das Problem auftritt, kann dies darauf hindeuten, dass ein Systemprozess so viel CPU verwendet, dass andere Prozesse beeinträchtigt werden.

Leistungsindikatoren

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

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

Beispielsweise beträgt die durchschnittliche Datenträgersekunden-/Übertragungszeit auf einem Computer, auf dem SQL Server ausgeführt wird, in der Regel weniger als 15 Millisekunden. Wenn der Wert "Average Disk Sec/Transfer" steigt, gibt dies an, dass das E/A-Subsystem die E/A-Anforderungen nicht optimal erfüllen kann.

Seien Sie bei der Verwendung der Leistungsindikatoren vorsichtig, da SQL Server die asynchronen E/A-Funktionen voll ausnutzt, die die Datenträgerwarteschlangenlängen stark pushen. Daher deuten längere Datenträgerwarteschlangenlängen allein nicht auf ein Problem hin.

Im Windows-Systemmonitor können Sie den Leistungsindikator "Physischer Datenträger: Datenträgerbytes/s" für jeden betroffenen Datenträger überprüfen und die Aktivitätsrate mit den Leistungsindikatoren "Process: IO Data Bytes/Sec" und "Process: IO Other Bytes/sec" für jeden Prozess vergleichen. Dadurch können Sie ermitteln, ob eine bestimmte Gruppe von Prozessen übermäßige E/A-Anforderungen generiert. Verschiedene andere E/A-bezogene Indikatoren im Process-Objekt zeigen präzisere Informationen an. Wenn Sie feststellen, dass eine SQL Server-Instanz für übermäßige E/A-Last auf dem Server verantwortlich ist, lesen Sie den nächsten Abschnitt zu Indizes und Parallelität. Eine ausführliche Diskussion zum Erkennen und Beheben von E/A-Engpässen finden Sie unter Problembehandlung für langsame SQL Server Leistung durch E/A-Probleme.

Indizes und Parallelität

Häufig treten E/A-Bursts auf, weil ein Index fehlt. Dieses Verhalten kann den E/A-Pfad stark pushen. Ein Pass, der den Indexwende-Assistenten (ITW) verwendet, kann dazu beitragen, E/A-Druck auf das System zu beheben. Wenn eine Abfrage von einem Index anstelle einer Tabellenüberprüfung profitiert oder wenn sie eine Sortierung oder einen Hash verwendet, kann das System die folgenden Vorteile nutzen:

  • Es wird eine Verringerung der physischen E/A vorgenommen, die erforderlich ist, um die Aktion abzuschließen, die direkt Leistungsvorteile für die Abfrage schafft.
  • Es müssen weniger Seiten im Datencache umgewandelt werden. Daher bleiben die Seiten, die sich im Datencache befinden, für aktive Abfragen relevant.
  • Sortierungen und Hashes werden verwendet, weil ein Index möglicherweise fehlt oder statistiken veraltet sind. Sie können tempdb-Verwendung und -Konflikte reduzieren, indem Sie einen oder mehrere Indizes hinzufügen.
  • Ressourcen, parallele Vorgänge oder beides werden reduziert. Da SQL Server keine parallele Abfrageausführung garantiert und die Auslastung des Systems berücksichtigt wird, ist es am besten, alle Abfragen für die serielle Ausführung zu optimieren. Um eine Abfrage zu optimieren, öffnen Sie Query Analyzer, und legen Sie den sp_configure Wert der Option max. Grad an Parallelität auf 1 fest. Wenn alle Abfragen so eingestellt sind, dass sie zeitnah als serieller Vorgang ausgeführt werden, ist die parallele Ausführung oft nur ein besseres Ergebnis. Die parallele Ausführung wird jedoch häufig ausgewählt, weil die Datenmenge groß ist. Bei einem fehlenden Index muss möglicherweise eine große Sortierung auftreten. Mehrere Worker, die den Sortiervorgang ausführen, erstellen eine schnellere Antwort. Diese Aktion kann jedoch den Druck auf das System dramatisch erhöhen. Große Leseanforderungen von vielen Workern können zusammen mit einer erhöhten CPU-Auslastung zu einem E/A-Burst führen. Eine Abfrage kann häufig so eingestellt werden, dass sie schneller ausgeführt wird und weniger Ressourcen beansprucht, wenn ein Index hinzugefügt wird oder eine andere Optimierungsaktion ausgeführt wird.

Praktische Beispiele aus SQL Server Support

Die folgenden Beispiele wurden von SQL Server-Support und Windows-Eskalationsunterstützung behandelt. Diese Beispiele sollen einen Referenzrahmen bieten und Dabei helfen, Ihre Erwartungen an festgefahrene und festgefahrene 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 eine Reihe von Treibern stellen ein bestimmtes Risiko oder ein erhöhtes Risiko gegenüber einem anderen dar. In dieser Hinsicht sind alle Systeme gleich.

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

Ein Versuch, eine SQL Server Protokolldatei zu schreiben, bleibt ca. 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 beginnt für andere Clients ein Timeout. Dadurch wird das Problem verschärft, da die Anwendung bei einem Abfragetimeout kein Rollback für geöffnete Transaktionen führt. Dadurch werden Hunderte von offenen Transaktionen erstellt, die Sperren enthalten. Daher kommt es zu einer schwerwiegenden Blockierungssituation.

Weitere Informationen zur Behandlung und Blockierung von Transaktionen finden Sie im folgenden Microsoft Knowledge Base-Artikel: 224453 Grundlegendes und Beheben von Problemen beim Blockieren von SQL Server

Die Anwendung verwaltet 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 ungefähr 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 wirkt sich die verzögerte E/A-Bedingung sehr negativ auf das System aus.

Auflösung

Das Problem wird anhand einer hängen gebliebenen E/A-Anforderung in einem HBA-Treiber (Host Bus Adapter) nachverfolgt. Der Computer verfügt über mehrere HBA-Karten mit Failoverunterstützung. Wenn sich ein HBA im Rückstand befindet oder nicht mit dem Storage Area Network (SAN) kommuniziert, wird der Timeoutwert "Wiederholen vor dem Failover" auf 45 Sekunden konfiguriert. Wenn das Timeout überschritten wird, wird die E/A-Anforderung an den zweiten HBA weitergeleitet. Der zweite HBA verarbeitet die Anforderung und wird schnell abgeschlossen. Um solche Stillstandszustände zu verhindern, empfiehlt der Hardwarehersteller eine Einstellung "Wiederholen vor dem Failover" von fünf Sekunden.

Beispiel 2: Filtertreiberinteraktion

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 Product Support Services hat verschiedene Probleme aufgrund von Fehlern festgestellt, die zu hängen gebliebenen E/A-Bedingungen oder verzögerten E/A-Bedingungen in einer Filtertreiberimplementierung führen.

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

Wenn die Sicherung gestartet wird, sinkt SQL Server Leistung erheblich, da die E/A-Vorgänge von SQL Server nacheinander abgeschlossen werden müssen. Die 1/a-Logik ist so, dass der E/A-Vorgang nicht asynchron ausgeführt werden kann, was das Problem verschmiert. Wenn SQL Server erwartet, eine E/A-Anforderung zu senden und fortzufahren, bleibt der Worker daher im Lese- oder Schreibaufruf hängen, bis die E/A-Anforderung abgeschlossen ist. Die Aktionen des Filtertreibers deaktivieren effektiv die Verarbeitungsaufgaben, z. B. SQL Server Read-Ahead. Darüber hinaus belässt ein anderer Fehler im Filtertreiber die einmaligen Aktionen im Prozess, auch wenn die Sicherung abgeschlossen ist. Die einzige Möglichkeit, SQL Server Leistung wiederherzustellen, besteht darin, SQL Server neu zu starten, sodass das Dateihandle freigegeben und ohne die Filtertreiberinteraktion erneut ausgeführt wird.

Auflösung

Um dieses Problem zu beheben, werden die SQL Server Datendateien aus dem Dateisicherungsprozess entfernt. Der Softwarehersteller hat das Problem behoben, durch das die Datei im Modus "Einzeln" belassen wurde.

Beispiel 3: Ausgeblendete Fehler

Viele High-End-Systeme verfügen über Mehrkanal-E/A-Pfade, um den Lastenausgleich oder ähnliche Aktivitäten zu bewältigen. Der Microsoft-Produktsupport hat Probleme mit der Lastenausgleichssoftware gefunden, bei denen eine E/A-Anforderung fehlschlägt, die Fehlerbedingung jedoch nicht ordnungsgemäß behandelt wird. Die Software kann endlose Wiederholungen versuchen. Der E/A-Vorgang bleibt hängen, und SQL Server kann die angegebene Aktion nicht abschließen. Ähnlich wie bei der zuvor beschriebenen Protokollschreibbedingung können viele schlechte Systemverhalten auftreten, nachdem eine solche Bedingung das System wediert.

Auflösung

Starten Sie den SQL Server neu, um dieses Problem zu beheben. 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, Spiegelung und RAID-Laufwerke

Viele Systeme verwenden die Spiegelung oder führen ähnliche Schritte aus, um Datenverluste zu verhindern. Einige Systeme, die die Spiegelung verwenden, sind softwarebasiert, andere sind hardwarebasiert. Die Situation, die normalerweise von Microsoft-Support für diese Systeme erkannt wird, ist eine erhöhte Latenz.

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

Auflösung

Strenge Konfigurationseinstellungen sind erforderlich, um die Latenz für Spiegelungen oder Raid-Neuerstellungsvorgänge zu verringern.

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 die NTFS-Komprimierung das WAL-Protokoll (Write Ahead Logging) unterbricht. Die NTFS-Komprimierung erfordert auch eine höhere Verarbeitung für jeden E/A-Vorgang. Bei der Komprimierung wird ein "nacheinander" ähnliches Verhalten erzeugt, das zu schwerwiegenden Leistungsproblemen führt.

Auflösung

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

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

Zusätzliche Datenpunkte

PAGEIOLATCH_* und Schreibprotokollwartevorgänge in sys.dm_os_wait_stats dynamischen Verwaltungssichten (Dynamic Management Views, DMV) sind Schlüsselindikatoren zur Untersuchung der E/A-Pfadleistung. Wenn lange PAGEIOLATCH-Wartezeiten vorliegen, bedeutet dies, dass SQL Server auf das E/A-Subsystem wartet. Eine bestimmte Anzahl von PAGEIOLATCH-Wartevorgängen ist typisch und erwartet. 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:

Referenzen

SQL Server erfordert, dass Systeme eine "garantierte Bereitstellung an stabile Medien" unterstützen, wie in den Anforderungen des SQL Server E/A-Zuverlässigkeitsprogramms beschrieben. Weitere Informationen zu den Eingabe- und Ausgabeanforderungen für die SQL Server-Datenbank-Engine finden Sie unter Eingabe-/Ausgabeanforderungen der Datenbank-Engine.

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