Beschreibung der Protokollierungs- und Datenspeicheralgorithmen, die die Datensicherheit in SQL Server

Ursprüngliche Produktversion: 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 Microsoft SQL Server Protokollierungs- und Datenalgorithmen 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 Dokument zu ACM-Transaktionen auf Datenbanksystemen (unter Volume 17, Nummer 1, März 1992):

Externer Link: ARIES: Eine Transaktionswiederherstellungsmethode, die Fine-Granularity Sperren und teilweise Rollbacks mit Write-Ahead Protokollierung unterstützt

Das Dokument behandelt die SQL Server Techniken zum Erweitern der Datenzuverlässigkeit und -integrität im Zusammenhang mit Fehlern.

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

• Beschreibung des Zwischenspeicherns von Datenträgercontrollern in SQL Server

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

In diesem Artikel verwendete Begriffe

Bevor wir mit der ausführlichen Diskussion beginnen, werden einige der Begriffe, die in diesem Artikel verwendet werden, in der folgenden Tabelle definiert.

WAL-Protokoll (Write-Ahead Logging)

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 im Fall eines Fehlers in einen bekannten Zustand wiederhergestellt werden können. So wie ein Netzwerk ein definiertes Protokoll zum konsistenten und geschützten Datenaustausch enthält, beschreibt auch das WAL das Protokoll zum Schutz von Daten.

Das ARIES-Dokument definiert das WAL wie folgt:

Das WAL-Protokoll bestätigt, dass sich die Protokolldatensätze, die Änderungen an einigen Daten darstellen, bereits im stabilen Speicher befinden müssen, bevor die geänderten Daten die vorherige Version der Daten im nicht flüchtigen Speicher ersetzen dürfen. Das heißt, das System darf keine aktualisierte Seite in die nicht flüchtige Speicherversion der Seite schreiben, bis mindestens die Rückgängig-Teile der Protokolldatensätze, die die Aktualisierungen der Seite beschreiben, in den stabilen Speicher geschrieben wurden.

Weitere Informationen zur Write-Ahead-Protokollierung finden Sie im Thema Write-Ahead-Transaktionsprotokoll in der SQL Server-Onlinedokumentation.

SQL Server und das WAL

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

Um diese Situation zu verdeutlichen, betrachten Sie das folgende spezifische Beispiel.

BEGIN TRANSACTION
 INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION

Als Nächstes unterteilen Sie die Aktivität in einfache Protokollierungsschritte, wie in der folgenden Tabelle beschrieben.

Lassen Sie sich nicht mit den Begriffen "Sperren" und "Protokollierung" verwechseln. Obwohl es wichtig ist, sind Sperren und Protokollierung separate Probleme, wenn Sie mit dem WAL umgehen. Im vorherigen Beispiel hält SQL Server den Latch auf Seite 150 in der Regel für die Zeit, die zum Ausführen der physischen Einfügeänderungen auf der Seite erforderlich ist, nicht für 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 der SQL Server-Onlinedokumentation.

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

SQL Server und stabiler Speicher

SQL Server verbessert Protokoll- und Datenseitenvorgänge, indem das Wissen über Datenträgersektorgrößen (in der Regel 4.096 Byte oder 512 Byte) eingeschlossen wird.

Um die ACID-Eigenschaften einer Transaktion beizubehalten, muss der SQL Server Fehlerpunkte berücksichtigen. Bei einem Ausfall garantieren viele Datenträgerspezifikationen nur eine begrenzte Anzahl von Sektorschreibvorgängen. Die meisten Spezifikationen garantieren den Abschluss eines einzelnen Sektorschreibvorgangs, wenn ein Fehler auftritt.

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

Erkennung von abgerissenen Seiten

Mit dieser Option können SQL Server unvollständige E/A-Vorgänge erkennen, die durch Stromausfälle oder andere Systemausfälle verursacht werden. Wenn true, bewirkt dies, dass ein Bit für jeden 512-Byte-Sektor auf einer 8-KB-Datenbankseite gedreht wird, wenn die Seite auf den Datenträger geschrieben wird. Wenn sich ein Bit im falschen Zustand befindet, wenn die Seite später von SQL Server gelesen wird, wurde die Seite falsch geschrieben. Eine abgerissene Seite wird erkannt. Bei der Wiederherstellung werden abgerissene Seiten erkannt, da jede seite, die falsch geschrieben wurde, wahrscheinlich von der Wiederherstellung gelesen wird.

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

Mithilfe von akkugestützten 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 abgerissenen Seiten nicht auf "true" fest, da dies nicht erforderlich ist.

Protokollparität

Die Protokollparitätsüberprüfung ähnelt der Erkennung von aufrissenen 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 erzwingen von Protokollschreibvorgängen an einer 512-Byte-Grenze können SQL Server sicherstellen, dass Commitvorgänge in die physischen Datenträgersektoren geschrieben werden.

Auswirkungen auf die Leistung

Alle Versionen von SQL Server die Protokoll- und Datendateien mithilfe der Win32 CreateFile-Funktion öffnen. 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, aber nicht verzögert leeren.

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

Viele Laufwerke (SCSI und IDE) enthalten integrierte Caches mit einer Größe von 512 KB, 1 MB oder mehr. 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 Fehlerpunkt garantieren. Sie garantieren nur den Abschluss der Sektorschreibvorgänge. Dies ist insbesondere der Grund, warum die Erkennung von zerrissenen Schreib- und Protokollparitäten in SQL Server 7.0 und höheren Versionen integriert wurden. Wenn die Laufwerke weiter an Größe zunehmen, 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 an. Diese Controllercaches können die Daten im Cache mehrere Tage lang verwalten und sogar die Zwischenspeicherhardware auf einem zweiten Computer platzieren. Wenn die Stromversorgung ordnungsgemäß wiederhergestellt wird, werden die nicht geschriebenen Daten geleert, bevor der weitere Datenzugriff zugelassen wird. Viele von ihnen ermöglichen es, einen Prozentsatz des Lese- und Schreibcaches für eine optimale Leistung zu erstellen. Einige enthalten große Speicherbereiche. Tatsächlich bieten einige Hardwareanbieter für ein bestimmtes Segment des Marktes High-End-Akku-Caching-Controllersysteme mit 6 GB Cache an. Diese können die Datenbankleistung erheblich verbessern.

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

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

Sektorreihenfolge

Ein gängiges Verfahren zum Erhöhen der E/A-Leistung ist die Sektorreihenfolge. 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 den stabilen Speicher, bevor der Seitenschreibvorgang ausgegeben werden kann. Die Verwendung des Caches kann jedoch zu einer erfolgreichen Protokollschreibanforderung führen, ohne dass die Daten auf das eigentliche Laufwerk (d. a. in einen stabilen Speicher geschrieben) geschrieben werden. Dies kann dazu führen, dass SQL Server die Schreibanforderung für die Datenseite ausgibt.

Da der Schreibcache beteiligt ist, werden die Daten weiterhin als in flüchtigem Speicher betrachtet. Aus dem Aufruf der Win32-API WriteFile wurde jedoch genau so, 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 feststellen, dass die Daten ordnungsgemäß stabilen Speicher erhalten haben.

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

Wenn Sie die optimalen Leistungsfaktoren für einen Datenbankserver auswerten, müssen viele Faktoren berücksichtigt werden. Die wichtigste davon ist: "Lässt mein System gültige FILE_FLAG_WRITE_THROUGH Funktionen zu?"

Tests haben gezeigt, dass viele Festplattenlaufwerkkonfigurationen das Zwischenspeichern von Schreibvorgängen ohne die entsprechende Akkusicherung enthalten können. SCSI-, IDE- und EIDE-Laufwerke nutzen schreibcaches in vollem Umfang. Weitere Informationen zur Zusammenarbeit von SSDs mit SQL Server finden Sie im folgenden Blogartikel zum 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, die Verwendung eines bestimmten Herstellerhilfsprogramms oder die Verwendung von Jumpern, die sich auf dem Laufwerk selbst befinden. Wenden Sie sich an den Hersteller des Laufwerks, um sicherzustellen, dass der Schreibcache für das Laufwerk selbst deaktiviert ist.

SCSI-Laufwerke verfügen auch über Schreibcaches. Diese Caches können jedoch häufig vom Betriebssystem deaktiviert werden. Wenn Sie Fragen haben, wenden Sie sich an den Hersteller des Laufwerks, um entsprechende Hilfsprogramme zu erfragen.

Stapeln des Schreibcaches

Schreibcachestapelung ähnelt der Sektorreihenfolge. Die folgende Definition stammt direkt aus der Website eines führenden IDE-Laufwerkherstellers:

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

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

Automatische Neuzuordnung von Schreibvorgängen (AWR)

Eine weitere gängige Technik, die zum Schutz von Daten verwendet wird, besteht darin, fehlerhafte Sektoren während der Datenbearbeitung zu erkennen. Die folgende Erklärung stammt aus der Website eines führenden IDE-Laufwerkherstellers:

Dieses Feature ist Teil des Schreibcaches und verringert das Risiko von Datenverlusten bei verzögerten Schreibvorgängen. Wenn während des Schreibvorgangs des Datenträgers ein Datenträgerfehler auftritt, wird der Datenträgertask beendet, und der verdächtige Sektor wird einem Pool alternativer Sektoren am Ende des Laufwerks zugeordnet. Nach der Neuzuordnung wird der Datenträgerschreibtask fortgesetzt, bis er abgeschlossen ist.

Dies kann ein leistungsstarkes Feature sein, wenn eine Akkusicherung für den Cache bereitgestellt wird. Dies ermöglicht eine entsprechende Änderung beim Neustart. Es ist besser, die Datenträgerfehler zu erkennen, aber die Datensicherheit des WAL-Protokolls erfordert erneut, dass dies in Echtzeit und nicht auf verzögerte Weise erfolgt. Innerhalb der WAL-Parameter kann die AWR-Technik keine Situation berücksichtigen, in der ein Protokollschreibvorgang aufgrund eines Sektorfehlers fehlschlägt, aber das Laufwerk voll ist. Die Datenbank-Engine muss sofort über den Fehler informiert werden, damit die Transaktion ordnungsgemäß abgebrochen werden kann, der Administrator benachrichtigt werden kann und die Schritte zum Schützen der Daten und zur Behebung der Medienfehlersituation ausgeführt werden können.

Datensicherheit

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

• Es ist immer eine gute Idee, sicherzustellen, dass Ihre Sicherungsstrategie ausreicht, um nach einem schwerwiegenden Fehler wiederherzustellen. Externe Speicherung und andere Vorsichtsmaßnahmen sind angemessen.
• Testen Sie den Datenbankwiederherstellungsvorgang häufig in einer sekundären Datenbank oder Testdatenbank.
• Stellen Sie sicher, dass alle Zwischenspeichergeräte alle Fehlersituationen verarbeiten können (Stromausfall, fehlerhafte Sektoren, fehlerhafte Laufwerke, Systemausfall, Sperrungen, Stromspitzen usw.).
• Stellen Sie sicher, dass Ihr Zwischenspeichergerät:
  • Verfügt über integrierte Akkusicherung
  • Schreibvorgänge können beim Einschalten erneut ausgegeben werden
  • Kann bei Bedarf vollständig deaktiviert werden
  • Behandeln einer fehlerhaften Sektorremapping in Echtzeit
• Aktivieren Sie die Erkennung von abgerissenen Seiten. (Dies wirkt sich nur wenig auf die Leistung aus.)
• Konfigurieren Sie RAID-Laufwerke, die einen Hot Swap eines fehlerhaften Laufwerks ermöglichen, sofern 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.

Testlaufwerke

Um Ihre Daten vollständig zu schützen, sollten Sie sicherstellen, dass das gesamte Zwischenspeichern von Daten ordnungsgemäß verarbeitet wird. In vielen Situationen müssen Sie die Schreibzwischenspeicherung des Laufwerks deaktivieren.

Microsoft hat tests auf mehreren SCSI- und IDE-Laufwerken mithilfe des SQLIOSim Hilfsprogramms durchgeführt. Dieses Hilfsprogramm simuliert eine hohe asynchrone Lese-/Schreibaktivität auf einem simulierten Daten- 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 der Microsoft Knowledge Base:

Verwenden des Hilfsprogramms SQLIOSim zum Simulieren 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 außer nicht protokollierten Situationen müssen SQL Server nur die Protokolldatensätze geleert werden. Bei nicht protokollierten Vorgängen müssen die Datenseiten ebenfalls in einen stabilen Speicher geleert werden. Es gibt keine einzelnen Protokolldatensätze, um die Aktionen im Falle eines Fehlers erneut zu generieren.

Die Datenseiten können im Cache verbleiben, bis sie vom LazyWriter- oder CheckPoint-Prozess in einen stabilen Speicher geleert werden. Die Verwendung des WAL-Protokolls, um sicherzustellen, dass die Protokolldatensätze ordnungsgemäß gespeichert sind, stellt sicher, dass die Wiederherstellung eine Datenseite in einem bekannten Zustand wiederherstellen kann.

Dies bedeutet nicht, dass es ratsam ist, Datendateien auf einem zwischengespeicherten Laufwerk zu platzieren. Wenn die SQL Server die Datenseiten in einen stabilen Speicher leert, können die Protokolldatensätze aus dem Transaktionsprotokoll abgeschnitten werden. Wenn die Datenseiten in einem flüchtigen Cache gespeichert sind, können Protokolldatensätze abgeschnitten werden, die bei einem Fehler zum Wiederherstellen einer Seite verwendet würden. Stellen Sie sicher, dass sowohl Ihre Daten- als auch Ihre Protokollgeräte stabilen Speicher ordnungsgemäß aufnehmen.

Leistungssteigerung

Die erste Frage, die Ihnen möglicherweise gestellt wird, lautet: "Ich habe ein IDE-Laufwerk, das zwischengespeichert wurde. Aber als ich es deaktivierte, 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 eindeutig: "Adressieren der Transaktionsrate".

Viele OLTP-Systeme (Online Transaction Processing, Onlinetransaktionsverarbeitung) erfordern eine hohe Transaktionsrate. Erwägen Sie für diese Systeme die Verwendung eines Cachecontrollers, der einen Schreibcache entsprechend unterstützt und die gewünschte Leistungssteigerung bietet und gleichzeitig die Datenintegrität sicherstellt.

Um signifikante Leistungsänderungen zu beobachten, die in SQL Server auf einem Cachelaufwerk auftreten, wurde die Transaktionsrate durch die Verwendung kleiner Transaktionen erhöht.

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

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, bei dem die gesamte Reihe von INSERT Vorgängen in eine einzelne Transaktion eingeschlossen wird, wird in allen Konfigurationen in etwa vier Sekunden ausgeführt. Dies liegt an der Anzahl der erforderlichen Protokollleerungen. 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 hat eine Größe von 512 Bytes. 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 Schreibvorgang kann verwendet werden, um die gesammelten Protokolldatensätze zu leeren. Dies reduziert den mechanischen Eingriff erheblich.

Untersuchen Sie die Anweisungen, die der Protokollleerung zugeordnet sind, um zu ermitteln, ob der Wert für geleerte Protokollbytes/Sekunde reduziert werden kann. Im vorherigen Beispiel wurde eine einzelne Transaktion verwendet. In vielen Szenarien kann dies jedoch zu unerwünschtem Sperrverhalten führen. Untersuchen Sie den Entwurf der Transaktion. Sie können Code ähnlich dem folgenden Code verwenden, um Batches auszuführen, um die häufige und kleine Aktivität zum Leeren von Protokollen 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 eine garantierte Übermittlung an stabile Medien unterstützen, wie im Downloaddokument SQL Server I/O Reliability Program Review Requirements beschrieben. Weitere Informationen zu den Eingabe- und Ausgabeanforderungen für die SQL Server-Datenbank-Engine finden Sie unter Eingabe-/Ausgabeanforderungen der Microsoft SQL Server-Datenbank-Engine.