Aufgabenblatt - Fachbereich Informatik

Hochschule Darmstadt, Fachbereich Informatik
Prof. Dr. U. Störl
Architektur von Datenbanksystemen
WS 2015/16
Praktikum 2: Pufferverwaltung
Ziel des Praktikums
Ziel des Praktikums ist es, für verschiedene Szenarien geeignete Puffergrößen zu ermitteln und
die Performance-Auswirkungen zu analysieren. Es soll simuliert werden, dass PerformanceProbleme bei einer Anwendung existieren. Neben anderen Maßnahmen wie Analyse der Anfragen und Anpassen der gewählten Indexe (diesem Thema werden wir uns in späteren Praktikas
widmen) soll hier die Analyse der Pufferdaten (d.h. der Buffer Hit Ratio) und die daraus
resultierende Auswahl einer geeigneten Puffergröße betrachtet werden.
Aufgabe 1 (Vorbereitung)
Befüllen Sie die Datenbank mit dem gleichen Mengengerüst wie im ersten Praktikum. Schalten
Sie danach wiederum Leistungsoptimierung für den Datenbank-Puffer ab:
ALTER BUFFERPOOL IBMDEFAULTBP IMMEDIATE SIZE 10000
Implementieren Sie nun in einem Programm folgende Analyse mit zwei geeigneten SQLStatements, die zusammen, d.h. direkt hintereinander, ausgeführt werden sollen: Für einen
bestimmten Bereich aufeinanderfolgender Bestellungen1 , d.h. von Bestellnummer x bis Bestellnummer y, soll folgendes ermittelt werden:
• Alle Produktnummern und die Anzahl der Bestellungen des Produktes, aufsteigend sortiert nach der Häufigkeit ihrer Bestellungen. Dabei sollen auch Produkte, die noch nie bestellt wurden, mit aufgelistet werden. Gefolgt von der Ermittlung aller Produktnummern
und der Anzahl der Bestellungen des Produktes, absteigend sortiert nach der Häufigkeit ihrer Bestellungen. Auch hierbei sollen Produkte, die noch nie bestellt wurden, mit
aufgelistet werden.
Verwenden Sie PreparedStatements. Stellen Sie im Programm sicher, dass die Ergebnisdatensätze wirklich gelesen werden (bspw. gibt JDBC bei einer SELECT-Anfrage typischerweise
zunächst nur ein bestimmte Anzahl Tupel zurück – die anderen Ergebnis-Tupel werden erst
bei Bedarf nachgeladen). Erläutern Sie im Praktikumsbericht, wie Sie das Lesen aller Ergebnisdatensätze sicherstellen und geben Sie die verwendeten SQL-Statements an.
Aufgabe 2 (Vorbereitungsarbeiten zur Pufferanalyse)
Um Daten über die logischen und physischen Datenbankzugriffe sammeln zu können, muss
zunächst das Sammeln dieser Daten im sog. Snapshot Monitor aktiviert werden. Diese Einstellung kann über die Konfiguration des Datenbankmanagers (database manager, dbm) verändert
werden: update dbm configuration using DFT MON BUFPOOL on 2
1
Die Angabe eines Bestellnummern-Bereichs von x bis y soll eine Zeitscheiben-Analyse simulieren, also
beispielsweise die Auswertung aller Bestellungen einer bestimmten Woche, eines bestimmten Monats etc.
2
Der Parameter DFT MON BUFPOOL steht dabei für die Bufferpools – weitere Parameter existieren für das
Sammeln von Informationen über Sperren, Aktivitäten auf bestimmten Tabellen, SQL-Statements etc. Der
1/3
Hochschule Darmstadt, Fachbereich Informatik
Prof. Dr. U. Störl
Architektur von Datenbanksystemen
WS 2015/16
Wichtig: Einige Änderungen der Konfiguration des Datenbankmanagers werden erst nach
Beenden und Neustarten der DB2-Instanz (db2stop3 bzw. db2start) aktiv.
Auf die Statistik über die Zugriffe im Datenbank-Puffer kann mit Hilfe des Befehls
get snapshot for bufferpools on <datenbankname>
zugegriffen werden.
Hinweis: Achten Sie darauf, dass Sie wirklich die Daten des Puffers IBMDEFAULTBP auswerten!
Die wichtigsten Parameter zur Berechnung der Buffer Hit Ratio sind die Angaben über die
logischen und physischen Zugriffe auf (Primär)daten bzw. Indexseiten4 :
pool
pool
pool
pool
data l reads
data p reads
index l reads
index p reads
Buffer
Buffer
Buffer
Buffer
Pool
Pool
Pool
Pool
Data Logical Reads
Data Physical Reads
Index Logical Reads
Index Physical Reads
Überlegen Sie sich, wie Sie aus diesen Daten die Buffer Hit Ratio berechnen können.
Zum Reset der Zähler zwischen den Messungen wird der folgende Befehl verwendet:
reset monitor for database <datenbankname>
Achtung! Dies bedeutet nur ein Rücksetzen bezüglich der aktuellen Session (also beispielsweise
des jeweiligen Befehlszeilenprozessors). Dabei werden keine globalen Zähler zurückgesetzt. Sie
müssen also das Reset und die Analyse der Daten immer aus dem gleichen Befehlszeilenprozessor, d.h. innerhalb der gleichen Session ausführen.
Aufgabe 3 (Optimale Puffergröße für verschiedene Szenarien ermitteln)
Ermitteln Sie für die folgenden 3 Szenarien, basierend auf der in Aufgabe 1 implementierten
Analyse, die optimalen Puffergrößen und analysieren Sie die Laufzeiten:
1. Sequentielle Auswertung auf allen Bestellungen in 100.000er Schritten.5
2. Wie in 1, jedoch werden 10.000er Schritte verwendet.
3. Auswertung nur auf einem eingeschränkten Bereich der Bestellungstabelle, d.h. einem
von Ihnen selbst gewählten 100.000 Abschnitt. Dabei sollen pro Durchlauf die AnalyseAbfragen fünfmal auf dem gleichen Bereich wiederholt werden.
Status der verschiedenen Parameter des Datenbankmanagers kann mit dem Befehl get dbm configuration
angezeigt werden.
3
Hinweis: sollte db2stop nicht erfolgreich ausgeführt werden können, sind ggf. noch Applikationen (z.B.
Befehlszeilenprogramme) aktiv bzw. es existieren noch Verbindungen zu Datenbanken. Beenden Sie diese. Falls
eine erfolgreiche Ausführung von db2stop trotzdem nicht möglich ist, können Sie diese Anwendungen mit dem
Kommando force application all oder mit Hilfe von db2stop force beenden.
4
Die deutsche Übersetzung Lesevorgänge im Pufferpoolindex bei der Anzeige ist irreführend – gemeint sind
hier die Lesevorgänge von Indexseiten im Puffer.
5
Simuliert z.B. die sequentielle Auswertung für Januar, Februar, März etc.
2/3
Hochschule Darmstadt, Fachbereich Informatik
Prof. Dr. U. Störl
Architektur von Datenbanksystemen
WS 2015/16
Ziel ist es jetzt, für die jeweiligen Szenarien optimale Puffergrößen zu finden, d.h. die Größe
des Puffers so zu wählen, dass kein physischer Zugriff auf die Daten im Dateisystem notwendig
wird und die Anfragen ausschliesslich vom Datenbankpuffer beantworten werden können. Ein
einfaches Erhöhen des Puffers auf die maximale Größe gilt dabei als nicht optimal, da dadurch
jegliche andere Ressourcen (Anwendungen etc.) ggf. mehr als nötig eingeschränkt werden bzw.
dies bei realistischen Datenbankgrößen von mehreren GB in der Praxis nicht möglich ist. Es
ist jeweils das Minimum für die 3 Szenarien zu finden.
Überlegen Sie sich vor Beginn der Arbeit, welches die von Ihnen erwartete theoretisch optimale
Größe für den Puffer für das jeweilige Anwendungsszenario wäre und protokollieren Sie diese
Thesen im Praktikumsbericht. Anmerkung: In der Realität kennen Sie natürlich den betroffenen
Anteil der Datenbank im Allgemeinen nicht vorher und müssen sich deshalb durch einen Mix
von theoretischen Untersuchungen des Szenarios und praktischer Analyse der Buffer Hit Ratio
an die optimale Puffergröße heranarbeiten.
Zum Verändern der Puffergröße verwenden Sie den bereits bekannten Befehl. Passen Sie für die
definierten Anwendungsszenarien die Puffergröße jeweils an und ermitteln und protokollieren
Sie die erhaltenen Buffer Hit Ratios sowie die jeweiligen Laufzeiten. Beginnen Sie mit einer
Puffergröße von 1.000 Seiten und verändern Sie die Größe, bis Sie die von Ihnen berechnete
optimale Größe erreichen. Sie sollten mehrere Schritte zwischen diesen beiden Grenzen wählen,
um die Änderungen im Verhalten der Buffer Pool Hit Ratio (BHR) zu erkennen. Falls die BHR
noch nicht optimal ist, vergrößern Sie den Puffer ggf. weiter und diskutieren Sie im Bericht,
warum der erwartete Wert nicht ausgereicht hat.
Überlegen Sie sich bei der Durchführung, ob und wann Sie sinnvollerweise den Puffer leeren
müssen (das geht nur durch die Ausführung von db2stop / db2start) oder ob Sie einen
bereits gefüllten Puffer benötigen und stellen Sie diese Umgebung ggf. vor der Messung her.
Begründen Sie, warum Sie sich wann für einen gefüllten oder leeren Puffer entschieden haben.
Hinweis: Die Puffergröße zu klein (unter 30 Seiten) zu wählen, ist nicht sinnvoll, da dann auch
Meta-Informationen (Katalogdaten etc.) permanent ein- und ausgelagert werden müssen und
keine sinnvollen Werte ermittelt werden können.
Analysieren Sie die erzielten Ergebnisse durch eine geeignete, übersichtliche Darstellung
(Tabelle, Diagramm o.ä.) im Praktikumsbericht und diskutieren Sie insbesondere, ob die von
Ihnen vorab prognostizierten Ergebnisse eingetroffen sind.
Praktikumsbericht
Der Praktikumsbericht ist bis 1 Woche nach dem Praktikumstermin per Mail einzureichen.
3/3

Download Report