Beschreibung der Protokoll- und Data Storage Algorithmen, die Zuverlässigkeit der Daten in SQL Server erweitern

Zusammenfassung

Dieser Artikel beschreibt, wie Microsoft SQL Server-Protokollierung und Daten Algorithmen Zuverlässigkeit und Integrität erweitern.

Erfahren Sie mehr über die zugrunde liegenden Konzepte der Motoren und WIDDER (Algorithmus für Recovery und Isolation ausnutzen Semantik) finden Sie auf folgenden ACM Transaktionen Datenbanksysteme Dokument ("Volume 17, Nummer 1, März 1992):

Leitender Verfasser dieses Dokuments ist C. Mohan. Das Dokument behandelt SQL Server Techniken Zuverlässigkeit und Integrität in Bezug auf Fehler.

Es wird empfohlen, Sie folgenden Artikel der Microsoft Knowledge Base weitere Informationen zum Zwischenspeichern lesen und andere Fehler-Modus:
86903 Beschreibung der Schreibcache-Controller in SQL Server
234656 Informationen über Laufwerk Caches mit SQL Server, die jeder Datenbankadministrator kennen sollte

Weitere Informationen

Vor dem Beginn der ausführliche werden in diesem Artikel verwendeten Begriffen in der folgenden Tabelle definiert.

BegriffDefinition
Batterie-BackupSeparate und lokalisierte Akku Sicherungsmechanismen direkt verfügbar und kontrolliert den Zwischenspeicherungsmechanismus um Datenverluste zu vermeiden.

Hinweis Dies ist keine unterbrechungsfreie Stromversorgung (USV). Eine USV garantiert keine Aktivitäten schreiben und kann vom Zwischenspeichern Gerät getrennt werden.
CacheZwischengeschaltete Speichermechanismus zum physischen e/a-Vorgänge optimieren und verbessern.
Modifizierte SeitenSeite mit Änderungen, die noch in den stabilen Speicher geschrieben. Weitere Informationen über modifizierte Seite Puffer finden Sie "Schreiben von Webseiten" in SQL Server-Onlinedokumentation.
Hinweis Der Inhalt gilt auch für Microsoft SQL Server 2012 und höher.
FehlerAlles, was einen unerwarteten Ausfall des SQL Server-Prozesses führen. Beispiele: Strom Ausfall Computer zurücksetzen, Speicherfehler, andere Hardwareprobleme, fehlerhafte Sektoren, Laufwerk Ausfälle, Systemausfälle, und.
LeerenDer Cache-Puffer erzwingen stabilen.
VerriegelungSynchronisierungsobjekt zu physischen Konsistenz einer Ressource verwendet.
Nicht flüchtigen SpeicherJedes Medium Systemausfällen verfügbar bleibt.
Fixierte SeiteSeite, die Daten zwischenspeichern und nicht in den stabilen Speicher geleert werden, bis alle zugeordneten Datensätze in einem stabilen Speicherort gesichert sind.
SpeicherortWie nicht flüchtigen Speicher.
Flüchtiger SpeicherJedes Medium nicht bei Ausfällen erhalten bleiben.

Protokoll Write-Ahead-Logging (WAL)

Begriff-Protokoll ist eine hervorragende Möglichkeit, WAL beschreiben. Ist ein bestimmtes und definierte erforderlichen Implementierungsschritte zum sicherstellen, dass diese Daten gespeichert und korrekt ausgetauscht und in einen bekannten Zustand bei einem Ausfall wiederhergestellt werden können. Nur ein Netzwerk definiertes Protokoll eine konsistente geschützt und so Datenaustausch enthält auch beschreibt die WAL das Protokoll um Daten zu schützen.

Das WIDDER-Dokument definiert die WAL wie folgt:
WAL-Protokoll versichert, dass Protokolleinträge Änderungen für Daten darstellt bereits im Speicherort sein müssen, bevor die geänderten Daten die vorherige Version der Daten im nicht flüchtigen Speicher ersetzen. D. h. das System darf nicht flüchtigen Speicher Version der Seite mindestens eine aktualisierte Seite schreibe rückgängig Teil der Protokolldatensätze, die Updates auf der Seite beschreiben stabilen geschrieben wurden.
Weitere Informationen zu Write-ahead-Logging finden Sie Write-Ahead Transaktionsprotokoll in SQL Server-Onlinedokumentation.

SQL Server und der WAL

SQL Server verwendet das Protokoll WAL. Um sicherzustellen, dass eine Transaktion ordnungsgemäß ausgeführt wird, müssen alle Datensätze, die der Buchung zugeordnete Speicherort gesichert werden.

Um dies zu verdeutlichen, Beispiel bestimmte.

Hinweis Beispielsweise Angenommen Sie, dass kein Index und die betroffene Seite 150 befindet.
BEGIN TRANSACTION   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
Dann unterteilen Sie die Aktivität in vereinfachte Anmeldung Schritte wie in der folgenden Tabelle beschrieben.
AnweisungAktionen
BEGIN TRANSACTIONIn den Protokollbereich Cache geschrieben. Es muss jedoch nicht auf Speicherort zu speichern, da SQL Server keine physische geändert hat.
INSERT INTO "tblTest"
  1. Seite 150 Daten werden in SQL Server Datencache ggf. nicht bereits abgerufen.
  2. Die Seite verriegelt, fixiertund fehlerhaft gekennzeichnetund entsprechende Sperren abgerufen werden.
  3. Ein Datensatz einfügen erstellt und den Protokollcache hinzugefügt.
  4. Die Seite wird eine neue Zeile hinzugefügt.
  5. Die Verriegelung wird freigegeben.
  6. Die Protokolleinträge, die der Transaktion zugeordnet oder Seite muss nicht zu diesem Zeitpunkt geleert werden, da alle Änderungen im flüchtigen Speicher bleiben.
COMMIT FÜR TRANSAKTION
  1. Commit Protokolldatensatz gebildet und die der Transaktion zugeordnete Datensätze müssen stabilen geschrieben werden. Die Transaktion gilt nicht bis die Protokolleinträge stabilen Speicher ordnungsgemäß zugewiesen sind.
  2. Datenseite 150 verbleibt im Datencache von SQL Server und nicht direkt in den stabilen Speicher geleert. Wenn Protokolleinträge ordnungsgemäß gesichert sind, kann Recovery ggf. den Vorgang wiederholen.
  3. Transaktionale Sperren werden aufgehoben.
Führen Sie nicht die Begriffe "Sperren" und "Protokollierung" verwechselt werden Wichtig, sind sperren und Protokollierung separate Probleme behandeln die WAL. Im vorherigen Beispiel enthält SQL Server in der Regel die Verriegelung auf 150 Mal physischen einfügen ändert nicht die ganze Zeit der Transaktion auf der Seite ausgeführt. Der entsprechenden Sperrtyp wird zu der Zeile, Bereich, Seite oder Tabelle bei Bedarf eingerichtet. Finden Sie in der SQL Server-Onlinedokumentation Sperren Abschnitte für weitere Einzelheiten zu sperren.

Betrachten das Beispiel, Fragen Sie was passiert, wenn verzögertes oder CheckPoint-Prozesse ausgeführt. SQL Server stellt alle entsprechende Leerungen um stabilen für Transaktions-Datensätze, die geändert und fixierte Seite zugeordnet sind. Dies stellt sicher, dass die Datenseite WAL Protokoll stabilen bis zugeordnete Transaktions Protokolldatensätze geleert wurde nie geschrieben werden kann.

SQL Server und stabilen Speicher

SQL Server optimiert Protokoll- und Seite Vorgänge durch einschließlich Kenntnisse Sektor Datenträgergrößen (häufig 4.096 oder 512 Bytes).

Um die ACID-Eigenschaften der Transaktion zu gewährleisten, müssen die SQL Server-Fehlerpunkte berücksichtigen. Bei einem Ausfall garantieren viele Laufwerk-Spezifikationen nur begrenzte Sektor schreiben. Die meisten Spezifikationen garantieren Abschluss eines Schreibvorgangs Sektor ein Fehler auftritt.


SQL Server verwendet 8-KB-Seiten und das Protokoll (sofern geleert) auf ein Vielfaches der Sektorgröße. (Die meisten Festplatten verwenden 512 Byte als Standard Sektorgröße.) Bei einem Ausfall kann SQL Server für Schreibvorgänge größer als ein Sektor Konto Protokoll Parität und zerrissene schreiben Techniken.

Zerrissene Seite Erkennung

Diese Option ermöglicht SQL Server unvollständige e/a-Vorgänge durch Stromausfälle oder Systemausfälle verursacht erkennen. Wenn true, wird ein Bit für jeden Sektor von 512 Byte auf einer Datenbankseite von 8 Kilobyte (KB) gekippt werden soll, wenn die Seite auf den Datenträger. Wenn ein bit im falschen Zustand Wenn die Seite später von SQL Server gelesen wird, wurde die Seite fehlerhaft geschrieben; eine zerrissene Seite wird erkannt. Zerrissene Seiten werden normalerweise während der Wiederherstellung entdeckt, da jede Seite, die fehlerhaft ist wahrscheinlich Wiederherstellen gelesen.


Obwohl SQL Server Datenbankseiten 8 KB sind, durchführen Datenträger e/a-Operationen mit 512-Byte-Sektor Daher werden pro Datenbankseite 16 Sektoren geschrieben. Eine zerrissene Seite möglich, wenn das System (z. B. durch einen Stromausfall) nicht zwischen dem der erste 512-Byte-Sektor auf der Festplatte geschrieben und Abschluss der Vorgang 8 KB. Wenn der erste Sektor einer Datenbankseite erfolgreich vor dem Fehler geschrieben, erscheint Datenbankseite auf der Festplatte aktualisiert, obwohl es nicht gelungen, kann.

Batterie-Controller Datenträgercaches verwenden, Sie können sicherstellen, dass Daten auf den Datenträger oder nicht erfolgreich geschrieben werden überhaupt geschrieben. Stellen Sie in diesem Fall nicht zerrissene Seite Erkennung auf "True" ist dies nicht erforderlich.

Hinweis Zerrissene Seite Erkennung ist in SQL Server standardmäßig nicht aktiviert. Weitere Informationen finden Sie auf der folgenden MSDN-Website:

Protokoll Parität

Protokoll Parität Überprüfung ähnelt zerrissene Seite Erkennung. Jeder Sektor von 512 Byte enthält Paritätsbits. Diese Paritätsbits sind immer mit der Protokolldatensatz geschrieben und ausgewertet, wenn der Datensatz abgerufen wird. Indem Schreibvorgängen auf 512-Byte-Grenze, kann SQL Server sicherstellen, dass Aktionsstatus Operationen vollständig in den physischen Sektoren geschrieben werden.

SQL Server-Versionen vor 7.0

SQL Server-Versionen als 7.0 Protokoll Parität oder zerrissene Bit Erkennung Räume übermittelte. Tatsächlich können diese Versionen die gleichen protokollseite mehrmals schreiben bis die Protokolldatensätze Seite 2 KB Protokoll füllen. Dadurch kann Transaktionen verfügbar machen, die erfolgreich übertragen wurden. Wenn die protokollseite bei einem Fehler erneut geschrieben wird, mit festgeschriebenen Transaktionen möglicherweise nicht korrekt umgeschrieben erhalten.

Performance-Einbußen

Alle Versionen von SQL Server öffnen die Protokoll- und Datendateien mithilfe der Win32- CreateFile -Funktion. Der DwFlagsAndAttributes -Member enthält die Option FILE_FLAG_WRITE_THROUGH beim Öffnen durch SQL Server.
FILE_FLAG_WRITE_THROUGH
Weist das System durch jeden Zwischencache schreiben und direkt zum Datenträger wechseln. Das System kann weiterhin Schreiboperationen zwischenspeichern aber löschen nicht verzögert werden.


Die Option FILE_FLAG_WRITE_THROUGH stellt sicher, dass ein Schreibvorgang gibt einen erfolgreichen Abschluss die Daten korrekt in Speicherort gespeichert werden. Dies richtet mit WAL-Protokoll, das die Daten.
Viele Laufwerke (SCSI- und IDE) enthalten integrierte Caches 512 KB, 1 MB oder mehr. Laufwerk-Cache jedoch verlassen normalerweise auf Kondensators und keine Batterie-Backup-Lösung. Diese Zwischenspeicherungsmechanismen können nicht garantieren, schreibt in eine Potenz aus- oder ähnliche Fehler zeigen. Sie garantiert nur den Abschluss der Sektor schreiben. Dies ist insbesondere Warum zerrissene schreiben und Protokoll Parität Erkennung in SQL Server 7.0 oder höher erstellt wurden. Wenn Laufwerke Größe wachsen, Caches größer, und sie können größere Datenmengen bei einem Ausfall machen.

Viele Hardwarehersteller Lösungen batteriegepuffertem Disk Controller. Dieser Controller-Caches können Daten im Cache für mehrere Tage verwalten und sogar Zwischenspeichern Hardware auf einem zweiten Computer platziert werden. Wenn richtig wiederhergestellt wird, werden geleerten Daten erst weitere Datenzugriff vollständig geleert. Viele zulassen Prozentsatz der Lese-und Schreib-Cache für eine optimale Leistung hergestellt werden Enthalten einige große Speicherbereiche Speicher. Tatsächlich bieten einige Hardwarehersteller für einen ganz bestimmten Marktsegment, High-End batteriegepuffertem Disk Controller Systeme mit 6 GB Cache Zwischenspeichern. Diese können die Leistung der Datenbank erheblich verbessern.

Erweiterte Zwischenspeichern Implementierung wird Handle FILE_FLAG_WRITE_THROUGH anfordern Cache des Controllers nicht deaktivieren, da sie True ermöglicht Funktionen setzt das System zurück, Stromausfall oder anderen Fehlerpunkt schreiben.


E/a-Übertragung ohne einen Cache können durch mechanische Zeit wesentlich länger sein, die zum Verschieben der Laufwerksköpfe Spin-Raten und andere einschränkenden Faktoren erforderlich.

Bereich Reihenfolge

Eine gängige Technik zur e/a-Leistung zu erhöhen ist bestellen. Zur Vermeidung von mechanischen Bewegung werden Anfragen Lese-/Schreibzugriff ermöglichen eine konsistente Bewegung des Kopfes abrufen oder Speichern von Daten sortiert.


Der Cache kann mehrere Protokolldateien und Daten schreiben Anfragen gleichzeitig. WAL-Protokoll und die SQL Server-Implementierung des Protokolls WAL erfordern das Protokoll geleert schreibt stabilen vor Schreibzugriff Seite ausgegeben werden kann. Allerdings kann Verwendung des Caches zurück Erfolg aus einer Protokolldatei schreibanforderung ohne die Daten auf dem Laufwerk (die stabilen geschrieben ist) geschrieben. Dies kann SQL Server die Daten Seite schreiben Anforderung.


Beteiligung Cache schreiben die Daten immer noch gilt im flüchtigen Speicher. Allerdings Aufruf der Win32-API WriteFile wurde wie SQL Server die Aktivität sieht ein erfolgreicher Rückgabecode abgerufen. SQL Server oder jeder Prozess, der WriteFile -API-Aufruf verwendet kann nur feststellen, dass die Daten ordnungsgemäß Speicherort abgerufen hat.

Für die Erläuterung wird davon ausgegangen Sie, dass alle Sektoren der Datenseite schreiben vor Bereich die übereinstimmenden Datensätze sortiert werden. Dies verletzt sofort WAL-Protokoll. Cache ist eine Datenseite vor Protokolldatensätze schreiben. Wenn der Cache Batterie-Backup, kann ein Fehler katastrophale Folgen.


Beim Auswerten der optimalen Faktoren für einen Datenbankserver sind viele Faktoren zu berücksichtigen. Die wichtigste ist "Meine gültige FILE_FLAG_WRITE_THROUGH Funktionen zulässt?"

Hinweis Jede Verwendung Cache muss vollständig Batterie-Backup-Lösung unterstützen. Andere Cachemechanismus sind verdächtig, zur Beschädigung oder Verlust von Daten. SQL Server ist bemüht, die WAL FILE_FLAG_WRITE_THROUGH aktivieren.


Tests haben gezeigt, dass viele Festplattenkonfigurationen enthält Schreibcache ohne entsprechende Batterie-Backup. SCSI-, IDE- und EIDE-Laufwerke nutzen Write-Caches. Weitere Informationen zur Funktionsweise von SSDs mit SQL Server finden Sie folgende CSS SQL Server Ingenieure Blog:


In vielen Konfigurationen ist können nur ordnungsgemäß Schreibcache IDE oder EIDE-Laufwerk mit einem Hersteller-Dienstprogramm oder Jumper befindet sich auf der Festplatte. Um sicherzustellen, dass der Schreibcache für das Laufwerk deaktiviert ist, Hersteller des Laufwerks.

SCSI-Laufwerke können auch Write-Caches. Allerdings können diese Caches häufig vom Betriebssystem deaktiviert. Ist Frage, Hersteller Laufwerk entsprechenden Dienstprogramme.

Write Cache Stapeln

Schreiben Sie Cache Stapeln Sektor Sortieren ähnelt. Die folgende Definition direkt führende IDE-Laufwerk der Website eines Druckerherstellers entnommen:
Normalerweise ist dieser Modus aktiv. Schreiben Sie im Cachemodus akzeptiert der Host Daten in den Puffer schreiben, bis der Puffer voll ist oder die Host-Übertragung abgeschlossen ist.

Eine Festplatte schreiben Aufgabe beginnt zum Speichern von Daten auf der Festplatte. Host Schreibbefehle weiterhin akzeptiert und Daten in den Puffer bis Befehlsstapel Schreiben voll ist oder Datenpuffer voll ist. Das Laufwerk kann Schreibbefehle Laufwerksdurchsatz optimieren neu anordnen.

Neubelegung automatische schreiben (AWR)

Eine andere allgemeine Verfahren verwendet wird, um Daten zu schützen ist fehlerhafte Sektoren beim Bearbeiten von Daten zu erkennen. Im folgenden Beispiel stammt aus führenden IDE-Laufwerk der Website eines Druckerherstellers:
Diese Funktion ist Teil der Schreib-Cache und reduziert das Risiko von Datenverlusten während verzögerte Schreibvorgänge. Tritt ein Datenträgerfehler bei Schreibvorgang Datenträger werden auf andere Bereiche am Ende des Laufwerks Datenträger Aufgabe beendet und verdächtige Bereich zugewiesen. Nach der erneuten Reservierung fortgesetzt Datenträger schreiben Aufgabe abgeschlossen ist.
Dies ist ein sehr leistungsfähiges Feature, wenn Batterie-Backup für den Cache bereitgestellt wird. Dadurch wird die Änderung nach dem Neustart. Ist es besser, die Fehler erkannt, aber die Sicherheit des Protokolls WAL müsste erneut Echtzeit erfolgen und nicht verzögert. WAL-Parameter kann nicht AWR-Technik Konto für eine Situation in dem Protokoll schreiben ein Sektorfehler scheitert, aber das Laufwerk ist voll. Das Datenbankmodul benötigen sofort zum Fehler damit Transaktion ordnungsgemäß abgebrochen werden kann, der Administrator kann und Schritte zum Sichern der Daten und Abhilfe für Media-Fehler zu korrigieren.

Sicherheit

Es gibt mehrere Sicherheitsvorkehrungen, mit denen ein Datenbankadministrator um die Sicherheit der Daten zu gewährleisten.
  • Es ist immer eine gute Idee zu Ihrer backup-Strategie zur Wiederherstellung nach einem Systemausfall ausreicht. Lagerung und andere Vorsichtsmaßnahmen sind.
  • Testen der Wiederherstellung in eine sekundäre Datenbank oder Testdatenbank regelmäßig.
  • Stellen Sie sicher, dass alle Geräte für das Zwischenspeichern aller Fehlersituationen (Stromausfall, fehlerhafte Sektoren, fehlerhafte Laufwerke, Systemausfall, Abstürze, Power Sammlung usw.) verarbeiten können.
  • Stellen Sie sicher, dass Ihr Gerät Zwischenspeichern:
    • Batterie-Backup integriert
    • Hochfahren können erneut schreibt
    • Kann vollständig deaktiviert werden, falls erforderlich
    • Neuzuordnen von fehlerhaften Sektor in Echtzeit verarbeitet
  • Zerrissener Seiten aktivieren. (Dies hat wenig Einfluss auf die Leistung.)
  • Konfigurieren Sie RAID-Laufwerke für hot-Swap eines fehlerhaften Laufwerks, wenn möglich.
  • Verwenden Sie neuer Cache-Controller, mit denen Sie mehr Speicherplatz hinzufügen, ohne das Betriebssystem neu zu starten. Dies ist eine ideale Lösung.

Testen der Laufwerke

Um Daten abzusichern, sollten Sie sicherstellen, dass alle Daten zwischenspeichern ordnungsgemäß behandelt wird. In vielen Fällen müssen Sie den Schreibcache des Laufwerks deaktivieren.

Hinweis Stellen Sie sicher, dass Alternative Cachemechanismus mehrere Fehlertypen richtig verarbeiten kann.

Microsoft hat auf mehrere SCSI- und IDE-Laufwerken mit dem Dienstprogramm SQLIOSim Tests durchgeführt. Dieses Dienstprogramm wird stark asynchronen Lese-/Schreibaktivitäten, simulierten Gerät Protokolliergerät simuliert. Test-Leistungsstatistik zeigt die durchschnittliche Schreibvorgänge pro Sekunde zwischen 50 und 70 für ein Laufwerk mit deaktivierten Schreibcache und ein Drehzahlbereich zwischen 5.200 und 7.200.


Weitere Informationen über das Dienstprogramm SQLIOSim finden Sie im folgenden Artikel der Microsoft Knowledge Base:

231619 wie mit dem Dienstprogramm SQLIOSim auf eine SQL Server-Aktivitäten zu simulieren
Viele Computerhersteller bestellen der Laufwerke mit der Schreib-Cache deaktiviert. Tests zeigt jedoch, dass dies möglicherweise nicht immer der Fall. Daher immer testen Sie vollständig.

Daten-devices

In alle nicht protokollierten Situationen benötigt SQL Server nur die Datensätze werden gelöscht. Bei nicht protokollierter Operationen müssen die Datenseiten auch in den stabilen Speicher geleert. Es sind keine einzelnen Protokolldatensätze Aktionen bei einem Fehler neu generieren.


Die Seiten bleibt im Cache, bis der Prozess für verzögertes Schreiben oder CheckPoint stabilen Speicher geleert. Mit dem Protokoll WAL sicherstellen, dass die Datensätze korrekt gespeichert werden sorgt Recovery eine Datenseite in einen bekannten Zustand wiederherstellen kann.

Dies bedeutet nicht, dass Daten Dateien auf zwischengespeicherte Laufwerk ist. Wenn SQL Server die Seiten stabilen entleert, können Protokolleinträge aus dem Transaktionsprotokoll abgeschnitten. Die Datenseiten auf flüchtige Cache gespeichert, kann Protokolldatensätze abgeschnitten, die zum Wiederherstellen einer Seite im Fehlerfall verwendet werden. Stellen Sie sicher, dass Ihre Daten- und Protokolldateien Geräte stabil ordnungsgemäß bereitstellen.

Erhöhen der Leistung

Die erste Frage, die auftreten können: "Ich habe eine IDE-Festplatte Zwischenspeichern wurde. Aber wenn ich es deaktiviert, meine Leistung deutlich geringer als erwartet. Warum?"

Viele IDE-Laufwerke, die von Microsoft getestet ausführen 5.200 RPM und SCSI-Laufwerke mit 7.200 u/MIN. Beim Deaktivieren der Schreibcache IDE-Laufwerk kann die mechanische Leistung ein Faktor.

-Methode folgen für die Bewältigung der Leistungsunterschied ist eindeutig: "Address die Transaktionsrate."

Viele erfordern online Transaction Processing (OLTP) eine hohe Transaktionsrate. Diese Systeme verwenden einem Cache-Controller, der entsprechende Unterstützung kann Schreib-Cache und bieten Sie die gewünschten Leistungssteigerung bei gleichzeitiger Gewährleistung der Datenintegrität.

Um signifikante Performance beobachten, die in SQL Server auf einem Laufwerk Zwischenspeichern auftreten, stieg die Transaktionsrate mit kleinen Transaktionen.

Tests zeigt, die hohe Aktivität Puffer schreiben, die kleiner als 512 KB oder größer als 2 MB kann langsam.
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')

Es folgen Beispieltestergebnisse für SQL Server:

84 SCSI(7200 RPM) Sekunden
SCSI(7200 RPM) 15 Sekunden (Zwischenspeichern Controller)


IDE(5200 RPM) 14 Sekunden (Laufwerk-Cache aktiviert)
IDE(5200 RPM) 160 Sekunden

Die gesamte Reihe von INSERT-Vorgänge in einer Transaktion umgebrochenen Verwaltungsvorgangs ungefähr vier Sekunden alle Konfigurationen. Dies ist aufgrund der Anzahl von protokollleerungen erforderlich sind. Wenn Sie eine Transaktion nicht erstellen, wird jeder EINFÜGEN als separate Transaktion verarbeitet. Daher müssen alle Protokolleinträge für die Buchung gelöscht werden. Jede Bereinigung ist 512 Byte. Dies erfordert erhebliche mechanische Laufwerk eingreifen.

Bei eine Transaktion die Protokolleinträge für die Transaktion gebündelt und einzelnen, größeren Schreibvorgänge verwendet werden, um die abgerufenen Datensätze löschen. Dies reduziert die mechanische Eingriffe.

Warnung Wir empfehlen die Transaktionsbereich nicht erhöhen. Langlebige Transaktionen können übermäßige und unerwünschte blockieren und erhöhten Verwaltungsaufwand. Verwenden Sie SQL Server: Datenbanken SQL Server-Leistungsindikatoren zum Anzeigen der Leistungsindikatoren mit Transaction Log. Protokollbytes Flushed/s können insbesondere viele kleine Transaktionen an, die mechanische hohe Datenträgeraktivität verursachen können.

Überprüfen Sie die Aussagen, die in das Protokoll leeren bestimmen, ob der Protokollbytes Flushed/s -Wert reduziert werden kann. Im vorherigen Beispiel wurde eine einzelne Transaktion verwendet. In vielen Szenarios kann dies jedoch unerwünschten Sperrverhalten führen. Überprüfen Sie den Entwurf der Buchung. Ähnelt dem folgenden Code können Sie um die häufige und kleine Protokoll leeren Aktivität ausführen:
BEGIN TRANGO

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 unterstützen "Übertragung auf stabilen Medium garantiert" SQL Server i/o-Zuverlässigkeit Überprüfung Anforderungen Download beschrieben. Weitere Informationen zu den Eingabe- und Ausgabeparameter für die SQL Server-Datenbank-Engine folgendem folgenden Artikel der Microsoft Knowledge Base zu:

967576 Microsoft SQL Server-Datenbank-Engine Input/Output Vorschriften

Eigenschaften

Artikelnummer: 230785 – Letzte Überarbeitung: 08.01.2017 – Revision: 1

Feedback