PRB: Zusätzliche SQL Server-Diagnose hinzugefügt, um nicht berichtete E/A-Probleme aufzuspüren

Wenn Probleme mit dem Betriebssystem, dem Treiber oder der Hardware zu Schreibverlustkonditionen oder zu veralteten Lesekonditionen führen, werden möglicherweise Fehlermeldungen zur Datenintegrität wie beispielsweise Fehler 605, 823, 3448 angezeigt. Möglicherweise werden ähnliche Fehlermeldungen wie die folgenden Beispiele angezeigt:

Service Pack-Informationen

Installieren Sie das neueste Service Pack für Microsoft SQL Server 2000, um dieses Problem zu beheben. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:

Build-Informationen

Microsoft hat ein SQL Server-Build freigegeben, das die Verfolgungsfähigkeiten erweitert. Diese Fähigkeiten sollen als Hilfe bei der Behebung der im Abschnitt "Problembeschreibung" beschriebenen Fehlermeldungen dienen. Wenn Sie davon ausgehen, dass das Problem nicht in Zusammenhang mit dem Betriebssystem oder der Hardware steht, müssen Sie das Build möglicherweise nicht anwenden.

Die englische Version dieses Builds weist die in der nachstehenden Tabelle aufgelisteten Dateiattribute (oder höher) auf. Datums- und Uhrzeitangaben für diese Dateien sind in der "Coordinated Universal Time" (UTC) angegeben. Wenn Sie sich die Dateiinformationen ansehen, werden diese Angaben in die lokale Zeit konvertiert. Die Abweichung zwischen UTC-Zeit und lokaler Zeit können Sie im Systemsteuerungsprogramm Datum/Uhrzeit mithilfe der Registerkarte Zeitzone ermitteln. Hinweis: Aufgrund von Dateiabhängigkeiten enthält der aktuellste Hotfix oder das aktuellste Feature, der/das diese Dateien enthält, möglicherweise noch weitere Dateien.

Microsoft hat bestätigt, dass unter seltenen und schweren E/A-Lasten einige Hardwareplattformen eine veraltete Lesekondition zurückgeben können. Wenn die erweiterte Diagnose eine mögliche Schreibverlustkondition oder veraltete Lesekondition anzeigt, wenden Sie sich an den Händler, bei dem Sie Ihre Hardware bezogen haben, um eine unverzügliche Nachverfolgung und eine Überprüfung mit dem Dienstprogramm SQLIOStress durchführen zu lassen.

Microsoft hat bestätigt, dass es sich hierbei um ein Problem bei den in diesem Artikel genannten Microsoft-Produkten handelt.

Dieses Problem wurde erstmals in Microsoft SQL Server 2000 Service Pack 4 behoben.

Wenn eine der im Abschnitt "Problembeschreibung" erwähnten Fehlermeldungen angezeigt wird und nicht mit einem Ereignis, wie beispielsweise einem Fehler des physischen Laufwerks, zu erklären ist, überprüfen Sie alle bekannten Probleme mit SQL Server, dem Betriebssystem, den Treibern und der Hardware. Zu diesem Build wurde eine zusätzliche SQL Server-Diagnose hinzugefügt, um externe E/A-Probleme leichter aufspüren zu können. Die zusätzliche Diagnose versucht Ihnen Informationen zu den folgenden zwei Konditionen zu liefern:

• Schreibverlust: Es erfolgt ein erfolgreicher Aufruf der WriteFile-API, aber das Betriebssystem, ein Treiber oder der Cache-Controller speichert die Daten nicht korrekt auf dem physikalische Medium, obwohl SQL Server die Information erhält, dass das Schreiben erfolgreich war.
• Veraltetes Lesen: Es erfolgt ein erfolgreicher Aufruf der ReadFile-API, aber das Betriebssystem, ein Treiber oder der Cache-Controller gibt fälschlicherweise eine ältere Version der Daten zurück.

Microsoft hat beispielsweise bestätigt, dass Szenarios auftreten, in denen der Aufruf einer WriteFile-API erfolgreich zurückgegeben wird, jedoch beim sofortigen erfolgreichen Lesen des gleichen Datenblock ältere Daten zurückgegeben werden, einschließlich der Daten, die wahrscheinlich in einem Cache zum Lesen von Hardware gespeichert sind. Dieses Problem tritt manchmal aufgrund eines Problems mit dem Lesecache auf. In anderen Fällen werden Daten, die geschrieben werden sollen, zu keinem Zeitpunkt wirklich auf den physikalischen Datenträger geschrieben.

Zu SQL Server wurde das Ablaufverfolgungs-Flag 818 hinzugefügt, um zusätzliche Diagnosen für diese Probleme zu ermöglichen. Sie können das Ablaufverfolgungs-Flag 818 für den Computer, auf dem SQL Server ausgeführt wird, als Startparameter, -T818, angeben, oder Sie führen die folgende Anweisungen aus:
Das Ablaufverfolgungs-Flag 818 aktiviert einen in Ihrem Arbeitsspeicher vorliegenden Ringpuffer, der verwendet wird, um die letzten 2.048 erfolgreichen Schreibvorgänge zurückzuverfolgen, die vom SQL Server-Computer durchgeführt wurden, ausschließlich Sortier- und Arbeitsdatei-E/As. Wenn Fehler wie beispielsweise Fehler 605, 823 oder 3448 auftreten, wird der Wert der LSN (Log Sequence Number) des eingehenden Puffers mit der aktuellen Schreibliste verglichen. Wenn die LSN, die während des Lesevorgangs abgerufen wird, älter ist als die, die während des Schreibvorgangs spezifiziert wird, wird im Fehlerprotokoll von SQL Server eine neue Fehlermeldung vermerkt. Die meisten Schreibvorgänge in SQL Server treten als Prüfpunkte oder als Lazy Writes auf. Lazy Write ist eine Hintergrundaufgabe, die asynchrone E/A verwendet. Die Implementierung des Ringpuffers beansprucht nur wenig Leistung, sodass die Auswirkung auf die Leistung des Systems geringfügig ist.

Die folgende Meldung zeigt an (sinngemäß), dass SQL Server vom Aufruf der WriteFile-API oder der ReadFile-API keinen Fehler gemeldet bekommt. Wenn die LSN jedoch erneut angezeigt wurde, war der Wert nicht korrekt: An dieser Stelle enthält entweder der Lesecache eine ältere Version der Seite, oder die Daten wurden nicht korrekt auf den physischen Datenträger geschrieben. In beiden Fällen (Schreibverlust oder Lesen veralteter Daten) berichtet SQL Server ein externes Problem mit dem Betriebssystem, dem Treiber oder den Hardwareebenen.

Wenn Fehler 3448 bei dem Versuch auftritt, einen Rollback einer Transaktion mit Fehler 605 oder Fehler 823 durchzuführen, schließt der Computer, auf dem SQL Server ausgeführt wird, automatisch die Datenbank und versucht, die Datenbank zu öffnen und wiederherzustellen. Die erste Seite, auf der Fehler 605 oder Fehler 823 auftritt, gilt als beschädigte Seite, und die Kennung der Seite wird vom Computer, auf dem SQL Server ausgeführt wird, gespeichert. Während der Wiederherstellung (vor der Wiederherstellungsphase), wenn die Kennung der beschädigten Seite gelesen wird, werden die primären Details zum Header der Seite im Fehlerprotokoll von SQL Server vermerkt. Dieser Vorgang ist wichtig, weil er dabei hilft, zwischen den Szenarios "Schreibverlust" und "Lesen veralteter Daten" zu unterscheiden.

In den Szenarios "Lesen veralteter Daten" stellen Sie möglicherweise die folgenden üblichen Verhaltensweisen fest:

• Wenn die Datenbankdateien geschlossen und anschließend geöffnet werden, werden während der Wiederherstellung die korrekten und zuletzt geschriebenen Daten zurückgegeben.
• Wenn Sie auf einen Checkpoint stoßen und die Anweisung DBCC DROPCLEANBUFFERS ausführen (um alle Seiten der Datenbank aus dem Speicher zu entfernen), und danach die Anweisung DBCC CHECKDB auf der Datenbank ausführen, werden die zuletzt geschriebenen Daten zurückgegeben.

Die im vorherigen Absatz erwähnten Verhaltensweisen zeigen ein Problem mit dem Lesecache an und werden häufig durch das Deaktivieren des Lesecaches behoben. Die im vorherigen Absatz beschriebenen Aktionen führen in der Regel zu einer Beschädigung des Cache, und das auftretende erfolgreiche Lesen zeigt, dass das physische Medium einwandfrei aktualisiert wurde. Der Schreibverlust tritt auf, wenn die Seite, die gelesen wird, noch die ältere Version der Daten enthält, sogar nachdem das Löschen des Cachemechanismus erzwungen wurde.

Manchmal hängt das Problem möglicherweise nicht mit einem Hardwarecache zusammen. Dann liegt eventuell ein Problem mit einem Filtertreiber vor. In diesem Fall sollten Sie Ihre Software überarbeiten, einschließlich der Sicherungsprogramme und der Antivirussoftware, und überprüfen, ob Probleme mit dem Filtertreiber vorliegen.

Microsoft hat auch Bedingungen festgestellt, die nicht mit den Kriterien von Fehler 605 oder Fehler 823 übereinstimmen, aber durch die gleichen Aktivitäten "Lesen veralteter Daten" oder "Schreibverlust" verursacht werden. In einigen Fällen scheint eine Seite zweimal aktualisiert zu werden, jedoch mit dem gleichen LSN-Wert. Dieses Verhalten kann auftreten, wenn die Objekt-ID und die Seiten-ID korrekt sind (die Seite ist dem Objekt bereits zugeordnet), und an der Seite eine Änderung vorgenommen wurde und an den Datenträger übertragen wurde. Wenn Sie die Seite das nächste Mal abrufen, wird ein älteres Bild zurückgegeben, und anschließend erfolgt eine zweite Änderung. Die SQL Server-Transaktionsprotokoll zeigt an, dass die Seite zweimal mit dem gleichen LSN-Wert aktualisiert wurde. Diese Aktion wird zu einem Problem, wenn Sie versuchen, eine Sequenz eines Transaktionsprotokolls wiederherzustellen, oder es kommt zu Problemen mit der Datenkonsistenz, wie beispielsweise Fehler in Fremdschlüsseln oder fehlende Dateneinträge. Die folgende Fehlermeldung ist ein Beispiel für diese Bedingung:
Folgenden Listen enthalten detailliertere Beschreibungen einiger Szenarios:

• LSN Sequence		Action
  1			Checkpoint
  2			Begin Transaction
  3			Table created or truncated
  4			Inserts (Pages allocated)
  5			Newly allocated page written to disk by Lazy Writer
  6			Select from table ? Scans IAM chain, newly allocated page read back from disk (LRU | HASHED = 0x9 in getpage message), encounters Error 605 - Invalid Object ID
  7			Rollback of transaction initiated
  

• LSN Sequence		Action
  1			Checkpoint
  2			Begin Transaction
  3			Page Modification
  4			Page written to disk by Lazy Writer
  5			Page read in for another modification (stale image returned)
  6			Page Modified for a second time but because of stale image does not see first modification 
  7			Rollback ? Fails ? Transaction Log shows two different log records with the same PREV LSN for the page
  

SQL Server 'sortiert' Operatoren nach der Durchführung von E/A-Aktivitäten, in erster Linie zur und von der tempdb-Datenbank. Diese E/A-Operationen ähneln den E/A-Operationen des Puffers, sie wurden jedoch bereits für die Verwendung von Logik zur Wiederholung des Lesevorgangs eingerichtet, um ähnliche Probleme beheben zu können. Die in diesem Artikel beschriebene zusätzliche Diagnose gilt nicht für diese E/A-Operationen.

Microsoft hat festgestellt, dass die Hauptursache der folgenden Fehler beim Sortierlesen im Allgemeinen das Lesen veralteter Daten oder Schreibverlust ist:Die Kunden, bei denen diese Fehler beim Sortieren auftraten, konnte das Problem häufig lösen, indem sie tempdb auf ein lokales Laufwerk ohne Cache verschoben haben, oder indem sie den Lesecachemechanismus deaktiviert haben.

Da das Lesen veralteter Daten oder ein Schreibverlust zur unerwarteter Speicherung von Daten führt, gibt es eine große Bandbreite an eventuell auftretenden Verhalten. Möglicherweise kommt es dazu, dass Daten fehlen, aber einige der häufiger auftretenden Auswirkungen von fehlenden Daten sind Beschädigungen des Index, wie beispielsweise Fehler 644 oder Fehler 625:Bei einige Kunden kam es zum Verlust von Zeilen, nachdem sie die Funktion zum Zählen der Zeilen durchgeführt haben. Dieses Problem tritt aufgrund eines Schreibverlusts auf. Vielleicht sollte die Seite mit der geclusterten Indexseitenkette verknüpft werden. Wenn das Schreiben physisch verloren gegangen ist, gehen auch die Daten verloren.

Wichtig Wenn bei Ihnen eine der Verhaltensweisen auftritt oder wenn Sie ähnliche Probleme in Zusammenhang mit der Deaktivierung des Cachemechanismus befürchten, empfiehlt Microsoft dringend, dass Sie das neueste Update für SQL Server sowie den aktuellsten SQL Server E/A-Stress Simulator beziehen. Microsoft rät auch dringend, das Betriebssystem und die zugeordneten Konfigurationen genau zu überprüfen.

Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: