Inhaltsbereich

Datenbankclone mit Oracle 11g und RMAN

Der RMAN Duplicate Befehl wurde in Oracle 11g deutlich verbessert: erstmals kann ein Datenbankclone über das Netzwerk erstellt werden. Insbesondere Kunden mit sehr großen Datenbanken, bei denen in der Praxis kein RMAN-Backup eingesetzt wird, profitieren von dieser Erweiterung. Neben diesem Key Feature gibt es einige weitere Punkte, in denen der Duplicate-Befehl erweitert wurde. Häufig besteht der Bedarf für eine exakte Kopie der Produktionsdatenbank, beispielsweise als Testdatenbank oder für Monats- bzw. Quartalsabschlüsse. Seit Oracle 8i kann dies mit Hilfe des RMAN Befehls Duplicate recht einfach und komfortabel durchgeführt werden. Dies allerdings ausschließlich entweder aus einemDisk-Backup oder einem Tape-Backup.

Showstopper dieses Features waren und sind aufgrund dieser Einschränkung vor
allem bei sehr großen Datenbanken meist folgende Aspekte:


• In der Praxis wird bei großen Datenbanken immer noch selten ein DiskBackup (z.B. über die Flash Recovery- Area) eingesetzt - vermehrt finden
sich hier die klassischen Bandsicherungen mit Betriebssystemmitteln.
• Wird bei einer Bandsicherung ein RMAN-Backup benutzt, steht oft kein
ausreichend langes Zeitfenster zu Verfügung, um die Sicherung auf Band zu
erstellen und anschließend aus dieser Sicherung den Clone wieder zu
erzeugen: Bei Datenbanken im Terabyte-Bereich reicht oftmals ein
Wochenende hierfür nicht aus.
• Voraussetzung für dem Duplicate-Befehl ist außerdem grundsätzlich ein
Backup-Konzept mit RMAN; werden die Backups mit Betriebssystemmitteln
durchgeführt, wird selten die Möglichkeit eines RMAN-Clones überhaupt in
Erwägung gezogen. Soll dennoch ein Datenbankclone erstellt werden, so ist
es erforderlich, die Datenbank im geschlossenen Zustand zu kopieren:
Offlinezeit und Performanceeinbüßen durch Verlust der Caches müssen in
Kauf genommen werden.


Mit Oracle 11g kann nun der Datenbankclone über das Netzwerk erstellt werden,
ohne dass ein RMAN-Backup vorliegt. Es ist auch nicht notwendigerweise eine
Backupstrategie mit RMAN erforderlich. Das große Plus: Selbst dann, wenn die
Sicherung mit Betriebssystemmitteln geschieht, kann ohne Weiteres der
Datenbankclone mit RMAN erstellt werden. Weiter können sämtliche Parameter der
Produktionsdatenbank kopiert werden. Somit entfällt die Notwendigkeit geänderte
Parameter der Produktion in allen Clonedatenbanken nachzupflegen.
RMAN-DUPLICATE-RUN-Befehl
Die recht einfachen Schritte zur Vorbereitung sind in der Metalink Note:452868.1
dargestellt.

RUN 
{
DUPLICATE TARGET DATABASE TO test 
FROM ACTIVE DATABASE 
DB_FILE_NAME_CONVERT 
'/ora/oradata/data/prod/','/ora/oradata/data/test/', 
'/ora/oradata/index/prod/','/ora/oradata/index/test/' 
PASSWORD FILE 
SPFILE 
PARAMETER_VALUE_CONVERT 
'/ora/admin/prod/diag/','/ ora/admin/test/diag/', 
SET LOG_FILE_NAME_CONVERT '/ora/redo/prod', 
'/ora/redo/test' 
SET MEMORY_TARGET = 5G; 
}


Die neuen Klauseln im Duplicate-Befehl: 
FROM ACTIVE DATABASE: die Daten werden über das Netzwerk kopiert, ohne  dass Zugriff auf den TARGET-Host über NFS z.B. eingerichtet werden muss.  DB_FILE_NAME_CONVERT konvertiert die Datendateinamen. Hier wird der 1. durch den 2, der 3. durch den 4. usw. ersetzt. In früheren Releases wurde diese Klausel als Parameter in die AUXILIARY-Datenbank eingetragen. Diese Klausel ist zwingend notwendig, wenn die Clone-Datenbank auf dem gleichen Host erstellt 
werden soll, damit das Ziel der Kopien von dem Original abweicht. 
PASSWORD FILE: Die Passwort-Datei wird kopiert. Als Resultat sind alle Anwender mit SYSDBA bzw. SYSOPER-Rolle auch in der Clonedatenbank entsprechend privilegiert. 
SPFILE: Das Spfile wird kopiert. Somit sind die aktuellen Einträge mit denen der Clone-Datenbank identisch. 
PARAMETER_VALUE_CONVERT:  Hiermit werden Werte der Parameter 
substituiert. Ist – wie im obigen Beispiel – in der Produktionsdatenbank der Wert des Parameters DIAGNOSTIC_DEST auf /ora/admin/prod/diag/ gesetz, so wird dieser in der Test auf / ora/admin/test/diag/ verändert. 
SET: An dieser Stelle können weitere Parameter umgesetzt werden. Hier im Beispiel: 
der LOG_FILE_NAME_CONVERT, der analog dem DB_FILE_NAME_CONVERT die 
Pfade der Online-Redologdateien substituiert. Der Parameter MEMORY_TARGET wird möglicherweise umgesetzt, weil der Zielhost im RAM nicht gleichermaßen ausgestattet ist wie die Produktivdatenbank oder weil der Clone auf dem gleichen Host erstellt wird und der Hauptspeicher hauptsächlich der Produktionsdatenbank zu 
Verfügung gestellt wird. 


FAZIT: Das bis dato ohnehin schon leistungsstarke Tool RMAN wurde mit dieser  Erweiterung des DUPLICATE-Befehls mit einem weiteren Highlight stark verbessert.  Es bietet nun – unabhängig vom Backup-Konzept – die Möglichkeit, eine  Datenbankkopie mit RMAN zu erstellen und ist auch bei sehr großen Datenbanken erste Wahl.
Kontakt: Claus Cullmann 
Erstellt von Claus Cullmann Copyright by eXirius IT Dienstleistungen GmbH

Wiederherstellen Archivelogs aus Backup

Möchte man Archivelogs aus einem Backupset wieder herstellen, kann dies mit
Hilfe von ein paar einfachen Befehlen getan werden.
export ORACLE_HOME=oracle_home<
export ORACLE_SID=sid>
Anmelden am RMAN
rman target user/passwort
Restore aller Archivelogs:

run {
set archivelog destination to '/tmp';
restore archivelog all;
}


Restore nach Sequenzen:

run {
set archivelog destination to '/tmp';
restore archivelog sequence between 46067 and 46114;
}


Restore nach Zeitpunkt:

run {
set archivelog destination to '/tmp';
restore archivelog from time 'SYSDATE-5' until time 'SYSDATE-1';
}


Restore nach SCN

run {
set archivelog destination to '/tmp';
restore archivelog BETWEEN 1000 AND 2000;
}


Wird die Archivelog Destination nicht gesetzt schreibt Oracle in die
default Location.

Rechter Inhaltsbereich

eXirius IT Dienstleistungen GmbH
Juchem-Straße 24
66571 Eppelborn

Telefon: +49 (6881) 99 99 5 - 0
Fax:        +49 (6881) 99 99 5 - 77

E-Mail: info(at)exirius.de