Home 
ORDIX News 4/2008 Datenbanken
ORDIX News 4/2008 Datenbanken
ORDIX News 4/2008 Datenbanken
Oracle Datenbanken über eine zentrale Schnittstelle warten wollen.
| Oracle EM Grid Control Oracle Enterprise Manager Grid Control. Nachfolger des Oracle Management Server mit erweitertem Funktionsumfang. Ermöglicht über Plug-In auch das Monitoring und die Administration von Produkten anderer Hersteller. |
| Oracle Streams Funktionalitäten, mit denen Daten zwischen Datenbanken verteilt werden können. |
| RMAN Recovery Manager Das Werkzeug von Oracle zur Sicherung und Wiederherstellung von Datenbanken (Backup, Restore, Recovery und Konvertierung). |
| Transportable Tablespace Ein Verfahren, um sehr einfach und schnell Tablespaces von einer Oracle Datenbank in eine andere zu übertragen. |
Weiterführende Links
Um zur Wartungsseite für Oracle Datenbanken im EM Grid Control zu gelangen, muss zunächst unter "Ziele ⇒ Datenbanken" die gewünschte Zieldatenbank ausgewählt werden. Nachdem man so auf die Übersichtsseite (im EM als Standardverzeichnis bezeichnet) des Zielsystems gelangt ist, findet sich neben den Reitern "Standardverzeichnis", "Performance" und "Administration" auch die "Wartung".
|
Die Wartungsseite des EM Grid Control (siehe Abbildung 1) gliedert sich auf den ersten Blick in die drei Bereiche
Alle drei Bereiche haben jeweils eine Reihe von Unterpunkten.
Hinter High Availability verbergen sich im Wesentlichen Funktionen zum Erzeugen und Einspielen eines Backup per RMAN und Oracle Secure Backup, aber auch ein Assistent zur Einrichtung und Verwaltung von Standby-Datenbanken mit Data Guard.
Diese Funktionalitäten werden in der Praxis über Grid Control nicht häufig genutzt. Unsere Kunden steuern die Backups fast ausschließlich über die zentralen Backup Tools, wie TSM, Networker, Data Protector etc. Diese Vorgehensweise halten wir in größeren Umgebungen auch für absolut richtig. Lediglich in kleineren Umgebungen, in denen ohne zentrales Werkzeug gearbeitet wird, kann über das Aufsetzen eines Backup über EM Grid Control nachgedacht werden.
Die Funktionen für Software Deployment unterstützen den Administrator beim Vergleich von Konfigurationen verschiedener Zielsysteme und beim Einspielen von Datenbank-Patches. Alle hier angebotenen Funktionen finden sich allerdings auch unter dem übergeordneten Menüpunkt "Deployments" wieder. Dieser Menüpunkt wird Thema eines eigenen Artikels dieser Serie sein. Aus diesem Grund werden wir an dieser Stelle den Bereich "Software Deployment" nicht weiter betrachten.
Da der Themenbereich "Verschieben von Daten" den Schwerpunkt dieses Artikels bildet, werden wir im Folgenden detailliert auf die unterschiedlichen Optionen eingehen.
Die unter diesem Punkt vorhandenen Optionen ermöglichen das Importieren und Exportieren von Daten aus der bzw. in die ausgewählte Zieldatenbank. Dabei können unterschiedliche Techniken wie SQL*Loader, Data Pump, Import/Export, Transportable Tablespaces, Oracle Streams, oder das Klonen von ganzen Datenbanken mittels RMAN zum Einsatz kommen.
Da nicht alle diese Techniken auf jedem Zielsystem verfügbar sind, kann die Anzahl der an dieser Stelle angebotenen Optionen bzw. deren Funktionsumfang mit dem Versionsstand der angesprochenen Zieldatenbank schwanken. So wurde zum Beispiel Data Pump erst mit Oracle 10g eingeführt. Die Funktion "aus Datenbank importieren", die Daten mittels Data Pump über einen Datenbank-Link zwischen zwei Systemen kopiert, kann auf einer Zieldatenbank der Version 9i nicht funktionieren und wird daher im EM Grid Control bei einer Datenbank in der Version 9 auch nicht angeboten. In den folgenden Beschreibungen gehen wir daher von einer Zieldatenbank in der Version 10g oder höher aus.
Die Funktion "In Exportdateien exportieren" ermöglicht es, die Daten einer Datenbank in Dateien zu schreiben, um diese zu archivieren oder in einer anderen Datenbank weiterzuverwenden. Dies geschieht mit Hilfe von Data Pump. Wie bei einem manuellen Aufruf von Data Pump kann auch hier zwischen den Exportmodi full, schema, table und tablespace gewählt werden. Der Modus transportable steht an dieser Stelle nicht zur Auswahl, da die Erzeugung von transportablen Tablespaces im EM in einen eigenen Menüpunkt auf der Wartungsseite ausgelagert wurde.
Je nachdem, welchen Modus man ausgewählt hat, können in weiteren Schritten die zu exportierenden Objekte gewählt werden, die maximale Anzahl von Threads für den Export-Job sowie gegebenenfalls der Pfad für die Logdatei gesetzt werden. Nachdem das Zielverzeichnis für den Export bestimmt wurde, kann der soeben erstellte Export-Job entweder sofort gestartet oder als Job für einen späteren Zeitpunkt geplant werden.
Der Link "Aus Exportdateien importieren" führt zu der zum eben beschriebenen Export passenden Importfunktion. Auch hier kann im ersten Schritt der Umfang des Imports bestimmt werden. Zur Auswahl stehen die Modi "ganze Dateien", "Schemas", "Tabellen" und "Tablespace". Nachdem der Nutzer sich für einen Modus entschieden und die zu lesende Exportdatei angegeben hat, wird diese zunächst gelesen und analysiert.
Anschließend besteht in Abhängigkeit vom zuvor gewählten Importmodus die Möglichkeit, auszuwählen, welche Objekte aus der angegebenen Datei importiert werden sollen. Im Modus "Schema" kann der Anwender wählen, ob er die gewünschten Schemata direkt in die Datenbank importieren möchte, oder ob die Objekte eines zu importierenden Schemas in ein bereits bestehendes Schema der Datenbank eingefügt werden sollen. Beim direkten Import muss darauf geachtet werden, dass in der Datenbank bisher kein gleichnamiges Schema vorhanden ist, da ansonsten eine Fehlermeldung erfolgt.
Ähnlich verhält es sich im Modus "Tabellen". Auch hier kann man entscheiden, welchem Zielschema in der Datenbank die Tabellen hinzugefügt werden und in welchen Tablespace sie geschrieben werden sollen. Wie beim Export kann auch der erstellte Import-Job entweder sofort oder später per Job ausgeführt werden.
Der Unterschied zwischen den beiden Funktionen "Import aus Dateien" und "Import aus einer Datenbank" besteht darin, dass die Daten beim Import aus einer Datenbank nicht in einer Datei zwischen zwei Systemen transferiert werden, sondern über einen Datenbank-Link direkt aus der Quelldatenbank gelesen werden. Hierzu kann ein bestehender Datenbank-Link verwendet oder direkt aus dem Auswahlprozess heraus ein neuer Link erstellt werden. Als Technologie für den Transfer kommt auch hier Data Pump zum Einsatz. Daher sind die Auswahlmöglichkeiten für den Anwender prinzipiell die gleichen wie bei dem bereits beschriebenen Import aus Dateien (siehe Abbildung 2).
Neben dem Import über die eigenen Exportformate von Oracle darf an dieser Stelle natürlich auch nicht eine Importmöglichkeit z. B. für csv-Dateien fehlen. Diese verbirgt sich hinter dem Link "Daten aus Benutzerdateien laden". Der erste Schritt beim csv-Import besteht darin, zu wählen, ob die Daten mit Hilfe einer bestehenden Kontrolldatei geladen werden sollen oder ob die benötigte Kontrolldatei vom EM erzeugt werden soll.
Entscheidet man sich für eine bestehende Datei, so ist als nächstes der Pfad dorthin anzugeben und zu bestimmen, ob die Datendatei durch die Kontrolldatei bestimmt oder explizit angegeben werden soll.
Überlässt man die Erstellung der Kontrolldatei dem EM, so muss zunächst der Pfad zur Datendatei angegeben werden. Diese kann entweder auf dem Datenbankserver oder auf dem Rechner des Anwenders, von dem aus Grid Control bedient wird, liegen. Ziel des Imports kann sowohl eine bestehende als auch eine per Assistent neu zu erstellende Tabelle sein.
Für die Erstellung der Kontrolldatei zeigt der EM eine Beschreibung der Zieltabelle und eine Vorschau auf die befüllte Tabelle. Nun kann der Anwender unter anderem festlegen, welche Spalten der Tabelle zu befüllen sind, durch welches Zeichen die Daten in der csv-Datei getrennt sind und ob Spalten mit einem Default-Wert gefüllt werden sollen, falls in der Datei kein passender Datensatz vorhanden ist. Durch einen Klick auf "Dateiformatattribute anwenden" kann jederzeit überprüft werden, wie sich die vorgenommenen Änderungen auf den Ladevorgang auswirken, da mit jedem Klick die Vorschau auf die befüllte Zieltabelle aktualisiert wird (siehe Abbildung 3).
Als Lademethoden stehen "conventional path", "direct path" und "parallel direct path" zur Verfügung. Die Einschränkungen der beiden letztgenannten Methoden werden auf der Seite erklärt, so dass der Anwender sich gezielt entscheiden kann. Abschließend können Optionen, wie das Überspringen von anfänglichen Zeilen oder ein Jobabbruch nach einer bestimmten Anzahl von Fehlern, festgelegt werden.
Für den Fall, dass nicht nur einzelne Datenbankobjekte, sondern ganze Tablespaces oder gar komplette Datenbanken repliziert werden sollen, bietet der EM zwei Alternativen zu den bereits beschriebenen Methoden, die bei großen Datenmengen deutliche Zeitgewinne versprechen:
1. Kopieren der Datenbankdateien
mittels RMAN
3. Übertragen der Dateien auf das
Zielsystem
3. Wiederherstellen des Klons mittels gespeicherter Archivelogs
4. Öffnen des Klons mit der Option
Resetlogs
Auch die Replikation von Daten zwischen zwei Systemen mittels Streams Replication und Advanced Queuing wird von EM Grid Control unterstützt. Dieses Thema wird hier aber aufgrund seines Umfangs nicht weiter behandelt.
Der Enterprise Manager Grid Control bietet eine Menge von Optionen für den Import und Export von Daten aus einer bzw. in eine Oracle Datenbank. Die Assistenten für diese Funktionalitäten wirken übersichtlich und durchdacht. Sie vereinfachen dem Administrator die Arbeit im Vergleich zur Kommandozeile an vielen Stellen.
Roman Peters (info@ordix.de).
