Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Kapitel 11 Tuning relationaler Datenbanken.

Ähnliche Präsentationen


Präsentation zum Thema: "Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Kapitel 11 Tuning relationaler Datenbanken."—  Präsentation transkript:

1 Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Kapitel 11 Tuning relationaler Datenbanken

2 2 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Tuning als Administration Optimierte Anfragebearbeitung (Kapitel 10) Entwicklung und Pflege (Kapitel 2-9) Abhängigkeiten Optimale Auswahl vorhandener Techniken Auswahl und Parametrierung Bevorratung nach Schichten Zugriffs- profile

3 3 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Grundsätze (1) Nach Dennis Shasha: Database Tuning: A Principled Approach. Prentice-Hall, Database tuning is the activity of making a database application run more quickly. More quickly usually means higher throughput, though it may mean lower response time for some applications. To make a system run more quickly, the database tuner may have to change the way applications are constructed, the data structures and parameters of a database system, the configuration of the operating system, or the hardware. The best database tuners therefore like to solve problems requiring broad knowledge of an application and of computer systems.

4 4 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Grundsätze (2) Think globally, fix locally Measure the right quantities and come to the right conclusions. Localize by identifying a bottleneck (a part of the system that limits overall performance), and resolve it. Partitioning breaks bottlenecks When you find a bottleneck, first try to speed up that component. If that does not work, then partition: divide the load over more resources or spread the load over time. Startup and running costs Most objects devote a substantial portion of their resources to starting up. Obtain the desired effect with the fewest possible startups.

5 5 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Kapitel 11.1 Messen

6 6 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Tuning als Administration Optimierte Anfragebearbeitung (Kapitel 10) Entwicklung und Pflege (Kapitel 2-9) Benchmark (1) Optimale Auswahl vorhandener Techniken Auswahl und Parametrierung Bevorratung nach Schichten Zugriffs- profile Benchmark: Standardisierte Messlast

7 7 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Benchmark (2) Benchmark: Eine Suite standardisierter Aufträge, um die Leistung eines DBMS zu bestimmen. Ein DBMS (oder seine aktuelle Einstellung) erzielt nicht für jede Art von Auftrag seine Höchstleistung. Daher: Messlast sollte sich nach der vorherrschenden oder gewichtigsten Art der Aufträge richten verschiedene Benchmarks. Zwei grundlegende Auftragsklassen: Online transaction processing (OLTP) Online analytical processing (OLAP) (decision support) Häufig gemischtes Auftreten: Mischverhältnis ist dann entscheidend. Hohe Nebenläufigkeit, schnelle Commit-Verarbeitung Gute Anfrageoptimierung

8 8 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Benchmark (3) Standardisierung durch Transaction Processing Performance Council (TPC). Sehr detaillierte Definition mit Vorgabe von Menge und Schema der Relationen (oder Objektklassen) Tupelgröße (Objektgröße) Art der Transaktionen geforderte Transaktionsrate abhängig davon: Tupelzahl Messgrößen: Durchsatz als tatsächliche Transaktionsrate (TPS, transactions per second) Antwortzeiten Kosten pro TPS Details bei Kemper/Eickler, Kap. 20

9 9 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Arten von Benchmarks (1) TPC-A OLTP: Simulation einer typischen Bankanwendung Eine Art der Transaktion: Konto mit Abheben und Einzahlen Fortschreiben folgender Relationen: Bank, Schalter, Kunde, Audit Trail Berücksichtigen der Endgeräte-Kommunikation TPC-B Abgemagerter TPC-A ohne jegliche Kommunikation mit Nutzern und Endgeräten (Messen im Backend-Betrieb) Heute kaum noch verwendet!

10 10 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Arten von Benchmarks (2) TPC-C OLTP: Simulation eines typischen Bestellwesens Transaktionen: Bestellung, Lieferung, Fakturierung, Zahlungseingänge, Verfolgen der Bestellung, Bestandskontrolle Entsprechend große Zahl an Relationen Sehr verbreitet!

11 11 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Arten von Benchmarks (3) TPC-D OLAP: Simulation von Verkaufs- und Lieferwesen Fortschreiben von Relationen für Artikel, Lieferanten, Kunden, Bestellungen und weitere Größe der Relationen im geeigneten Verhältnis, Größe der simulierten Datenbasis im GB-Bereich 17 komplexe SQL-Anfragen, z.T. mit mehrfacher Schachtelung und Aggregierung TPC-R Reporting: Erweiterter TPC-D mit Einfügen und Löschen und Verwendung materialisierter Sichten TPC-H Ad-hoc: Abgemagerter TPC-R ohne materialisierte Sichten, mit Schlüssel/Fremdschlüssel als einzige Indexe

12 12 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Arten von Benchmarks (4) TPC-W Web Commerce Benchmark anhand elektronischem Buchhandel Statische und dynamische Webseiten Caching von dynamischen Webseiten Skalierungsfaktoren Messgrößen: Web interactions per second (WIPS), Kosten pro WIPS OODB Benchmarks OO7: Ein Sammlung von Benchmarks für jeweils verschiedene OODB-Transaktionen, unterschieden nach typischen Objektoperationen Gemäß erwarteter Last zu kombinieren

13 13 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Kapitel 11.2 Steuern

14 14 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuermöglichkeiten (1) Mengenorientiertes Datenmodell Anfragebearbeitung Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Dateien Dateiverwaltung Geräteschnittstelle Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Vergrößerung des Hauptspeichers (mehr Pufferspeicher, weniger virtueller Speicher) Hinzunahme von Magnetplatten Vorgesehene RAID-Typen Formatierung der Magnetplatten in Sektoren Zahl der Prozessoren Übertragungsbandbreiten Betriebssystem: Multiprogrammiergrad (Zahl nebenläufiger Transaktionen), Umschaltintervalle der Threads (möglichst lang)

15 15 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuermöglichkeiten (2) Mengenorientiertes Datenmodell Anfragebearbeitung Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Dateien Dateiverwaltung Geräteschnittstelle Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Zuordnen von Dateien. Wahl der phys. Platten Logdateien auf eigenen phys. Platten Kritische Indexe auf eigenen phys. Platten Einrichten von Dateien. Festlegen der Dateimerkmale, insbesondere Länge der log. Blöcke, Größe und Zahl der Partitionen Wahl des RAID-Typs (Datenparallelität, Zuverlässigkeit) Häufig benutzte Daten in die mittleren Spuren

16 16 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuermöglichkeiten (3) Mengenorientiertes Datenmodell Anfragebearbeitung Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Dateien Dateiverwaltung Geräteschnittstelle Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Einrichten von Segmenten, Segmenttypen Festlegen der Seitengröße Festlegen von Zahl und Größe der Puffer, Speicherzuteilungsstrategie Einlagerungs- /Ersetzungsstrategien Prefetch-Faktor Füllfaktoren für Seiten Seitenadressierung in Segment und Puffer, Suchstrategien

17 17 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuermöglichkeiten (4) Mengenorientiertes Datenmodell Anfragebearbeitung Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Dateien Dateiverwaltung Geräteschnittstelle Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Einbring-/Verdrängungs-/ Auslagerungsstrategie Logging/Shadowing Logging-Verfahren: page/record/physiologisch Redo-Strategie (redo-winners, redo-history) Strategie für Sicherungspunkte (Logging/Shadowing) Sicherungsintervalle Vorlesung Transaktionsverw.

18 18 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuermöglichkeiten (5) Mengenorientiertes Datenmodell Anfragebearbeitung Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Dateien Dateiverwaltung Geräteschnittstelle Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Transaktionsdauer (Konsistenz vs. Blockade) Sperrenverwaltung Scheduler-Strategie: Synchronisationsprotokoll, Vorrangstrategie (Leser, Schreiber) Sperren: Arten, Verschärfung, Granulate Isolationsgarantien Verklemmungskontrolle Behandlung der Hot Spots Vorlesung Transaktionsverwerwaltung

19 19 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuermöglichkeiten (6) Mengenorientiertes Datenmodell Anfragebearbeitung Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Dateien Dateiverwaltung Geräteschnittstelle Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Freispeicherverwaltung von Segmenten und Seiten Platzieren und Adressieren von Datensätzen Satzformatierung Verwaltung großer Datensätze Pointer Swizzling Zerlegen langer Transaktionen Für gegebene Satzmenge/log. Zugriffspfad: Ballungstechniken Hashverfahren: Hashfunktion/ Kollisionsauflösung/Dynamik Listen B-Baum-Verfahren und Parameter Komprimierung Mehrdimensionale Indexe

20 20 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuermöglichkeiten (7) Mengenorientiertes Datenmodell Anfragebearbeitung Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Dateien Dateiverwaltung Geräteschnittstelle Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Materialisierung von Relationen (interne Dateien) / Struktur von Datensätzen Zuordnung navigierender Zugriffspfade Zuordnung von Primär-/Sekundär-/ Clusterindex Verfügbare Implementierungen von Scan-, Sort-, und relationalen Operatoren Speicherung LOB, NF 2, XML Verfahren/Quellen für die Selektivitätsabschätzung Kostenmodelle

21 21 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuermöglichkeiten (8) Mengenorientiertes Datenmodell Anfragebearbeitung Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Dateien Dateiverwaltung Geräteschnittstelle Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Datenbankentwurf: Normalisierung, Denormalisierung, Replikation Verteilungen

22 22 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Kapitel 11.3 Oracle 9i

23 23 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Speicherorganisation (1) Phys. Block Datei 1 Datei 2 Log. Block Datei 3 Log. Block Datei 1 Log. Block Table- space J Table- space K Table- space I Table R Index R1 Index R2 Table S Index S Datensegm. r Indexsegm. r1 Indexsegm. r2 Datensegm. s Indexsegm. s1 Basis- Extent Extent Daten- block 1 Daten- block Log. Block

24 24 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Logische Datenbankstrukturen Physische Datenbankstrukturen Speicherorganisation (2) Phys. Block Datei 1 Datei 2 Log. Block Datei 3 Log. Block Datei 1 Log. Block Table- space J Table- space K Table- space I Table R Index R1 Index R2 Table S Index S Datensegm. r Indexsegm. r1 Indexsegm. r2 Datensegm. s Indexsegm. s1 Basis- Extent Extent Daten- block 1 Daten- block Log. Block

25 25 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Speicherorganisation (3) Phys. Block Datei 1 Datei 2 Log. Block Datei 3 Log. Block Datei 1 Log. Block Table- space J Table- space K Table- space I Table R Index R1 Index R2 Table S Index S Datensegm. r Indexsegm. r1 Indexsegm. r2 Datensegm. s Indexsegm. s1 Basis- Extent Extent Daten- block 1 Daten- block Log. Block Entspricht unserer Seite Entspricht unserem Segment Jede logische Struktur wird eigenständig gespeichert und verwaltet Dyn. Anpassung für jede logische Struktur getrennt Entspricht unserer Seite 4 Arten: Daten-, Index-, Rollback-, temp. Segmente

26 26 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Es werden in den nachfolgenden Anweisungen nur die Teile behandelt, die sich mit dem Einstellen von Performanzmaßnahmen befassen. Dabei wird keine Vollständigkeit angestrebt illustratives Vorgehen. Vorbemerkung

27 27 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von Dateien (1) Phys. Block Datei 1 Datei 2 Log. Block Datei 3 Log. Block Datei 1 Log. Block Table- space J Table- space K Table- space I Table R Index R1 Index R2 Table S Index S Datensegm. r Indexsegm. r1 Indexsegm. r2 Datensegm. s Indexsegm. s1 Basis- Extent Extent Daten- block 1 Daten- block Log. Block

28 28 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von Dateien (2) create database datenbank datafile dateiangabe,..., dateiangabe dateiangabe hat das Aussehen dateipfad [size wert [K|M]] [ autoextend off] oder dateipfad [size wert [K|M]] [autoextend on [next wert [K|M]] [maxsize wert [K|M]] Legt einen Tablespace SYSTEM an, der die Systemtabellen aufnimmt. Er kann auch Nutzdaten aufnehmen, und nur auf diese beziehen sich die Dateiangaben. Angabe mehrerer Dateien zur Verteilung über mehrere Platten. Einrichten der Datei mit Anfangsgröße. Bei automatischer Erweiterung wird jeweils um wert KB oder MB inkrementiert (fehlende Angabe: 1 Block), ggf. bis zu einer maximalen Größe.

29 29 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von Segmenten (1) Phys. Block Datei 1 Datei 2 Log. Block Datei 3 Log. Block Datei 1 Log. Block Table- space J Table- space K Table- space I Table R Index R1 Index R2 Table S Index S Datensegm. r Indexsegm. r1 Indexsegm. r2 Datensegm. s Indexsegm. s1 Basis- Extent Extent Daten- block 1 Daten- block Log. Block

30 30 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von Segmenten (2) create tablespace tablespace datafile dateiangabe,..., dateiangabe [offline|online] [permanent|temporary] extent management [default speicherklausel ] Modifikation ist möglich: alter tablespace tablespace [add datafile dateiangabe,..., dateiangabe ] [online] [offline normal|temporary|immediate] [permanent|temporary] [default speicherklausel ] Legt einen Tablespace SYSTEM an. Er enthält Dateien für Nutzdaten,für redo, und zur Beschreibung der phys. Struktur. Die Dateiangaben beziehen sich auf die Nutzdaten. Angabe mehrerer Dateien ermöglicht die Verteilung über mehrere Platten. Der Tablespace kann zunächst außer Betrieb gelassen werden. Temporäre Tablespaces nehmen nur Zwischenergebnisse auf. extent management belässt die Wahl zwischen system- und nutzergewählten Extents. Die speicherklausel greift, wenn keine entsprechende Klausel bei den Tabellen angeben wird. Bei offline Transaktionsschutz: normal führt zu force aller Dateien, temporary zu force der online-Dateien, immediate bleibt bei noforce.

31 31 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuerung von Relationen (1) Phys. Block Datei 1 Datei 2 Log. Block Datei 3 Log. Block Datei 1 Log. Block Table- space J Table- space K Table- space I Table R Index R1 Index R2 Table S Index S Datensegm. r Indexsegm. r1 Indexsegm. r2 Datensegm. s Indexsegm. s1 Basis- Extent Extent Daten- block 1 Daten- block Log. Block

32 32 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuerung von Relationen (2) create table relation ( attributvereinbarung,..., attributvereinbarung ) [ speicherorganisation |organization -klausel |cluster -klausel ] Speicherung durch Index bestimmt Speicherung sonst

33 33 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuerung von Relationen (3) speicherorganisation ::= [tablespace tablespace ] [pctfree wert ] [pctused wert ] [storage -klausel ] Seitenkopf Verzeichnis der vertretenen Relationen und der Slotnummern der Tupel pctfree : Vorzuhaltende Reserve für Datensatzvergrößerungen (Standard 10%). pctused : Falls Reserve erreicht wurde, Freiraum, ab dem wieder eingefügt werden darf (Standard 40%). Zuordnung an Tablespace

34 34 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuerung von Relationen (4) storage -klausel ::= storage ( [initial wert [K|M]] [next wert [K|M]] [pctincrease wert ] [minextents wert ] [maxextents wert ] ) Initialgröße (1. Extent) Größe aller weiteren Extents (fest oder prozentual wachsend) Mindest- und Höchstzahl der Extents Bei geschickter Wahl lässt sich der Fragmentierung vorbeugen!

35 35 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Wie bei den Relationen selbst (eigenes Segment!). Aber: Es wird empfohlen, eine Relation und ihre Indexe in verschiedenen Tablespaces abzulegen. Einrichten von B*-Bäumen (1) create [unique] index index on relation ( attribut [asc|desc],..., attribut [asc|desc]) [ speicherorganisation ] [compress wert ] Beachte auch: create table relation ( attributvereinbarung,..., attributvereinbarung )... unique( attribut,..., attribut ) primary key( attribut,..., attribut ) oder innerhalb attributvereinbarung : unique primary key Index auf der Attributkombination der angegebenen Relation Bei mehreren Attributen kann die Wiederholung gleicher Präfixe (der Länge anzahl) in den Blättern vermieden werden. Automatisches Anlegen eines Primärindex (bei nicht auf den dort zugelassenen NULL-Werten)

36 36 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von B*-Bäumen (2) create table relation ( attributvereinbarung,..., attributvereinbarung )..... primary key vereinbart..... [ speicherorganisation |organization -klausel |cluster -klausel ] organization -klausel ::= organization index [ speicherorganisation 1 ] [compress wert ] [pcthreshold wert ] [ [including attribut ] overflow [ speicherorganisation 2 ] ] Automatisches Anlegen eines Clusterindex über dem Primärschlüssel Um die Tiefe eines Baums nicht zu sehr ansteigen zu lassen, können Attribute in einen Überlaufbereich ausgelagert werden. Klauseln geben an, ab welchem Attribut, und wie der Überlaufbereich organisiert werden soll. wie zuvor

37 37 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Ballung (1) create cluster cluster ( attribut,..., attribut ) [index] [size wert [K|M]] [ speicherorganisation ] create table relation ( attributvereinbarung,..., attributvereinbarung ) [ speicherorganisation |organization -klausel |cluster -klausel ] cluster -klausel ::= cluster( attribut,..., attribut ) wie zuvor, insbesondere Zuordnung zu einem Tablespace Attribute, nach denen geballt werden soll Platzplanung für eine Ballungseinheit Zuordnung einer Relation zu einem Cluster, Attribute müssen sich entsprechen Nutzen: Gemeinsames Ballen zweier Relationen zur Join-Unterstützung: Statische Partitionierung für letzte Phase à la Grace-Hash-Join. Einzelne Relation: Schneller Fremdschlüsselzugriff

38 38 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Ballung (2) create cluster cluster ( attribut,..., attribut ) [index] [size wert [K|M]] [ speicherorganisation ] create [unique] index index on cluster cluster [ speicherorganisation ] Auf einem Cluster kann soll ein Index angelegt werden Vereinbarung dieses Index wie für Indexe üblich

39 39 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Keine Angabe: Systemdefinierte Hashfunktion über die Clusterattribute. Einzelattribut: Attributwert bestimmt Hashwert. Ausdruck: Eigene Hashfunktion. Hashing create cluster cluster ( attribut,..., attribut ) hashkeys wert [hash is attribut | ausdruck ] [size wert [K|M]] [ speicherorganisation ] Größe N des Hashbereichs Statisches Hashing Platzplanung für eine Ballungseinheit

40 40 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Horizontale Fragmentierung sehr großer Relationen Partitionen können verschiedenen Tablespaces zugeordnet werden, damit ist auch Ablage auf verschiedenen Festplatten gegeben. Vorteile: Bei der Anfrageverarbeitung muss nicht immer auf die gesamte Relation zugegriffen werden. Bei Ablage auf verschiedenen Festplatten ist ein paralleler Scan möglich. Jede Partition bildet eine eigene Verwaltungseinheit, so dass sich die Administration, vor allem auch die Recovery vereinfacht. Partitionieren (1)

41 41 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Bereichspartionierung: create table relation ( attributvereinbarung,..., attributvereinbarung ) partition by range ( attribut ) (partition partition1 values less than wert1 tablespace name1, partition partition2 values less than wert2 tablespace name2,... ) Partionierung über Wertelisten partition by list Hash-Partionierung partition by hash Partitionieren (2)

42 42 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Im Datenbankkatalog werden Informationen und Statistiken zu den Datenbankobjekten geführt: TABLES : Für Tabellen Tupelzahl ( num_rows ), Zahl der belegten Seiten ( num_blocks ), durchschnittl. Tupellänge ( avg_row_len ). TAB_COL_STATISTICS : Für Spalten Anzahl der verschiedenen Werte ( num_distinct ), Anzahl der Nullwerte ( num_nulls ), Anzahl der Unterteilungen im Histogramm ( num_buckets ). INDEXES : Für Indexe Zahl der Blattseiten ( leaf_blocks ), Indexhöhe ( blevel ), Ballungsfaktor ( clustering_factor ). Statistiken (1)

43 43 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Berechnung der Statistiken ist aufwendig, beeinträchtigt den laufenden Betrieb und unterliegt daher der Kontrolle des DBA: Exakte Histogramm-Berechnung: analyze table relation compute statistics for columns attribut,..., attribut size wert Stichprobenverfahren: analyze table relation estimate statistics sample wert percent Statistiken (2)

44 44 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuerung für eine Sitzung: alter session set optimizer_goal = optimierermodus Optimierermodus ::= choose Wahl der Optimierung durch das System, Standard ist die kostenbasierter Optimierung all_rows Durchsatz-Optimierung (Minimierung der Zeit für das Gesamtergebnis) first_rows Antwortzeit-Optimierung (Minimierung der Zeit für das erste Ergebnis) rule Beschränkung auf äquivalenzregel-basierte Optimierung Steuerung des Optimierers (1)

45 45 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Steuerung für eine Anfrage: select /*+ Hinweis-Liste */ attributliste from... Hinweis-Liste ::= Optimierermodus: all_rows oder first_rows Algorithmenwahl: z.B. für Verbindung use_nl oder use_merge oder use_hash Indexnutzung: Verwendung von Index ( index ) oder Nicht- Verwendung und stattdessen voller Scan ( full ) Join-Reihenfolge: ordered zum Befolgen der Vorgabe in der from -Klausel Parallelisierungsgrad Steuerung des Optimierers (2)

46 46 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Anzeige von Anfrageplänen Geschätzte Kosten von Oracle

47 47 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Kapitel 11.4 Microsoft SQL Server

48 48 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Physische Datenbankstruktur (1) Phys. Block Primärdatei Sekundärdatei1 Log. Block Sekundärdatei2 Log. Block Logdatei 1 Log. Block Daten- basis J Daten- basis K Daten- basis I Log. Block Primär- Datei- gruppe Sekundär -Datei- gruppe

49 49 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Nutzen von Sekundär- Dateigruppen: Kontrollierte Recovery u. Plattenzuordn. Nutzen mehrerer dann kleinerer Dateien: Leichteres Verschieben zwischen Festplatten Physische Datenbankstruktur (2) Phys. Block Primärdatei Sekundärdatei1 Log. Block Sekundärdatei2 Log. Block Logdatei 1 Log. Block Daten- basis J Daten- basis K Daten- basis I Log. Block Primär- Datei- gruppe Sekundär -Datei- gruppe Dateiverzeichnis und Nutzdaten Nutzdaten( optional) automatisch erzeugt

50 50 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von Datenbasen (1) create database archive on primary (name = arch1, filename =..., size = 100MB, maxsize = 200, filegrowth = 20) (name = arch2, filename =..., size = 100MB, maxsize = 200, filegrowth = 20, autoshrink) log on (name = archlog1, filename =..., size = 100MB, maxsize = 200, filegrowth = 20) Primär- datei Primär- Dateigruppe Sekundär- datei Logdatei

51 51 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von Datenbasen (2) create database archive on primary (name = arch1, filename =..., size = 100MB, maxsize = 300MB, filegrowth = 20MB) (name = arch2, filename =..., size = 100MB, maxsize = 200MB, filegrowth = 15%, autoshrink) log on (name = archlog1, filename =..., size = 100MB, maxsize = 200MB, filegrowth = 20MB) Anfangsgröße Automatische Erweiterung um filegrowth (oder 10%) bis zu maxsize (oder unbegrenzt) Automatisches Schrumpfen auf eine Reserve von 25% mit Speicherplatzfreigabe Wenn diese Klausel fehlt, automatisches Einrichten mit 25% der Summe aller Dateigrößen Nachträgliche Anpassungen über alter database

52 52 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Speicherorganisation (1) Daten- basis J Daten- basis K Daten- basis I Relation 1 Relation n Index 1 Index m Extent mit 8 Seiten à 8 kB Uniform extent: Extent wird 1 Relation oder 1 Index zugewiesen Mixed extent: Extent wird mehreren kleinen Relationen und/oder Indexen zugewiesen Unser Segment-Konzept existiert nicht direkt, die Datenbasis ähnelt ihm aber.

53 53 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Fortschreiben aller Statistiken bei Änderungen Speicherorganisation (2) Optionen für die Performanzsteuerung alter database set option option ::= offline|online read_only|read_write auto_create_statistics auto_shrink auto_update_statistics recovery { full|bulk_logged|simple } Optimierer sammelt Statistiken über die in der where-Klausel aufgeführten Attribute Periodisches Schrumpfen. Bei Log-Dateien werden zusätzliche Sicherungsmaßnahmen ergriffen Rein transaktionales Logging Vereinfachtes Logging für Massendatenbehandlung Logging für transaktionale Recovery und für Archivierung (Backup)

54 54 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 FreispeichertabelleseitenNutzdatenseiten Speicherorganisation (3) Seitenorganisation ähnlich wie in Kapitel 5 behandelt, keine Parametereinstellungen! Seitenkopf Verwaltungsdaten Slotnummern der Tupel

55 55 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von B*-Bäumen (1) create [unique] [clustered|nonclustered] index index on relation ( attribut [asc|desc],..., attribut [asc|desc]) [include attributliste ] [with] [fillfactor = n ] [[,] pad_index] [[,] ignore_dup_key] [[,] drop_existing] [[,] online = [on|off]] [[,] statistics_norecompute] [on dateigruppe ]

56 56 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von B*-Bäumen (2) create [unique] [clustered|nonclustered] index index on relation ( attribut [asc|desc],..., attribut [asc|desc]) [include attributliste ] [with] [fillfactor = n ] [[,] pad_index] [[,] ignore_dup_key] [[,] drop_existing] [[,] online = [on|off]] [[,] statistics_norecompute] [on dateigruppe ] Clusterindex, geballte Speicherung der Tupel Primär-/Sekundärindex, unkontrollierbare Speicherung der Tupel Index auf der Attributkombination der angegebenen Relation Falls nonclustered : Zusätzliche Attribute in den Blättern Ballung von Teilsätzen

57 57 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von B*-Bäumen (3) create [unique] [clustered|nonclustered] index index on relation ( attribut [asc|desc],..., attribut [asc|desc]) [include attributliste ] [with] [fillfactor = n ] [[,] pad_index] [[,] ignore_dup_key] [[,] drop_existing] [[,] online = [on|off]] [[,] statistics_norecompute] [on dateigruppe ] Verstoß führt zu Transaktionsabbruch Platzreserve in den Zwischenknoten Platzreserve in den Blattseiten Vorhandener Index soll nicht fortgeschrieben, sondern ersetzt werden Bei Verstoß wird Einfügeoperation ignoriert

58 58 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von B*-Bäumen (4) create [unique] [clustered|nonclustered] index index on relation ( attribut [asc|desc],..., attribut [asc|desc]) [include attributliste ] [with] [fillfactor = n ] [[,] pad_index] [[,] ignore_dup_key] [[,] drop_existing] [[,] online = [on|off]] [[,] statistics_norecompute] [on dateigruppe ] Automatisches Fortschreiben der Indexstatistiken wird unterbunden Hinweis zum Speicherort

59 59 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von B*-Bäumen (5) Index auch wie folgt: create table relation unique [clustered|nonclustered] ( attribut,..., attribut ) oder create table relation primary key [clustered|nonclustered] ( attribut,..., attribut ) Nullwerte zugelassen aber ignoriert Automatisches Anlegen eines Primärindex, aber Wahl ob mit Ballung der Tupel oder nicht Nullwerte nicht zugelassen

60 60 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Einrichten von B*-Bäumen (6) alter table relation mit Optionen rebuild reorganize disable Neuaufbau ohne vorheriges Löschen, z.B. wegen Fragmentierung Blattebene so organisieren, dass physikalische und logische Ordnung übereinstimmen Deaktiviert Index. Reaktivierung durch rebuild Es gibt Prozeduren bzw. Kommandos, mit denen man sich detaillierte Informationen über Speicherung und Leistungsverhalten von Indexen beschaffen und auch Einstellungen vornehmen kann.

61 61 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Horizontale Fragmentierung sehr großer Relationen Partitionen können verschiedenen Dateigruppen zugeordnet werden, damit ist auch Ablage auf verschiedenen Festplatten gegeben. Eine Dateigruppe kann Partitionen mehrerer Relationen aufnehmen. Vorteile: Bei der Anfrageverarbeitung muss nicht immer auf die gesamte Relation zugegriffen werden. Bei Ablage auf verschiedenen Festplatten ist ein paralleler Scan möglich. Jede Partition bildet eine eigene Verwaltungseinheit, so dass sich die Administration, vor allem auch die Recovery vereinfacht. Partitionieren (1)

62 62 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Partitionieren (2) Schritt 1: Erstelle Dateigruppen für die Partitionierung: create database test_database on primary (name = MyDB_Primary, filename =..., size = 2000, maxsize = 5000, filegrowth = 1), filegroup MyDB_FG1 (name = FirstFileGroup, filename =..., size = 1000, maxsize = 2500, filegrowth = 1), filegroup MyDB_FG2 (name = SecondFileGroup, filename =..., size = 1000, maxsize = 2500, filegrowth = 1)

63 63 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Partitionieren (3) Schritt 2: Erstelle Partitionierungsfunktion: create partition function functname ( pametertype ) as range [left|right] for values ( value,..., value ) Beispiel: create partition function MyRangePF1(int) as range left for values (500000) Intervalle für die Partitionen Interpretation der Grenzwerte 2 Intervalle < , )

64 64 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Partitionieren (4) Schritt 3: Ordne Partitionierungsfunktion den Dateigruppen zu (Partitionierungsschema): use test_database create partition scheme MyRangePS1 as partition MyRangePF1 to (MyDB_FG1, MyDB_FG1) Partitionierungsfunktion mit 2 Intervallen 2 Dateigruppen

65 65 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Partitionieren (5) Schritt 4: Partitioniere Relationen und Indexe: create table bestellung (bestell_nr integer not null,...,) on MyRangePS1(bestell_nr) create unique clustered index CI_orders on bestellung (bestell_nr) on MyRangePS1(bestell_nr) Partitionierungsschema Parameter der Partitionierungsfunktion Man kann hier übrigens auch eine einzige Dateigruppe angeben

66 66 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Interaktiv: Management Studio. Leistungsüberwachung (1) Definiere oder entferne Indexe Stelle Anfrage Zeige Ausführungsplan an Bestimme Kosten

67 67 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Systemprozeduren: sp_helpindex sp_monitor sp_spaceused dbcc-Kommando: show_statistics memusage Leistungsüberwachung (2) Informationen über Indexe Statistiken zum Zeitverbrauch Belegter Plattenspeicher f. Daten/Indexe Ressourcenverbrauch gezielt für Relationen/Indexe Angaben zum Arbeitsspeicher

68 68 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Systemmonitor: Statistiken zum phys. Seitenreferenzstring Systemweiter Nutzungsgrad des Arbeitsspeichers Full Scans pro Zeiteinheit Statistiken zum Verhältnis log. Seitenreferenzstring zu phys. Seitenreferenzstring Transaktionsrate Leistungsüberwachung (3)

69 69 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 SQL-Steuerung: update_statistics relation [ index ] schreibt automatisch die Werteverteilung für den angegebenen bzw. alle Indexe der Relation fort. set liste-von-optionen [on|off] mit liste-von-optionen : showplan noexec forceplan statistics i/o statistics time Leistungsüberwachung (4) Anzeige Ausführungsplan Nur Übersetzung (nützlich mit showplan ) Join-Reihenfolge gemäß from-Klausel erzwungen Angaben zum phys. Seitenreferenzstring Übersetzungs- und Ausführungszeit

70 70 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Index-Hinweise: select * from arbeiten with (index(x_einst_dat) where einst_dat = select * from arbeiten with (index(0) where einst_dat = Steuerung des Optimierers (1) Optimierer wird zur Nutzung des Index gezwungen Optimierer wird die Nutzung jeglichen Index verboten

71 71 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Vorschreiben des Join- Verfahrens: loop join hash join merge join Join-Reihenfolge gemäß from-Klausel erzwungen Join-Hinweise: select m_name, m_vorname from arbeiten join mitarbeiter on mitarbeiter.m_nr = arbeiten.m_nr where arbeiten.aufgabe = Projektleiter option (force order) select m_name, m_vorname from arbeiten join mitarbeiter on mitarbeiter.m_nr = arbeiten.m_nr option ( join-Verfahren ) Steuerung des Optimierers (2) Auch: select m_name, m_vorname from arbeiten hash join mitarbeiter on mitarbeiter.m_nr = arbeiten.m_nr

72 72 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Gruppierungs-Hinweise: select einst_dat, count(*) from arbeiten group by einst_dat option (hash group) Steuerung des Optimierers (3)

73 73 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Optimierungsratgeber: Dialog-Programm für den Datenbankadministrator, um sich mit dem Optimierer über Empfehlungen abzusprechen mit dem Ziel optimalen Ressourceneinsatzes. Physische Strukturen: Auswahl unter den vorrätigen Verfahren (vor allem Indextechniken) Rückkopplung: Analyse der Nutzung der bisher gewählten Verfahren. Zu verwendende Partitionierungsstrategie Nach einem Tuning-Prozess beizubehaltende physische Strukturen Steuerung des Optimierers (4) Der Ratgeber bietet ein Reihe von Berichten über die Verwendung der physischen Strukturen.

74 74 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Kapitel 11.5 DB2 Universal Database - Blick in die Zukunft

75 75 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Selbstorganisation As the cost of both hardware and software falls due to technological advancements and economies of scale, the cost of ownership for database applications is increasingly dominated by the cost of people to manage them. Databases are growing rapidly in scale and complexity, while skilled database administrators (DBAs) are becoming rarer and more expensive. (Lightstone, Lohman, Zilio, SIGMOD Record 31:3, Sep 2002) Self-managing (autonomic) technology: Autonomic systems are capable of running themselves, adjusting to varying circumstances, and preparing their resources to handle most efficiently the workloads we put on them. These systems must anticipate needs and allow users to concentrate on what they want to accomplish rather than figuring how to rig the computing system to get them there. (Paul Horn, IBM)

76 76 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Verantwortlichkeiten Planung der Anforderungen und der Investitionen Entwurf der Datenbasis und der DB- Verwaltung Erzeugen und Tuning der Datenbasis Pflege, Wartung und Administration Change management Zeit

77 77 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Verantwortlichkeiten Planung der Anforderungen und der Investitionen Entwurf der Datenbasis und der DB- Verwaltung Erzeugen und Tuning der Datenbasis Pflege, Wartung und Administration Change management Zeit Bestimmen der Leistungs- und Speicheranforderungen, Wahl geeigneter Produkte Logischer und physischer Entwurf: Relationen, Integritäten, Indexe, Materialisierungen, Verteilung, Sicherheit, Strategien für Zuverlässigkeit und Recovery, Benutzerverwaltung Vorbereiten des Produktivstarts mit Testen, Validieren, Einstellen und Integration mit anderen Systemen und Prozessen

78 78 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Verantwortlichkeiten Planung der Anforderungen und der Investitionen Entwurf der Datenbasis und der DB- Verwaltung Erzeugen und Tuning der Datenbasis Pflege, Wartung und Administration Change management Zeit Veränderungen auf der Anwendungsseite, die einer Anpassung des logischen und physischen Entwurfs bedürfen Produktion: Monitoring, Anfrage-Tuning, Statistiken, Datenreorganisation, Anpassung an neue Bedürfnisse, Recovery-Verwaltung

79 79 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Werkzeuge der Selbstorgaisation Planung der Anforderungen und der Investitionen Entwurf der Datenbasis und der DB- Verwaltung Erzeugen und Tuning der Datenbasis Pflege, Wartung und Administration Change management Zeit Konfigurations-Berater Automatische Index- Reorganisation Anfrageoptimierer Entwurfs-Berater Prüfung der physischen Konsistenz Query Patroller

80 80 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Ziel: Möglichst gute Systemleistung durch Setzen von rd. 35 Speicherparametern unter geringst möglichen Ansprüchen an die DBA-Kompetenz. Aufgabe: Konfigurieren der wichtigen Speicherbereiche: Speicherzuweisung an Datenbankoperationen wie Pufferung, Sortieren, Netzverbindungen. Setzen von Betriebsparametern wie Zahl der Server- Agenten, Häufigkeit der Operationen rund um die Recovery. Konfigurations-Berater (1)

81 81 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Vorgehen: Abschätzungen auf der Grundlage eines Systemmodells: Automatische Erfassung der Systemumgebung, z.B. RAM, Plattenzahl, CPU-Zahl. Messung von Betriebskennzahlen. Ermittlung der Konfigurationsparameter aus den gewichteten Kennzahlen. Randbedingen wie Nutzerprofil und Gesamtkapazitäten. Konfigurations-Berater (2)

82 82 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Ziel: Bestimmen einer günstigen Index-Menge auf der Grundlage von Nutzungsprofilen. Aufgabe: Evaluieren vorhandener Indexe (EVALUATE INDEXES). Vorschlagen neuer Indexe (RECOMMEND INDEXES). Entwurfs-Berater (1)

83 83 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Vorgehen: Abschätzungen unter Verwendung des Anfrageoptimierers: Einbezug vorhandener (realer) und ggf. vorzuschlagender (virtueller) Indexe. Herleitung von Statistiken für die virtuellen Indexe. Entwicklung von Auswertungsplänen für die diversen Anfragen im Profil auf der Grundlage aller Indexe unter Abschätzung der Laufzeit- und Speicherkosten. Empfehlungen zu den einzurichtenden und zu löschenden Indexen. Empfehlungen zu Fragmentierungen und Partitionierungen der Relationen in Abhängigkeit vom Parallelitätsgrad. Entwurfs-Berater (2)

84 84 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Ziel: Auftragseinplanung auf der Grundlage vorgegebener Strategien. Aufgabe: Entscheidungen über Annahme, Priorisierung und Terminierung von Anfragen. Dabei Vermeiden von Lastspitzen, Blockieren durch Langläufer und Ressourcenverknappung. Query Patroller (1)

85 85 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Vorgehen: Kostenabschätzung für jede Anfrage unter Verwendung der EXPLAIN Funktion. Bei Kostenüberschreitung Zurückhalten mit Benutzermitteilung und manueller Disposition. Andernfalls Einlasten unter Beachtung der aktuellen Anfragelast, der aktuellen Gesamtkosten, der Prioritäten, der Server-Zahl, der Anfragen pro Benutzer. Abschließend Kostenerfassung und -zurechnung, Berichtswesen. Query Patroller (2)

86 86 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Ziel: Schutz der Datenbasis vor unvollständiger E/A. Vorgehen: Patentierte Technik für die Konsistenzprüfung beim Einlesen von Hintergrundspeicher. Prüfung der physischen Konsistenz

87 87 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Ziel: Defragmentierung und Füllgrad-Steigerung von Indexen. Vorgehen: Füllgrad-Analyse. Zusammenlegen dünn belegter Seiten. Neuorganisation des Baumes. Automatische Index-Reorganisation

88 88 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Vorgehen: Klassische Schritte mit Standardisierung der SQL-Anfrage. Logische Anfrageoptimierung. Physische Anfrageoptimierung. Einbezug der Indexe. Einbezug materialisierter Sichten. Sammlung der Statistiken. Berücksichtigung der Ausführungsumgebung: CPU- Geschwindigkeit, Hintergrundspeicher, Parallelisierungsgrad und –art, Zahl der Puffergruppen, Pufferdynamik. Anfrage-Optimierer (1)

89 89 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Optimierungsziele: Vorrangig: Minimaler Ressourcenverbrauch (Durchsatz). Bei Parallelisierung: Antwortzeitminimierung. Optimierungstechnik: Im Normalfall: Dynamische Programmierung. Bei komplexen Anfragen: Greedy-Suche. Anfrage-Optimierer (2)


Herunterladen ppt "Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 11 Kapitel 11 Tuning relationaler Datenbanken."

Ähnliche Präsentationen


Google-Anzeigen