Benedikt Terschluse ORACLE 10g the self-managing database Friedrich-Schiller-Universität Jena Lehrstuhl für Datenbanken und Informationssysteme Seminar: Aspekte und Werkzeuge der DB-Administration und deren Automatisierung

Benedikt Terschluse Gliederung: 1. Einleitung 2. Funktionalität von ORACLE Database 10g 2.1 self-configuring 2.2 self-optimizing 2.3 self-organizing 2.4 self-inspecting 2.5 self-protecting 2.6 self-healing 3. Vergleich zur Konkurrenz 4. Fazit Gliederung

Benedikt Terschluse 1. Einführung Die Firma ORACLE »gegründet 1977 in Kalifornien von Larry Ellison, Bob Miner und Ed Oates »CEO: Lawrence J. Ellison »heute rund Mitarbeiter weltweit Marktanteil von ORACLE liegt bei 41,3% Hauptkonkurrent ist IBM mit ähnlichem Marktanteil ORACLE Database 10gHier wird ORACLE Database 10g Release 2 betrachtet (von 2005) 1. Einführung

Benedikt Terschluse Analyse der Fähigkeiten von Database 10g in den Gebieten: Self-configuring: »Installation und Konfiguration Self-optimizing: »Probleme erkennen -> Performance verbessern Self-organizing: »gegebene Ressourcen geschickt verteilen Self-inspecting: »wann fällt welche workload an Self-protecting: »Sicherheitslücken erkennen Self-healing: »Fehler beheben können 1. Einführung

Benedikt Terschluse Gliederung: 1. Einleitung 2. Funktionalität von ORACLE Database 10g 2.1 self-configuring 2.2 self-optimizing 2.3 self-organizing 2.4 self-inspecting 2.5 self-protecting 2.6 self-healing 3. Vergleich zur Konkurrenz 4. Fazit Gliederung

Benedikt Terschluse 2. Funktionalität von ORACLE Database 10g 2.1 self-configuring schnellere Installation:schnellere Installation: »Server-Installation (1.5 GB) in 20 Minuten »Client Installation (80MB) in einer Minute einfache Konfiguration:einfache Konfiguration: »Database Creation Assistant (DBCA): leitet den DBA durch den Einrichtungsvorgang einfache Updates:einfache Updates: »Database Update Assistant (DBUA): leitet durch den Update-Vorgang. Für manuelle Updates: catupgrd.sql 2. Funktionalität von Database 10g 2.1 self-configuring

Benedikt Terschluse Automatic Shared (SGA) Memory Management: Normal muß der DBA für jede der folgenden Komponenten einzeln Speicher festlegen: shared pool (für die Ausführung von SQL und PL/SQL) java pool (java excecution state) large pool (für große Bedarfe wie recovery manager) buffer cache streams pool Jetzt nur noch den SGA-TARGET Parameter wählen. 2. Funktionalität von Database 10g 2.1 self-configuring

Benedikt Terschluse Abb1: SGA-TARGET auf 132 MB festgelegt aktuell wird der Speicher wie in der Tabelle dargestellt verteilt. Alternativ: View V$SGA_DYNAMIC_COMPONENTS 2. Funktionalität von Database 10g 2.1 self-configuring

Benedikt Terschluse Einschränkungen zur automatischen Verteilung: DBA kann Speicheruntergrenzen festlegen »Beispiel: –SGA_TARGET = 132 MB –SHARED_POOL_SIZE = 32 MB –DB_CACHE_SIZE = 20 MB –bleiben 80 MB zur automatischen Verteilung recycle buffer caches und additional buffer caches manuell festlegen »Speicher dafür bei automatischer Verteilung abziehen 2. Funktionalität von Database 10g 2.1 self-configuring

Benedikt Terschluse Vorteiledurch automatisches Speichermanagement: Vorteile durch automatisches Speichermanagement: Out-of-memory Fehler seltener deutliche Performanceverbesserung: »schnelle Anpassung an neue workload einfacher zu bedienen »nur ein Parameter muß festgelegt werden 2. Funktionalität von Database 10g 2.1 self-configuring

Benedikt Terschluse Zum Aktivieren des automatic memory managements im Enterprise Manager auf enable klicken oder in der Kommandozeile ALTER SYSTEM SET SGA_TARGET = „Größe des Speichers“ eingeben. Abb2: aktivieren des automatic shared managements 2. Funktionalität von Database 10g 2.1 self-configuring

Benedikt Terschluse SGA_TARGET kann zwischen SGA_MaxSize und Minimum des Speichers, der den einzelnen Komponenten zugeteilt wurde, gesetzt werden. Zur Hilfe kann man den SizeAdvisor befragen (siehe Abb3). Abb3: size advisor für den SGA_TARGET 2. Funktionalität von Database 10g 2.1 self-configuring

Benedikt Terschluse 2.2 self-optimizing Kernpunkt der Bemühungen des autonomic computing. Gegebene Ressourcen effektiv auslasten Anfragen tunen ORACLE Database 10g ORACLE Database 10g verwendet hier: automatic workload repositoryAWRautomatic workload repository (AWR): »sammelt Statistiken über die workload automatic database diagnostics monitorADDMautomatic database diagnostics monitor (ADDM): »erkennt wo Optimierungsbedarf besteht »optimiert selbst »oder leitet an „Spezialisten“ weiter (siehe Abb4) 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Abb4: die Optimierungsarchitektur 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Die automatic workload repository (AWR): läuft automatisch im Hintergrund Standardeinstellungen: alle 30 min. ein snapshot, Daten die älter als 7 Tage sind, werden gelöscht Einstellungen kann der DBA natürlich verändern DBA kann auch jederzeit selbst einen snapshot machen Gesammelte Statistiken sind Basis für Optimierungen im ADDM 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Der automatic database diagnostics monitor (ADDM): Ziel: Finde die Bereiche der Datenbank, welche den größten Ressourcenbedarf haben Ist die Stelle des Problems gefunden, wird nach den Ursachen gesucht ADDM gibt Vorschläge was man tun sollte und welchen „Experten“ man ggf. zu Rate ziehen sollte Im Enterprise Manager kann man durch intuitive Steuerung das Problem bis auf die Basis herunterbrechen genaueres in den folgenden screenshots Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Abb5: Im Enterprise Manager wird angezeigt, dass es 2 Probleme gibt, die das ADDM gefunden hat 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Abb6: Kurzbeschreibung der Probleme und Lösungsvorschläge 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Abb7: Detailinformationen zu Problem Nr. 1 mit Details, wie man es beheben könnte 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Abb8: ADDM Report mit Verbesserungsvorschlag in Textform 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Der Enterprise Manager Enterprise Manager ist das Herzstück der Datenbankverwaltung. von hier aus sind die verschiedenen Reports zu erreichen Struktur sieht folgendermaßen aus: 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Abb10: Enterprise Manager 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Die Detailseiten Die Detailseiten: ADDM Detail bekannt aus Abb. 7 Wait Detail: Zeigt an, wie die Wartezeiten verteilt sind. Von hier aus kann man sich weitere Details zu den sessions und den SQL Statements ansehen Session Detail: Sind die Wartezeiten gleichmäßig auf alle sessions verteilt oder gibt es welche wo gar nichts geht SQL Detail: Welche SQL Statements warten am längsten 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse SQL-Tuning in Database 10g klassische Aufgabe des Optimizers kein rule-based optimizer mehr, nur noch cost-based optimizing in database 10g manuelles SQL Tuning schwierig und zeitaufwendig, da man sowohl das Datenbankschema (Indexe,...) genau kennen muss als auch die workload workload verändert sich mit der Zeit, => neue Indexe/materialized views müssen her daher: automatisches SQL Tuning 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Der SQL tuning process: Dieser Prozess besteht aus 3 Schritten, die in einer Art Schleife ablaufen, bis eine akzeptable Performance erreicht ist, oder keine Verbesserungen mehr erreicht werden können: herausfinden, welche Anfragen sehr lange dauern und einen besonders hohen Bedarf an Systemresourcen haben sicherstellen, dass der Query-Optimizer die Anfrage bereits gut optimiert hat Andere Ausführungspläne testen, um die Anfrage schneller zu machen. 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Abb11: Manuelles SQL-tuning 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse Abb12: Autom. SQL-tuning 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse SQL Tuning Advisor Der SQL Tuning Advisor Er checkt SQL Statements in 4 Stufen: Analyse von Statistiken »jedes Objekt nach Statistiken durchsuchen »Vorschläge machen, was noch erhoben werden sollte SQL-Profiling: »Erstellen eines SQL Profils zur Anfrageoptimierung »SQL Syntax selbst muss nicht geändert werden Ausführungspfadanalyse: »schauen ob neuer Index Bearbeitung schneller macht SQL Strukturanalyse: »SQL-Anfrage auf syntaktische und semantische Struktur prüfen 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse SQL Tuning Advisor Der SQL Tuning Advisor Abb13: Aufruf des SQL Tuning Advisors im ADDM 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse SQL Tuning Advisor Der SQL Tuning Advisor Abb14: Vorschlag des SQL Tuning Advisors nach Aufruf aus ADDM 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse SQL Access Advisor Der SQL Access Advisor analysiert ein vorgeschlagenes Datenbankschema für eine bestimmte workload schlägt vor, welche Indexe und matirialized views zu erstellen sind prüft, dass Kosten für Anlegen der Strukturen nicht deren Nutzen übersteigen 2. Funktionalität von Database 10g 2.2 self-optimizing

Benedikt Terschluse 2.3 self-organizing gegebenen Ressourcen geschickt nutzen und verteilen nicht trennscharf von self-configuring oder self-optimizing abzugrenzen Resource ManagerORACLE Database 10g: besitzt für die Verteilung der Systemressourcen den Resource Manager »CPU-Zeit an Benutzergruppen und Anwendungen verteilen »Batch Jobs evtl. nur in Nebenzeiten ausführen lassen »dazu kann man einen resource plan festlegen 2. Funktionalität von Database 10g 2.3 self-organizing

Benedikt Terschluse Parameter des resource plans: CPU-Zeit Anzahl aktiver Sessions Anzahl paralleler Zugriffe Automatische Gruppenzuweisung SQL Anfragen und Sessions beenden Ausführungsdauer Undo Operationen Maximale Wartezeit 2. Funktionalität von Database 10g 2.3 self-organizing

Benedikt Terschluse 3 Beispiele für verschiedene resource plans 1.: resource plan für eine Bank (zweistufig) Abb15.1: Struktur des PlansAbb15.2: Tabelle zur Ressourcenverteilung auf Stufe 1 (Banksystem) 2. Funktionalität von Database 10g 2.3 self-organizing

Benedikt Terschluse 3 Beispiele für verschiedene resource plans 2.: resource plan für ERP oder CRM System Abb16: Tabelle zur Ressourcenverteilung (ERP oder CRM System) 2. Funktionalität von Database 10g 2.3 self-organizing

Benedikt Terschluse 3 Beispiele für verschiedene resource plans 3.: resource plan für ein Data Warehouse Abb17: Tabelle zur Ressourcenverteilung (Data Warehouse) 2. Funktionalität von Database 10g 2.3 self-organizing

Benedikt Terschluse Resource Manager Den Resource Manager findet man natürlich auch im Enterprise Manager: Abb18: Resource Manager im Enterprise Manager 2. Funktionalität von Database 10g 2.3 self-organizing

Benedikt Terschluse Weitere Möglichkeiten des self-optimizing in Database 10g: Intelligent Capacity Planning »Schätzung, wie groß ein Objekt werden wird »Wählt daher den passenden Speicherort »vermeidet Fragmentierung der Platten Storage Manager »Verteilung der Daten auf verschiedene Platten »Lese- und Schreibzeit wird kürzer »Grundlage ist Analyse der workload 2. Funktionalität von Database 10g 2.3 self-organizing

Benedikt Terschluse 2.4 self-inspecting Ein DBMS sollte „sich kennen“ große Herausforderung, da workload sich dauernd ändert Statistiken müssen stets aktuell gehalten werden in Database 10g ist dafür die automatic workload repository (AWR) zuständig ist bereits in 2.2 erklärt worden 2. Funktionalität von Database 10g 2.4 self-inspecting

Benedikt Terschluse 2.5 self-protecting Schutz vor deadlocks und Abstürzen, verursacht durch schlechte Anfragen oder schlechte Ressourcenverteilung »-> das sollte der Resource Manager regeln (siehe 2.3) Schutz vor Angriffen auf die Datenbank »ORACLE bietet row-level security an. IBM und Microsoft setzen auf security per table »nur regelbasiert, daher keine weitere Betrachtung an dieser Stelle 2. Funktionalität von Database 10g 2.5 self-protecting

Benedikt Terschluse 2.6. self-healing Datenbank nach einem Fehler schnell wieder in einen funktionierenden Zustand zurückversetzen ACID-Eigenschaften erfüllen und dabei downtime möglichst klein halten, Ausfallzeiten sind schließlich immer teuer Recovery ManagerIn Database 10g gibt es hierfür den Recovery Manager (RMAN) 2. Funktionalität von Database 10g 2.6 self-healing

Benedikt Terschluse Recovery Manager Der Recovery Manager Zeitfenster festlegen, in dem backup stattfinden soll Speicherort für backup festlegen: »DB_RECOVERY_FILE_DEST Alle notwendigen Dateien (control files, log files,...) hier gespeichert und verwaltet: »Dateianordnung und Komprimierung für maximale Speicherplatzausnutzung »alte und nicht mehr benötigte Dateien automatisch löschen 2. Funktionalität von Database 10g 2.6 self-healing

Benedikt Terschluse inkrementelle backup Das inkrementelle backup gibt es seit ORACLE Database 8.0 Neu in Database 10g: »geänderte Blöcke werden gekennzeichnet »erspart zeitaufwendige Suche bei Anstoß des backup »daher kann inkrementelles backup nun schneller durchgeführt werden 2. Funktionalität von Database 10g 2.6 self-healing

Benedikt Terschluse flashback feature Das flashback feature Ein Hauptproblem für die Sicherheit in Datenbanken ist der Benutzer. Fehler, die durch Benutzereingriff entstehen sind schwer zu vermeiden flashback featuremit flashback feature schnell zu einer funktionierenden Konfiguration zurückspringen soll schneller gehen als den Fehler zu machen 2. Funktionalität von Database 10g 2.6 self-healing

Benedikt Terschluse flashback feature Das flashback feature Abb18: Vergleich vor/mit ORACLE Database 10g bei Wiederherstellung einer versehentlich gelöschten Tabelle 2. Funktionalität von Database 10g 2.6 self-healing

Benedikt Terschluse Gliederung: 1. Einleitung 2. Funktionalität von ORACLE Database 10g 2.1 self-configuring 2.2 self-optimizing 2.3 self-organizing 2.4 self-inspecting 2.5 self-protecting 2.6 self-healing 3. Vergleich zur Konkurrenz 4. Fazit Gliederung

Benedikt Terschluse 3. Vergleich zur Konkurrenz da es sehr viele verschiedene DBMS gibt vergleiche ich hier nicht mit allen, sondern nur mit dem Hauptkonkurrenten IBM DB2 Universal Database 8.2 „unabhängige“ Studie der Edison Group vom Vergleich zur Konkurrenz

Benedikt Terschluse Ergebnisse der Studie Installation und erste, einfache out of the box Konfiguration 3. Vergleich zur Konkurrenz

Benedikt Terschluse Ergebnisse der Studie täglicher Betrieb 3. Vergleich zur Konkurrenz

Benedikt Terschluse Ergebnisse der Studie Sicherungen und Wiederherstellung nach Fehler 3. Vergleich zur Konkurrenz

Benedikt Terschluse Ergebnisse der Studie Performancediagnose und tuning 3. Vergleich zur Konkurrenz

Benedikt Terschluse Ergebnisse der Studie Zusammenfassung: Database 10g ist insgesamt im Schnitt 47% schneller als DB2 und erfordert 36% weniger Schritte um ein gewünschtes Ergebnis zu erzielen ORACLE hält also sein Versprechen, hier eine wesentlich schnellere und einfacher zu bedienende Datenbank erstellt zu haben 3. Vergleich zur Konkurrenz

Benedikt Terschluse Gliederung: 1. Einleitung 2. Funktionalität von ORACLE Database 10g 2.1 self-configuring 2.2 self-optimizing 2.3 self-organizing 2.4 self-inspecting 2.5 self-protecting 2.6 self-healing 3. Vergleich zur Konkurrenz 4. Fazit Gliederung

Benedikt Terschluse 4. Fazit Viele sehr interessante automatische Features sehr große Vereinfachung der Bedienung, sichtbar auch in der Studie die in Abschnitt 3 betrachtet wurde gleichzeitig ist die Datenbank auch wirklich schneller geworden, auch dies zeigt sich in Abschnitt 3 trotzdem gibt es noch genug Möglichkeiten für den Administrator um einzugreifen aus gutem Grund?? Fazit

Benedikt Terschluse Vielen Dank für die Aufmerksamkeit.