Oracle 10g: Es muss kein Grid sein

15.10.2004
Die Einführung von "Oracle 10g" hat der Hersteller sehr stark mit dem Thema Grid-Computing verknüpft. Doch das Datenbank-Upgrade bietet auch unabhängig vom verteilten Rechnen Vorteile für Administratoren.

Von Christian Antognini*

Jede neue Softwareversion enthält Features, die man von Anfang an (out of the box) nutzen kann, und andere, die zwar interessant, aber nur nach intensiven Tests mit gutem Gewissen einsetzbar sind. Hier geht es um die Verbesserungen aus der ersten Kategorie, wobei der Fokus auf komplett neuen oder zumindest stark erweiterten Funktionen für Administratoren und das Monitoring von Datenbanken liegt.

Ein Beispiel dafür ist das Handling von Performance-Daten. Welchem Datenbankadministrator (DBA) ist es nicht schon passiert, dass ein Anwender anrief und fragte, weshalb am Vortag Performance-Probleme auf der Produktionsdatenbank auftraten. Hier hat der DBA nicht nur ein technisches, sondern auch ein Kommunikationsproblem zu bewältigen: Er wurde viel zu spät informiert! Ohne Monitoring-Tool kann er kaum mehr tun, als in das Alert Log zu schauen und eventuell nach Trace Files zu suchen.

Statspack-Probleme behoben

Um Performance-relevante Instanzdaten zu sammeln, legt Oracle daher seit Oracle 8i Release 2 das "Statspack" bei. Hat der DBA dieses PL/SQL-Package mitsamt einem Job zum Sammeln der Performance-Daten installiert, so kann er auch im Nachhinein die problematischsten SQL-Statements analysieren und Hit Ratios vergleichen. Das Problem von Statspack ist aber sein nicht sehr übersichtlicher Output: nur Ascii-Text, nicht einmal HTML, von Grafiken ganz zu schweigen. Zudem können immer nur zwei Datenmengen/Zeitpunkte miteinander verglichen werden, nicht aber eine Sequenz von Daten, das heißt die Entwicklung eines Wertes. Dies ist auch der Grund, weshalb Dritthersteller mit Zusatz-Tools hier eingesprungen sind.

In Oracle 10g wurde nun das Sammeln von Performance-Daten auf eine neue Ebene gehoben. Nicht nur, dass die gesammelten Daten in das "Data Dictionary" der Datenbank integriert sind. Darüber hinaus sind per Default auch Jobs zum Sammeln der Daten aktiviert. Es gibt mit dem "Enterprise Manager" (Grid Control oder Database Control) ein grafisches Interface, und die Betrachtung einer Sequenz von Zeitpunkten ist endlich möglich - quasi also ein Statspack++. Natürlich musste hier ein neuer Name her, "Automatic Workload Repository" (AWR) heißt der jüngste Spross in der Familie des Oracle-Performance-Tunings. Das alte Statspack ist übrigens nach wie vor vorhanden.

Mit Oracle 8i wurden "Transportable Tablespaces" (TTS) eingeführt, um den Transfer von großen Datenmengen zwischen Datenbanken zu beschleunigen. Hier muss man nur noch Metadaten zu den transportierten Tablespaces exportieren und importieren, die Daten selber werden durch OS-Level-Copy der Daten-Files an ihr Ziel gebracht. Das Einklinken der Tablespaces in die Zieldatenbank erfolgt im Zuge des Imports der Metadaten. Der Hauptvorteil dieses Ansatzes besteht in der Vermeidung der ressourcenintensiven Daten-Export/Import-Operationen.

Da beim Transportieren eine Eins-zu-eins-Kopie der Datenfiles angelegt wird, können nur Tablespaces transportiert werden, deren Datenfiles mit denen der Zieldatenbank kompatibel sind. Was heißt nun kompatibel? In Oracle 8i bedeutete dies, dass die Datenbanken auf dem gleichen Betriebssystem laufen, dieselbe Datenbank-Blockgröße und dieselben Zeichensätze (sowohl Character Set als auch National Character Set müssen gleich sein!) benutzen. Das sind ziemlich strenge Voraussetzungen. Vor allem in der Königsdisziplin "Datentransport aus dem Online-Transaction-Processing-(OLTP-)System in das Data Warehouse" wird die Bedingung der gleichen Datenbank-Blockgröße meistens verletzt sein.

Glücklicherweise hat Oracle schon in 9i mit dem Multi-Blocksize-Support einen wesentlichen Stolperstein aus dem Weg geräumt. Der Datentransport aus dem OLTP-System in das Warehouse geht damit problemlos, die Zieldatenbank muss einfach über einen Buffer Cache verfügen, der mit der Blockgröße der Quelldatenbank konfiguriert ist.

Der große Durchbruch kommt mit Oracle 10g: Der Transport von Tablespaces ist nun auch über Betriebssystem-Grenzen hinweg möglich. Prinzipiell läuft der Vorgang gleich ab wie seit Oracle 8i, nur wenn die CPUs der beteiligten Betriebssysteme ein unterschiedliches Byte-Ordering verwenden, müssen die Datenfiles mittels RMAN (Recovery Manager) konvertiert werden, was etwa so viel Zeit benötigt, wie ein RMAN-Backup des Datenfiles dauern würde.

Das "TTS"-Feature wird von Oracle zu den neuen Grid-Komponenten gezählt. Daten sind damit zwischen den Knoten eines Grids verschiebbar. Über die Positionierung von TTS mag man sich streiten, doch das Feature an sich ist genial. Es erlaubt die Plattformmigration auch bei Datenmengen, bei denen bislang ein Export/Import aus Gründen der Zeit oder des Volumens nicht möglich war. Man stelle sich eine Oracle-Datenbank auf einem Network Attached Storage (NAS) vor: Die Migration von einer Sparc-Solaris- auf eine Intel-Linux-Maschine wäre nur noch ein Export/Import der Metadaten plus RMAN-Durchlauf, da die Daten-Files an sich durch das Protokoll Network File System (NFS) ohne File-System-Konversion auf beiden Maschinen sichtbar gemacht werden können.

Eine weitere Verbesserung kommt in Form der "Recycle Bin". Jeder hat schon einmal aus Versehen die falsche Tabelle gelöscht. Vor Oracle 10g lag die einzige Rettung für Anwender ohne Zugang zu Oracle-internen Tools in einer "Database Point in Time Recovery". Zumindest jedoch in einer "Tablespace Point in Time Recovery", was je nach Oracle-Version kein Vergnügen war. Glücklich konnte sich derjenige schätzen, der in solch einer Situation über ein einigermaßen aktuelles, logisches Backup (Export) der Tabelle verfügte.

Mit Oracle 10g gibt es eine viel bequemere Lösung: "FLASHBACK TABLE table name TO BEFORE DROP". So einfach? Ja - der Grund liegt darin, dass Tabellen nicht mehr entfernt, sondern mitsamt Constraints, Triggern und Indizes nur umbenannt werden. Sie wandern in einen logischen Papierkorb, aus dem sie zurückgeholt werden können, sofern der Platz nicht wieder verwendet wurde. Letzteres kann aber nur dann geschehen, wenn eine Data-Management-Operation keinen anderen freien Platz mehr gefunden hat.

Seit Oracle 8 empfiehlt der Hersteller das Backup mit RMAN. Die meisten Backup/Recovery-Novitäten betreffen seitdem auch dieses Tool. Das Oracle-Marketing bewirbt die RMAN-Neuerungen in 10g zwar nur sehr zurückhaltend, für den Betriebs-DBA sind sie jedoch äußerst interessant.

Schnelle inkrementelle Backups

So zum Beispiel die inkrementellen Backups. Diese waren bis jetzt nicht schneller als die Full-Backups, meistens sogar langsamer. Das lag daran, dass Oracle die gesamte Datenbank nach geänderten Blöcken scannen musste. Der Gewinn der inkrementellen Backups lag daher nur in der geringeren Größe. Ab 10g kann Oracle eine Bitmap verwalten, die die geänderten Blöcke kennzeichnet. Auf diese Art sind deutliche Performance-Gewinne möglich, die Backup-Zeit bewegt sich proportional zur Anzahl der geänderten Blöcke. Grundsätzlich sind Backups auch komprimierbar, man muss also nicht mehr manuell die Backup-Pieces nach dem Backup durch "COMPRESS" oder "GZIP" schleusen.

Bis Oracle 9i einschließlich war es empfohlen, nach einer Datebase Point in Time Recovery ein Backup zu erstellen. Durch das "OPEN RESETLOGS" konnte ein Backup, welches vor dem OPEN erzeugt wurde, nicht mehr für ein Recovery nach dem OPEN verwendet werden. Ab Oracle 10g existiert dieses Problem nicht mehr: Ohne dass irgendeine Konfiguration nötig wäre, die Datenbank läuft bei einem Recovery über ein OPEN RESETLOGS hinweg. (ue)

*Christian Antognini

ist Senior Consultant und Trainer für Oracle Database Server bei der Trivadis AG in Zürich.

Features

- Automatic Workload Repository (AWR) für das Handling von Performance-Daten;

- Transportable Tablespaces (TTS), die in 10g auch über Betriebssystem-Grenzen hinweg möglich sind;

- Recycle Bin zur einfachen Wiederherstellung einer versehentlich gelöschten Tabelle;

- Backup und Recovery, in deren Bereich jetzt einige Aktionen schneller oder automatisch ablaufen.

Fazit: nicht mehr Grid als in 9i

Oracle positioniert die Kombination aus 10g RDBMS, Application Server 10g und Enterprise Manager 10g (Grid Control und Database Control) als die erste komplette Grid-Software-Infrastruktur und damit Oracle 10g als die Datenbank der Wahl für das Grid. Oracle 10g ist aber noch nicht wirklich Grid-aware, zumindest nicht mehr, als es schon von Version 9i her bekannt ist. Dies ist aber kein Problem, denn nur sehr wenige Firmen benötigen heute schon ein Grid. Wichtig ist, dass sich viele der neuen 10g-Features auch ohne Grid-Absichten nutzen lassen.