Beschreibung der Caching-Festplattencontroller in SQL Server
Zusammenfassung
Durch die Verwendung eines Schreib-Caching-Festplattencontrollers (auch Write-Back-Caching genannt) kann die Leistung von SQL Server verbessert werden. Schreibcaching-Controller und Festplattensubsysteme sind für SQL Server sicher, wenn sie speziell für die Verwendung in einer datenkritischen DBMS-Umgebung (Transaktional Database Management System) konzipiert sind. Diese Designfunktionen müssen zwischengespeicherte Daten bewahren, wenn ein Systemfehler auftritt. Der Einsatz einer externen unterbrechungsfreien Stromversorgung (USV) reicht hierfür im Allgemeinen nicht aus, da Fehler auftreten können, die nichts mit der Stromversorgung zu tun haben.
Caching-Controller und Festplattensubsysteme können für die Verwendung durch SQL Server sicher sein. Die meisten neuen speziell entwickelten Serverplattformen, die diese integrieren, sind sicher. Sie sollten sich jedoch bei Ihrem Hardwareanbieter erkundigen, um sicherzustellen, dass das Festplattensubsystem speziell für die Verwendung in einer datenkritischen transaktionalen relationalen Datenbankverwaltungssystemumgebung (RDBMS) getestet und zugelassen wurde.
Mehr Informationen
SQL Server-Datenänderungsanweisungen generieren logische Seitenschreibvorgänge. Man kann sich diesen Schreibstrom so vorstellen, dass er an zwei Orte geht: das Protokoll und die Datenbank selbst. Aus Leistungsgründen verzögert SQL Server Schreibvorgänge in die Datenbank über sein eigenes Cache-Puffersystem. Schreibvorgänge in das Protokoll werden nur vorübergehend bis zum COMMIT-Zeitpunkt verzögert. Sie werden nicht auf die gleiche Weise zwischengespeichert wie Datenschreibvorgänge. Da Protokollschreibvorgänge für eine bestimmte Seite immer vor den Datenschreibvorgängen der Seite erfolgen, wird das Protokoll manchmal als „Write-Ahead"-Protokoll bezeichnet.
Transaktionsintegrität ist eines der grundlegenden Konzepte eines relationalen Datenbanksystems. Transaktionen gelten als atomare Arbeitseinheiten, die entweder vollständig angewendet oder vollständig zurückgesetzt werden. Das SQL Server-Write-Ahead-Transaktionsprotokoll ist eine wichtige Komponente bei der Implementierung der Transaktionsintegrität.
Jedes relationale Datenbanksystem muss sich auch mit einem Konzept befassen, das eng mit der Transaktionsintegrität zusammenhängt, also der Wiederherstellung nach einem ungeplanten Systemausfall. Eine Vielzahl nicht idealer, realer Effekte kann zu diesem Fehler führen. Bei vielen Datenbankverwaltungssystemen kann ein Systemausfall zu einem langwierigen manuellen Wiederherstellungsprozess führen.
Im Gegensatz dazu erfolgt der Wiederherstellungsmechanismus von SQL Server vollständig automatisch und ohne menschliches Eingreifen. Beispielsweise könnte SQL Server eine geschäftskritische Produktionsanwendung unterstützen und aufgrund einer kurzzeitigen Stromschwankung ein Systemausfall auftreten. Nach Wiederherstellung der Stromversorgung würde die Serverhardware neu gestartet, die Netzwerksoftware würde geladen und initialisiert und SQL Server würde neu gestartet. Bei der Initialisierung von SQL Server wird der Wiederherstellungsprozess automatisch auf der Grundlage der Daten im Transaktionsprotokoll ausgeführt. Dieser gesamte Prozess erfolgt ohne menschliches Eingreifen. Bei jedem Neustart der Client-Workstations waren für die Benutzer sämtliche Daten bis zur letzten von ihnen eingegebenen Transaktion vorhanden.
Die Transaktionsintegrität und die automatische Wiederherstellung von SQL Server stellen eine sehr leistungsstarke zeit- und arbeitssparende Funktion dar. Wenn ein Schreib-Caching-Controller nicht ordnungsgemäß für den Einsatz in einer datenkritischen Transaktions-DBMS-Umgebung konzipiert ist, kann er die Wiederherstellungsfähigkeit von SQL Server beeinträchtigen und somit die Datenbank beschädigen. Dies kann auftreten, wenn der Controller SQL Server-Transaktionsprotokollschreibvorgänge abfängt und sie in einem Hardware-Cache auf der Controllerplatine puffert, diese geschriebenen Seiten jedoch bei einem Systemausfall nicht beibehält.
Die meisten Caching-Controller führen Schreib-Caching durch. Die Schreib-Caching-Funktion kann nicht immer deaktiviert werden.
Selbst wenn der Server eine USV verwendet, ist die Sicherheit der zwischengespeicherten Schreibvorgänge dadurch nicht gewährleistet. Es können viele Arten von Systemausfällen auftreten, die von einer USV nicht behoben werden können. Beispielsweise kann ein Speicherparitätsfehler, ein Betriebssystem-Trap oder ein Hardwarefehler, der einen System-Reset verursacht, zu einer unkontrollierten Systemunterbrechung führen. Ein Speicherfehler im Hardware-Schreibcache kann auch zum Verlust wichtiger Protokollinformationen führen.
Ein weiteres mögliches Problem im Zusammenhang mit einem Schreib-Caching-Controller kann beim Herunterfahren des Systems auftreten. Es ist nicht ungewöhnlich, dass das Betriebssystem während Konfigurationsänderungen „zyklisch" läuft oder neu gestartet wird. Selbst wenn ein sorgfältiger Bediener die Empfehlung des Betriebssystems befolgt, mit dem Neustart des Systems zu warten, bis die gesamte Festplattenaktivität beendet ist, können im Controller immer noch zwischengespeicherte Schreibvorgänge vorhanden sein. Wenn die Tastenkombination STRG+ALT+ENTF oder die RESET-Taste gedrückt wird, können zwischengespeicherte Schreibvorgänge verworfen werden, was möglicherweise zu einer Beschädigung der Datenbank führen kann.
Es ist möglich, einen Hardware-Schreibcache zu entwerfen, der alle möglichen Ursachen für das Verwerfen fehlerhafter Cache-Daten berücksichtigt und somit für die Verwendung durch einen Datenbankserver sicher wäre. Zu diesen Designmerkmalen gehören das Abfangen des RST-Bussignals, um ein unkontrolliertes Zurücksetzen des Caching-Controllers, eine integrierte Batteriesicherung und ein gespiegelter oder ERC-Speicher (Error Checking & Correcting) zu verhindern. Erkundigen Sie sich bei Ihrem Hardwarehersteller, ob der Schreibcache diese und alle anderen Funktionen enthält, die zur Vermeidung von Datenverlusten erforderlich sind.
SQL Server erfordert, dass Systeme die „garantierte Bereitstellung auf stabile Medien" unterstützen, wie im Microsoft SQL Server Always-On Storage Solution Review-Programm beschrieben. Weitere Informationen zu den Eingabe- und Ausgabeanforderungen für das SQL Server-Datenbankmodul erhalten Sie, indem Sie auf die folgende Artikelnummer klicken, um den Artikel in der Microsoft Knowledge Base anzuzeigen:
967576 Eingabe-/Ausgabeanforderungen für die Microsoft SQL Server-Datenbank-Engine
No comments:
Post a Comment