DetailPage-MSS-KB

Knowledge Base

Artikel-ID: 230785 - Geändert am: Donnerstag, 9. Februar 2006 - Version: 5.3

 

Auf dieser Seite

Zusammenfassung

SQL Server 7.0, SQL Server 2000 und SQL Server 2005 neu strukturieren und umgestalten die Algorithmen Protokollierung und Daten aus früheren Versionen von Microsoft SQL Server zur Verbesserung der Zuverlässigkeit für Daten und Integrität.

Weitere Informationen über die zugrunde liegenden Konzepte der SQL Server 7.0 und SQL Server 2000-Module finden Sie unter "ARIES (für die Wiederherstellung und Isolation Exploiting Semantik Algorithm): eine Transaktion wiederherstellen-Methode unterstützen fein-Granularität sperren und teilweise: Rollbacks mit Write-Ahead-Logging", der ACM Transactions on Database Systems. Dieses Dokument wurde von Chunder Mohan geschrieben.

Dieses Dokument behandelt die SQL Server 7.0, SQL Server 2000 und SQL Server 2005 Techniken, die Zuverlässigkeit der Daten und Integrität in Bezug auf Fehler zu erweitern.

Es wird empfohlen, dass Sie die folgenden Artikeln in der Microsoft Knowledge Base für Weitere Erläuterungen zum Zwischenspeichern von lesen und alternative Fehler Modus Diskussionen:
86903  (http://support.microsoft.com/kb/86903/ ) Beschreibung des Zwischenspeicherns Festplattencontroller in SQL Server
46091  (http://support.microsoft.com/kb/46091/ ) Festplatte Zwischenspeichern Controller mit SQL Server
234656  (http://support.microsoft.com/kb/234656/ ) Laufwerk Zwischenspeichern mit SQL Server

Weitere Informationen

Vor der ausführlichen Erläuterung sind einige der in diesem Artikel verwendeten Begriffe in der folgende Abschnitt definiert.
Tabelle minimierenTabelle vergrößern
BegriffDefinition
Batterie-gesichert Separate und lokalisierte Batterie Sicherungsmöglichkeit direkt verfügbar und durch den Cachingmechanismus gesteuert, um den Verlust von Daten zu vermeiden.
Hinweis: Dies ist keine unterbrechungsfreie Stromversorgung (USV). Eine USV garantiert nicht, alle Aktivitäten schreiben und kann vom Zwischenspeichern Gerät getrennt werden.
Cache Zwischengeschaltete Speichermechanismus verwendet, um physische e/A-Vorgänge optimieren und Verbessern der Leistung.
Modifizierte Seiten Seite enthält die Datenänderungen, die noch in den stabilen Speicher geleert werden. Weitere Informationen, modifizierte Seite Puffer betreffen finden Sie in der Onlinedokumentation zu SQL Server-Dokumentation.
Fehler Alles, was einen unerwarteten Ausfall des SQL Server-Prozesses auftreten. Beispiele: Strom Ausfall, Computer zurücksetzen, Speicherfehler, andere Hardwareprobleme, fehlerhafte Sektoren, Laufwerk Ausfälle, Betriebssystem-Fehler und usw..
Leerung Erzwungen eines Puffers Cache Speicher stabil.
Latch Synchronisierung zum Schutz der physischen Konsistenz einer Ressource verwendete Objekt.
Nicht flüchtigen Speicher Jedes Medium, das über Systemausfälle verfügbar bleibt.
Fixierte Seite Seite, die bleibt in Daten zwischengespeichert und können nicht in den stabilen Speicher geleert werden, bis alle zugeordneten Protokolleinträge in einem stabilen Speicherort gesichert sind.
Stabilen Speicherung Identisch mit der nicht flüchtigen Speicher.
Flüchtiger Speicher Jedes Medium, das wird nicht über Fehler intakt bleiben.
SQL Server 2005, SQL Server 2000, SQL Server 7.0, frühere Versionen von SQL Server und vielen gängigen Datenbankprodukte auf dem Markt verwenden heute das Protokoll Write-Ahead-Protokoll (WAL).

Protokoll Write-Ahead-Protokoll (WAL)

Das Protokoll Begriff ist eine hervorragende Möglichkeit, WAL zu beschreiben. Es ist eine bestimmte und definierten Satz von Implementierung erforderlichen Schritte zum sicherzustellen, dass diese Daten gespeichert und ausgetauscht ordnungsgemäß und können in einem bekannten Zustand im Falle von einem Fehler wiederhergestellt werden. Wie ein Netzwerk ein definierten Protokoll so Austausch von Daten in einer konsistenten und geschützte Weise enthält zu unterstützt die WAL das Protokoll zum Schutz der Daten beschreiben.

Das ARIES-Dokument definiert WAL als:
Das WAL-Protokoll bestätigt, dass die Protokolldatensätze Änderungen für einige Daten darstellt bereits in stabilen Speicher befinden müssen, bevor geänderten Daten zulässig ist, um die vorherige Version der Daten in einem nicht flüchtigen Speicher zu ersetzen. Das System ist nicht zulässig in den nicht flüchtigen Speicher Version der Seite bis mindestens eine aktualisierte Seite schreiben die rückgängig Teile der Protokolldatensätze, die Updates auf der Seite beschreiben, haben Speicher stabil geschrieben wurde.
Weitere Informationen über Write-Ahead-Protokollierung finden Sie in der Onlinedokumentation zu SQL Server-Dokumentation.

SQLServer und der WAL

SQL Server 2005, SQL Server 2000, SQL Server 7.0 und früheren Versionen von SQL Server verwenden das WAL-Protokoll. Um richtige Committal einer Transaktion zu gewährleisten, müssen alle Protokolleinträge der Transaktion zugeordnete in stabilen Speicher gesichert werden.

Um dies zu verdeutlichen, Beispiel bestimmte (für in diesem Beispiel wird davon ausgehen, dass kein Index vorhanden ist und die betroffenen Seite ist Seite 150).
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
unterteilen die Aktivität nun in einfache Protokollierung Schritte:
Tabelle minimierenTabelle vergrößern
AnweisungAusgeführte Aktionen
ANFANG TRANSAKTION Geschrieben, aber es Bereich Cache Protokoll ist nicht erforderlich, die in den stabilen Speicher zu leeren, da der SQL Server keine physischen Änderungen vorgenommen hat.
INSERT INTO-tblTest1. Daten Seite 150 ist in SQL Server-Daten-Cache abgerufen, wenn nicht bereits verfügbar.

2. Die Seite ist aktiviert , fixiert und fehlerhaft gekennzeichnet , und entsprechende Sperren werden abgerufen.

3. Ein Datensatz einfügen Protokoll wird erstellt und den Protokollcache hinzugefügt.

4. Eine neue Zeile wird die Datenseite hinzugefügt.

5. Der Latch wird freigegeben.

6 Die Protokolldatensätze der Transaktion zugeordnet sind oder Seite muss nicht zu diesem Zeitpunkt geleert werden, da alle Änderungen im flüchtigen Speicher verbleiben.
COMMIT FÜR TRANSAKTION1. Ein Datensatz Commit-Protokoll wird gebildet, und die Protokolleinträge der Transaktion zugeordnet müssen zum Speicher stabil geschrieben werden. Die Transaktion gilt nicht übernommen, bis die Protokolldatensätze stabilen Speicher ordnungsgemäß zugewiesen sind.

2. Daten Seite 150 bleibt im SQL Server-Daten-Cache und nicht sofort in den stabilen Speicher geleert. Wenn die Protokolldatensätze ordnungsgemäß kann sichere Wiederherstellung den Vorgang ggf. wiederholen.

3. Transaktions-Sperren werden aufgehoben.
Führen Sie nicht mit verwechselt werden Sie sperren und Protokollierung. Zwar wichtig, sind Sperren und Protokollierung separate Probleme beim Umgang mit den WAL. Im obigen Beispiel enthalten SQL Server 7.0, SQL Server 2000 und SQL Server 2005 im Allgemeinen die Latch Seite 150 für die Zeit zum physischen einfügen Änderungen auf der Seite nicht die ganze Zeit der Transaktion ausführen. Der entsprechenden Sperrtyp wird eingerichtet, um die Zeile, Bereich, Seite oder Tabelle bei Bedarf zu schützen. Finden Sie in der SQL Server-Onlinedokumentation Sperren Abschnitten weitere Einzelheiten zur Sperrtypen.

Im Beispiel genauer betrachten, können Sie bitten, was geschieht, wenn die Prozesse für verzögertes Schreiben oder CheckPoint ausführen. SQL Server 7.0, SQL Server 2000 und SQL Server 2005 ausgeben, alle entsprechende Leerungen, stabile Speicher für Transaktions-Protokolldatensätze, die der Seite geändert und fixierten zugeordnet. Dadurch wird das WAL-Protokoll, das eine Datenseite nie geschrieben werden kann, stabile Speicher, bis die zugeordnete Transaktions Protokolldatensätze bereits übertragen wurden.

SQL Server und stabil Speicher

SQL Server 7.0, SQL Server 2000 und SQL Server 2005 verbessern Protokoll- und Seite-Operationen, indem z. B. das Wissen der Sektor Datenträgergrößen (häufig 512 Byte).

Um die ACID-Eigenschaften einer Transaktion zu gewährleisten, muss der SQL Server Fehlerpunkte berücksichtigt werden. Bei einem Fehler garantieren viele Laufwerkspezifikationen nur einen begrenzten Umfang von Sektor Schreibvorgänge. Die meisten Spezifikationen garantieren Abschluss der einzelnen Sektor schreiben, wenn ein Fehler auftritt.

SQL Server 7.0, SQL Server 2000 und SQL Server 2005 verwenden 8-KB-Datenseiten und das Protokoll (falls geleert), auf ein Vielfaches von die Sektorgröße. (Die meisten Festplatten verwenden 512 Bytes als die Standardgröße Sektor.) Im Fall von einem Fehler können SQL Server für Schreibvorgänge größer als ein Sektor Konto mithilfe von Protokolldateien Parität und zerrissene schreiben Techniken.

Torn Page detection

Im folgende Abschnitt stammt aus der SQL Server 7.0-Onlinedokumentation torn Page Detection beschreiben:
Diese Option ermöglicht SQL Server unvollständige Ausgabeoperationen, die durch Stromausfälle oder andere Systemausfälle verursacht erkennen. Bei true bewirkt eine Bit für jeden Sektor von 512-Byte auf einer Datenbankseite von 8 Kilobyte (KB) gedreht wird, sobald die Seite geschrieben wird auf der Festplatte. Wenn ein bit im falschen Zustand Wenn die Seite später von SQL Server gelesen wird, dann die Seite wurde fehlerhaft geschrieben; eine zerrissene Seite wird erkannt. Zerrissene Seiten werden normalerweise während der Wiederherstellung entdeckt, da jede Seite, die falsch geschrieben wurde wahrscheinlich durch Wiederherstellung gelesen werden.

Obwohl SQL Server Datenbankseiten 8 KB sind, führen Datenträger Ausgabeoperationen Sektor von 512 Byte verwenden. Daher werden pro Datenbankseite 16 Sektoren geschrieben. Eine zerrissene Seite kann auftreten, wenn das System (z. B. aufgrund eines für Stromausfall) zwischen dem Zeitpunkt des Betriebssystems der erste 512-Byte-Sektor auf den Datenträger geschrieben wird, und der Beendigung der 8 KB e/A-Operation fehlschlägt. Wenn der erste Sektor einer Datenbankseite erfolgreich vor dem Fehler geschrieben ist, wird die Datenbankseite auf dem Datenträger aktualisiert, angezeigt, obwohl er nicht erfolgreich haben kann.

Mithilfe des Datenträgercaches akkuunterstützten Domänencontroller kann sicherstellen, dass Daten erfolgreich oder nicht auf den Datenträger geschrieben werden überhaupt geschrieben. Führen Sie in diesem Fall nicht Satz unterbrochener Page Detection auf True für Sie nicht benötigt wird.
Hinweis: Torn Page Detection ist standardmäßig in SQL Server 7.0 nicht aktiviert. Finden Sie unter Sp_dboption zur Erkennung auf Ihrem System zu aktivieren.

Protokoll Parität

Protokoll Paritätsprüfung ist torn Page Detection sehr ähnlich. Jeden Sektor von 512 Byte enthält Paritätsbits. Diese Paritätsbits sind immer mit der Protokolldatensatz geschrieben wurde und ausgewertet, wenn der Protokolldatensatz abgerufen wird. Durch Erzwingen von Protokolldateien schreibt eine 512-Byte-Grenze, SQL Server 7.0, SQL Server 2000 und SQL Server 2005 gewährleisten können, dass Committal Operationen vollständig in den physischen Sektoren geschrieben werden.

Die Änderungen bieten höhere Datenkonsistenz, sogar über frühere Versionen von SQL Server.

SQL Server-Versionen als 7.0

SQL Server-Versionen hat Protokoll Parität oder zerrissene Bit Erkennung Einrichtungen nicht als 7.0 bereitgestellt. In der Tat können diese Versionen die gleichen Seite Protokoll mehrere Male schreiben bis die Protokolldatensätze Protokoll 2 KB-Seite ausfüllen. Dadurch kann Transaktionen verfügbar gemacht, die ein Commit erfolgreich ausgeführt haben. Wenn die Seite Protokoll während eines Fehlers umgeschrieben werden ist, ein Sektor mit zugesicherten Transaktion möglicherweise nicht ordnungsgemäß umgeschrieben erhalten.

Leistung Auswirkungen

Alle Versionen von SQL Server öffnen Sie die Protokoll- und Dateien, die mithilfe der Win32- CreateFile -Funktion. Das DwFlagsAndAttributes -Element enthält die Option FILE_FLAG_WRITE_THROUGH beim Öffnen von SQL Server.
FILE_FLAG_WRITE_THROUGH
Weist das System über Zwischencache schreiben und direkt zum Datenträger wechseln. Das System kann weiterhin Schreiboperationen Zwischenspeichern aber leeren kann nicht verzögert werden.

Die Option "FILE_FLAG_WRITE_THROUGH wird sichergestellt, dass wenn ein Schreibvorgang Vorgang gibt erfolgreicher Abschluss, den die Daten ordnungsgemäß in den stabilen Speicher gespeichert werden. Dies richtet mit dem WAL-Protokoll die Daten sichergestellt.
Viele Laufwerke (SCSI und IDE) enthalten integrierte Caches 512 KB, 1 MB oder größer. Jedoch benötigen die Laufwerk-Caches in der Regel einen Kondensator und keine Lösung akkuunterstützten. Diese Mechanismen zwischenspeichern können nicht garantieren Schreibvorgänge über eine Potenz Zyklus oder ähnliche Fehler zeigen. Sie garantiert nur den Abschluss der Sektor-Schreibvorgänge. Dies ist insbesondere warum die zerrissene schreiben und Protokoll Parität Erkennungstechnologie in SQL Server 7.0, SQL Server 2000 und SQL Server 2005 erstellt wurden. Die Laufwerke weiterhin in Größe anwachsen, die Caches größer werden und Sie können größere Mengen von Daten während eines Fehlers verfügbar machen.

Viele Hardwarehersteller bieten akkuunterstützten Datenträger Controller Lösungen. Diese Domänencontroller-Caches können Daten im Cache für mehrere Tage verwalten und sogar ermöglichen die Zwischenspeicherung Hardware in einem zweiten Computer platziert werden. Wenn Power ordnungsgemäß wiederhergestellt wird, werden unwritten Daten vollständig geleert, bevor weitere Datenzugriff zulässig ist. Viele ermöglichen einen Prozentsatz der Lese-und Schreibcache für eine optimale Leistung hergestellt werden. Enthalten einige große Speicherbereiche Speicher. Tatsächlich bieten einige Hardwarehersteller für ein sehr spezifische Segment des Markts High-End-akkuunterstützten Datenträger Zwischenspeichern Controller Systemen mit 6 GB Cache. Diese können die Leistung erheblich verbessern.

Erweiterte Zwischenspeicherung Implementierungen wird Handle FILE_FLAG_WRITE_THROUGH anfordern, indem den Cache-Controller nicht deaktivieren, da Sie True bieten können Funktionen im Falle eines ein System zurücksetzen, bei einem Stromausfall oder anderen Fehlerpunkt schreiben.

E/A-Übertragungen ohne Verwendung von einem Cache können erheblich länger aufgrund, mechanische verschieben die Köpfe Laufwerk, Drehfeld Wechselkurse und andere einschränkenden Faktoren benötigte Zeit sein.

Sektor bestellen

Ein verbreitetes Verfahren verwendet, um die Serverleistung zu erhöhen ist Sektor bestellen. Damit mechanische Head Bewegung werden die Lese-Schreib-Anforderungen ermöglicht eine konsistentere Bewegung der Kopf zum Abrufen oder Speichern von Daten sortiert.

Der Cache kann mehrere Protokolldateien enthalten, und Daten schreiben Anforderungen zur gleichen Zeit. Das WAL-Protokoll und die SQL Server-Implementierung des WAL-Protokolls erfordern leeren des Protokolls schreibt in Speicher stabil, bevor der Schreibvorgang Seite ausgegeben werden kann. Allerdings kann Verwendung des Caches zurück Erfolg aus eine Schreibanforderung Protokoll ohne die Daten in das aktuelle Laufwerk (, an den Speicher stabile geschrieben wird,) geschrieben werden. Dies kann zu SQL Server Ausstellen der Seitenanforderung schreiben Daten führen.

Mit Beteiligung Cache schreiben gilt die Daten immer noch im flüchtigen Speicher sein. Allerdings Aufruf der Win32-API WriteFile wurde genau wie SQL Server die Aktivität sieht ein erfolgreicher Rückgabecode abgerufen. SQL Server oder jeder Prozess, mit der WriteFile -API Aufruf kann nur hergeleitet werden die Daten ordnungsgemäß stabilen Speicher abgerufen wurde.

Für Erläuterung wird davon gegangen Sie aus, dass alle Sektoren der Datenseite sortiert werden, bevor die Sektoren der entsprechenden Protokolldatensätze zu schreiben. Dies verstößt gegen sofort das WAL-Protokoll. Der Cache ist eine Datenseite, bevor Sie die Protokolleinträge schreiben. Wenn der Cache Akku vollständig gesichert ist, kann ein Fehler katastrophalen Ergebnissen führen.

Beim Auswerten der Faktoren eine optimale Leistung für einen Datenbankserver sind viele Faktoren zu berücksichtigen. Diese Aspekte zumeist ist "meinem System zulassen gültige FILE_FLAG_WRITE_THROUGH Funktionen?"

Hinweis: Einen beliebigen Cache muss vollständig Verwendung unterstützen eine akkuunterstützten Lösung. Alle anderen Cachemechanismus sind fehlerverdächtig Datenbeschädigung und Datenverlust. SQL Server stellt alle Mühe damit die WAL, indem FILE_FLAG_WRITE_THROUGH.

Tests haben gezeigt, dass viele Laufwerkkonfigurationen Schreibcache ohne ordnungsgemäße Batteriesicherung enthalten können. SCSI und IDE, EIDE-Laufwerke nutzen schreiben Caches.

In vielen Konfigurationen ist die einzige Möglichkeit um ordnungsgemäß zu deaktivieren, den Schreibcache ein IDE- oder EIDE-Laufwerk mit einem bestimmten Hersteller oder indem Sie Jumper auf dem Laufwerk selbst befindet. Um sicherzustellen, dass der Schreibcache für das Laufwerk deaktiviert ist, Hersteller des Laufwerks.

SCSI-Laufwerke auch Schreibzugriff Caches haben, aber diese Caches können häufig durch das Betriebssystem deaktiviert werden. Wenn Sie eine Frage, Hersteller Laufwerk entsprechenden Dienstprogramme.

Stapeln von Cache zu schreiben

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

Ein Datenträger schreiben Vorgang beginnt, die Host-Daten auf der Festplatte speichern. Host schreiben Befehle weiterhin akzeptiert werden und Daten übertragen an den Puffer, bis der Schreibzugriff Befehl Stapel voll ist oder Datenpuffer voll ist. Das Laufwerk möglicherweise Schreibzugriff Befehle zum Laufwerk Durchsatz zu optimieren neu anordnen.

Schreiben automatische Neuzuordnung (AWR)

Andere allgemeine Verfahren verwendet, um Daten zu schützen ist fehlerhafte Sektoren während Datenbearbeitung zu erkennen. Die folgende Erklärung stammen aus derselben führende IDE-Laufwerk Hersteller-Website:
Dieses Feature ist Teil der Schreibcache und verringert das Risiko von Datenverlusten während verzögerten Schreibvorgängen. Wenn ein Datenträgerfehler während Datenträger Write-Prozess auftritt, wird der Datenträger Aufgabe beendet und der verdächtige Sektor in einen Pool von alternativen Sektoren am Ende des Laufwerks neu reserviert. Nach der Neuzuordnung wird die Festplatte schreiben Aufgabe fortgesetzt, bis er abgeschlossen ist.
Dies kann ein sehr leistungsstarkes Feature sein, wenn Batteriesicherung ermöglicht ordnungsgemäßen Änderung nach dem Neustart für den Cache bereitgestellt wird. Ist es vorzuziehen, Datenträgerfehler erkennen, doch die Datensicherheit des Protokolls WAL müsste erneut dazu Echtzeit erfolgen und nicht in eine verzögerte Weise. Innerhalb der WAL-Parameter kann nicht die AWR-Technik Konto für eine Situation ein Schreibvorgang Protokoll aufgrund ein Sektorfehler fehlschlägt wobei das Laufwerk ist voll. Das Datenbankmodul muss sofort über den Fehler kennen, damit die Transaktion ordnungsgemäß, abgebrochen werden kann der Administrator kann gewarnt werden, und erforderlichen Schritte zum Sichern der Daten und korrigieren Sie die Medien Fehler Situation.

Datensicherheit

Es gibt verschiedene Vorsichtsmaßnahmen, die ein Datenbankadministrator ergreifen sollten, um die Sicherheit der Daten sicherzustellen.
  • Es ist immer ratsam, sicherzustellen, dass Ihre Sicherungsstrategie ausreichend, um einen schwerwiegenden Fehler wiederherstellen. Externe Speicherung und andere Vorsichtsmaßnahmen sind geeignet.
  • Testen Sie den Vorgang der Datenbankwiederherstellung in eine sekundäre oder Testdatenbank Grundlage häufig.
  • Stellen Sie sicher, dass keine Zwischenspeicherung Geräte, alle Fehler Situationen (Stromausfall, fehlerhafte Sektoren, fehlerhaften Laufwerke, System Ausfall, Systemblockierungen, Power-Sammlung und usw. behandeln können).
  • Sicherstellen Sie, dass Ihr Gerät Zwischenspeichern:
    • Batteriesicherung verfügt integriert werden.
    • Neuausstellung können Stromversorgung schreibt einrichten.
    • Kann vollständig ggf. deaktiviert werden.
    • Fehlerhaften Sektor Echtzeit re-mapping behandelt.
  • Aktivieren von torn Page Detection, er hat nur wenig Leistungseinbußen.
  • Konfigurieren Sie möglichst für ein hot Swap einem fehlerhaften Laufwerk, sodass RAID-Laufwerke.
  • Verwenden Sie neuere Zwischenspeichern Domänencontroller, die Hinzufügung von mehr Speicherplatz zu, ermöglichen ohne Neustart des BETRIEBSSYSTEMS. Dies kann eine ideale Lösung sein.

Testen von Laufwerken

Um Ihre Daten zu sichern, sollten Sie sicherstellen, dass alle Daten zwischenspeichern ordnungsgemäß verarbeitet werden. In vielen Fällen bedeutet dies, müssen Sie deaktivieren den Schreibcache des Laufwerks.

Hinweis: Stellen Sie sicher, dass eine alternative Zwischenspeicherungsmechanismus mehrere Typen von Fehler ordnungsgemäß verarbeiten kann.

Microsoft hat auf mehrere SCSI- und IDE-Laufwerken mit dem Dienstprogramm SQLIOStress Tests durchgeführt. Dieses Dienstprogramm wird stark asynchronen Lese-/Schreibzugriff Aktivitäten einer simulierten Daten Gerät und Protokollmedium simuliert. Test-Leistungsstatistik zeigt die durchschnittliche Schreibvorgänge pro Sekunde zwischen 50 und 70 für ein Laufwerk mit Schreibcache deaktiviert und ein RPM Bereich zwischen 5,200 und 7200.

Weitere Informationen und Details über das Dienstprogramm SQLIOStress finden Sie unter den folgenden Artikel der Microsoft Knowledge Base:
231619  (http://support.microsoft.com/kb/231619/ ) Wie Sie das Dienstprogramm SQLIOStress, um ein Datenträgersubsystem wie z. B. SQL Server zu belasten
Viele PC-Hersteller (z. B. Compaq, Dell, Gateway, HP und usw.) Reihenfolge der Laufwerke mit der Write-Cache deaktiviert. Testen jedoch Tests zeigt, dass dies immer der Fall sollte daher immer möglicherweise nicht vollständig.

Daten-Geräte

In alle jedoch nicht protokolliert Situationen benötigt SQL Server die Protokolldatensätze geleert werden. Beim Ausführen nicht protokollierter Operationen die Datenseiten müssen auch geleert werden in den stabilen Speicher; es gibt keine einzelne Protokolldatensätze, die Aktionen, wenn ein Fehler neu zu generieren.

Die Datenseiten verbleiben im Cache, bis der Prozess für verzögertes Schreiben oder CheckPoint in den stabilen Speicher geleert. Die Verwendung von WAL-Protokoll um sicherzustellen, dass die Protokolldatensätze ordnungsgemäß gespeichert werden stellt sicher, dass die Wiederherstellung eine Datenzugriffsseite in einem bekannten Zustand wiederherstellen kann.

Dies bedeutet nicht, dass es ratsam, von Datendateien auf eine zwischengespeicherte Laufwerk zu speichern ist. Wenn der SQL Server die Daten Seite(n) zu Speicher stabile geleert, können die Protokolldatensätze aus dem Transaktionsprotokoll abgeschnitten werden. Die Datenseiten auf flüchtige Cache gespeichert sind, ist möglich, Abschneiden Protokolldatensätze, die zum Wiederherstellen einer Seite ein Fehler verwendet werden. Stellen Sie sicher, dass sowohl die Daten- und Protokolldateien Geräte stabilen Speicher ordnungsgemäß aufzunehmen.

Erhöhen der Leistung

Die erste Frage, die entsteht, ist: "Ich habe ein IDE-Laufwerk, die Zwischenspeicherung wurde, aber wenn ich es deaktiviert, Meine Leistung war erheblich kleiner als erwartet – warum?"

Viele der von Microsoft getesteten IDE-Laufwerken führen Sie eine Rate RPM 5,200, und der SCSI-Laufwerke an ein von 7200 Umdrehungen/min. Wenn Sie den Schreibschutz deaktivieren kann sich das Zwischenspeichern von IDE-Laufwerk die mechanische Leistung auf den Faktor werden.

Es ist ein sehr klarer Bereich um den Leistungsunterschied zu beheben: "Adressieren der Transaktionsrate."

Es gibt viele Systeme online Transaction processing (OLTP), die eine hohe Transaktionsrate erfordern. Diese Systeme sollten Sie verwenden einen Cache-Controller, der ordnungsgemäß unterstützen einen Schreibcache und bieten die Leistungssteigerung beim Sicherstellen der Datenintegrität kann.

Leistung Änderungen mit SQL Server auf einem Laufwerk Zwischenspeichern erheblich zu begegnen, wurde die Transaktionsrate mit kleine Transaktionen erhöht.

Tests haben gezeigt, dass hohe Schreibaktivität der Puffer weniger als 512 KB oder mehr als 2 MB Leistungseinbußen verursachen kann.
Im folgenden 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')
				
die folgenden Beispieltestergebnisse für SQL Server sind:
SCSI(7200 RPM) 84 Sekunden
SCSI(7200 RPM) 15 Sekunden (Zwischenspeichern Controller)

IDE(5200 RPM) 14 Sekunden (Drive Cache aktiviert)
IDE(5200 RPM) 160 Sekunden
Die gesamte Serie INSERT-Operationen in einer einzigen Transaktion wrappen führt in ungefähr 4 Sekunden in allen Konfigurationen.

Der Grund ist die Anzahl der Protokolldateien Leerungen erforderlich. Ohne die Transaktion jedes INSERT ist eine Transaktion in und von sich selbst, und jedes Mal, wenn die Protokolleinträge für die Buchung müssen geleert werden. Jeder Löschvorgang ist 512 Byte Größe, die bedeutende mechanische Laufwerk Eingriff erforderlich ist.

Wenn eine einzelne Transaktion verwendet wird, können die Protokolleinträge für die Transaktion gebündelt werden, und ein einzelner, größerer Schreibvorgang kann so leeren Sie die erfassten Protokolleinträge verwendet werden. Mechanische Eingriff wird erheblich verringert.

Warnung Es wird nicht empfohlen, dass Sie Ihre Transaktionsbereich erhöhen. Langlebige Transaktionen können zu übermäßigen und unerwünschte blockiert führen sowie Verwaltungsaufwand erhöht. Verwenden Sie die SQL Server 7.0, SQL Server 2000 und SQL Server 2005-Leistungsindikatoren SQL Server: Datenbanken , um die Transaktion Protokollbasierter Leistungsindikatoren anzuzeigen. Insbesondere können Protokoll Flushed pro Sekunde vielen kleine Transaktionen führt zu hoher Datenträgeraktivität mechanische angeben.

Sehen Sie sich mit dem Protokoll leeren verknüpften Anweisungen, und bestimmen Sie, wenn die Anzahl der Leerungen Protokoll reduziert werden kann. Im obigen Beispiel wurde eine einzelne Transaktion implementiert. Jedoch kann dies zu unerwünschten Sperrverhalten in vielen Szenarios führen. Betrachten Sie den Entwurf der Transaktion. Vielleicht etwas wie folgende Batches verringern sich häufig und kleinen auszuführenden Aktivität flush:
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 6. X sehen möglicherweise nicht die gleichen Leistungsbeeinträchtigung von häufigen und kleine Transaktionsprotokoll schreibt. SQL Server 6. X schreibt die gleichen Seite 2-KB-Protokolls Transaktionen ein Commit ausgeführt werden. Dies kann die Größe des Protokolls beträchtlich im Vergleich zu den Sektor von 512 Byte Grenze Leerungen in SQL Server 7.0, SQL Server 2000 und SQL Server 2005 reduzieren. Reduzieren der Größe des Protokolls direkt bezieht sich auf die Datenmenge mechanische Laufwerk Aktivität. Allerdings als beschrieben über die SQL Server 6. X Algorithmus kann Transaktionen verfügbar machen.
SQL Server erfordert Systeme unterstützen ‘ garantierte Übermittlung mit stabilen Medium ’ wie beschrieben unter das Programm Microsoft SQL Server Always-On Storage Solution überprüfen. FOWeitere Informationen zu den Eingabe- und Anforderungen für die SQL Server Datenbank-Engine finden Sie im folgenden Artikel der Microsoft Knowledge Base:
967576  (http://support.microsoft.com/kb/967576/ ) Microsoft SQL Server Engine E/A-Anforderungen

Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Keywords: 
kbmt kbhowto kbinfo KB230785 KbMtde
Maschinell übersetzter ArtikelMaschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 230785  (http://support.microsoft.com/kb/230785/en-us/ )
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.
Freigeben
Weitere Supportoptionen
Microsoft Community-Supportforen
Kontaktieren Sie uns direkt
Zertifizierten Partner finden
Microsoft Store
Folgen Sie uns: