Kapitel 7 Datenbank-Tuning Flien zum Datenbankpraktikum Wintersemester 2010/11 LMU München 2008 Thmas Bernecker, Tbias Emrich unter Verwendung der Flien des Datenbankpraktikums aus dem Wintersemester 2007/08 vn Dr. Matthias Schubert 7.1 Ziele und Tuning-Ebenen 7.2 Relatinenschema 7.3 Cluster Übersicht 7.4 Verwendung vn Indexstrukturen LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 2
Ziele vn DB-Tuning Verkürzung der Antwrtzeit (Online Analytical Prcessing - OLAP): Wichtig bei Einbenutzer-Datenbankapplikatinen (z.b. Data Mining): der Benutzer möchte möglichst rasch eine Antwrt auf seine Anfrage. Erhöhung des Durchsatzes (Online Transactin Prcessing - OLTP): Wichtig bei Hchleistungs-Transaktinssystemen (z.b. Flugbuchung): pr Zeiteinheit sllen möglichst viele Anfragen bearbeitet werden. Zielknflikt: Zwischen der Verkürzung der Antwrtzeit und der Erhöhung des Durchsatzes besteht häufig ein Zielknflikt, da z.b. die Verlagerung vn Prgrammfunktinalität in den DB-Server (gespeicherte Przeduren) die Antwrtzeit im Einbenutzermdus verkürzt, dagegen im Mehrbenutzermdus den Durchsatz hemmt. LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 3 Tuning-Ebenen (Auszug) Relatinenschema: Nrmalisierung, Denrmalisierung Physisches DB-Schema: Clustering, Index Anfrageptimierung: Query Rewriting, Hinweise an den SQL-Optimierer Client-Server-Architektur Parallelisierung und Verteilung Transaktinsdesign Betriebssystemparameter und DB-Vreinstellungen: Größe eines DB-Blcks, Größe des DB-Cache LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 4
7.1 Ziele und Tuning-Ebenen 7.2 Relatinenschema 7.3 Cluster Übersicht 7.4 Verwendung vn Indexstrukturen LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 5 Nrmalisierung Wenn auf bestimmte Attribute einer Relatin erheblich häufiger zugegriffen wird, als auf andere (speicherintensive) Attribute der selben Relatin, kann es günstig sein, die Relatin zu zerlegen. Beispiel: ERSATZTEILLAGER (TeileNr, Bestand, Teilebeschreibung) ib Wenn auf Bestand viel häufiger zugegriffen wird als auf Teilebeschreibung, dann ist flgendes Relatinenschema günstiger: g LAGERBESTAND (TeileNr, Bestand) TEILE (TeileNr, Beschreibung) Zerlegung ist z.b. bei Jins mit einer anderen Relatin günstiger im Leistungsverhalten, aber auch platzintensiver. Durch Zerlegung über Cmpsite Indexes kann i.d.r. ein nch besserer Leistungsgewinn erzielt werden (siehe Abschnitt 7.4). LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 6
Denrmalisierung: Vermeidung vn Jins ( Materialisierter Jin ) Beispiel: PRAKTIKUMSTEILNEHMER (PraktikumsNr, MatrikelNr) STUDENT (MatrikelNr, Name, Adresse, Telefnnummer) Bei den meisten Zugriffen auf die PRAKTIKUMSTEILNEHMER wird auch gleichzeitig der Name des Studenten benötigt (Jin). Eine redundante Speicherung vn Name kann daher sinnvll sein: PRAKTIKUMSTEILNEHMER (PraktikumsNr, MatrikelNr, Name) STUDENT (MatrikelNr, Name, Adresse, Telefnnummer) aber: Gefahr vn Update-Anmalien Frmulieren vn Integritätsbedingungen Überwachung durch Trigger (aufwändig) Prblem auf physischer Ebene lösen: Cluster verwenden LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 7 7.1 Ziele und Tuning-Ebenen 7.2 Relatinenschema 7.3 Cluster Übersicht 7.4 Verwendung vn Indexstrukturen LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 8
Cluster Ein Cluster ist ein physisch vrberechneter Jin. Im Gegensatz zur Denrmalisierung ist er redundanzfrei. Zwei der mehr Relatinen werden ineinander verschränkt gespeichert. Allerdings ergeben sich spürbar erhöhte Update-Ksten. Beispiel: BESTELLUNG (KundenNr, TeileNr, Menge) KUNDEN (KundenNr, Name) Speicherrganisatin eines Clusters auf KundenNr: : (KundenNr 1, Name 1 ) [(TeileNr 1,1, Menge 1,1 ),(TeileNr 1,2, Menge 1,2 ), (TeileNr 1,3, Menge 1,3 )... ], (KundenNr 2, Name 2 ) [(TeileNr 2,1, Menge 2,1 ),...],... Schwierige Speicherplatzrganisatin, daher nicht in allen RDBMS verfügbar Syntax in ORACLE: CREATE CLUSTER <clustername> (attribut1 typ1, attribut2 typ2,...); DROP CLUSTER <clustername>; ALTER CLUSTER <clustername>...; LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 9 Beispiel Praktikum/Student: CREATE CLUSTER psc (matrnr NUMBER(15)) ; CREATE TABLE student ( matrnr NUMBER (15) PRIMARY KEY, name char(80) ) CLUSTER psc (matrnr) ; CREATE TABLE praktikum ( praktnr NUMBER (4) NOT NULL, matrnr NUMBER (15) NOT NULL, PRIMARY KEY (matrnr, praktnr) ) CLUSTER psc (matrnr) ; CREATE INDEX psc_idx ON CLUSTER psc ; Erst jetzt können Tupel in die Relatinen eingefügt werden. LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 10
7.1 Ziele und Tuning-Ebenen 7.2 Relatinenschema 7.3 Cluster Übersicht 7.4 Verwendung vn Indexstrukturen LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 11 Indexstukturen Werden die Relatinen hne Index gespeichert, dann bestehen sie nur aus einer ungerdneten Ansammlung einzelner Tupel. Jeder Zugriff erfrdert dann einen vllständigen Durchlauf der gesamten Relatin (full table scan). Ein Index ist eine Datenstruktur (z.b. B + -Baum der Hash Table), in der Verweise auf die Tupel in einer spezifizierten Srtierrdnung gespeichert werden, um effiziente Anfragebearbeitung zu ermöglichen. ORACLE erzeugt autmatisch einen Index auf den Attributen des Primärschlüssels, wenn ein Primary Key-Cnstraint gesetzt ist. Fremdschlüssel-Beziehungen werden nicht autmatisch durch einen Index unterstützt; dieser muss explizit erzeugt werden, wenn er nicht identisch mit dem gesetzten Primärschlüssel ist. Sllen Anfragen über Nicht-Schlüsselattributen effizient bearbeitet werden, s muss ebenfalls explizit ein Index aufgebaut werden. mehr dazu: Vrlesung Index- und Speicherungsstrukturen für Datenbanksysteme LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 12
Index: Syntax Index-Generierung: CREATE INDEX <index-name> name> ON <table> (attr1, attr2,..., attrn); Ein Cmpsite Index besteht aus mehr als einer Spalte. Die Tupel sind dann nach den Attributwerten t t (lexikgraphisch) h) gerdnet: t 1 < t 2 gdw. t 1.a 1 < t2.a 1 der (t 1.a 1 = t 2.a 1 und t 1.a 2 < t 2.a 2 ) der... Für den Vergleich der einzelnen Attribute gilt die jeweils übliche Ordnung: numerischer Vergleich für numerische Typen, lexikgraphischer Vergleich bei CHAR, Datums-Vergleich bei DATE usw. Löschen eines Index: DROP INDEX <index-name>; Verändern eines Index: (betrifft u.a. Speicherungs-Parameter und Rebuild) ALTER INDEX <index-name>...; LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 13 Durch Index unterstützte Anfragen Exact match query für Attribute a 1 bis a n : SELECT * FROM t WHERE a1=... AND... AND an=... Partial match query: SELECT * FROM t WHERE a1=... AND... AND ai=... für i < n, d.h. wenn die exakt spezifizierten Attribute ein Präfix der indizierten Attribute sind. Eine Spezifikatin vn a i +1 kann i.a. nicht genutzt werden, wenn a i nicht spezifiziert ist. Range query: SELECT * FROM t WHERE a1=... AND... AND ai=... AND ai+1<=... auch z.b. für > der BETWEEN LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 14
Pint Set query: SELECT * FROM t WHERE a1=... AND... AND ai=... AND ai+1 IN (7,17,77) auch z.b. (ai+1=... OR ai+1=... OR...) Pattern matching query: SELECT * FROM t WHERE a1=... AND... AND ai=... AND ai+1 LIKE c1c2...ck% Prblem: Anfragen wie wrt LIKE %system werden nicht unterstützt. Man kann aber z.b. eine Relatin aufbauen, in der alle Wörter revers gespeichert werden und dann effizient nach revers_wrt LIKE metsys% suchen lassen. Dies lässt sich auch mit einem Functin-based Index (wird nicht auf den Attributen direkt, sndern nach Anwenung einer Funktin auf ihnen erzeugt) elegant lösen. LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 15 Index-unterstützte Anfragebearbeitung Für manche Anfragen reicht der Indexzugriff zur Beantwrtung aus, z.b. SELECT COUNT(*) FROM t WHERE a1=...... WHERE EXISTS (SELECT...)... SELECT a1, a2,..., ai FROM t WHERE a1=... AND... Index umfasst alle Attribute aus select-list und where-klausel Für die meisten Anfragen ist aber eine sg. tuple materializatin erfrderlich: Hierbei wird über die ROWID (= physische Psitin des Datensatzes in der DB) auf das Tupel zugegriffen. I.a. ist dann pr Ergebnistupel ein zusätzlicher Plattenzugriff erfrderlich. Abhilfe: Index Organized Tables (IOT) speichern die Tupel vllständig in den Datenseiten der Indexstruktur. LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 16
Weitere Eigenschaften vn Indexen: Anfrage wird effizienter bearbeitet, aber INSERT/DELETE/UPDATE müssen auch auf dem Index ausgeführt werden. Das Leistungsverhalten verschlechtert sich, wenn viele Updates auf vielen Indexen durchgeführt werden. Bei größeren Updates (Einlesen der gesamten Relatin der grßer Teile aus einer Datei) kann es günstiger sein, den Index vr dem Einlesen zu löschen und nachher neu aufzubauen ( bulk lad ) ). Dies gilt u.u. auch für den impliziten Primärschlüsselindex: DROP INDEX i; UPDATE t SET... ; CREATE INDEX i ON t (...); der: ALTER TABLE t DROP PRIMARY KEY; INSERT INTO t... ; ALTER TABLE t ADD CONSTRAINT p PRIMARY KEY (...); Indexe lhnen sich nur bei grßen Relatinen. Wenn eine Relatin im Arbeitsspeicher einer Sessin ( DB-Cache ) Platz hat, kann sie auch hne Index schnell durchsucht werden. LMU München Flien zum Datenbankpraktikum Wintersemester 2010/11 17