Seminar06_ORACLE - Friedrich-Schiller
Werbung
Friedrich-Schiller-Universität Jena Lehrstuhl für Datenbanken und Informationssysteme Seminar: Aspekte und Werkzeuge der DB-Administration und deren Automatisierung ORACLE 10g the self-managing database Benedikt Terschluse Gliederung 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 Benedikt Terschluse 1. Einführung 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 • Hier wird ORACLE Database 10g Release 2 betrachtet (von 2005) Benedikt Terschluse 1. Einführung 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 Benedikt Terschluse Gliederung 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.1 self-configuring 2. Funktionalität von ORACLE Database 10g 2.1 self-configuring • schnellere Installation: » Server-Installation (1.5 GB) in 20 Minuten » Client Installation (80MB) in einer Minute • einfache Konfiguration: » Database Creation Assistant (DBCA): leitet den DBA durch den Einrichtungsvorgang • einfache Updates: » Database Update Assistant (DBUA): leitet durch den Update-Vorgang. Für manuelle Updates: catupgrd.sql Benedikt Terschluse 2. Funktionalität von Database 10g 2.1 self-configuring 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. Benedikt Terschluse 2. Funktionalität von Database 10g 2.1 self-configuring Abb1: SGA-TARGET auf 132 MB festgelegt aktuell wird der Speicher wie in der Tabelle dargestellt verteilt. Alternativ: View V$SGA_DYNAMIC_COMPONENTS Benedikt Terschluse 2. Funktionalität von Database 10g 2.1 self-configuring 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.1 self-configuring 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.1 self-configuring Abb2: aktivieren des automatic shared managements 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. Benedikt Terschluse 2. Funktionalität von Database 10g 2.1 self-configuring Abb3: size advisor für den SGA_TARGET 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). Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing 2.2 self-optimizing • • • Kernpunkt der Bemühungen des autonomic computing. Gegebene Ressourcen effektiv auslasten Anfragen tunen ORACLE Database 10g verwendet hier: • • automatic workload repository (AWR): » sammelt Statistiken über die workload automatic database diagnostics monitor (ADDM): » erkennt wo Optimierungsbedarf besteht » optimiert selbst » oder leitet an „Spezialisten“ weiter (siehe Abb4) Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing Abb4: die Optimierungsarchitektur Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing 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 ... Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing Abb5: Im Enterprise Manager wird angezeigt, dass es 2 Probleme gibt, die das ADDM gefunden hat Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing Abb6: Kurzbeschreibung der Probleme und Lösungsvorschläge Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing Abb7: Detailinformationen zu Problem Nr. 1 mit Details, wie man es beheben könnte Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing Abb8: ADDM Report mit Verbesserungsvorschlag in Textform Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing 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: Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing Abb10: Enterprise Manager Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing 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. Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing Abb11: Manuelles SQL-tuning Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing Abb12: Autom. SQL-tuning Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing Der SQL Tuning Advisor Abb13: Aufruf des SQL Tuning Advisors im ADDM Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing Der SQL Tuning Advisor Abb14: Vorschlag des SQL Tuning Advisors nach Aufruf aus ADDM Benedikt Terschluse 2. Funktionalität von Database 10g 2.2 self-optimizing 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.3 self-organizing 2.3 self-organizing • gegebenen Ressourcen geschickt nutzen und verteilen • nicht trennscharf von self-configuring oder self-optimizing abzugrenzen • ORACLE 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.3 self-organizing 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.3 self-organizing 3 Beispiele für verschiedene resource plans 1.: resource plan für eine Bank (zweistufig) Abb15.1: Struktur des Plans Abb15.2: Tabelle zur Ressourcenverteilung auf Stufe 1 (Banksystem) Benedikt Terschluse 2. Funktionalität von Database 10g 2.3 self-organizing 3 Beispiele für verschiedene resource plans 2.: resource plan für ERP oder CRM System Abb16: Tabelle zur Ressourcenverteilung (ERP oder CRM System) Benedikt Terschluse 2. Funktionalität von Database 10g 2.3 self-organizing 3 Beispiele für verschiedene resource plans 3.: resource plan für ein Data Warehouse Abb17: Tabelle zur Ressourcenverteilung (Data Warehouse) Benedikt Terschluse 2. Funktionalität von Database 10g 2.3 self-organizing Den Resource Manager findet man natürlich auch im Enterprise Manager: Abb18: Resource Manager im Enterprise Manager Benedikt Terschluse 2. Funktionalität von Database 10g 2.3 self-organizing 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.4 self-inspecting 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.5 self-protecting 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.6 self-healing 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 • In Database 10g gibt es hierfür den Recovery Manager (RMAN) Benedikt Terschluse 2. Funktionalität von Database 10g 2.6 self-healing 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.6 self-healing 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 Benedikt Terschluse 2. Funktionalität von Database 10g 2.6 self-healing Das flashback feature • Ein Hauptproblem für die Sicherheit in Datenbanken ist der Benutzer. • Fehler, die durch Benutzereingriff entstehen sind schwer zu vermeiden • mit flashback feature schnell zu einer funktionierenden Konfiguration zurückspringen • soll schneller gehen als den Fehler zu machen Benedikt Terschluse 2. Funktionalität von Database 10g 2.6 self-healing Das flashback feature Abb18: Vergleich vor/mit ORACLE Database 10g bei Wiederherstellung einer versehentlich gelöschten Tabelle Benedikt Terschluse Gliederung 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 Benedikt Terschluse 3. Vergleich zur Konkurrenz 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 Benedikt Terschluse 3. Vergleich zur Konkurrenz Ergebnisse der Studie • Installation und erste, einfache out of the box Konfiguration Benedikt Terschluse 3. Vergleich zur Konkurrenz Ergebnisse der Studie • täglicher Betrieb Benedikt Terschluse 3. Vergleich zur Konkurrenz Ergebnisse der Studie • Sicherungen und Wiederherstellung nach Fehler Benedikt Terschluse 3. Vergleich zur Konkurrenz Ergebnisse der Studie • Performancediagnose und tuning Benedikt Terschluse 3. Vergleich zur Konkurrenz 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 Benedikt Terschluse Gliederung 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 Benedikt Terschluse 4. Fazit 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?? ... Benedikt Terschluse Vielen Dank für die Aufmerksamkeit. Benedikt Terschluse
