Die meisten Daten, die eine Datenbank verarbeitet, werden letztlich in einem Storage-Subsystem abgelegt. Jedes Betriebssystem stellt hierzu spezielle Verwaltungs- und Zugriffskonzepte zur Verfügung. Die älteste Variante ist der direkte, ungepufferte Zugriff, auch bekannt als Raw Devices. Zwischen einer Applikation (hier das Oracle RDBMS) und einem Raw Device befinden sich keine Betriebssystem-Schichten wie zum Beispiel zusätzliche Caches oder die File-System-Logik, so dass die I/O-Performance nahezu optimal ist.
Zwei Verfahren - zwei Nachteile
Das Fehlen einer Schicht zwischen Applikation und Hardware hat aber auch Nachteile, der wichtigste ist der Mangel an Flexibilität. Aus diesem Grunde gibt es File-Systeme. Sie abstrahieren von der physischen Schicht der Devices und ermöglichen der Applikation eine sehr viel flexiblere Handhabung der Speichersysteme. Es ist natürlich unvermeidbar, dass diese zusätzliche Schicht auch Overhead mit sich bringt, insbesondere, weil sie die Anforderungen vieler unterschiedlicher Applikationen erfüllen muss. Aus diesem Grund haben Hersteller wie Veritas in Zusammenarbeit mit Oracle neue File-Systeme entwickelt, die die speziellen Bedürfnisse einer Datenbank berücksichtigen und so die Flexibilität eines klassischen Dateisystems (File-Allokation) mit den Performance-Vorteilen von Raw Devices verbinden. Nachteil ist aber, dass hier ein weiterer Hersteller ins Boot kommt und die File-Systeme relativ teuer sind.
Die Lösung mit ASM
Um diesen Nachteil auszuräumen und die Gesamtkosten eines Datenbank-Servers zu senken, hat Oracle nun eine eigene Schicht des Storage-Managements entwickelt, welche die Funktionen von Volume Manager und File-System vereint und speziell auf die Bedürfnisse einer Oracle-Datenbank - insbesondere im Grid-Umfeld - zugeschnitten ist: "Automated Storage Management" (ASM).
Die Verantwortung für Storage verschiebt sich hierbei vom Systemadministrator zum Datenbankadministrator (DBA) und zur Datenbank. Während früher der Systemadministrator Disks zu Mirrors und Stripesets zusammengefasst und darauf File-Systeme erstellt hat, ist er heute nur noch für das Ändern des Besitzers des Raw Device zuständig. Der DBA gruppiert die Devices dann in Gruppen (mit null, einem oder zwei Spiegeln) und erstellt darauf die Tablespaces. Funktionen wie Striping werden von der Datenbank automatisch erledigt, weder Systemadministrator noch DBA müssen sich darum kümmern. Das gilt auch für die Verzeichnishierarchie. Der DBA definiert einfach die Disk-Gruppe, auf der ein Tablespace liegt, dieser wird dann von Oracle automatisch platziert beziehungsweise verteilt, und die entsprechende Ordnerstruktur wird erstellt.
Das liest sich dann so:
CREATE TABLESPACE users DATAFILE ?+DISK_GROUP_01? SIZE 200M.
Zu beachten ist, dass eine Disk-Gruppe durch das vorangestellte "+" gekennzeichnet wird.
Um mit ASM zu arbeiten, ist eine "Menge von Prozessen" erforderlich, die die administrativen Arbeiten (zum Beispiel das Re-Balancing) erledigen. Eine Menge von Prozessen bedeutet im Oracle-Jargon eine Instanz, die per Voreinstellung "+ASM" heißt. Wohlgemerkt: Es handelt sich um eine Instanz, also keine Daten-oder Control-Files, sondern nur um einen Parameter-File, der zudem äußerst klein ist. Der eigentliche Aufbau der Diskgroups ist auf diesem gespeichert. Es ist zudem wichtig, zu verstehen, dass der I/O immer direkt von der Datenbankinstanz zu den Disks geht und nie über eine ASM-Instanz. Quasi als "Verzeichnisdienst der ASM-Instanzen", der auch im Cluster-Umfeld zum Tragen kommt, dient der "Oracle Cluster Synchronization Service Daemon" (OCSSD), der bei der Installation der Oracle-Software schon fest im System verankert wurde.
Vieles läuft automatisch
Unterm Strich lässt sich sagen, dass ASM die Anforderungen an Datenbank-Storage (einfache Administration und gute Performance ohne zusätzliche Kosten) erfüllt. Die Administration ist zentralisiert, kann über Kommandozeile (SQLPLUS) oder über GUI (Database oder Grid Control) erfolgen und verläuft so weit wie möglich automatisch. Natürlich wird jeder DBA ein so zentrales Features zuerst einmal in seiner Umgebung intensiv testen, insbesondere das Verhalten bei Plattenausfällen.
Über die letzten Jahre hat sich "Real Applications Cluster" (RAC), der ehemalige Oracle Parallel Server, zu einer zuverlässigen und performanten Cluster-Lösung gemausert. Es handelt sich sicher um eine der interessantesten, wenn auch eine der teuersten Optionen der Oracle Enterprise Edition. In Oracle 10g wurde die Feature-Liste der RAC-Option nicht wesentlich modifiziert. Es gibt aber drei Änderungen, die die Kosten von RAC massiv senken und damit auch seine Verbreitung erhöhen werden.
Was die RAC-Kosten senkt
Die erste ist, dass Oracle ab sofort für alle Plattformen, auf denen RAC erhältlich ist, eine eigene Cluster-Manager-Software mitliefert: die "Cluster Ready Services" (CRS). Schon in Oracle 9i traf dies auf Windows und Linux zu, jetzt gibt es sie unter anderem auch für Solaris und HP-UX. Die Kosten für ein Dritthersteller-Produkt entfallen damit, denn CRS ist in die RAC-Option integriert. Will man aus Gründen der Einheitlichkeit oder weil man dem neuen Produkt noch nicht traut, mit einer anderen Cluster-Software arbeiten, ist dies auch weiterhin möglich. Oracle positioniert CRS als zentrale Komponente der Datenbankschicht im Grid Computing.
Komplexität löst sich auf
Die zweite für RAC relevante Verbesserung ist ASM. Während im Single-Instance-Betrieb manche Anwender das Striping und die Raw-Device-Performance nicht zum Anlass nehmen, die Speicherarchitektur zu wechseln, verhält sich das bei RAC anders. Hat man kein spezielles Cluster-File-System oder keinen Network Attached Storage (beides ist teuer), dann muss man mit Raw Devices arbeiten, denn Aufgaben wie das Backup der archivierten Redo Logs sind nicht trivial. Mit ASM ist das allerdings kein Thema: Daten- und Control-Files, archivierte Redo Logs, Server-Parameter-Files etc. sind mit exzellenter Performance von allen Knoten mit einfachen Mitteln handhabbar.
Die dritte Verbesserung ist nicht mehr technischer Natur: Die RAC-Option ist in der Standard Edition kostenfrei enthalten, falls das Cluster insgesamt nicht mehr als vier Knoten hat. Das heißt, man kann heute eine relativ kleine Datenbank, zum Beispiel den Katalog eines Internet-Shops, anstatt auf einem Intel-Server mit vier Prozessoren zu gleichen Oracle-Lizenzkosten auf zwei Zwei-Prozessor-Knoten hochverfügbar auslegen. Dass hier kein Cluster-Manager eines Drittherstellers unterstützt wird, lässt sich wohl verschmerzen.
Zurücksetzen der Datenbank
Ein weiteres 10g-Feature ist "Flashback Database". Im Fall von logischen Datenproblemen oder Benutzerfehlern war es der DBA gewohnt, eine Point-in-Time-Recovery des Tablespace, meistens aber der Datenbank vorzunehmen. Dieser Vorgang erforderte zwei Schritte: Das Zurückholen der Daten-Files sowie ihr Ausrollen mit Hilfe der inkrementellen Backups oder archivierten Redo Logs. Technisch funktioniert das zwar gut, bei einem 2 TB umfassenden Data Warehouse überlegt man sich diesen Schritt aber zweimal. Ein versehentliches Drop Table wird dann unter Umständen auf eine andere, aufwändigere Art behoben, aber immer noch schneller erledigt als bei einem Restore der kompletten Datenbank.
Ein besserer Ansatz wäre es, die Datenbank mit Hilfe der Redo Logs zurückzusetzen. Dies kann Oracle aber nicht, man denke nur an Kommandos wie Truncate Table. Dennoch hat Oracle das Zurücksetzen mit einem neuen Feature implementiert, allerdings nicht auf Basis der Redo Logs. Falls die Datenbank im so genannten Flashback-Modus betrieben wird (ALTER DATABASE FLASHBACK ON im Mount-Status), kopiert ein neuer Hintergrundprozess (RVWR) in regelmäßigen Abständen die "Before Images" von geänderten Blöcken in einen speziellen Bereich auf der Platte, die "Flash Recovery Area". Will man nun den Inhalt der Datenbank zu einem vergangenen Zeitpunkt wiederherstellen, so werden die entsprechend älteren Block-Images der geänderten Blöcke aus dieser Flash Recovery Area zurückgeholt und mit Hilfe der Redo Logs auf den gewünschten Zeitpunkt zurückgesetzt, die Datenbank muss also im Archivelog-Modus betrieben werden. Wie weit man mit dieser Methode zurückgehen kann, wird über einen Instanzparameter (DB_FLASHBACK_RETENTION_TARGET) bestimmt.
Dabei ist darauf zu achten, dass die mit Flashback Database zurückzusetzenden Daten-Files tatsächlich vorhanden und auch nicht durch Plattenfehler beschädigt sind. Die Flash Recovery Area ist also kein Ersatz für ein normales Backup!
Schließlich gehört noch die "Data Pump" zu den herausragenden 10g-Features. Jeder DBA kennt die Tools zum logischen Sichern und Zurückholen von Daten: EXP und IMP. Über die letzten zehn Jahre hat Oracle nur wenige wirklich neue Features in diese Werkzeuge eingebaut, die Architektur blieb sogar komplett unverändert. Ein Blick zurück in die Zeit, in der EXP und IMP entwickelt wurden, lässt schnell erkennen, dass die Datenbanken seinerzeit viel schneller und einfacher aufgebaut waren. Es ist also nicht verwunderlich, dass Oracle entschieden hat, die beiden Tools komplett durch Data Pump Export (EXPDP) und Data Pump Import (IMPDP) zu ersetzen. Die alten Tools sind vorerst aber immer noch vorhanden und werden auch unterstützt.
Schneller Im- und Export
Das Hauptziel der neuen Architektur ist die Geschwindigkeitssteigerung beim Export und Import. Dies wird vor allem - aber nicht nur - durch Parallelisierung erreicht. Genauer: Für eine bestimmte Operation werden jeweils mehrere Slave-Prozesse und Daten-Files unterstützt. Andere Features machen den Export und Import flexibler, so zum Beispiel das Job-Management, das dynamische Hinzufügen von Dump Files und Prozessen zur Laufzeit sowie der Import/Export über Database Links. Die wichtigste Änderung in der Architektur besteht darin, dass das ganze Processing durch das Paket DBMS_DATAPUMP abgewickelt wird. Man kann also von einem Server-managed-Export sprechen, so wie von einem Server-managed-Backup. EXPDP und IMPDP sind dabei nur noch Steuerprogramme, wie RMAN ein reines Steuerprogramm für den eigentlichen Backup-Server-Prozess ist. Ein willkommener Nebeneffekt der paketbasierenden Architektur ist, dass man aus einer PL/SQL-Applikation einen Export oder Import starten kann, ohne ein externes Programm aufrufen zu müssen.
Für 9i nicht geeignet
Data Pump wurde als spezieller Treiber (neben dem bisherigen ORACLE_LOADER) auch in die externen Tabellen integriert. Damit ist es möglich, externe Tabellen mittels CREATE TABLE aus Oracle heraus zu erstellen. Leider ist das externe Tabellenformat dann aber ein binäres und kann nur über den DATA-PUMP-Treiber wieder gelesen werden (also nicht mit Oracle 9i). Ein echtes SQLUNLDR als Pendant zum SQLLDR fehlt immer noch.
Es ist offensichtlich, dass Oracle mit der Version 10g nicht nur das Datenbank-Management vereinfacht, sondern auch Aufgaben von Partnern wie EMC und Veritas übernehmen möchte. Sollten sich ASM und CRS langfristig als genügend stabil und unterstützt erweisen, werden diese Hersteller mit mehr als nur I/O-Balancing, einem File-System oder einem Cluster-Manager die Oracle-Kunden überzeugen müssen. (ue)