Wichtige Faktoren beim Auswerten von Drittanbietern-Dateisysteme-Cache mit SQL Server

Dieser Artikel beschreibt einige der wichtigsten Faktoren für die Kunden beim Auswerten einer Fremdanbieter-Datei System Zwischenspeichern bewusst sein sollten.

Fremdanbieter-Datei Cacheimplementierungen u.u. eine Leistungsverbesserung von Microsoft SQL Server-Datenbanken Wenn ordnungsgemäß implementiert. Spezifische Implementierungen jedoch und Konfigurationen dieser Produkte können SQL Server-Datenbanken auf ein hohes Risiko von Datenverlusten lassen. Kunden sollten die richtigen Datenintegrität-Konfiguration vollständig testen.

Informationen in diesem Dokument, einschließlich URLs und andere Verweise auf unterliegt ohne vorherige Ankündigung ändern. Andernfalls sind, soweit Firmen, Organisationen, Produkte, Domänennamen, e-Mail-Adressen, Logos, Personen, Orte und Ereignisse in den Beispielen verwendeten fiktiven. Jede Ähnlichkeit mit tatsächlichen Firmen, Organisation, Produkt, Domänennamen, e-Mail-Adresse, Logo, Person, Ort oder Ereignis ist rein zufällig. Die Benutzer sind verantwortlich für das Einhalten aller anwendbaren Urheberrechtsgesetze. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation kein Teil dieses Dokuments für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies geschieht.

Es ist möglich, dass Microsoft Rechte an Patenten bzw. angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Das Bereitstellen dieses Dokuments gibt Ihnen jedoch keinen Anspruch auf diese Patente, Marken, Urheberrechte oder auf sonstiges geistiges Eigentum, es sei denn, dies wird ausdrücklich in den schriftlichen Lizenzverträgen von Microsoft eingeräumt.

© 2006 Microsoft Corporation. Alle Rechte vorbehalten.

Microsoft, Windows, Windows Server, und SQL Server sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern.

In diesem Artikel wird speziell für SQL Server geschrieben jedoch im Allgemeinen von Produkten Active Directory und Exchange Server verwendeten Jet-Datenbanken betrifft.

In diesem Abschnitt erläutert Anforderungen und bietet ausführliche Beispiele, die vollständig behandelt werden sollte ein Drittanbieter vor dem Bereitstellen einer Lösung. Kunden sollten auch ergreifen besondere Sorgfalt So testen Sie verschiedene Wiederherstellungsszenarien sicherstellen, dass die Datenintegrität ordnungsgemäß verwaltet wird.

Eingabe-/Ausgabefehler (e/A)-Anforderungen von SQL Server

Alle SQL Server-Datenbank oder Sicherung Dateien benötigt Speicher Grundlagen unterstützen des Protokolls Write-Ahead-Protokoll (WAL). Diese Grundlagen werden in den folgenden Artikeln beschrieben: Hinweis: Der Artikel gilt auch für SQL Server 2005.Nachfolgend eine Liste der einige wichtigen Anforderungen:

• Schreibreihenfolge muss verwaltet werden.
• Abhängige schreiben Konsistenz muss verwaltet werden.
• Schreibt müssen immer in oder auf stabilen Medium gesichert werden.
• Zerrissene e/A-Vorbeugung muss auftreten.

Partner Produkt Zertifizierungen sind keine Garantie der Kompatibilität oder Sicherheit

Ein Drittanbieter-Produkt oder einen bestimmten Kreditor erhalten eine Microsoft-Logo-Zertifizierung. Allerdings ist Partner-Zertifizierung oder eine bestimmte Microsoft-Logo nicht Kompatibilitäts- oder Eignung für einen bestimmten Zweck für SQL Server, Exchange Server oder Active Directory zertifizieren.

FILE_FLAG_WRITETHROUGH und FILE_FLAG_NO_BUFFERING

Microsoft-Datenbank Serverprodukte verwenden speziell die Write-through und keine Pufferung Flags beim Öffnen von Datenbankdateien um Datenverlust zu verhindern. Jede Schreibanforderung auf diese Dateien muss mit stabilen Medium gesichert werden. Andernfalls kann Datenverluste auftreten. Unten finden Sie spezifische Beispiele, die Datei System Caches verfügbar machen können:

• Kombinieren von und Schreiben Neuanordnen schreiben
  Um physische e/A-Anforderungen zu reduzieren, die Grundlage Caches nicht Batterie häufig kombinieren und neu anordnen Schreibvorgänge sofort Zerstören der WAL-Protokollanforderungen.
• Block-Größe der e/A
  Ähnlich wie das Schreiben kombinieren und Neuanordnen von sind e/A-Blockgröße. Die Caches, die versucht, e/A auf Grundlage der e/a-Pfad Blockgröße abzuschließen. Erneut, dies kann eine Leistungssteigerung aber öffnet die Datenbank beschädigen und sofort unterbricht die WAL-Protokollanforderungen.

Talking Punkte und Beispiele

Der folgende Abschnitt enthält wichtige Beispiele und Talking Punkte zur Datenintegrität und Sicherheit. Es Stromausfall als allgemeine Fehler und Klarheit verwendet, aber dies kann häufig verschiedene Probleme, die zu Integritätsproblemen ähnliche Datenbank ersetzt.

Beispiel 1: Datenverlust und physische oder logische Beschädigung

Stellen Sie sich das folgende Szenario vor:

1. Ein Protokolleintrag wird für Seite 100 in der Datenbank geschrieben.
2. Ein Protokolleintrag wird im Cache nicht auf Batterie basierende gehalten, aber das Datenbankmodul wird angewiesen die Protokolldatei abgeschlossen "gesicherte zu Medien stabile" ist.
3. Das Datenbankmodul betrachtet die LSN abgesichert und Probleme mit Schreibzugriff für die Seite 100.
4. Seite 100 wird auch im nicht Batterie basierten Cache gehalten.
5. Commit Transaktion ohne Fehler abgeschlossen ist.

Das Datenbankmodul fortgesetzt, als ob es die Schreibvorgänge erfolgreich in stabilen Medium übertragen. Ein Stromausfall wird sofort Datenverlust zu diesem Zeitpunkt jedoch führen, da die Änderungen außerhalb der gesicherten Cache nicht Batterie nie physisch vorhanden waren. Absturz Wiederherstellung weist nicht auf Fehler hin, da Absturz Wiederherstellung nicht, zu dem Protokolldatensatz verloren weiß und nicht versucht, die die Arbeit zu wiederholen. Szenarien mit mehreren Objekt Änderung (z. B. Primärschlüssel, Fremdschlüssel Schlüssel fügt) erweitern Sie die verschiedenen Arten der Datenbank Schäden, die auftreten können.

Es gibt verschiedene Probleme, die mit kleinen Änderungen, wie der Cache der e/A behandelt auftreten können. Eine kurze Ableitung wird davon ausgegangen, Rollback der Transaktion jedoch Seite 100 war es zu physischen Medien ausgeführt wurde. Absturz Wiederherstellung erneut weiß zu der Protokolleintrag (nie vorgenommen, um stabile Medien), so Seite 100 wird nicht rückgängig-Vorgänge während der Absturz Wiederherstellung verlassen der Datenbank logisch und physisch möglicherweise fehlerhaft empfangen nicht.

Beispiel 2: Fehlerverdächtig Datenbank

Einige Anbieter zulassen "opt out der Dateien" und häufig empfehlen lassen die Datenbank-Protokolldatei (.ldf für SQL Server) aus dem Cache entschieden. Die Richtlinie "opt out" ist, dass der Administrator insbesondere hat Dateien von der Zwischenspeicherung Software ignoriert werden markiert. Andernfalls ist die Datei automatisch enthalten.

Dies ist eine schlechte Annahme markieren Sie die folgenden Beispiele. Microsoft empfiehlt allen Datenbank und Sicherungsdateien von solchen Cache entschieden werden.

1. Die Protokolldatei ist, entschieden, sodass Schreibvorgänge mit stabilen Medium erhalten.
2. Seite 100 wird geändert.
3. Das Datenbankmodul führt eine Operation Prüfpunkt.
4. Das Modul wird angewiesen, alle Datenbanken Seiten und Protokolleinträge sind sichere (Zeitpunkt up to Prüfpunkt berücksichtigt abgesichert). Die Datenseiten sind jedoch nicht alle auf oder in stabilen Medium gespeichert.
5. SQL Server-Datenbank befindet sich im Wiederherstellungsmodus "SIMPLE", damit Prüfpunkt jetzt die Protokolldatensätze schneidet.
6. Seite 100, die nur Kontrollkästchen verwiesen wurde, wird erneut geändert.

Diese Situation hat die Datenbank Daten verloren gehen ausgesetzt und im Allgemeinen führt zu einer fehlerverdächtigen Datenbank. Erneut, wenn ein Stromausfall stattfindet, hat Absturz Wiederherstellung keine Protokolldatensätze da Sie aufgrund von Kürzungen nicht mehr vorhanden sind. Das Datenbankmodul verfügt über keine Informationen, die angibt, dass Datenbankseiten fehlen Daten, die während der Prüfpunkt geschützt sollten. Absturz Wiederherstellung versucht, die zweite Änderung auf Seite 100 analysieren jedoch fehlschlägt, weil Seite 100 nicht richtig auf stabilen Medium bei der die Prüfpunkt gesichert wurde.

Absturz Wiederherstellung verwendet in die Kopfzeile der Seite gespeicherten LSN-Wert, um Wiederherstellung Anforderungen bestimmen.

• Wenn die LSN auf der Seite gleich oder höher als der der Protokolldatensatz ist, hat Wiederherstellung keine weiteren arbeiten auf der Seite, da die Seite bereits mit der basierend auf LSN Vergleich Protokolldatensatz konsistent ist.
• Wenn die LSN auf der Seite älter als des Protokolldatensatzes ist, muss Wiederherstellung die korrekten Operationen um die Seite in den richtigen Zustand. Wiederherstellung schlägt fehl, wenn Wiederherstellung eine fehlende Daten Bedingung aufgedeckt hat und die Seite kann nicht ordnungsgemäß in den korrekten Zustand zurückgegeben.

Aus dem Beispiel die vorherige LSN, die in den Protokolleintrag für die zweite Änderung Seite 100 gespeichert in den Seitenkopf nicht vorhanden ist, und es ist kein früheres Protokolldatensatz vorhanden, um die Seite zu wiederholen. Daher wird die Datenbank als fehlerverdächtig, als markiert Wiederherstellung nicht sicher fortgesetzt werden kann.

Beispiel 3: Sicherungen sind nicht gültig - automatische Sicherung Kette unterbrochen

Beispiel 2 ist nur ein Bruchteil diese Arten von Problemen, die festgestellt werden konnte. In diesem Beispiel statt Wiederherstellungsmodus "SIMPLE" lassen Sie uns legen die Datenbank in "FULL RECOVERY" Modus jedoch dauern regelmäßige Sicherungen der Protokolldatei und der Datenbank. Zunächst wird Sie diese besser wäre, da Sie eine Kette intakt Protokoll und konnte nur ein Wiederherstellungssequenz zur Behebung des Problems ausführen.

Dies möglicherweise keine Annahme gültig, wie einige Cacheimplementierungen die Richtlinie "opt out" verwenden, damit der Sicherungsdatei oder Teile davon unerwartet zwischengespeichert werden können. Wenn SQL Server die backup-Datei schreibt, muss, dass alle Schreibvorgänge auf dem Sicherungsmedium ordnungsgemäß in stabilen Medium mithilfe der Win32-API FlushFileBuffers -Funktion oder gespeichert werden. Folglich Wenn der Cache-Hersteller nicht sicher ist alle Schreibvorgänge ordnungsgemäß geleert werden, während des Aufrufs FlushFileBuffers Funktion kann zu Medien stabil, bevor der Vorgang erfolgreich, beendet die Datenbank wird Modul sich ohne eine sichere Sicherung abschneiden. Erneut führt ein Stromausfall an dieser Stelle eine Bedingung, in denen die entsprechenden Protokolldatensätze fehlen und Absturz Wiederherstellung fehlschlagen kann. Was noch wichtiger ist ist, dass Absturz Wiederherstellung möglicherweise nicht aufgrund der fehlenden Protokolldatensätze in der Datenbank erkannt und die Sicherung Kette automatisch beschädigt. Nur, wenn, eine Wiederherstellung von der Sicherung versucht wird kann die Datenbank-Engine werden an die Sicherung beschädigt wurde.

Beispiel 4: Ungültiger Datenbankstatus

Datenbankdateien enthalten Abhängigkeiten einander gleichgestellt erfordert strikte Write-through und-Anordnung Kompatibilität auf alle von Ihnen als Gruppe angewendet werden soll. Prüfpunkt, Änderungen an Größe der Datei, differenzielle Sicherungen, nicht protokollierter Operationen, und das Wiederherstellungsmodell PROTOKOLLIERT BULK gehören zu ein paar der Schlüsseldatenbank Aktivitäten, die Schreibzugriff durch erfordern bei Datendateien, auf Richtlinien wie Abonnementkündigung nur die Protokolldatei eine ungültige Annahme vornehmen.

Beispiel 5: Datenverlust für Snapshot-Datenbank ? möglicherweise silent sein.

SQL Server 2005 eingeführt Snapshotdatenbanken für Punkt in Mal Abfragen. Hier wird Copy-on-Write-Datenbanktechnologie, um eine Kopie einer Datenseite in der Datenbank Snapshot Daten schützen, bevor eine neue Änderung auf die Datenseite in die Basisdatenbank vorgenommen wird. Dieser Prozess erfordert, dass die Seite in der Snapshot-Datenbank gesichert werden, bevor die Transaktion fortgesetzt werden kann. Wenn die Seite nicht in stabilen Medium oder gesichert ist, bleiben Datenintegritätsprobleme. Snapshot-Datenbank enthält ein Transaktionsprotokoll nicht, daher ist das Schreiben der Seite von Bedeutung. Wenn etwa ein Stromausfall aufgetreten ist, kann es möglich sein, dass die Hauptdatenbank Seite geändert wurde, aber der Snapshot der vorherigen Abbildung nicht wieder, gibt da zwischengespeicherte Schreibzugriff unterbrochen wurde.

Zum Konfigurieren

Cache ist spezifisch für Kreditor-Implementierung, wie so konfigurieren Sie ein Produkt bereitstellen Dateicache von etwa nicht Batterie gesichert. Jedoch können ein paar Regeln angewendet werden:

• Alle Schreibvorgänge müssen in oder auf stabilen Medium abgeschlossen werden, bevor der Cache für das Betriebssystem gibt an, dass die e/A beendet ist.
• Daten können zwischengespeichert werden, solange eine Leseanforderung aus dem Cache bedient dasselbe Bild, zurückgibt wie in oder auf stabilen Medium gefunden.

Diese Regeln bedeutet im Wesentlichen, dass nicht Batterie gesicherte Cache für Lesevorgänge wirksam sein kann, aber nicht für Schreibanforderungen verwendet werden sollte. Mit der richtigen Konfiguration kann dies für das Datenbankmodul eine Leistungsverbesserung. Dies sollte jedoch, sorgfältig getestet werden, weil reserviert etwas festlegen, wie RAM, die von SQL Server verwendet werden könnten Gesamtleistung beeinträchtigen kann. SQL Server, den zusätzlichen Arbeitsspeicher mit höhere Genauigkeit als einen generischen Cache-Mechanismus verwenden möglicherweise.

Nur-Lese-Datenbanken

Nur-Lese-Datenbanken möglicherweise ein gutes Beispiel, in denen excel diese Arten von Produkten. Wenn die Datenbank wurde zuerst erstellt und gespeichert oder in stabilen Medium an, die Datenintegrität, ALTER DATABASE-Anweisung verwendet, um die Datenbank READ ONLY markieren und die Datenbank anschließend den Cachingmechanismus zugewiesen sicherzustellen, können Leistungsverbesserungen auftreten. Einige Implementierungen behalten komprimierte Bilder von der Datenbankseiten im Cache mehr physischen Daten aus dem Cache abgerufen werden und physische e/A zu reduzieren.

Vorsicht Die Datenbank sollte nie vorgenommen werden READ WRITE, wenn in einem Cache zugewiesen, die nicht das Protokoll WAL einzuhalten ist.

Sicherheit

Einführung in einen Cache, wie der RAM-basierte Dateisystemcache führt einen anderen "in-Memory" Speicherort für Daten. Produkte z. B. eine Datenbank-Engine können davon ausgehen, wichtige Daten wurde in oder auf stabilen Medium gespeichert und korrekt beibehalten Zugriff Steuerelement ACL-Schutzmaßnahmen. Der RAM-basierten Cache konnte die Daten eine Reihe von Sicherheitsproblemen verfügbar machen, eindeutig im Vergleich mit stabilen Medium sind. Wenn die Anwendung geeignet ist, um etwa die SecureZeroMemory -Funktion verwenden, jedes Mal, dass die Verwendung wichtigen Informationen abgeschlossen hat, verfügt die Anwendung z. B. eine Annahme, dass die Daten nicht mehr im Arbeitsspeicher vorhanden ist. Wenn eine Form der Daten zwischengespeicherte bleiben kann, wenn die Anwendung in oder auf stabilen Medium werden erwartet, konnte Sie jedoch die Sicherheitsaspekte ändern.

Integritätsprüfungen Daten

Microsoft empfiehlt, immer eine sichere und löschen Datenintegrität Strategie. Dies sollte enthalten, ist jedoch nicht beschränkt auf Wiederherstellen von Sicherungen und regulären DBCC CHECKDB-Operationen für die Produktion und die wiederhergestellte Datenbank.

Microsoft empfiehlt außerdem erhöhen die Häufigkeit der Tests Sicherheit beim Auswerten und Implementieren von Änderungen an der Umgebung, oder wenn Probleme auftreten, die die Stabilität der Umgebung betreffen.

Weitere Informationen zum Verwenden der SQLIOStress-Dienstprogramm finden Sie im folgenden Artikel der Microsoft Knowledge Base:

Die TEMPDB-Datenbank

Es ist möglich, suchen Sie die TEMPDB -Datenbank auf bestimmte Systeme Zwischenspeichern. Mehrere Faktoren sollten sorgfältig betrachtet und beim Auswerten der des Speicherort für die TEMPDB -Datenbank in dieser Konfiguration getestet werden. Im folgenden Microsoft Knowledge Base-Artikel werden die e/A-Anforderungen, zugeordnete Supporteinschränkungen und möglichen Leistungsgewinne beschrieben.

Unterstützung

Microsoft SQL Server-Support hilft Kunden, die mit Standarddaten Wiederherstellungstechniken. Wenn Produkte installiert, auf dem Computer zeichnen die Datenintegrität in Frage, Microsoft SQL Server, Active Directory und Exchange Support Fragen möglicherweise, dass das Produkt deinstalliert werden und wird nicht in Ursachenanalyse bis solche Einbindung kann das Problem ohne genannte Produkt reproduziert werden.

Microsoft zertifizieren weder überprüfen, dass Produkte von Drittanbietern mit SQL Server ordnungsgemäß funktionieren. Darüber hinaus bietet Microsoft Garantie, Garantie oder -Anweisung alle Drittanbieterprodukt Eignung für die Verwendung mit SQL Server keinen.

Überlegen Sie zusätzlichen Informationen durch die folgenden Verweise auf die Verbesserung der Leistung bewerten: