Beschreibung von Protokollierungs- und Datenspeicheralgorithmen zur Erweiterung der Datenzuverlässigkeit in SQL Server

Originalproduktversion: SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005
Ursprüngliche KB-Nummer: 230785

Zusammenfassung

In diesem Artikel wird erläutert, wie die Protokollierung und Datenalgorithmen von Microsoft SQL Server die Zuverlässigkeit und Integrität von Daten erweitern.

Weitere Informationen zu den zugrunde liegenden Konzepten der Engines und zu Algorithm for Recovery and Isolation Exploiting Semantics (ARIES) finden Sie im Folgenden ACM-Transaktionen im Datenbanksystemdokument (unter Volume 17, Nummer 1, März 1992):

Externer Link: ARIES: Eine Transaktionswiederherstellungsmethode, die fein granulare Sperrung und partielle Rollbacks mithilfe der Write-Ahead-Protokollierung unterstützt

Im Dokument werden die SQL Server-Techniken behandelt, um die Datenzuverlässigkeit und -integrität im Zusammenhang mit Fehlern zu erweitern.

Es wird empfohlen, die folgenden Artikel in der Microsoft Knowledge Base zu lesen, um weitere Informationen zum Zwischenspeichern und alternativen Fehlermodusdiskussionen zu erhalten:

• Beschreibung der Zwischenspeicherung von Datenträgercontrollern in SQL Server

• Informationen zur Verwendung von Datenträgerlaufwerkcaches mit SQL Server, die jeder Datenbankadministrator kennen sollte

In diesem Artikel verwendete Begriffe

Bevor wir mit der eingehenden Diskussion beginnen, sind einige der Begriffe, die in diesem Artikel verwendet werden, in der folgenden Tabelle definiert.

Begriff	Definition
Akkusicherung	Separate und lokalisierte Batteriesicherungseinrichtung steht direkt zur Verfügung und wird durch den Caching-Mechanismus gesteuert, um Datenverluste zu verhindern. Dies ist keine unterbrechungsfreie Stromversorgung (UPS). Ein UPS garantiert keine Schreibaktivitäten und kann vom Zwischenspeicherungsgerät getrennt werden.
cache	Der zwischengeschaltete Speichermechanismus zur Optimierung physischer E/A-Vorgänge und zur Verbesserung der Leistung.
Geänderte Seite	Seite mit Datenänderungen, die noch nicht auf stabilen Speicher geleert werden sollen. Weitere Informationen zu schmutzigen Seitenpuffern finden Sie unter "Schreiben von Seiten " in SQL Server Books Online. Der Inhalt gilt auch für Microsoft SQL Server 2012 und höhere Versionen.
Fehler	Alles, was zu einem unerwarteten Ausfall des SQL Server-Prozesses führen kann. Beispiele: Stromausfall, Computerzurücksetzung, Speicherfehler, andere Hardwareprobleme, fehlerhafte Sektoren, Laufwerkausfälle, Systemausfälle usw.
Leerung	Erzwingen eines Cachepuffers zum stabilen Speicher.
Latch	Synchronisierungsobjekt, das zum Schutz der physischen Konsistenz einer Ressource verwendet wird.
Nichtvolatile Speicher	Jedes Medium, das über Systemfehler hinweg verfügbar bleibt.
Angeheftete Seite	Die Seite, die im Datencache verbleibt und nicht auf stabilen Speicher geleert werden kann, bis alle zugehörigen Protokolldatensätze an einem stabilen Speicherort gesichert sind.
Stabiler Speicher	Identisch mit nichtvolatilem Speicher.
Flüchtiger Speicher	Jedes Medium, das nicht über Fehler hinweg intakt bleibt.

Write-Ahead Logging (WAL)-Protokoll

Der Begriff Protokoll ist eine hervorragende Möglichkeit, WAL zu beschreiben. Es handelt sich um einen bestimmten und definierten Satz von Implementierungsschritten, die erforderlich sind, um sicherzustellen, dass Daten ordnungsgemäß gespeichert und ausgetauscht werden und in einen bekannten Zustand wiederhergestellt werden können, wenn ein Fehler auftritt. 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.

Das DOKUMENT ARIES definiert das WAL wie folgt:

Das WAL-Protokoll bestätigt, dass die Protokolldatensätze, die Änderungen an einigen Daten darstellen, bereits im stabilen Speicher vorhanden sein müssen, bevor die geänderten Daten die vorherige Version der Daten im nicht volatile Speicher ersetzen dürfen. Das System darf also keine aktualisierte Seite in die nicht volatile Speicherversion der Seite schreiben, bis mindestens die Rückgängig-Teile der Protokolldatensätze, die die Aktualisierungen der Seite beschreiben, in stabilen Speicher geschrieben wurden.

Weitere Informationen zur Protokollierung mit Schreibschutz finden Sie im Thema "Write-Ahead Transaction Log " in SQL Server Books Online.

SQL Server und wal

SQL Server verwendet das WAL-Protokoll. Um sicherzustellen, dass eine Transaktion ordnungsgemäß zugesichert ist, müssen alle Protokolldatensätze, die der Transaktion zugeordnet sind, im stabilen Speicher gesichert werden.

Um diese Situation zu klären, betrachten Sie das folgende spezifische Beispiel.

Notiz

Gehen Sie in diesem Beispiel davon aus, dass kein Index vorhanden ist und dass die betroffene Seite Seite 150 ist.

BEGIN TRANSACTION
 INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION

Unterteilen Sie als Nächstes die Aktivität in vereinfachte Protokollierungsschritte, wie in der folgenden Tabelle beschrieben.

Anweisung	Ausgeführte Aktionen
BEGINTRANSACTION	In den Protokollcachebereich geschrieben. Es ist jedoch nicht erforderlich, den stabilen Speicher zu leeren, da der SQL Server keine physischen Änderungen vorgenommen hat.
INSERT INTO tblTest	1. Die Datenseite 150 wird im SQL Server-Datencache abgerufen, sofern noch nicht verfügbar. 2. Die Seite wird angeheftet, angeheftet und gekennzeichnet, und entsprechende Sperren werden abgerufen. 3. Ein Datensatz zum Einfügen von Protokollen wird erstellt und dem Protokollcache hinzugefügt. 4. Der Datenseite wird eine neue Zeile hinzugefügt. 5. Der Riegel wird losgelassen. 6. Die protokollierten Datensätze, die der Transaktion oder Seite zugeordnet sind, müssen an diesem Punkt nicht geleert werden, da alle Änderungen im veränderliche Speicher verbleiben.
COMMIT TRANSACTION	1. Ein Commit-Protokolldatensatz wird gebildet, und die protokollierten Datensätze, die der Transaktion zugeordnet sind, müssen in einen stabilen Speicher geschrieben werden. Die Transaktion gilt nicht als zugesichert, bis die Protokolldatensätze ordnungsgemäß dem stabilen Speicher zugewiesen sind. 2. Die Datenseite 150 verbleibt im SQL Server-Datencache und wird nicht sofort auf stabilen Speicher geleert. Wenn die Protokolldatensätze ordnungsgemäß gesichert sind, kann die Wiederherstellung den Vorgang wiederholen, falls erforderlich. 3. Transaktionssperren werden freigegeben.

Verwechseln Sie sich nicht mit den Begriffen "Sperren" und "Protokollierung". Obwohl wichtig, sperren und protokollieren sind separate Probleme beim Umgang mit dem WAL. Im vorherigen Beispiel enthält SQL Server in der Regel den Riegel auf Seite 150 für die Zeit, die erforderlich ist, um die physischen Einfügeänderungen auf der Seite auszuführen, nicht die gesamte Zeit der Transaktion. Der entsprechende Sperrtyp wird eingerichtet, um die Zeile, den Bereich, die Seite oder die Tabelle nach Bedarf zu schützen. Weitere Informationen zu Sperrtypen finden Sie in den Abschnitten "SQL Server Books Online".

Wenn Sie sich das Beispiel genauer ansehen, können Sie fragen, was passiert, wenn die LazyWriter- oder CheckPoint-Prozesse ausgeführt werden. SQL Server gibt alle geeigneten Leerungen für den stabilen Speicher für Transaktionsprotokolldatensätze aus, die der schmutzigen und angehefteten Seite zugeordnet sind. Dadurch wird sichergestellt, dass die WAL-Protokolldatenseite nie in stabilen Speicher geschrieben werden kann, bis die zugehörigen Transaktionsprotokolldatensätze geleert wurden.

SQL Server und stabiler Speicher

SQL Server verbessert Protokoll- und Datenseitenvorgänge, indem die Größe des Datenträgersektors (häufig 4.096 Byte oder 512 Byte) berücksichtigt wird.

Um die ACID-Eigenschaften einer Transaktion beizubehalten, muss sql Server Fehlerpunkte berücksichtigen. Während eines Ausfalls garantieren viele Datenträgerlaufwerkspezifikationen nur eine begrenzte Anzahl von Sektorschreibvorgängen. Die meisten Spezifikationen garantieren den Abschluss eines einzelnen Sektors, wenn ein Fehler auftritt.

SQL Server verwendet 8-KB-Datenseiten und das Protokoll (sofern geleert) auf Vielfachen der Sektorgröße. (Die meisten Festplattenlaufwerke verwenden 512 Byte als Standardsektorgröße.) Wenn ein Fehler auftritt, kann SQL Server Schreibvorgänge berücksichtigen, die größer als ein Sektor sind, indem protokollparitätische und torn-Schreibtechniken verwendet werden.

Erkennung von Tornseiten

Mit dieser Option kann SQL Server unvollständige E/A-Vorgänge erkennen, die durch Stromausfälle oder andere Systemausfälle verursacht werden. Wenn dies der Fall ist, wird ein Bit für jeden 512-Byte-Sektor in einer 8 KB-Datenbankseite gedreht, wenn die Seite auf den Datenträger geschrieben wird. Wenn sich ein Bisschen im falschen Zustand befindet, wenn die Seite später von SQL Server gelesen wird, wurde die Seite falsch geschrieben. eine torn-Seite wird erkannt. Torn-Seiten werden während der Wiederherstellung erkannt, da jede Seite, die falsch geschrieben wurde, wahrscheinlich von der Wiederherstellung gelesen wird.

Obwohl SQL Server-Datenbankseiten 8 KB sind, führen Datenträger E/A-Vorgänge mithilfe eines 512-Byte-Sektors aus. Daher werden 16 Sektoren pro Datenbankseite geschrieben. Eine Tornseite kann auftreten, wenn das System (z. B. aufgrund eines Stromausfalls) zwischen dem Zeitpunkt, zu dem das Betriebssystem den ersten 512-Byte-Sektor auf den Datenträger schreibt, und dem Abschluss des 8-KB-E/A-Vorgangs fehlschlägt. Wenn der erste Sektor einer Datenbankseite erfolgreich vor dem Fehler geschrieben wird, wird die Datenbankseite auf dem Datenträger als aktualisiert angezeigt, obwohl sie möglicherweise nicht erfolgreich war.

Durch die Verwendung von Akku-gesicherten Datenträgercontrollercaches können Sie sicherstellen, dass Daten erfolgreich auf den Datenträger geschrieben oder gar nicht geschrieben werden. Legen Sie in diesem Fall die Erkennung von Seiten nicht auf "true" fest, da dies nicht erforderlich ist.

Notiz

Die Erkennung von Tornseiten ist in SQL Server standardmäßig nicht aktiviert. Weitere Informationen finden Sie unter ALTER DATABASE SET-Optionen (Transact-SQL).

Protokollparität

Die Überprüfung der Protokollparität ähnelt der Erkennung von RN-Seiten. Jeder 512-Byte-Sektor enthält Paritätsbits. Diese Paritätsbits werden immer mit dem Protokolldatensatz geschrieben und ausgewertet, wenn der Protokolldatensatz abgerufen wird. Durch das Erzwingen von Protokollschreibvorgängen auf einer Grenze von 512 Byte kann SQL Server sicherstellen, dass Committalvorgänge in die physischen Datenträgersektoren geschrieben werden.

Auswirkungen auf die Leistung

Alle Versionen von SQL Server öffnen die Protokoll- und Datendateien mithilfe der Win32 CreateFile-Funktion. Das dwFlagsAndAttributes-Element enthält die FILE_FLAG_WRITE_THROUGH Option, wenn sie von SQL Server geöffnet werden.

FILE_FLAG_WRITE_THROUGH weist das System an, über jeden Zwischencache zu schreiben und direkt auf den Datenträger zu wechseln. Das System kann Schreibvorgänge weiterhin zwischenspeichern, sie aber nicht verzögert leeren.

Die FILE_FLAG_WRITE_THROUGH Option stellt sicher, dass die Daten korrekt im stabilen Speicher gespeichert werden, wenn ein Schreibvorgang einen erfolgreichen Abschluss zurückgibt. Dies entspricht dem WAL-Protokoll, das die Daten sicherstellt.

Viele Festplattenlaufwerke (SCSI und IDE) enthalten Onboard-Caches von 512 KB, 1 MB oder höher. Die Laufwerkcaches basieren jedoch 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. Dies ist insbesondere der Grund, warum die Paritätserkennung in SQL Server 7.0 und höhere Versionen integriert wurde. Da die Laufwerke weiterhin in der Größe wachsen, werden die Caches größer, und sie können größere Datenmengen während eines Fehlers verfügbar machen.

Viele Hardwareanbieter bieten Lösungen für akkugestützte Datenträgercontroller. Diese Controllercaches können die Daten im Cache mehrere Tage lang verwalten und sogar zulassen, dass die Zwischenspeicherhardware auf einem zweiten Computer platziert wird. Wenn die Stromversorgung ordnungsgemäß wiederhergestellt wird, werden die nicht geschriebenen Daten geleert, bevor der weitere Datenzugriff zulässig ist. Viele von ihnen ermöglichen die Erstellung eines Prozentsatzes des Lese- und Schreibcaches für eine optimale Leistung. Einige enthalten große Arbeitsspeicherbereiche. Tatsächlich bieten einige Hardwareanbieter für ein bestimmtes Segment des Marktes High-End-Speicherspeicherungscontrollersysteme mit 6 GB Cache an. Diese können die Leistung der Datenbank erheblich verbessern.

Erweiterte Zwischenspeicherungsimplementierungen behandeln die FILE_FLAG_WRITE_THROUGH Anforderung, indem der Controllercache nicht deaktiviert wird, da sie im Falle einer Systemzurücksetzung, eines Stromausfalls oder eines anderen Fehlerpunkts echte Neuschreibfunktionen bereitstellen können.

E/A-Übertragungen ohne Die Verwendung eines Caches können aufgrund der mechanischen Zeit, die zum Verschieben der Laufwerksköpfe, Drehraten und anderer Begrenzungsfaktoren erforderlich ist, länger sein.

Sektorbestellung

Ein gängiges Verfahren zur Steigerung der E/A-Leistung ist die Sektorordnung. Um mechanische Kopfbewegungen zu vermeiden, werden die Lese-/Schreibanforderungen sortiert, sodass eine konsistentere Bewegung des Kopfes zum Abrufen oder Speichern von Daten ermöglicht wird.

Der Cache kann mehrere Protokoll- und Datenschreibanforderungen gleichzeitig enthalten. Das WAL-Protokoll und die SQL Server-Implementierung des WAL-Protokolls erfordern das Leeren der Protokollschreibvorgänge in stabilen Speicher, bevor der Seitenschreibvorgang ausgegeben werden kann. Die Verwendung des Caches kann jedoch erfolglos aus einer Protokollschreibanforderung zurückgeben, ohne dass die Daten auf das tatsächliche Laufwerk geschrieben werden (d. a. in stabilen Speicher geschrieben). Dies kann dazu führen, dass SQL Server die Datenseiten-Schreibanforderung ausgibt.

Bei der Einbindung des Schreibcaches werden die Daten weiterhin als veränderliche Speicher betrachtet. Aus dem Win32-API WriteFile-Aufruf wurde jedoch genau wie SQL Server die Aktivität sieht, ein erfolgreicher Rückgabecode abgerufen. SQL Server oder ein beliebiger Prozess, der den WriteFile-API-Aufruf verwendet, kann nur bestimmen, dass die Daten ordnungsgemäß stabilen Speicher erhalten haben.

Gehen Sie zu Diskussionszwecken davon aus, dass alle Bereiche der Datenseite sortiert werden, um vor den Sektoren der übereinstimmenden Protokolldatensätze zu schreiben. Dies verstößt sofort gegen das WAL-Protokoll. Der Cache schreibt eine Datenseite vor den Protokolldatensätzen. Sofern der Cache nicht vollständig akkusichert ist, kann ein Fehler zu katastrophalen Ergebnissen führen.

Wenn Sie die optimalen Leistungsfaktoren für einen Datenbankserver auswerten, sind viele Faktoren zu berücksichtigen. Das Wichtigste ist: "Lässt mein System gültige FILE_FLAG_WRITE_THROUGH Funktionen zu?"

Notiz

Jeder cache, den Sie verwenden, muss eine akkugestützte Lösung vollständig unterstützen. Alle anderen Zwischenspeicherungsmechanismen sind anfällig für Datenbeschädigungen und Datenverlust. SQL Server bemüht sich, den WAL durch Aktivieren FILE_FLAG_WRITE_THROUGHvon WAL sicherzustellen.

Tests haben gezeigt, dass viele Laufwerkkonfigurationen schreibzwischenspeichern können, ohne die entsprechende Akkusicherung. SCSI-, IDE- und EIDE-Laufwerke nutzen die vollen Vorteile von Schreibcaches. Weitere Informationen dazu, wie SSDs mit SQL Server zusammenarbeiten, finden Sie im folgenden BLOGartikel zu CSS SQL Server Engineers:

SQL Server und SSDs – Lernnotizen von RDORR – Teil 1

In vielen Konfigurationen ist die einzige Möglichkeit, die Schreibzwischenspeicherung eines IDE- oder EIDE-Laufwerks ordnungsgemäß zu deaktivieren, indem ein bestimmtes Herstellerhilfsprogramm oder Jumper verwendet wird, die sich auf dem Laufwerk selbst befinden. Um sicherzustellen, dass der Schreibcache für das Laufwerk selbst deaktiviert ist, wenden Sie sich an den Laufwerkhersteller.

SCSI-Laufwerke verfügen auch über Schreibcaches. Diese Caches können jedoch häufig vom Betriebssystem deaktiviert werden. Wenn eine Frage besteht, wenden Sie sich an den Laufwerkhersteller, um entsprechende Dienstprogramme zu suchen.

Schreiben des Cachestapels

Das Schreiben des Cachestapels ähnelt der Sektorreihenfolge. Die folgende Definition wurde direkt von einer führenden Website des IDE-Laufwerkherstellers übernommen:

Normalerweise ist dieser Modus aktiv. Der Schreibcachemodus akzeptiert den Hostschreibdaten in den Puffer, bis der Puffer voll ist oder die Hostübertragung abgeschlossen ist.

Eine Datenträgerschreibaufgabe beginnt mit dem Speichern der Hostdaten auf dem Datenträger. Hostschreibbefehle werden weiterhin akzeptiert und daten, die an den Puffer übertragen werden, bis entweder der Schreibbefehlsstapel voll ist oder der Datenpuffer voll ist. Das Laufwerk kann Schreibbefehle neu anordnen, um den Laufwerkdurchsatz zu optimieren.

Automatische Schreibverlagerung (AWR)

Eine weitere gängige Technik, die zum Schutz von Daten verwendet wird, besteht darin, fehlerhafte Sektoren während der Datenmanipulation zu erkennen. Die folgende Erläuterung stammt von einer führenden Website des IDE-Laufwerkherstellers:

Dieses Feature ist Teil des Schreibcaches und reduziert das Risiko von Datenverlust während verzögerter Schreibvorgänge. Wenn während des Datenträgerschreibvorgangs ein Datenträgerfehler auftritt, wird die Datenträgeraufgabe beendet, und der verdächtige Sektor wird einem Pool von alternativen Sektoren zugeordnet, die sich am Ende des Laufwerks befinden. Nach der Neuzuweisung wird die Datenträgerschreibaufgabe fortgesetzt, bis sie abgeschlossen ist.

Dies kann ein leistungsfähiges Feature sein, wenn die Akkusicherung für den Cache bereitgestellt wird. Dadurch wird beim Neustart eine entsprechende Änderung bereitgestellt. Es ist vorzuziehen, die Datenträgerfehler zu erkennen, aber die Datensicherheit des WAL-Protokolls würde dies erneut in Echtzeit und nicht auf verzögerte Weise erfordern. Innerhalb der WAL-Parameter kann die AWR-Technik keine Situation berücksichtigen, in der ein Protokollschreibfehler aufgrund eines Sektorfehlers fehlschlägt, das Laufwerk jedoch voll ist. Das Datenbankmodul muss sofort über den Fehler informiert werden, damit die Transaktion ordnungsgemäß abgebrochen werden kann, der Administrator benachrichtigt werden kann, und die richtigen Schritte zur Sicherung der Daten und zur Behebung der Medienfehlersituation ausgeführt werden.

Datensicherheit

Es gibt mehrere Vorsichtsmaßnahmen, die ein Datenbankadministrator ergreifen sollte, um die Sicherheit der Daten zu gewährleisten.

• Es ist immer eine gute Idee, sicherzustellen, dass Ihre Backup-Strategie ausreicht, um sich von einem katastrophalen Fehler zu erholen. Offsite-Lagerung und andere Vorsichtsmaßnahmen sind angemessen.
• Testen Sie den Datenbankwiederherstellungsvorgang in einer sekundären oder Testdatenbank häufig.
• Stellen Sie sicher, dass alle Zwischenspeicherungsgeräte alle Ausfallsituationen verarbeiten können (Stromausfall, schlechte Sektoren, schlechte Laufwerke, Systemausfall, Sperren, Leistungsspitzen usw.).
• Stellen Sie sicher, dass Ihr Zwischenspeicherungsgerät:
  • Integrierte Akkusicherung
  • Kann Schreibvorgänge auf Power-Up neu erstellen
  • Kann vollständig deaktiviert werden, wenn dies erforderlich ist
  • Behandelt fehlerhafte Sektorumgestaltung in Echtzeit
• Aktivieren sie die Erkennung von Tornseiten. (Dies hat wenig Auswirkungen auf die Leistung.)
• Konfigurieren Sie RAID-Laufwerke, die einen hot Swap eines fehlerhaften Festplattenlaufwerks ermöglichen, wenn dies möglich ist.
• Verwenden Sie neuere Cachecontroller, mit denen Sie mehr Speicherplatz hinzufügen können, ohne das Betriebssystem neu zu starten. Dies kann eine ideale Lösung sein.

Testen von Laufwerken

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

Notiz

Stellen Sie sicher, dass ein alternativer Cachemechanismus mehrere Fehlertypen ordnungsgemäß verarbeiten kann.

Microsoft hat mithilfe des SQLIOSim Hilfsprogramms Tests auf mehreren SCSI- und IDE-Laufwerken durchgeführt. Dieses Hilfsprogramm simuliert schwere asynchrone Lese-/Schreibaktivitäten auf einem simulierten Datengerät und Protokollgerät. Testleistungsstatistiken zeigen die durchschnittlichen Schreibvorgänge pro Sekunde zwischen 50 und 70 für ein Laufwerk mit deaktivierter Schreibzwischenspeicherung und einem RPM-Bereich zwischen 5.200 und 7.200 an.

Weitere Informationen zum SQLIOSim Hilfsprogramm finden Sie im folgenden Artikel in der Microsoft Knowledge Base:

Verwenden des SQLIOSim-Hilfsprogramms zum Simulieren der SQL Server-Aktivität auf einem Datenträgersubsystem

Viele Computerhersteller bestellen die Laufwerke, indem der Schreibcache deaktiviert ist. Tests zeigen jedoch, dass dies möglicherweise nicht immer der Fall ist. Testen Sie daher immer vollständig.

Datengeräte

In allen nicht protokollierten Situationen muss SQL Server nur die Protokolldatensätze geleert werden. Bei nicht protokollierten Vorgängen müssen die Datenseiten ebenfalls auf einen stabilen Speicher geleert werden. es gibt keine einzelnen Protokolldatensätze, um die Aktionen im Falle eines Fehlers neu zu generieren.

Die Datenseiten können im Cache verbleiben, bis der LazyWriter- oder CheckPoint-Prozess sie auf stabilen Speicher löscht. Wenn Sie das WAL-Protokoll verwenden, um sicherzustellen, dass die Protokolldatensätze korrekt gespeichert sind, stellen Sie sicher, dass die Wiederherstellung eine Datenseite in einen bekannten Zustand wiederherstellen kann.

Dies bedeutet nicht, dass es ratsam ist, Datendateien auf einem zwischengespeicherten Laufwerk zu platzieren. Wenn sql Server die Datenseiten in stabilen Speicher löscht, können die Protokolldatensätze aus dem Transaktionsprotokoll abgeschnitten werden. Wenn die Datenseiten im veränderbaren Cache gespeichert werden, können Protokolldatensätze abgeschnitten werden, die zum Wiederherstellen einer Seite im Falle eines Fehlers verwendet werden. Stellen Sie sicher, dass sowohl Ihre Daten als auch Die Protokollgeräte einen stabilen Speicher richtig berücksichtigen.

Leistungssteigerung

Die erste Frage, die für Sie auftreten kann, ist: "Ich habe ein IDE-Laufwerk, das zwischengespeichert wurde. Aber als ich es deaktiviert habe, wurde meine Leistung weniger als erwartet. Warum?"

Viele der von Microsoft getesteten IDE-Laufwerke werden mit 5.200 U/MIN und die SCSI-Laufwerke mit 7.200 U/MIN ausgeführt. Wenn Sie die Schreibzwischenspeicherung des IDE-Laufwerks deaktivieren, kann die mechanische Leistung zu einem Faktor werden.

Um den Leistungsunterschied zu beheben, ist die folgende Methode klar: "Adressieren der Transaktionsrate".

Viele OLTP-Systeme (Online Transaction Processing) erfordern eine hohe Transaktionsrate. Berücksichtigen Sie für diese Systeme die Verwendung eines Cachecontrollers, der einen Schreibcache unterstützen kann, und stellen Sie die gewünschte Leistungssteigerung bereit, während gleichzeitig die Datenintegrität sichergestellt wird.

Um erhebliche Leistungsänderungen zu beobachten, die in SQL Server auf einem Cachelaufwerk auftreten, wurde die Transaktionsrate mit kleinen Transaktionen erhöht.

Tests zeigen, dass hohe Schreibaktivitäten von Puffern, die kleiner als 512 KB oder größer als 2 MB sind, zu einer langsamen Leistung führen können.

Betrachten Sie das folgende Beispiel:

CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
INSERT INTO tblTest VALUES ('Test')

Im Folgenden sind Beispieltestergebnisse für SQL Server aufgeführt:

SCSI(7200 RPM) 84 seconds
SCSI(7200 RPM) 15 seconds (Caching controller)

IDE(5200 RPM) 14 seconds (Drive cache enabled)
IDE(5200 RPM) 160 seconds

Der Prozess des Umbruchs der gesamten Reihe von INSERT Vorgängen in eine einzelne Transaktion wird in etwa vier Sekunden in allen Konfigurationen ausgeführt. Dies liegt an der Anzahl der erforderlichen Protokolllöschungen. Wenn Sie keine einzelne Transaktion erstellen, wird jede INSERT Transaktion als separate Transaktion verarbeitet. Daher müssen alle Protokolldatensätze für die Transaktion geleert werden. Jede Leerung ist 512 Byte groß. Dies erfordert einen erheblichen mechanischen Antriebseingriff.

Wenn eine einzelne Transaktion verwendet wird, können die Protokolldatensätze für die Transaktion gebündelt werden, und ein einzelner, größerer Schreibzugriff kann verwendet werden, um die gesammelten Protokolldatensätze zu leeren. Dies reduziert den mechanischen Eingriff erheblich.

Warnung

Es wird empfohlen, den Transaktionsumfang nicht zu erhöhen. Lange ausgeführte Transaktionen können zu übermäßigem und unerwünschtem Blockieren und erhöhtem Mehraufwand führen. Verwenden Sie die SQL Server:Databases SQL Server-Leistungsindikatoren, um die transaktionsprotokollbasierten Leistungsindikatoren anzuzeigen. Insbesondere können log Bytes Flushed/Sec auf viele kleine Transaktionen hinweisen, die zu einer hohen mechanischen Datenträgeraktivität führen können.

Überprüfen Sie die Anweisungen, die dem Protokoll geleert werden, um zu ermitteln, ob der Wert "Log Bytes Flushed/Sec" reduziert werden kann. Im vorherigen Beispiel wurde eine einzelne Transaktion verwendet. In vielen Szenarien kann dies jedoch zu unerwünschtem Sperrverhalten führen. Überprüfen Sie den Entwurf der Transaktion. Sie können Code verwenden, der dem folgenden Code ähnelt, um Batches auszuführen, um die häufige und kleine Log-Flush-Aktivität zu reduzieren:

BEGIN TRAN
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
    BEGIN
        INSERT INTO tblTest VALUES ('Test')
  
        if(0 = cast(@@IDENTITY as int) % 10)
        BEGIN
            PRINT 'Commit tran batch'
            COMMIT TRAN
            BEGIN TRAN
        END
    END
GO

COMMIT TRAN
GO

SQL Server erfordert, dass Systeme die garantierte Übermittlung an stabile Medien unterstützen, wie im Downloaddokument für das SQL Server-E/A-Zuverlässigkeitsprogramm beschrieben. Weitere Informationen zu den Eingabe- und Ausgabeanforderungen für das SQL Server-Datenbankmodul finden Sie unter Microsoft SQL Server Datenbank-Engine Input/Output Requirements.