»ORACLE 10g: The self-managing database«

Transkript

1 Fakultät für Mathematik und Informatik Lehrstuhl für Datenbanken und Anwendungssysteme Seminar: Aspekte und Werkzeuge der DB Administration und deren Automatisierung»ORACLE 10g: The self-managing database«sommersemester 2006 Benedikt Terschluse, Matrikelnr.: 67605

2 Inhalt 1. Einleitung 3 2. Funktionalität von ORACLE 10g self-configuring Das automatische Speichermanagement Der Size Advisor self-optimizing Die Automatic Workload Repository (AWR) Der Automatic Database Diagnostic Monitor (ADDM) Der Enterprise Manager SQL Tuning in Database 10g Der SQL Tuning Advisor Der SQL Access Advisor self-organizing Der Resource Manager Beispiele für Ressourcenpläne self-inspecting self-protecting self-healing Vergleich zu DB Fazit 22 2

3 1. Einleitung ORACLE wurde 1977 in Kalifornien (USA) von Larry Ellison, Bob Miner und Ed Oates gegründet. Heutiger CEO ist Lawrence J. Ellison. Das Unternehmen beschäftigt heute rund Mitarbeiter weltweit und hat bei Datenbanken einen Marktanteil ca. 41%, in etwa soviel wie Hauptkonkurrent IBM mit DB2. In dieser Ausarbeitung wird ORACLE Database 10g Release 2 betrachtet (von 2005). ORACLE gibt vor, mit Database 10g das erste Datenbankmanagementsystem geschaffen zu haben, was sich zu großen Teilen selbst verwalten und optimieren kann. Dazu sollen die entsprechenden Features in den folgenden Gebieten betrachtet werden [1]: Self-configuring: Eine Datenbank sollte nach der Installation eine Konfiguration annehmen, mit der man arbeiten kann, ohne großartig etwas einzustellen. Wünschenswert ist hier eine automatische Analyse der Rechenpower, etc. um dem Kunden dann eine möglichst passende Konfiguration out of the box anzubieten. Es gibt auch Wizzards, die nach der eigentlichen Installation aufgerufen werden können. Self-optimizing: Eine Datenbank sollte sich selbst optimieren können. Das heißt, sie muss erkennen wo Schwachstellen liegen und diese beseitigen. Self-healing: Bei Fehlern sollte die Datenbank diese lösen, oder zumindest dem Administrator Lösungsvorschläge machen. Self-protecting: Die Datenbank sollte Sicherheitslücken erkennen um sich selbst vor potentiellen Angriffen schützen zu können. Self-organizing: Die Datenbank sollte mit den gegeben Ressourcen gut wirtschaften und diese performanceoptimal verteilen. Dieser Punkt ist recht eng mit self-optimizing verwoben. Self-inspecting: DBMS sollte sich kennen. Es muss wissen, wann welche workload anfällt, also Statistiken sammeln, etc. 3

4 2. Funktionalität von ORACLE 10g In diesem Kapitel sollen nun analysiert werden, welche Funktionen Database 10g in den eben angesprochenen Bereichen besitzt. 2.1 self-configuring Mitunter dauert schon die reine Installation einer Datenbank sehr lange, ganz zu schweigen von der ersten halbwegs lauffähigen Konfiguration. Bei ORACLE Database 10g soll eine Server-Installation (1.5 GB) in 20 Minuten abgeschlossen sein, vorher soll es doppelt so lange gedauert haben. Eine Client Installation soll sogar in nur einer Minute geschafft sein und ist 80MB groß. Um eine Datenbank zu erstellen gibt es den Database Creation Assistent (DBCA). Der DBCA leitet den DBA als eine Art Wizzard durch den Einrichtungsvorgang. Hier kann man direkt alle Einstellungen tätigen, um eine erste, funktionierende Datenbank zu erstellen. Dies ist auf dem Gebiet der out-of-the-box Konfiguration die einzige Möglichkeit, die Database 10g bietet. Denkbar wäre hier auch eine selbständige Konfiguration auf Grund der verfügbaren Hardware, ohne einen Eingriff des Benutzers. Dies wird aber nicht angeboten. Für spätere Updates gibt es den Database Update Assistent (DBUA). Er leitet durch den Update-Vorgang. Auch die manuellen updates wurden vereinfacht: Man muss nur noch das catupgrd.sql Skript ausführen. Es ruft dann selbständig alle weiteren notwendigen Skripte auf [2] Das automatische Speichermanagement Auf Grund der Einführung des Automatic Shared (SGA) Memory Management (SGA steht für System Global Area, den Bereich wo Daten und Informationen für eine Datenbank gehalten werden) muss der DBA nicht mehr festlegen welche Komponente wie viel Speicher bekommt, sondern legt nur noch den SGA_TARGET Parameter fest. Dieser verteilt dann, je nach Workload, den Speicher an die einzelnen Komponenten [4]. Diese sind: - 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 RMAN) - buffer cache - streams pool Vor Database 10g musste man für jede dieser Komponenten den Speicher einzeln festlegen. Dieser Wert war dann fix. Hatte eine Komponente nun eine hohe Last, so konnte es zu einem 4

5 Out-Of-Memory-Fehler kommen, auch wenn das System möglicherweise noch Speicher zur Verfügung hatte, dieser aber anderen Komponenten zugeteilt war. Hier müsste dann der DBA explizit eingreifen und die Speicherverteilung ändern. In Database 10g läuft das nun folgendermaßen ab: Man legt den SGA_TARGET Parameter fest. Nun verteilt das System den zur Verfügung stehenden Speicher nach der aktuellen Workload. Ändert sich diese und braucht dadurch eine Komponente mehr Speicher, so wird dieser von einer anderen Komponente übertragen. Hierfür ist kein Benutzereingriff mehr notwendig. Eingriffsmöglichkeiten für den DBA bestehen hier insoweit, dass er für die einzelnen Komponenten minimale Speichergrößen festlegen kann. Der verbleibende Speicher kann dann wiederum automatisch verteilt werden. Hierzu ein kleines Beispiel: SGA_TARGET = 132 MB SHARED_POOL_SIZE = 32 MB DB_CACHE_SIZE = 20 MB Für SHARED_POOL_SIZE und DB_CACHE_SIZE werden nun nie weniger als 32, bzw. 20 MB bereitgestellt. Die verbleibenden 80MB können dagegen frei an die anderen Komponenten vergeben werden. Diese Einstellungen kann man sich im Enterprise Manager oder im View V$SGA_DYNAMIC_COMPONENTS ansehen. Abbildung 1: Festlegen und Aktivieren des SGA_Target Parameters im Enterprise Manager 5

6 Es gibt allerdings noch Komponenten, für die der DBA den Speicher weiterhin manuell zuteilen muss. Dies sind zum Beispiel die Recycle Buffer Caches und Additional Buffer Caches. Der hier verbrauchte Speicher steht dann ebenfalls nicht für die automatische Verwendung zur Verfügung. Zusammenfassung der Vorteile durch das automatische Speichermanagement: 1. Out-Of-Memory-Fehler treten seltener auf und auch nur dann, wenn tatsächlich kein Speicher mehr vorhanden ist. Beispiel: Datenbank mit 1 GB Speicher. Alte Konfiguration: SHARED_POOL_SIZE = 128 MB DB_CACHE_SIZE = 896 MB. Versucht das System nun mehr als 128 MB dem Shared Pool zuzuweisen gibt es einen Out-Of-Memory-Fehler, auch wenn noch Speicher zur Verfügung steht, dieser aber für DB Cache reserviert ist. Neue Konfiguration: SGA_TARGET = 1GB. Nun kann das System diese 1GB frei verteilen, je nach dem wo sie benötigt werden. 2. Performance wird deutlich verbessert: Ändert sich die Workload, beispielsweise durch Saisonzyklen oder Tag/Nacht Wechsel, so kann das System direkt darauf reagieren und die Speicherzuweisungen anpassen. Der DBA müsste hier zunächst mal analysieren, wie sich die Belastungen überhaupt geändert haben und kann dann erst reagieren. 3. Einfacher zu bedienen: Der DBA braucht im Minimum nur einen Parameter festlegen und kann dann einfach das System machen lassen. Das automatische Speichermanagement lässt sich auf zwei verschiedene Weisen aktivieren: Entweder explizit im Enterprise Manager auf Enable klicken (siehe Abbildung 1) oder implizit über die Kommandozeile: Dort ALTER SYSTEM SET SGA_TARGET = Größe des Speichers und alle anderen Komponenten auf Null setzen Der Size Advisor Um die optimale Größe für den SGA_TARGET-Parameter zu finden gibt es den Size Advisor. Dazu gibt es in Database 10g ein Diagramm, was die Veränderung der Dauer von Anfragen an die Datenbank zeigt (in Abbildung 2 als Improvement in DB Time bezeichnet), je nach dem 6

7 wie viel Speicher zur Verfügung gestellt wird. Dieses Diagramm ist in Abbildung 2 zu sehen: In diesem Beispiel ist Ab ca. 165MB ist hier keine weitere Verbesserung zu erkennen. Dies liegt daran, dass der Speicher dann einfach nicht mehr die knappe Ressource ist. Eine weitere Speichererhöhung bringt also keine Performance mehr. Abbildung 2: Veränderung der Performance in Abhängigkeit vom bereitgestellten Speicher Natürlich kann man dem SGA_TARGET nicht mehr Speicher zuweisen, als das System besitzt (SGA_MAX_SIZE). Außerdem kann man auch nicht weniger zuweisen, als für die Summer der Minimalkonfigurationen der anderen Komponenten benötigt wird. Dazu ein kleines Beispiel [4]: SGA_MAX_SIZE = 1024 MB DB_CACHE_SIZE = 96 MB SHARED_POOL_SIZE = 128 MB Der SGA_TARGET kann nun zwischen 224 und 1024 MB auf jeden beliebigen Wert gesetzt werden. Er muss allerdings innerhalb dieser Grenzen bleiben. 2.2 self-optimizing Self-optimizing beschreibt alle Maßnahmen, die vom DBMS unternommen werden, um die Datenbank so schnell wie möglich zu machen. Das bedeutet, dass Datenbankoperationen zu jeder Zeit möglichst schnell ausgeführt werden können. Damit sind Lese- wie auch Schreibzugriffe gemeint. Je nach dem, welcher Last die Datenbank ausgesetzt ist, müssen hier unterschiedliche Strategien angewendet werden. Es kommt also immer darauf an, einen geschickten trade-off zwischen den Kosten, welche beispielsweise die Pflege eines weiteren Indexes oder Matirialized Views verursacht, und der eingesparten Suchzeit zu finden. Mit 7

8 dieser Problematik beschäftigt sich auch die Optimierungsarchitektur von Database 10g. Um Probleme überhaupt erst zu finden gibt es das sogenannte AWR und ADDM. AWR ist die Automatic Workload Repository und ADDM der Automatic Database Diagnostic Monitor [2]. Abbildung 3: Optimierungsarchitektur in Database 10g Die Automatic Workload Repository (AWR) Die AWR läuft automatisch im Hintergrund. Standardmäßig erstellt sie alle 30 Minuten einen Snapshot der Workload und löscht Daten, die älter als 7 Tage sind. Somit wird sichergestellt, dass die Festplatte nicht mit Statistiken überschüttet wird. Diese Parameter können natürlich angepasst werden, und den DBA kann auch jederzeit selbst einen snapshot machen. Die Daten, die in der AWR gespeichert und verwaltet werden, stellen die Basis für alle Optimierungen des ADDM da [7] Der Automatic Database Diagnostic Monitor (ADDM) Der ADDM schaut sich das gesamte System an und analysiert, was zur Verbesserung der Performance beitragen kann. Er schlägt dann vor, was man optimieren könnte oder leitet an einen der Spezialisten, wie z.b. den SQL Tuning Advisor weiter. Diese Spezialisten werden 8

9 später noch vertiefend betrachtet. Das Ziel des ADDM ist es, die Bereiche der Datenbank zu finden, welche die meiste Datenbankzeit verbrauchen. Diese Probleme werden vom ADDM dann weiter analysiert, um die Ursachen zu finden (Abbildung 3). Reports, die das ADDM erstellt hat, kann man sich in Textform oder auch mit graphischen Illustrationen im Enterprise Manager (siehe: 2.2.3) ansehen. Über den Enterprise Manager kann man sich komfortabel bis zur Quelle des Problems navigieren (Abbildung 4). Man bekommt verschiedene Lösungsvorschläge generiert und eine Angabe über die mögliche Zeitersparnis (Abbildung 5). Man kann also abschätzen, ob sich ein Eingriff lohnt oder ob man besser an anderer Stelle optimieren sollte [3]. Abbildung 4: Vom ADDM gefundene Performanceprobleme Abbildung 5: Lösungsvorschläge für diese Probleme 9

10 2.2.3 Der Enterprise Manager Abbildung 6: Titelseite des Enterprise Manager An dieser Stelle soll der Enterprise Manager mit seinen verschiedenen Reports näher erläutert werden. Von dort aus kann man diverse Untermenüs aufrufen, um sich oben genannte Problemlösungsvorschläge genauer anzuschauen oder einen Blick auf die Lastverteilung des Systems zu werfen. Der Enterprise Manager verfügt über folgende Komponenten: - DB Home - Performance Page - Top Session - Top SQL - Wait Detail - SQL Detail - Session Detail - ADDM Page - ADDM Detail Die Struktur, in der diese Komponenten zusammenhängen ist in Abbildung 7 dargestellt. 10

11 Abbildung 7: Struktur des Enterprise Managers Die Wait-Detail-Seite zeigt an, welche Sessions oder Seiten am längsten warten müssen. So kann man herausfinden, ob es Kandidaten gibt, die aus der Reihe fallen. Will man sich diese genauer anschauen, kann man aus dem wait detail direkt zum session detail, sowie zum SQL detail springen. Im SQL-Detail kann man sich den Text des ausgewählten SQL Statements anschauen, sowie die CPU Auslastung. So kann man analysieren, ob das Statement wirklich bearbeitet wird oder noch auf andere Ressourcen wartet. Im Session-Detail bekommt man Informationen zu den Sessions. So kann man analysieren, ob die Wartezeiten in etwa gleich auf die Sessions verteilt sind, oder ob es Sessions gibt, die überhaupt nicht mehr an die Reihe kommen SQL Tuning in Database 10g Einer der wichtigsten Punkte zur Performanceoptimierung sind die SQL Anfragen, die von den Anwendungen, die mit der Datenbank arbeiten, gesendet werden. Diese zu optimieren ist Aufgabe des Optimizers. In ORACLE 10g gibt es den rule-based Optimizer nicht mehr, sondern nur noch den cost-based Optimizer. Dieser berechnet die optimale Ausführung der Anfrage auf Grund der Ausführungskosten (in CPU-Zeit). Ein Eingriff des DBA ist hier nicht mehr erforderlich. Um SQL Anfragen zu tunen, gibt es im Wesentlichen 3 Schritte, die so lange wiederholt werden, bis die Performance entweder akzeptabel wird oder sich einfach keine signifikanten Verbesserungen mehr einstellen. Diese Schritte sehen folgendermaßen aus [5]: 1. Herausfinden, welche Anfragen sehr lange dauern und einen besonders hohen Bedarf an Systemressourcen haben. 11

12 2. Sicherstellen, dass der Query-Optimizer die Anfrage bereits gut optimiert hat. 3. Andere Ausführungspläne testen, um die Anfrage schneller zu machen. Die Abarbeitung der Schritte, sowie die Anzahl der Wiederholungen laufen in Database 10g vollkommen automatisch ab. ADDM und AWR finden die SQL Anfragen, die am längsten dauern (high load SQL). Diese können dann mit dem SQL Tuning Advisor getunt werden Der SQL Tuning Advisor Abbildung 8: SQL Tuning in Database 10g Der SQL Tuning Advisor hat gegenüber dem bisher verwendeten Optimizerkonzept den Vorteil, dass er mehr Zeit für die Optimierung der Statements hat, da hier nur die echten Härtefälle landen. Alle Statements wurden ja bereits mit dem Query Optimizer getunt. Dieser hat aber in der Regel nur Sekunden für die Erstellung eines geeigneten Ausführungsplans, da der laufende Betrieb weitergeht. Daher muss er sich auf Heuristiken und grobe Statistiken verlassen und hat auch keine Möglichkeit die Resultate zu analysieren. Der SQL Tuning Advisor dagegen bekommt einige Minuten um seinen Ausführungsplan zu erstellen. Dazu fährt er Analysen in vier verschiedenen Bereichen: 1. Analyse von Statistiken: Es wird jedes Objekt in der Anfrage nach fehlenden Statistiken analysiert. Ebenfalls geprüft wird, ob die Statistiken auch aktuell sind. Dann können Vorschläge gemacht werden, was man in Zukunft noch erheben sollte und welche Statistiken aktualisiert werden sollten. 12

13 2. SQL-Profiling: Hier werden zunächst einmal die Daten verifiziert, auf deren Basis der Query Optimizer seinen Ausführungsplan angelegt hat. Das heißt, es wird geschaut, ob er nicht Fehleinschätzungen vorgenommen haben könnte, da er zum Beispiel mit Standardheuristiken gerechnet hat, da es keine guten Statistiken zu den Tabellen gibt, über die eine Anfrage gestellt wurde. So etwas kann zu gewaltigen Fehleinschätzungen und somit zu ineffizienten Ausführungsplänen führen. Ist dieser Teil abgeschlossen, so prüft der Tuning Optimizer noch, ob er Informationen aus den zurückliegenden Ausführungen des SQL Statements gewinnen kann. Wenn also beispielsweise ein Statement meistens nur teilweise ausgeführt wird, so könne er den Optimizer entsprechend darauf einstellen. Hat der SQL Tuning Advisor nun einen geeigneten Plan gefunden, erstellt er ein SQL Profil. Anschließend wird dem Benutzer vorgeschlagen dieses zu speichern und zu benutzen. Ist ein SQL Profil erst einmal gespeichert, so kann es der Optimizer jederzeit verwenden, um für Anfragen gleicher oder ähnlicher Charakteristik einen geeigneten Ausführungsplan zu erstellen (Abbildung 9). Abbildung 9: Erstellen und benutzen des SQL Profils 3. Zugriffspfadanalyse: Es wird geschaut, ob das Anlegen eines neuen Indexes die Ausführung der Anfrage deutlich beschleunigen kann. Dabei wird auch darauf geachtet, dass der Aufwand zum Anlegen des Indexes nicht seinen Nutzen übersteigt. 4. SQL Struktur Analyse: Hier wird die SQL Anfrage auf ihre Struktur geprüft und dann ggf. verbessert. Diese Verbesserungen können syntaktischer, sowie semantischer Natur sein. 13

14 Aufrufen kann man den SQL Tuning Optimizer im ADDM. Hier bekommt man die Ergebnisse seiner oben aufgeführten Bemühungen dann auch wieder graphisch zu sehen und kann dann auch festlegen, welchen seiner Vorschläge man beherzigen will (Abbildung 10). Abbildung 10: Vorschlag des SQL Tuning Advisors Der SQL Access Advisor Der SQL Access Advisor analysiert ein vorgeschlagenes Datenbankschema für eine bestimmte Workload und schlägt dann vor, welche Indexe und Materialized Views zu erstellen sind. Hierbei wird auch wieder beachtet, dass die Kosten zum Anlegen dieser Strukturen nicht den Nutzen, den man durch kürzere Ausführungszeiten erhält, übersteigen. 2.3 self-organizing Ein DBMS sollte die Fähigkeit haben sich selbst zu organisieren. Das bedeutet, die gegebenen Ressourcen geschickt nutzen und auf die Anfragen verteilen. Dieser Punkt ist natürlich nicht trennscharf von self-configuring oder self-optimizing abzugrenzen, da hier auch eine Art Konfiguration passiert und es letztendlich, wie immer, um die Optimierung der Performance geht. ORACLE Database 10g besitzt für die Verteilung der Systemressourcen den Resource Manager. 14

15 2.3.1 Der Resource Manager Im Resource Manager kann man einstellen, wie die Systemressourcen (angegeben in CPU- Zeit) auf die Anwendungen verteilt werden können. Hier kann man also bestimmten Anwendungen oder Benutzern, die auf der Datenbank arbeiten möchten, bestimmte Prozentsätze der CPU Leistung zuweisen. Außerdem ist es möglich, Batch Jobs Resourcen zu bestimmten Zeiten unterschiedlich zuzuweisen, um diese z.b. nur in Nebenzeiten auszuführen, damit sie den laufenden Betrieb nicht stören. All diese Dinge (und noch mehr) kann man in einem Resource-Plan festlegen [6]: - CPU-Zeit: Hier lässt sich, wie oben schon gesagt, die Verteilung der CPU-Zeit auf die anfragenden Anwendungen und Benutzer(-gruppen) verteilen. Es ist möglich, verschiedene Pläne anzulegen, je nach dem wie die Workload gerade aussieht. Außerdem kann man auch Unterpläne festlegen, in welchen man Aktionen bestimmt, die bei einer CPU-Auslastung von 100% ausgeführt werden. Hier kann man beispielsweise festlegen, dass dann hoch prioritäre Anwendungen mehr CPU Zeit bekommen. Hat man also beispielsweise bei einem großen Versandhaus eine Anwendung, die für die Verwaltung des Lagers auf die Datenbank zugreifen möchte, so ist diese sicherlich als höher prioritär anzusehen als beispielsweise ein Sicherungsjob, der auch zu einer Nebenzeit (z.b. nachts) durchgeführt werden kann. Hier würde das System dann einfach die CPU Zeit ganz an die Lagerverwaltung geben, damit die Kunden bedient werden können. - Anzahl aktiver Sessions: Hier kann man die maximale Anzahl gleichzeitiger Anfragen festlegen, die pro Benutzergruppe ausgeführt werden dürfen. Ist diese maximale Anzahl erreicht und wird eine weitere Anfrage abgesetzt, so wird sie eingereiht und muss warten, bis eine frühere abgearbeitet ist. - Parallelitätsgrad: Dieser Punkt ist hauptsächlich für Data-Warehouses interessant: Man kann festlegen wie viele Server parallel eine Anfrage ausführen dürfen. Das soll verhindern, dass eine einzige Operation das gesamte System belegt. - Automatischer Wechsel der Gruppen: Hier kann man festlegen, dass eine Session, wenn sie einen bestimmten Ressourcenverbrauch erreicht hat, automatisch einer anderen Verbrauchergruppe zugeordnet wird. Diese hat dann meist eine niedrigere Priorität, so dass zunächst kürzere Anfragen eine Chance haben, bearbeitet zu werden. - Abbrechen von Anfragen und Sessions: Eine Abwandlung des Gruppenwechsels von eben dahingehend, dass lang laufende Sessions nicht mehr nur eine niedrigere Priorität bekommen sondern direkt beendet werden. 15

16 - Grenzen für die Ausführungszeit: Man kann eine maximale Ausführungszeit für Datenbankoperationen festlegen. Wenn das DBMS schätzt, dass die Anfrage länger als diese Zeit dauern wird, so wird sie gar nicht erst ausgeführt. - Rücksetzungspool: Hier legt man fest, wie viele oder auch wie lange alte Daten gespeichert bleiben sollen und Aktionen wieder rückgängig machen zu können. Dies kann viele Ressourcen kosten und daher hier limitiert werden. - Grenzen für Untätigkeit: Hier kann man festlegen, wie lange eine Session maximal untätig sein darf, bis sie beendet wird Beispiele für Ressourcenpläne Am deutlichsten wird die Notwendigkeit verschiedener Ressourcenpläne wenn man sich ein paar Beispiele zu den verschiedenen Einsatzmöglichkeiten ansieht: 1. Banksystem: Tabelle 1: Ressourcenverteilung Bank Für die Bank kommt es darauf an, dass die Kunden möglichst schnell bedient werden. Daher teilt man ihnen auch 90% der verfügbaren CPU-Zeit zu. Nur 10% verbleiben dann für Batch-Jobs (Tabelle 1). Man kann diesen Plan auch nochmals unterteilen (Subplan festlegen): So kann man dann beispielsweise festlegen, dass bestimmte Premiumkunden 70% von diesen 90% bekommen sollen (Abbildung 11). Abbildung 11: Mehrstufige Ressourcenverteilung für die Bank 16

17 2. ERP- oder CRM-System Tabelle 2: Ressourcenverteilung ERP oder CRM System In diesem Beispiel haben wir ganz andere Anforderungen als bei der Bank. In einem ERP-System kann es auch länger dauernde Operationen geben. Somit legt man hier fest, dass eine Operation, wenn sie länger als 3 Minuten dauert, automatisch in die BATCH-Gruppe gegeben wird und ihr damit weniger CPU-Ressourcen zur Verfügung stehen sollten. Dadurch wird verhindert, dass einzelne Operationen das System lahm legen. Des Weiteren wird hier festgelegt, dass nur maximal 6 Batchoperationen gleichzeitig laufen dürfen. Dies ist vernünftig, da der gesamten Gruppe ohnehin nur 30% der CPU Zeit zur Verfügung steht und sonst möglicherweise Batchoperationen sehr lange dauern. Noch dazu werden alle Batchoperationen abgebrochen, die länger als 12 Stunden laufen (Tabelle 2). 3. Data Warehouse Tabelle 3: Ressourcenverteilung Data Warehouse In diesem Beispiel haben wir 3 verschiedene Gruppen, je nach dem, wie wichtig die jeweiligen Operationen sind. Läuft eine Operation länger als 60 Minuten, so wird sie in die low priority Gruppe geschoben. Mehr als 20 Operationen dürfen außerdem nicht gleichzeitig laufen. Damit soll auch verhindert werden, dass die Operationen sich gegenseitig blockieren. Für die Maximum Estimated Excecution Time wird geschätzt, wie lange eine Operation wohl brauchen wird. Ist das Ergebnis mehr als 15 Stunden, so wird sie gar nicht erst gestartet (Tabelle 3). 17

18 Anhand dieser Beispiele wird klar, warum es so wichtig ist, dass je nach Anforderungen unterschiedliche Ressourcenpläne festgelegt werden sollten. Einstellen kann man diese, wie immer, über das graphische Interface des Enterprise Managers (Abbildung 12). Abbildung 12: Resource Monitor im Enterprise Manager Neben der Ressourcenverteilung des Resource Monitors gibt es noch weitere Möglichkeiten im Bereich des self-optimizing in Database 10g: Die Intelligent Capacity Planning ermöglicht Schätzungen über die voraussichtliche Größe der Objekte, bevor sie erstellt werden. So kann man direkt den besten Speicherort auswählen und vermeidet eine übermäßige Fragmentierung der Platten. Der Storage Manager verteilt die Daten so auf die zur Verfügung stehenden Platten, dass eine minimale Lade- und Schreibzeit gebraucht wird. Grundlage für die Anordnung ist hierbei eine Analyse der workload. ASM ermöglicht auch die Vergrößerung der Datenbank, ohne die Notwendigkeit diese zuvor herunterzufahren. 18

19 2.4 self-inspecting Ein DBMS sollte sich kennen, also jederzeit Bescheid wissen, wie es um die Ressourcen und die workload bestellt ist. Gerade Letzteres ist nicht gerade einfach, da die workload sich dauernd ändert und nicht immer unbedingt regelmäßig. Daher ist es wichtig, dass das DBMS seine Statistiken stets aktuell hält. Nur dann können die Optimierungsfunktionen die richtigen Maßnahmen ergreifen. In Database 10g übernimmt diesen Job die AWR (Automatic Workload Repository) mit ihren regelmäßigen Snapshots. Da dieses bereits in Abschnitt 2.2 erklärt wurde, soll hier nicht noch einmal darauf eingegangen werden. 2.5 self-protecting Dieser Punkt beinhaltet sowohl den Schutz vor Angriffen auf die Datenbank als auch den Schutz vor deadlocks und Abstürzen durch schlechte Anfragen oder schlechte Ressourcenverteilung. Für ersteres ist der Resource Manager zuständig, der bereits in Abschnitt 2.3 erklärt wurde. Mit den richtigen Ressourcenplänen kann hier bereits verhindert werden, dass eine Anwendung oder eine Benutzergruppe die Datenbank in die Knie zwingt (siehe Beispiele in 2.3). Zum Schutz vor Angreifern bietet ORACLE die row-level security an. IBM und Microsoft setzen hier eher auf security per table. Vorteile der row-level security sind, dass mehrere Anwendungen mit unterschiedlichen Berechtigungen auf der selben Tabelle arbeiten können, ohne dass Materialized Views erstellt werden müssen. Da dies aber auch nur regelbasiert und nicht automatisch abläuft, soll hier nicht weiter darauf eingegangen werden self-healing Der Bereich self-healing stellt für ein autonomes DBMS folgende Anforderungen: Es muss in der Lage sein die Datenbank nach einem Fehler schnell wieder in einen funktionierenden Zustand zurückzuversetzen. Dabei muss natürlich gewährleistet sein, dass sensible Daten nicht verloren gehen und keine Inkonsistenzen entstehen (ACID-Eigenschaften müssen erfüllt werden). Wichtig ist aber auch, die Downtime möglichst klein zu halten. In Database 10g gibt es hierfür den Recovery Manager (RMAN). Der Benutzer muss hier nur noch ein Zeitfenster festlegen, in dem das Backup stattfinden, sowie die Stelle, wo das Backup hingespeichert werden soll. Dies legt man über den Parameter DB_RECOVERY_FILE_DEST fest. Alles was man für ein Backup braucht (control files, log files,...) wird dann hier gespeichert und verwaltet. Gerade diese Verwaltung ist ein entscheidendes Feature: Die Dateien werden so komprimiert und angeordnet, dass eine maximale Ausnutzung des Speicherplatzes möglich ist. Außerdem werden alte und nicht mehr benötigte Dateien automatisch gelöscht [2]. 19

20 Das inkrementelle Backup gibt es bereits seit ORACLE Database 8.0. Inkrementelle Backups sichern nur die Änderungen seit dem letzten Backup. In Database 10g lassen sich diese nun schneller durchführen, da die Datenbank sich im laufenden Betrieb die Blöcke merkt, die geändert wurden. Somit entfällt eine lange Suche, wenn das Backup angestoßen wird. Dadurch wird sowohl der Speicherbedarf, als auch die Zeit für das eigentlich Backup reduziert. Ein Hauptproblem für die Sicherheit in Datenbanken ist immer der Benutzer. Fehler, die durch Benutzereingriff entstehen, sind auch sehr schwer zu vermeiden. Um nach einem Benutzerfehler wieder in einen funktionierenden Zustand zurück zu kommen gibt es das flashback feature. Damit kann man sehr schnell den Fehler ungeschehen machen. Die Beispieltabelle (Tabelle 4) zeigt, um wie vieles einfacher es in Database 10g ist, eine versehentlich gelöschte Tabelle wiederherzustellen: Tabelle 4: Wiederherstellung einer versehentlich gelöschten Tabelle Das Verfahren hinter dieser Funktionalität ist das Prinzip des doppelten Bodens, wie man es auch von Windows kennt: Es gibt einen Papierkorb, in dem gelöschte Objekte aufbewahrt werden, bis der Benutzer sich entschließt sie endgültig zu löschen. Bei Database 10g gibt es für dieses endgültige Löschen den neuen PURGE-Befehl. Noch dazu werden alte Objekte im Papierkorb spätestens dann gelöscht, wenn der Speicher für andere Objekte benötigt wird [2]. Alle Objekte, die sich noch im Papierkorb befinden, können wie in Tabelle 4 beschrieben wiederhergestellt werden. 20

21 3. Vergleich zu DB2 In diesem Abschnitt bezieht sich hauptsächlich auf eine Studie der Edison Group, in der Oracle Database 10g und IBM DB2 verglichen wurden (Datum der Studie: ) [8]. Es wurden Aufgaben aus verschiedenen Bereichen, die für die Datenbankadministration relevant sind, gestellt. Dabei wurde geprüft, wie viel Zeit benötigt wird, um die Aufgabe zu lösen und wie viele Schritte erforderlich waren. Bereiche und Ergebnisse: - Installation und erste, einfache out-of-the box Konfiguration. Hier ist ORACLE 11% schneller und braucht 29% weniger Schritte - Täglicher Betrieb: ORACLE ist 52% schneller und braucht 21% weniger Schritte - Sicherungen und Wiederherstellung nach einem Fehler. Sehr gute Werte für ORACLE: 58% schneller und 30% weniger komplex - Performancediagnose und Tuning. Hier ist der Vorteil von ORACLE am größten: 76% schneller und 62% weniger komplex Insgesamt zeigt sich schon, dass ORACLE mit Database 10g sehr gute Performancewerte erzielen konnte. Zusammengefasst über alle Bereiche ergibt sich folgendes Endergebnis: Tabelle 5: Vergleich ORACLE/DB2 Database 10g ist 47% schneller und man braucht im Schnitt 36% weniger Schritte um zum gewünschten Ergebnis zu kommen. Noch dazu wird dann hier die Arbeitsersparnis für den DBA ausgerechnet. Das kann man aber analog zu den oben genannten Daten sehen. Zusammenfassend kann man also sagen, dass die Ergebnisse dieser Studie eine klare Sprache für ORACLE sprechen. Fast 50% Zeitersparnis ziehen für ein Unternehmen erhebliche Kosteneinsparungen nach sich. Da Oracle verstärkt auf einfache Bedienbarkeit wert legt (siehe Enterprise Manager) und auch versucht, viele Informationen und Funktionen direkt am entsprechenden Objekt anzubieten ist dieses Ergebnis verständlich. Allerdings muss man auch 21