Tuning relationaler Datenbanken Kapitel 11 Tuning relationaler Datenbanken

Abhängigkeiten Optimierte Anfragebearbeitung (Kapitel 10) Optimale Auswahl vorhandener Techniken Entwicklung und Pflege (Kapitel 2-9) Tuning als Administration Bevorratung nach Schichten Auswahl und Parametrierung Zugriffs-profile

Grundsätze (1) Nach Dennis Shasha: Database Tuning: A Principled Approach. Prentice-Hall, 1992. 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.

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.

Kapitel 11.1 Messen

Benchmark (1) Optimierte Anfragebearbeitung (Kapitel 10) Benchmark: Optimale Auswahl vorhandener Techniken Benchmark: Standardisierte Messlast Entwicklung und Pflege (Kapitel 2-9) Tuning als Administration Bevorratung nach Schichten Auswahl und Parametrierung Zugriffs-profile

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

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

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!

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!

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

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

Kapitel 11.2 Steuern

Steuermöglichkeiten (1) Mengenorientiertes Datenmodell Anfragebearbeitung Satzorientiertes Datenmodell 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) Satz- u. Satzmengenverwaltung Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Dateien Dateiverwaltung Geräteschnittstelle

Steuermöglichkeiten (2) Mengenorientiertes Datenmodell Anfragebearbeitung 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 Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Dateien Dateiverwaltung Geräteschnittstelle

Steuermöglichkeiten (3) Mengenorientiertes Datenmodell Anfragebearbeitung Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung 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 Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Dateien Dateiverwaltung Geräteschnittstelle

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

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

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

Steuermöglichkeiten (7) Mengenorientiertes Datenmodell 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, NF2, XML Anfragebearbeitung Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Verfahren/Quellen für die Selektivitätsabschätzung Kostenmodelle Dateien Dateiverwaltung Geräteschnittstelle

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

Kapitel 11.3 Oracle 9i

Speicherorganisation (1) Table-space I Daten-block 1 Basis-Extent Daten-block 2 Datei 1 Table-space J Phys.Block Log. Block Extent Table R Datensegm. r ... Datei 2 Extent Index R1 Indexsegm. r1 Log. Block ... Index R2 Indexsegm. r2 Datei 3 ... Log. Block ... Table S Datensegm. s Phys.Block Datei 1 Index S1 Indexsegm. s1 Log. Block Table-space K

Speicherorganisation (2) Physische Datenbankstrukturen Logische Datenbankstrukturen Table-space I Daten-block 1 Basis-Extent Daten-block 2 Datei 1 Table-space J Phys.Block Log. Block Extent Table R Datensegm. r ... Datei 2 Extent Index R1 Indexsegm. r1 Log. Block ... Index R2 Indexsegm. r2 Datei 3 ... Log. Block ... Table S Datensegm. s Phys.Block Datei 1 Index S1 Indexsegm. s1 Log. Block Table-space K

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

Vorbemerkung 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.

Einrichten von Dateien (1) Table-space I Daten-block 1 Basis-Extent Daten-block 2 Datei 1 Table-space J Phys.Block Log. Block Extent Table R Datensegm. r ... Datei 2 Extent Index R1 Indexsegm. r1 Log. Block ... Index R2 Indexsegm. r2 Datei 3 ... Log. Block ... Table S Datensegm. s Phys.Block Datei 1 Index S1 Indexsegm. s1 Log. Block Table-space K

Einrichten von Dateien (2) 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. create database datenbank datafile dateiangabe,..., dateiangabe dateiangabe hat das Aussehen ’dateipfad‘ [size wert [K|M]] [autoextend off] oder [autoextend on [next wert [K|M]] [maxsize wert [K|M]] 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.

Einrichten von Segmenten (1) Table-space I Daten-block 1 Basis-Extent Daten-block 2 Datei 1 Table-space J Phys.Block Log. Block Extent Table R Datensegm. r ... Datei 2 Extent Index R1 Indexsegm. r1 Log. Block ... Index R2 Indexsegm. r2 Datei 3 ... Log. Block ... Table S Datensegm. s Phys.Block Datei 1 Index S1 Indexsegm. s1 Log. Block Table-space K

Einrichten von Segmenten (2) 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. 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] Bei offline Transaktionsschutz: normal führt zu force aller Dateien, temporary zu force der online-Dateien, immediate bleibt bei noforce.

Steuerung von Relationen (1) Table-space I Daten-block 1 Basis-Extent Daten-block 2 Datei 1 Table-space J Phys.Block Log. Block Extent Table R Datensegm. r ... Datei 2 Extent Index R1 Indexsegm. r1 Log. Block ... Index R2 Indexsegm. r2 Datei 3 ... Log. Block ... Table S Datensegm. s Phys.Block Datei 1 Index S1 Indexsegm. s1 Log. Block Table-space K

Steuerung von Relationen (2) create table relation (attributvereinbarung,..., attributvereinbarung) [speicherorganisation|organization-klausel|cluster-klausel] Speicherung durch Index bestimmt Speicherung sonst

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

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!

Einrichten von B*-Bäumen (1) Index auf der Attributkombination der angegebenen Relation 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 Bei mehreren Attributen kann die Wiederholung gleicher Präfixe (der Länge anzahl) in den Blättern vermieden werden. Wie bei den Relationen selbst (eigenes Segment!). Aber: Es wird empfohlen, eine Relation und ihre Indexe in verschiedenen Tablespaces abzulegen. Automatisches Anlegen eines Primärindex (bei nicht auf den dort zugelassenen NULL-Werten)

Einrichten von B*-Bäumen (2) Automatisches Anlegen eines Clusterindex über dem Primärschlüssel create table relation (attributvereinbarung,..., attributvereinbarung) ..... primary key vereinbart ..... [speicherorganisation|organization-klausel|cluster-klausel] organization-klausel ::= organization index [speicherorganisation1] [compress wert] [pcthreshold wert] [ [including attribut ] overflow [speicherorganisation2] ] wie zuvor 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.

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) Attribute, nach denen geballt werden soll Platzplanung für eine Ballungseinheit wie zuvor, insbesondere Zuordnung zu einem Tablespace 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

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

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

Partitionieren (1) 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 (2) 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

Statistiken (1) 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 (2) 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: estimate statistics sample wert percent

Steuerung des Optimierers (1) 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 (2) 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

Anzeige von Anfrageplänen Geschätzte Kosten von Oracle

Kapitel 11.4 Microsoft SQL Server

Physische Datenbankstruktur (1) Daten-basis I Primär-Datei-gruppe Primärdatei Daten-basis J Phys.Block Log. Block Sekundärdatei1 Log. Block Sekundär-Datei-gruppe 1 Sekundärdatei2 Log. Block ... Phys.Block Logdatei 1 Log. Block ... ... Daten-basis K

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

Einrichten von Datenbasen (1) create database archive on primary (name = arch1, filename = ’...‘, size = 100MB, maxsize = 200, filegrowth = 20) (name = arch2, filegrowth = 20, autoshrink) log on (name = archlog1, Primär-datei Primär- Dateigruppe Sekundär-datei Logdatei

Einrichten von Datenbasen (2) create database archive on primary (name = arch1, filename = ’...‘, size = 100MB, maxsize = 300MB, filegrowth = 20MB) (name = arch2, maxsize = 200MB, filegrowth = 15%, autoshrink) log on (name = archlog1, 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

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

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 Logging für transaktionale Recovery und für Archivierung (Backup) Fortschreiben aller Statistiken bei Änderungen Vereinfachtes Logging für Massendatenbehandlung Rein transaktionales Logging

Speicherorganisation (3) Freispeichertabelleseiten Nutzdatenseiten 25 60 15 20 05 ... ... 320 ••• ••• Seitenkopf 100 3600 Verwaltungsdaten Seitenorganisation ähnlich wie in Kapitel 5 behandelt, keine Parametereinstellungen! Slotnummern der Tupel

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]

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] Primär-/Sekundärindex, unkontrollierbare Speicherung der Tupel Clusterindex, geballte Speicherung der Tupel Index auf der Attributkombination der angegebenen Relation Falls nonclustered: Zusätzliche Attribute in den Blättern  Ballung von Teilsätzen

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 Blattseiten Platzreserve in den Zwischenknoten Bei Verstoß wird Einfügeoperation ignoriert Vorhandener Index soll nicht fortgeschrieben, sondern ersetzt werden

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

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

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.

Partitionieren (1) 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 (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‘, size = 1000, maxsize = 2500, filegrowth = 1), filegroup MyDB_FG2 (name = ’SecondFileGroup‘, size = 1000, maxsize = 2500, filegrowth = 1)

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) Interpretation der Grenzwerte Intervalle für die Partitionen 2 Intervalle <500.000,  500.000)

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

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) Partitionierungsschema Parameter der Partitionierungsfunktion Man kann hier übrigens auch eine einzige Dateigruppe angeben

Leistungsüberwachung (1) Interaktiv: Management Studio. Definiere oder entferne Indexe Bestimme Kosten Stelle Anfrage Zeige Ausführungsplan an

Leistungsüberwachung (2) Systemprozeduren: sp_helpindex sp_monitor sp_spaceused dbcc-Kommando: show_statistics memusage Informationen über Indexe Statistiken zum Zeitverbrauch Belegter Plattenspeicher f. Daten/Indexe Ressourcenverbrauch gezielt für Relationen/Indexe Angaben zum Arbeitsspeicher

Leistungsüberwachung (3) 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 (4) 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 Anzeige Ausführungsplan Nur Übersetzung (nützlich mit showplan) Join-Reihenfolge gemäß from-Klausel erzwungen Angaben zum phys. Seitenreferenzstring Übersetzungs- und Ausführungszeit

Steuerung des Optimierers (1) Index-Hinweise: select * from arbeiten with (index(x_einst_dat) where einst_dat = ’01.01.2007‘ from arbeiten with (index(0) Optimierer wird zur Nutzung des Index gezwungen Optimierer wird die Nutzung jeglichen Index verboten

Steuerung des Optimierers (2) 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) option (join-Verfahren) Join-Reihenfolge gemäß from-Klausel erzwungen Vorschreiben des Join-Verfahrens: loop join hash join merge join Auch: select m_name, m_vorname from arbeiten hash join mitarbeiter on mitarbeiter.m_nr = arbeiten.m_nr

Steuerung des Optimierers (3) Gruppierungs-Hinweise: select einst_dat, count(*) from arbeiten group by einst_dat option (hash group)

Steuerung des Optimierers (4) 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 Der Ratgeber bietet ein Reihe von Berichten über die Verwendung der physischen Strukturen.

Kapitel 11.5 DB2 Universal Database - Blick in die Zukunft

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)

Verantwortlichkeiten Zeit Planung der Anforderungen und der Investitionen Entwurf der Datenbasis und der DB-Verwaltung Erzeugen und Tuning der Datenbasis Pflege, Wartung und Administration Change management

Verantwortlichkeiten Zeit Planung der Anforderungen und der Investitionen Entwurf der Datenbasis und der DB-Verwaltung Erzeugen und Tuning der Datenbasis Pflege, Wartung und Administration Change management Vorbereiten des Produktivstarts mit Testen, Validieren, Einstellen und Integration mit anderen Systemen und Prozessen 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

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

Werkzeuge der Selbstorgaisation Anfrageoptimierer Zeit Planung der Anforderungen und der Investitionen Entwurf der Datenbasis und der DB-Verwaltung Erzeugen und Tuning der Datenbasis Pflege, Wartung und Administration Change management Konfigurations-Berater Automatische Index-Reorganisation Entwurfs-Berater Query Patroller Prüfung der physischen Konsistenz

Konfigurations-Berater (1) 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 (2) 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.

Entwurfs-Berater (1) 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 (2) 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.

Query Patroller (1) 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 (2) 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.

Prüfung der physischen Konsistenz Ziel: Schutz der Datenbasis vor unvollständiger E/A. Vorgehen: Patentierte Technik für die Konsistenzprüfung beim Einlesen von Hintergrundspeicher.

Automatische Index-Reorganisation Ziel: Defragmentierung und Füllgrad-Steigerung von Indexen. Vorgehen: Füllgrad-Analyse. Zusammenlegen dünn belegter Seiten. Neuorganisation des Baumes.

Anfrage-Optimierer (1) 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 (2) Optimierungsziele: Vorrangig: Minimaler Ressourcenverbrauch (Durchsatz). Bei Parallelisierung: Antwortzeitminimierung. Optimierungstechnik: Im Normalfall: Dynamische Programmierung. Bei komplexen Anfragen: Greedy-Suche.