Pufferverwaltung

Artikel
12/15/2008

Neu: 17. Juli 2006

Der Hauptzweck einer SQL Server-Datenbank ist das Speichern und Abrufen von Daten. Daher stellt eine hohe Ein-/Ausgabe auf dem Datenträger ein Hauptmerkmal von Datenbankmodul dar. Datenträger-E/A-Vorgänge beanspruchen viele Ressourcen und benötigen relativ viel Zeit für die Ausführung. Daher ist SQL Server so konzipiert, dass E/A-Vorgänge möglichst effizient gestaltet werden. Die Pufferverwaltung ist eine zentrale Komponente zum Erreichen dieser Effizienz. Die Pufferverwaltungskomponente von SQL Server 2005 weist zwei Mechanismen auf: den Puffer-Manager, mit dem auf Datenbankseiten zugegriffen wird und mit dem sie aktualisiert werden, und den Puffercache (auch als Pufferpool bezeichnet), mit dem Datenbankdatei-E/A-Vorgänge reduziert werden.

Funktionsweise der Pufferverwaltung

Ein Puffer ist eine 8-KB-Seite im Arbeitsspeicher. Dies entspricht der Größe einer Datenseite oder Indexseite. Der Puffercache ist ebenfalls in Seiten von je 8 KB unterteilt. Mit dem Puffer-Manager werden die Funktionen verwaltet, mit denen Daten- oder Indexseiten aus Datenbankdatenträgerdateien in den Puffercache geladen und geänderte Seiten zurück auf den Datenträger geschrieben werden. Eine Seite bleibt im Puffercache, bis auf diese Seite während eines bestimmten Zeitraumes nicht mehr verwiesen wird, oder bis der Pufferbereich vom Puffer-Manager zum Laden weiterer Daten benötigt wird. Daten werden nur dann zurück auf den Datenträger geschrieben, wenn sie geändert wurden. Daten im Puffercache können mehrfach geändert werden, bevor sie zurück auf den Datenträger geschrieben werden. Weitere Informationen finden Sie unter Lesen von Seiten und Schreiben von Seiten.

Beim Starten wird von SQL Server die Größe des virtuellen Adressraumes für den Puffercache auf Grundlage verschiedener Parameter berechnet (z. B. der Größe des physikalischen Arbeitsspeichers des Systems, der Anzahl der maximal konfigurierten Serverthreads und verschiedener Startparameter). Die berechnete Größe des virtuellen Adressraumes (auch als Arbeitsspeicherziel bezeichnet) für den Puffercache wird von SQL Server reserviert; es wird jedoch nur die für die aktuelle Last erforderliche Größe an physikalischen Arbeitsspeicher verwendet. Sie können eine Abfrage an die bpool_commit_target-Spalte und die bpool_committed-Spalte in der sys.dm_os_sys_info-Katalogsicht senden, um die Anzahl der als Arbeitsspeicherziel reservierten Seiten bzw. die Anzahl der Seiten, für die im Puffercache ein Commit ausgeführt wird, zurückzugeben.

Das Intervall zwischen dem Start von SQL Server und dem Zeitpunkt, wenn der Puffercache sein Arbeitsspeicherziel erreicht hat, wird als Anlaufprozess bezeichnet. In dieser Zeit wird der Puffer mit den erforderlichen Leseanforderungen gefüllt. Durch eine Leseanforderung für eine einzelne Seite wird beispielsweise eine einzelne Pufferseite gefüllt. Dies bedeutet, dass der Anlaufprozess von der Anzahl und der Art der Clientanforderungen abhängt. In SQL Server 2005 Enterprise Edition wird dieser Prozess beschleunigt, indem Leseanforderungen für einzelne Seiten in ausgerichtete 8-Seiten-Anforderungen transformiert werden. Dadurch kann der Anlaufprozess sehr viel schneller erfolgen, insbesondere auf Maschinen mit großem Arbeitsspeicher.

Ein Großteil seines Arbeitsspeichers verwendet der Puffer-Manager im SQL Server-Vorgang. Daher erfolgt eine Zusammenarbeit zwischen Puffer-Manager und Speicher-Manager, damit auch andere Komponenten die Puffer verwenden können. Der Puffer-Manager interagiert vorrangig mit den folgenden Komponenten:

Ressourcen-Manager zur Steuerung der gesamten Speicherauslastung, und für 32-Bit-Plattformen zur Steuerung der Adressraumverwendung.
Datenbank-Manager und dem SQL Server-Betriebssystem (SQLOS) für Datei-E/A-Vorgänge auf niedriger Ebene.
Protokoll-Manager für Write-Ahead-Protokollierung.

Änderungen in SQL Server 2005

In SQL Server 2005 weist der Puffer-Manager die folgenden Verbesserungen auf:

Der Puffer-Manager ist NUMA-fähig (Non-Uniform Memory Access). Außerdem werden Puffercacheseiten auf NUMA-Hardwareknoten verteilt, sodass ein Thread auf eine Pufferseite zugreifen kann, die dem lokalen NUMA-Knoten zugewiesen ist, statt den Zugriff über einen fremden Speicher vorzunehmen. Weitere Informationen finden Sie unter Unterstützung der NUMA-Funktionalität in SQL Server 2005. Weitere Informationen zur Zuweisung von Arbeitsspeicherseiten aus dem Puffercache beim Verwenden von NUMA finden Sie unter Vergrößern und Verkleinern des Pufferpools unter NUMA.
Der Puffer-Manager unterstützt das Hinzufügen von Arbeitsspeicher im laufenden Systembetrieb (Hot Add Memory), das dem Benutzer ermöglicht, physikalischen Arbeitsspeicher hinzuzufügen, ohne den Server neu starten zu müssen. Weitere Informationen finden Sie unter Hinzufügen von Speicher im laufenden Systembetrieb (Hot Add Memory).
Außerdem wird vom Puffer-Manager die dynamische Arbeitsspeicherzuordnung für die Microsoft Windows XP 32-Bit-Plattform und die Windows 2003 32-Bit-Plattform unterstützt, wenn AWE aktiviert ist. Durch die dynamische Arbeitsspeicherzuordnung kann Datenbankmodul dem Puffercache Arbeitsspeicher zuordnen oder für diesen Arbeitsspeicher freigeben, um so die aktuelle Arbeitsauslastung zu unterstützen. Weitere Informationen finden Sie unter Dynamische Arbeitsspeicherverwaltung.
Es werden auch große Seiten auf 64-Bit-Plattformen vom Puffer-Manager unterstützt. Die Seitengröße ist spezifisch für die Version von Windows. Weitere Informationen finden Sie in der Windows-Dokumentation.
Es werden vom Puffer-Manager zusätzliche Diagnosen bereitgestellt, durch die dynamische Verwaltungssichten offengelegt werden. Mithilfe dieser Sichten können Sie verschiedene für SQL Server spezifische Betriebssystemressourcen überwachen. Beispielsweise können Sie mithilfe der Sicht sys.dm_os_buffer_descriptors die Seiten im Puffercache überwachen. Weitere Informationen finden Sie unter Dynamische Verwaltungssichten in Verbindung mit dem SQL Server-Betriebssystem.

Datenträger-E/A

Mit dem Puffer-Manager werden nur Lese- und Schreibvorgänge für die Datenbank ausgeführt. Sonstige Datei- und Datenbankvorgänge, z. B. öffnen, schließen, erweitern und verkleinern) werden von den Datei- und Datenbank-Manager-Komponenten ausgeführt.

Datenträger-E/A-Vorgänge des Puffer-Managers weisen die folgenden Merkmale auf:

Alle E/A-Vorgänge werden asynchron ausgeführt, sodass der aufrufende Thread die Verarbeitung fortsetzen kann, während der E/A-Vorgang im Hintergrund ausgeführt wird.
Alle E/A-Vorgänge werden an die aufrufenden Threads ausgegeben, sofern nicht die Option affinity I/O verwendet wird. Durch die Option affinity I/O mask wird die SQL Server-Datenträger-E/A an eine bestimmte Teilmenge der CPUs gebunden. In High-End-OLTP-Umgebungen (Online Transactional Processing, Onlinetransaktionsverarbeitung) für SQL Server kann diese Erweiterung die Leistung von SQL Server-Threads, die E/A verursachen, verbessern.
Mehrfachseiten-E/A wird durch Scatter-Gather-E/A erreicht; dadurch wird ermöglicht, dass Daten in nicht zusammenhängende Bereiche des Arbeitsspeichers oder aus diesen übertragen werden können. Damit kann der Puffercache von SQL Server problemlos gefüllt oder gelöscht werden; zugleich werden mehrere physikalische E/A-Anforderungen verhindert.

Lange E/A-Anforderungen

In SQL Server 2005 werden vom Puffer-Manager alle seit mindestens 15 Sekunden ausstehenden E/A-Anforderungen gemeldet. Damit kann der Systemadministrator einfacher zwischen SQL Server-Problemen und Problemen im E/A-Subsystem unterscheiden. Es wird die Fehlermeldung 833 angegeben. Im SQL Server-Fehlerprotokoll wird sie wie folgt angezeigt:

Bei %d E/A-Anforderungen von SQL Server wurden mehr als %d Sekunden zum Abschließen des Vorgangs für die Datei [%ls] in der [%ls]-Datenbank benötigt (%d). Das Dateihandle des Betriebssystems lautet 0x%p. Der Offset des letzten langen E/A-Vorgangs lautet: %#016I64x.

Eine lange E/A kann entweder ein Lese- oder ein Schreibvorgang sein; in der Meldung wird dies nicht angegeben. Bei langen E/A-Meldungen handelt es sich um Warnungen, nicht um Fehlermeldungen. Probleme mit SQL Server werden nicht angegeben. Die Meldungen werden ausgegeben, damit der Systemadministrator die Ursache der langen Antwortzeiten von SQL Server leichter ermitteln kann und um Probleme, die nicht durch SQL Server verursacht werden, abgrenzen zu können . Die Meldungen erfordern keine bestimmte Vorgehensweise; der Systemadministrator sollte jedoch untersuchen, weshalb die E/A-Anforderung so viel Zeit beansprucht, oder ob die benötigte Zeit gerechtfertigt ist.

Ursachen für lange E/A-Anforderungen

Eine lange E/A-Meldung kann darauf hinweisen, dass eine E/A dauerhaft blockiert ist und nicht beendet werden kann (dies wird auch als verlorene E/A bezeichnet), oder dass die E/A noch nicht beendet wurde. Es kann anhand der Meldung nicht ermittelt werden, welches Szenario hier zutrifft. Eine verlorene E/A führt jedoch häufig zu einem Latchtimeout.

Lange Wartezeiten bei der E/A sind häufig ein Hinweis auf eine zu hohe Arbeitsauslastung für das Datenträgersubsystem in SQL Server. Ein unzureichendes Datenträgersubsystem wird in folgenden Fällen angezeigt:

Es werden mehrere lange E/A-Meldungen im Fehlerprotokoll angezeigt bei starker SQL Server-Arbeitsauslastung.
Leistungsindikatoren weisen auf eine lange Datenträgerwartezeit, lange Datenträgerwarteschlangen und eine fehlende Datenträger-Leerlaufzeit hin.

Lange E/A-Vorgänge können auch durch eine Komponente im E/A-Pfad verursacht werden (z. B. durch einen Treiber, einen Controller oder durch Firmware), bei der das Bedienen einer alten E/A-Anforderung kontinuierlich verschoben wird, anstatt neuere Anforderungen zu bedienen, die näher an der aktuellen Position des Lesekopfs liegen. Das häufig verwendete Verfahren, dass sich die Priorität in Bezug auf die Bearbeitung von Anforderungen danach richtet, welche Anforderungen näher an der aktuellen Position des Lese-/Schreibkopfes liegen, wird auch als "Fahrstuhlsuche" bezeichnet. Es ist möglicherweise schwierig, dies mithilfe des Systemmonitors von Windows (PERFMON.EXE) zu prüfen, da die meisten E/A-Vorgänge direkt bedient werden. Lange E/A-Anforderungen werden durch Arbeitsauslastungen erschwert, bei denen viele sequenzielle E/A-Anforderungen (z. B. Sichern und Wiederherstellen, Prüfen von Tabellen, Sortieren, Erstellen von Indizes, Massenladen und Dateien auf Null setzen) ausgeführt werden.

Isolierte lange E/A-Anforderungen, die nicht mit einer der vorherigen Bedingungen verknüft sind, können durch einen Hardware- oder Treiberfehler verursacht werden. Das Systemereignisprotokoll enthält möglicherweise ähnliche Ereignisse, anhand derer eine Problemdiagnose vorgenommen werden kann.

Fehlererkennung

In SQL Server 2005 kann von Datenbankseiten einer von zwei möglichen optionalen Mechanismen verwendet werden, mit dem die Integrität der Seite ab dem Zeitpunkt sichergestellt werden kann, an dem die Datei auf den Datenträger geschrieben wird, bis zu dem Zeitpunkt, wenn sie erneut gelesen wird: Schutz vor zerrissenen Seiten und Prüfsummenschutz. Anhand dieser Mechanismen kann die richtige Funktionsweise des Datenspeichers, der Hardwarekomponenten (Controller, Treiber, Kabel) und des Betriebssystems unabhängig geprüft werden. Der Schutz wird der Seite hinzugefügt, bevor sie auf den Datenträger geschrieben wird, und überprüft, wenn die Seite vom Datenträger gelesen wird.

Schutz vor zerrissenen Seiten

Der Schutz vor zerrissenen Seiten, der in SQL Server 2000 eingeführt wird, stellt in erster Linie eine Methode zum Erkennen von Seitenbeschädigungen dar, die auf Stromausfälle zurückzuführen sind. Beispielsweise kann der Fall eintreten, dass durch einen unerwarteten Stromausfall nur ein Teil einer Seite auf den Datenträger geschrieben wird. Bei Verwenden des Schutzes vor zerrissenen Seiten wird eine 2-Bit-Signatur am Ende jedes 512-Byte-Sektors in der Seite eingefügt (nachdem die ursprünglichen zwei Bit in den Seitenkopf kopiert wurden). Die Signatur wechselt bei jedem Schreibvorgang zwischen den Binärzuständen 01 und 10. Damit ist es jederzeit möglich, zu ermitteln, ob nur ein Teil der Sektoren auf den Datenträger geschrieben wird: wenn ein Bit beim späteren Lesen der Seite den falschen Zustand aufweist, wurde die Seite nicht richtig auf den Datenträger geschrieben, d. h. es wird eine zerrissene Seite ermittelt. Für die Erkennung von zerrissenen Seiten sind nur minimale Ressourcen erforderlich. Es werden jedoch keine Fehler erkannt, die durch Hardwarefehler des Datenträgers verursacht werden.

Prüfsummenschutz

Der Prüfsummenschutz, der in SQL Server 2005 eingeführt wird, ermöglicht eine verbesserte Datenintegritätsprüfung. Eine Prüfsumme wird für die Daten berechnet, die in den einzelnen Seiten geschrieben werden, und im Seitenkopf gespeichert. Wenn eine Seite, deren Prüfsumme gespeichert wird, vom Datenträger gelesen wird, wird vom Datenbankmodul die Prüfsumme für die Daten in der Seite neu berechnet. Wenn die neue Prüfsumme von der gespeicherten Prüfsumme abweicht, wird der Fehler 824 ausgegeben. Mithilfe des Prüfsummenschutzes können mehr Fehler ermittelt werden als mithilfe des Schutzes vor zerrissenen Seiten, da sich jedes in der Seite enthaltene Byte auf dieses Verfahren auswirkt. Der Prüfsummenschutz ist jedoch relativ ressourcenintensiv. Wenn die Prüfsumme aktiviert ist, werden durch Stromausfälle oder fehlerhafte Hard- oder Firmware verursachte Fehler erkannt, sobald die Seite vom Puffer-Manager vom Datenträger gelesen wird.

Die Art des verwendeten Seitenschutzes stellt ein Attribut der Datenbank dar, in der die Seite enthalten ist. Der Prüfsummenschutz stellt den Standardschutz für Datenbanken dar, die in SQL Server 2005 erstellt werden. Der Seitenschutzmechanismus wird beim Erstellen der Datenbank angegeben; er kann mithilfe von ALTER DATABASE modifiziert werden. Sie können den aktuellen Seitenschutz bestimmen, indem Sie eine Abfrage an die Spalte page_verify_option in der sys.databases-Katalogsicht oder der IsTornPageDetectionEnabled-Eigenschaft der DATABASEPROPERTYEX-Funktion senden. Bei einer Änderung der Seitenschutzeinstellungen haben die neuen Einstellungen nicht unmittelbar Auswirkungen auf die gesamte Datenbank. Stattdessen wird von Seiten die aktuelle Schutzebene der Datenbank übernommen, wenn der nächste Schreibvorgang für die Seite erfolgt. Dies bedeutet, dass in der Datenbank Seiten mit unterschiedlichem Schutz enthalten sein können.

Siehe auch