Benedikt Terschluse ORACLE 10g the self-managing database Friedrich-Schiller-Universität Jena Lehrstuhl für Datenbanken und Informationssysteme Seminar:

Präsentation zum Thema: "Benedikt Terschluse ORACLE 10g the self-managing database Friedrich-Schiller-Universität Jena Lehrstuhl für Datenbanken und Informationssysteme Seminar:"—  Präsentation transkript:

1 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

2 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

3 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 55000 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

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

15 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

16 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... 2. Funktionalität von Database 10g 2.2 self-optimizing

17 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

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

19 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

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

21 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

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

23 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

24 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

25 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

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

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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 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

40 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

41 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

42 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

43 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

44 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

45 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

46 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

47 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 1.11.2004 3. Vergleich zur Konkurrenz

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

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

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

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

52 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

53 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

54 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??... 4. Fazit

55 Benedikt Terschluse Vielen Dank für die Aufmerksamkeit.