CloneDB – schnell und einfach … aber nicht weitersagen!

CloneDB Feature

Oracle hat mit Version 11.2.0.2 (also mit dem Patchset!) still und heimlich eine neue Möglichkeit für das Duplizieren von Datenbanken zur Verfügung gestellt. CloneDB erlaubt es, auf Basis einer RMAN Image Kopie beliebig viele Datenbanken aufzusetzen. Grundlage hierfür ist die bereits mit Version 11.1.0.6 eingeführte Direct NFS Unterstützung in der Datenbank. Mit Direct NFS ist es zunächst möglich, dass eine Oracle Datenbank über einen speziellen Treiber (dNFS) auf NFS-Laufwerken betrieben werden kann. Mit CloneDB wird jetzt eine zusätzliche I/O Schicht eingeführt, so dass lesende Zugriffe aus dem RMAN Backup bedient werden, während schreibende Zugriffe in eigene Dateien erfolgen. In der Datenbank selbst sieht es allerdings so aus, als ob ganz normale Datafiles benutzt werden, d.h. ein Administrator bzw. eine Anwendung kann nicht erkennen, dass hier ein Clone benutzt wird.

Vorteil Copy-On-Write

CloneDB lässt sich ganz leicht aufsetzen und die Erstellung eines weiteren Clones geschieht in Minuten und verbraucht so gut wie keinen Platz, egal wie groß die Quelldatenbank ist. Dies wird erreicht durch Einsatz des Copy-On-Write-Verfahrens, welches bereits im ZFS oder btrfs Dateisystem ihren Einsatz findet. Die Grundidee hinter Copy-On-Write (C.O.W., englisch für Kopieren-beim-Schreiben) ist ganz einfach, die Kopie wird erst dann „real“ angefertigt, sobald sie verändert wird. Solange die Kopie nicht verändert wird, genügt es, das Original ein einziges Mal zu speichern. Die Kopie erfolgt also zunächst „virtuell“ und eigene Daten-Blöcke werden erst bei einer Veränderung angelegt.

In unserem Fall wird dies also mit einer RMAN Image Kopie, welche lokal oder ebenfalls auf einem NFS-Storage liegen kann, als Quelle auf die nur lesend zugegriffen wird, und einem NFS-Share auf dem unsere referenzierten C.O.W. Files liegen realisiert. Zusammen erhalten wir eine vollständige Klon-Datenbank, wobei dieser Umstand für die Datenbank selbst und Anwendungen die auf diese zugreifen transparent ist. Soweit so gut. Bis zu diesem Zeitpunkt haben wir noch kein einziges Byte Speicher gespart, mit der Einrichtung des ganzen sogar noch mehr Zeit gebraucht als mit unserem bewährten RMAN DUPLICATE. Der eigentliche Clou zeigt sich sobald man auf die Idee kommt einen zweiten Clone aufzusetzen. Denn jetzt können wir unsere bereits vorhandene RMAN Image Kopie wieder hernehmen und ein zweites Mal darauf referenzieren und wenn wir einen dritten Clone brauchen wieder und so weiter. Wir müssen uns also nicht alles zwei, drei oder viermal zurechtlegen nicht zigmal Giga- oder gar Terabyte an Daten übers Netz schicken. Nein. Theoretisch reicht es aus wenn wir uns einmal ein Image ziehen und dieses bereitstellen. Theoretisch deshalb, weil jedes Backup Image im Datenbankumfeld natürlich über kurz oder lang veraltet ist. Des Weiteren müssen wir bedenken, je mehr Datenblöcke bei Test- oder Entwicklungsarbeit verändert werden, desto mehr Speicher wird in der C.O.W. Location benötigt. Im Extremfall haben wir eine vollständig veränderte Kopie unserer Datenbank in unserem NFS-Share liegen. Ein weiterer Punkt in dem Zusammenhang ergibt sich auch aus der Backup-Methode. Falls man nicht mit Image Backups arbeitet muss man den zusätzlichen Overhead an dieser Stelle natürlich auch kalkulieren. Als letzten Wehrmutstropfen muss man sich sicherlich der Einschränkung bezüglich Performancetests bewusst sein. Ja, man kann, aber was bringt das, wenn unterschiedliche Storage-Technologien genutzt werden und auch für den Referenzierungsabgleich zwischen Backup und C.O.W. Files zusätzlicher I/O entsteht.

Wer mit diesen Punkten leben kann, für den auch ein NFS-Share im eigenen IT-Umfeld kein Problem darstellt und für den unterm Strich eine klare Verbesserung herausspringt, kann mit der nachfolgenden Step-by-Step Anleitung ganz einfach selbst sein Clone-Umfeld unter 11g aufbauen. 

Step by Step zur Clone Datenbank

CloneDB ist im My Oracle Support unter „Clone your dNFS Production for Testing (Doc ID 1210656.1)“ dokumentiert. In diesem Dokument wird auch ein Perl-Skript namens „clonedb.pl“ bereitgestellt, welches Sie für den Aufbau eines Clones benötigen. Inzwischen gibt es zu dem Thema auch einen Eintrag im Administrators Guide „Cloning a Database with CloneDB“ in dem sich ein erster wichtige Hinweis findet: „The CloneDB feature is supported starting with Oracle Database 11g Release 2 (11.2.0.3).“ Wir arbeiten also mit dem neuesten 11g Release unter OE Linux (11.2.0.4) und haben in dieser Hinsicht keine Probleme.

NFS Server Setup

Auf unserem NFS-Server müssen wir zunächst ein Verzeichnis für unsere C.O.W. Files erstellen.

# mkdir -p /u01/nfshare/clonedb/klon

Exportieren des Verzeichnisses durch Eintragen in etc/exports.

/u01/nfshare/clonedb/klon         *(rw,sync,no_wdelay,insecure,insecure_locks,no_root_squash)

Produktions-Backup

Erstellen eines Image Kopie Backups der Datenbank. Die Kopie kann lokal oder ebenfalls auf einem NFS Share abgelegt werden.

$ rman target /

BACKUP AS COPY erstellt eine Byte-for-Byte Kopie der Datenbank.

RMAN> configure controlfile autobackup off; RMAN> sql 'alter database begin backup'; RMAN> backup as copy database format '/u03/orabackup/prod/%U'; RMAN> sql 'alter database end backup'; 

Parameterfile der Produktion

Erstellen einer Kopie des PFILE der Produktion.

$ sqlplus / as sysdba SQL> CREATE PFILE='/u03/orabackup/prod/initKLON.ora' FROM SPFILE; 

Alle Referenzen zu Original-SID und –Datenbank entsprechend dem künftigen Klon ändern. Ab Datenbankversion 11.2.0.3 muss zusätzlich der Parameter „clonedb“ im PFILE des Klons auf „true“ gesetzt werden.

*.clonedb=true

CloneDB Server Setup

Linken des Direct NFS Moduls.

$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk dnfs_on 

Erstellen aller notwendigen Verzeichnisse zum Mounten des NFS und starten der Instanz.

# su - oracle $ mkdir -p $ORACLE_BASE/oradata/KLON $ mkdir -p $ORACLE_BASE/fast_recovery_area/KLON $ mkdir -p $ORACLE_BASE/admin/KLON/adump $ mkdir -p $ORACLE_BASE/admin/KLON/dpdump 

NFS mount in /etc/fstab für ein automatisches Verbinden beim Reboot eintragen.

nas1:/u01/nfshares/clonedb/klon /u01/app/oracle/oradata/KLON  nfs  rw,bg,hard,nointr,tcp,vers=3,timeo=600,rsize=32768,wsize=32768,actimeo=0  0 0

Mounten des NFS Verzeichnisses als „oracle“ User. Ownership und Permission sollten überprüft werden.

# mount /u01/app/oracle/oradata/KLON

Klonen

Umgebungsvariablen setzen.

$ export ORACLE_SID=KLON $ export MASTER_COPY_DIR=/u03/orabackup/prod $ export CLONE_FILE_CREATE_DEST=/u01/app/oracle/oradata/KLON $ export CLONEDB_NAME=KLON 

Perl-Skript clonedb.pl ausführen. Dieses Skript finden Sie entweder in $ORACLE_HOME/rdbms/install/clonedb.pl oder als Attachment im My Oracle Support unter Doc ID 1210656.1.

$ perl clonedb.pl /u01/app/oracle/product/11.2.0.4/db_1/dbs/initKLON.ora crtdb.sql dbren.sql

Dieses Skript erzeugt unter Angabe des Parameterfiles zwei weitere SQL-Skripte. Das erste Skript „crtdb.sql“ führt lediglich ein CREATE CONTROLFILE durch und bildet die Grundlage. Mit dem zweiten Skript bekommen wir aber die Magie in unseren Clone. Das zweite Skript „dbren.sql“ verlinkt mit einem DBMS_DNFS.CLONEDB_RENAMEFILE unsere Backup-Databasefiles mit den Copy-On-Write Databasefiles.

$ sqlplus / as sysdba Connected to an idle instance. @crtdb.sql @dbren.sql 

Wenn alles funktioniert hat bekommen Sie … Trommelwirbel … eine Fehlermeldung. Wie sollte es anders sein bei Oracle, keine Medizin ohne Nebenwirkungen. Aber halb so wild, es konnte lediglich der nicht vorhandene TEMP-Tablespace unseres Clones gelöscht und neu erstellt werden. Daher müssen wir das selber übernehmen.

SQL> alter tablespace TEMP add tempfile '/u01/app/oracle/oradata/KLON/temp01.dbf' size200M; Tablespace altered. 

Sobald die Skripte vollständig ausgeführt sind und der TEMP ERROR behoben ist erhält man einen funktionierenden Clone. Aus Datenbanksicht ist alles normal einen Hinweis auf die Existenz als Klon lässt sich bis auf unsere Bezeichnung nicht finden.

SELECT 	t.name AS tbs, 	d.name AS dbf, 	status FROM 	v$datafiled JOIN 	v$tablespacet ON t.ts# = d.ts# ORDER BY t.name; TBS		DBF							STATUS --------------------------------------------------------------------------- EXAMPLE 	/u01/app/oracle/oradata/KLON/ora_data_KLON0.dbf 	ONLINE SYSAUX 		/u01/app/oracle/oradata/KLON/ora_data_KLON1.dbf 	ONLINE SYSTEM 		/u01/app/oracle/oradata/KLON/ora_data_KLON2.dbf 	SYSTEM UNDOTBS1 	/u01/app/oracle/oradata/KLON/ora_data_KLON3.dbf 	ONLINE USERS 		/u01/app/oracle/oradata/KLON/ora_data_KLON4.dbf 	ONLINE

Auf OS-Ebene lässt sich nun der feine Unterschied erkennen. Die Copy-On-Write Location enthält jetzt nur die geänderten Blöcke und keine vollständige Kopie der Databasefiles.

$ du -k /u03/orabackup/prod/* 162452	/u03/orabackup/prod/data_D-PROD_I-4197193115_TS-EXAMPLE_FNO-5_0eom14qg 614412	/u03/orabackup/prod/data_D-PROD_I-4197193115_TS-SYSAUX_FNO-2_0bom14rf 716812	/u03/orabackup/prod/data_D-PROD_I-4197193115_TS-SYSTEM_FNO-1_0aom14po 312332	/u03/orabackup/prod/data_D-PROD_I-4197193115_TS-UNDOTBS1_FNO-3_0com14ss 5128	/u03/orabackup/prod/data_D-PROD_I-4197193115_TS-USERS_FNO-4_0dom14tl $ du -k /u01/app/oracle/oradata/KLON/*.dbf 20	/u01/app/oracle/oradata/KLON/ora_data_KLON0.dbf 55	/u01/app/oracle/oradata/KLON/ora_data_KLON1.dbf 89	/u01/app/oracle/oradata/KLON/ora_data_KLON2.dbf 201	/u01/app/oracle/oradata/KLON/ora_data_KLON3.dbf 18	/u01/app/oracle/oradata/KLON/ora_data_KLON4.dbf 9851	/u01/app/oracle/oradata/KLON/KLON_ctl.dbf 

Zum Abschluss noch ein Hinweis: Bei einem Hot Backup muss man die Datenbank gegebenenfalls Recovern.

SQL> recover database using backup controlfile until cancel; SQL> alter database open resetlogs; 

So geschafft, unser erster Klon steht, das testen kann losgehen. Und was machen wir jetzt beim nächsten Klon? Alles von vorn? Natürlich nicht. Wir müssen lediglich ein zweites NFS Verzeichnis erstellen, auf unserem bereits konfigurierten Clone-Server eine zweite Instanz anlegen und das Klonen wiederholen. Wenn man mit den einzelnen Schritten vertraut ist, kann man in kürzester Zeit einen Klon nach dem anderen bereitstellen.

Mit mehreren Klonen können wir nun auch verschiedene Testszenarien durchspielen. Während wir auf Klon 1 Version 1 unserer neuesten Applikation auf die Datenbank loslassen testen wir mit dem zweiten eine leicht abgewandelte, vielleicht verbesserte Version, das wird sich zeigen. Auf Klon 3 können wir nun endlich den schon lange geplanten Recovery-Test durchführen. Während wir Klon 4 wieder wegschmeißen und Klon 5 bereitstellen weil irgendwer beim Entwickeln die Where-Klausel vergessen hat. Kann passieren …

• I   – Datenbank-Virtualisierung und Instant Cloning … und was macht 12c
• II  – CloneDB – schnell und einfach … aber nicht weiter sagen!