Dass der Puffer die Performance der Datenbank maßgeblich beeinflusst ist den meisten Lesern sicher bekannt, je mehr Daten der Datenbank im Hauptspeicher liegen, desto weniger Lesezugriffe auf die Storage-Einheit werden benötigt. Am besten ist es natürlich, wenn sich die gesamte Datenbank im Cache befindet. Die Übertragung der einzelnen Datensegmente in den Puffer bedingt jedoch eine Client-Anfrage, bei deren Verarbeitung diese Daten benötigt werden. Bei größeren Datenbanken dauert es daher lange, bis alle Segmente auch im Cache vorhanden sind.
Bei einer Datenbank von 50GB kann es durchaus mehrere Tage dauern, bis der Puffer komplett gefüllt ist. Nach einem Neustart des Servers ist der Cache-Inhalt allerdings verloren und der Datenbankbetrieb startet wieder bei einem leeren Puffer. Dadurch kann in der ersten Zeit nach dem Öffnen ein spürbarer Geschwindigkeitsverlust entstehen.
Zur Vermeidung dieses Effekts gibt es in Zukunft ein neues Feature des Datenbankservers, welches ein automatisches Befüllen des Caches nach dem Öffnen einer Datenbank erlaubt. Dafür gibt es zwei unterschiedliche Mechanismen, die sich pro Datenbank einzeln aktivieren lassen.
Die erste Variante sichert die Belegung des Puffers (nicht den Inhalt) beim Schließen der Datenbank in einer speziellen Datei (<datenbankname>.cache). Beim Öffnen der Datenbank wird diese Datei auf Gültigkeit geprüft und anschließend erfolgt das Einlesen aller Segmente, die sich zuletzt im Cache befanden. Die Operation liest die Datenblöcke in sequentieller Reihenfolge aus der Datenbank, um eine möglichst hohe Transferrate zu erzielen. Dieses Verfahren ist auch bei kleinen und mittleren Cachegrößen sehr effizient.
Sofern keine Pufferbelegung gespeichert ist, führt die zweite Variante ein vollständiges Lesen der gesamten Datenbank durch. Unter Berücksichtigung der Zugriffshäufigkeit wird der Cache dabei entsprechend gefüllt. Ist der Puffer größer als die Datenbank, so werden alle Daten in den Cache transferiert, bei kleinerem Puffer zumindest die häufiger benötigten Segmente.
Die Erweiterung wird in einem der nächsten Updates der 5.7 zur Verfügung stehen.
2 Antworten
Idealerweise stehen im Cache die Daten mit den höchsten Zugriffshäufigkeiten – in diesem Fall wird der höchste Geschwindigkeitszuwachs erzielt.
Diese Werte verändern sich während des Datenbankbetriebs ständig, eine Vorhersage anhand des Inhaltstyps ist sehr spekulativ. Aufgrund der Struktur der Datenbank und empirischen Messungen ergibt sich eine klare Häufigkeitsverteilung nach Segmenttyp. Die Ziffern geben die Anzahl von Zugriffen innerhalb eines Messintervalls an:
Blattsegmente: 1 bis 100
Knotensegmente: 50 bis 3000
Wurzelsegmente: 1000 bis 20000
Eine manuelle Proritätsvergabe würde die Cacheleistung eher negativ beeinflussen.
Wäre es vielleicht sinnvoll, das man die Cache-Priorität vorgeben kann um z.B. Konstanten-Dateien, Prozduren, Oberflächenobjekte usw bevorzugt zu laden ?