Logo Oracle Deutschland   DBA Community  -  April 2013
Direct NFS Clone - Klonen der Oracle Datenbank zum Testen
von Sebastian Solbach ORACLE Deutschland B.V. & Co.KG

Mit Oracle 11gR1 wurde direkt in die Oracle Binärdateien ein NFS 3 Client implementiert. Diese Direct NFS bzw. DNFS genannte Funktionalität brachte die optimale Anbindung für Network Attached Storage (NAS) mit sich, welches per NFS angebunden ist. DNFS ersetzt damit die betriebssystemeigenen NFS Clients oder ergänzt, wie im Falle von Windows, das Betriebssystem um einen standardisierten NFS Client für die Oracle Datenbank.

DNFS bietet dabei für die Oracle Datenbank erhebliche Performanceverbesserungen. Diese werden einerseits durch die Eliminierung des Betriebssystem NFS Layers bei einem Datenbank Storage Zugriff erreicht, andererseits wird eine bessere Performance dadurch erzielt, dass der Storage nun über bis zu 4 Pfade angesprochen werden kann (die betriebssystemeigenen NFS Clients können nur 2). Beim Einsatz von NFS Storage und einer Oracle 11g Datenbank empfiehlt es sich also, in jedem Fall DNFS einzusetzen. Details zu den Vorteilen von DNFS können in folgendem Whitepaper nachgelesen werden: Oracle Direct NFS Client with Oracle Database 11g Release 1

Neben den Performancevorteilen bietet DNFS aber noch eine weitere wichtige Funktion: DNFS Clone - die Möglichkeit, eine Datenbank zu Testzwecken zu klonen. Hierbei wird nicht, wie bei einem RMAN DUPLICATE, die komplette Datenbank kopiert, sondern die "Copy-On-Write" Technologie verwendet, um lediglich geänderte Blöcke festzuhalten. Dadurch ist ein DNFS Clone nicht nur schnell erzeugt, sondern nimmt auch relativ wenig Plattenplatz ein. Schaut man sich die Implementation näher an, so stellt man fest, dass diese Funktionalität auch zur Verfügung steht, wenn die Produktivdatenbank selbst nicht auf NFS liegt.

Direct NFS

Die Dateien einer Datenbank können lokal im Filesystem, in ASM oder auf einem NFS Filer liegen. Liegen die Dateien auf NFS, wird normalerweise dieses Filesystem über den betriebssystemeigenen NFS Client gemounted und erlaubt somit den Zugriff auf Datendateien, als ob es sich um ein lokales Dateisystem handelt.

Direkt NFS erlaubt es nun, dass das Oracle Executable selber direkt auf dieses NFS Filesystem zugreifen kann (ohne den Umweg über den NFS Client des Betriebssystems). Hierzu wurde der notwendige NFS Client Code einfach in das Oracle Exectuable integriert und muss nur noch aktiviert werden. Wenn alle Vorraussetzungen erfüllt sind, reicht der Standard NFS Eintrag für Oracle Datenbankdateien in der /etc/fstab und ein "make -f ins_rdbms.mk dnfs_on" aus:

$ cat /etc/fstab
...      
sccloud016:/opt/oracle  /nfsmount   nfs rw,bg,hard,nointr,tcp,vers=3,rsize=32768,wsize=32768,timeo=600  0 0

$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk dnfs_on
rm -f /opt/oracle/product/11.2.0.3/db/lib/libodm11.so; 
cp /opt/oracle/product/11.2.0.3/db/lib/libnfsodm11.so /opt/oracle/product/11.2.0.3/db/lib/libodm11.so
Wie die Anbindung eines NFS Filers mit DNFS im Detail funktioniert, steht in der MOS Note DNFS: Example About How To Setup DNFS (Direct NFS) On Oracle Release 11.2 [ID 1452614.1]. Die Einsatzmöglichkeiten und Vorteile von DNFS sind im Whitepaper
Oracle Direct NFS Client with Oracle Database 11g Release 1 beschrieben.

Zum Testen von DNFS und Ausprobieren des DNFS Clone ist allerdings kein NAS Storage notwendig, sondern es kann auch ein normaler Linux Server / Openfiler oder anderer Software NFS Server verwendet werden. Dies ist von Oracle zwar für den produktiven Einsatz nicht supported, zum Testen reicht dies aber allemal. Zum Einrichten eines NFS Servers findet man im Netz viele Anleitungen, auch Oracle hat eine simple beschrieben im Zusammenhang mit DNFS: Step by Step - Configure Direct NFS Client (DNFS) on Linux (11g) [ID 762374.1]. Allerdings gibt es dabei den einen oder anderen Stolperstein, auf den am Ende dieses Tipps eingegangen wird.

Direct NFS Clone - Ein Backup als Grundlage

Basis für ein DNFS Clone ist immer ein Backup, d.h. ein RMAN Backup oder ein Snapshot eines Storage Systems. Dieses Backup muss über NFS erreichbar sein und erklärt auch, warum die Produktivdatenbank nicht auf NFS liegen muss. Für DNFS Clone muss kein eigenes Backup angelegt werden, sondern jedes vollständige Backup via Image Kopie kann herangezogen werden. Ein Cold Backup ist ebenso als Grundlage möglich wie ein Hot Backup einer Datenbank im Archivelogmodus.

Möchte man explizit ein Backup für DNFS Clone via RMAN anlegen, so könnte dies über den Befehl "BACKUP AS COPY DATABASE FORMAT" passieren:

rman target sys/oracle@orcl
RMAN> BACKUP AS COPY DATABASE FORMAT '/opt/oracle/backup/%U';

Starting backup at 18-APR-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=28 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00002 name=/opt/oracle/oradata/orcl/sysaux01.dbf
output file name=/opt/oracle/backup/data_D-ORCL_I-1340774340_TS-SYSAUX_FNO-2_03o7cn3a 
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting datafile copy
input datafile file number=00001 name=/opt/oracle/oradata/orcl/system01.dbf
output file name=/opt/oracle/backup/data_D-ORCL_I-1340774340_TS-SYSTEM_FNO-1_04o7cn44
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting datafile copy
input datafile file number=00003 name=/opt/oracle/oradata/orcl/undotbs01.dbf
output file name=/opt/oracle/backup/data_D-ORCL_I-1340774340_TS-UNDOTBS1_FNO-3_05o7cn4t
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile copy
copying current control file
output file name=/opt/oracle/backup/cf_D-ORCL_id-1340774340_06o7cn5c
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile copy
input datafile file number=00005 name=/opt/oracle/oradata/orcl/users01.dbf
output file name=/opt/oracle/backup/data_D-ORCL_I-1340774340_TS-USERS_FNO-5_07o7cn5d
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 18-APR-13
channel ORA_DISK_1: finished piece 1 at 18-APR-13
piece handle=/opt/oracle/backup/08o7cn5e_1_1 tag=TAG20130418T105434 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 18-APR-13
Dabei wird eine Image Kopie auf /opt/oracle/backup angelegt. Wir gehen davon aus, dass "/opt/oracle/backup" ein Verzeichnis eines NFS Filers ist, welches auf dem Testserver unter /nfsmount gemounted wird. Zum Testen würde es auch reichen, dieses Verzeichnis mit Hilfe eines NFS Shares zu exportieren, also dafür zu sorgen, dass es von einem NFS Client gemounted werden kann. Es muss aber hier explizit erwähnt werden, dass dies nicht von Oracle unterstützt wird.

Damit die Testdatenbank erzeugt werden kann, muss diese ein Controlfile besitzen. Dieses Controlfile wird aus der Primärdatenbank erzeugt:
sqlplus sys/oracle@orcl
SQL> ALTER DATABASE BACKUP CONTROLFILE to TRACE;

Database altered.
Der Befehl erzeugt ein SQL Skript zum Erzeugen der Controlfiles für die Clone Datenbank. Das erzeugte Trace sieht man im alert.log der Datenbank und findet sich unter $ADR_BASE/rdbms/<dbname>/<dbname>/trace/ . Das darin befindliche SQL sollte nun für die Backup Datenbank angepasst werden: Der Datenbankname wird geändert, die Datendateien sollten auf die Backupdateien verweisen und für die Redologs ein neues Verzeichnis verwendet werden.
$ cp /opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_2413.trc createclonecontrolfile.sql
$ vi createclonecontrolfile.sql

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE SET DATABASE "CLONE" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/nfsmount/backup/clone/redo01.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 '/nfsmount/backup/clone/redo02.log'  SIZE 50M BLOCKSIZE 512
DATAFILE
  '/nfsmount/backup/data_D-ORCL_I-1340774340_TS-SYSTEM_FNO-1_04o7cn44',
  '/nfsmount/backup/data_D-ORCL_I-1340774340_TS-SYSAUX_FNO-2_03o7cn3a',
  '/nfsmount/backup/data_D-ORCL_I-1340774340_TS-UNDOTBS1_FNO-3_05o7cn4t',
  '/nfsmount/backup/data_D-ORCL_I-1340774340_TS-USERS_FNO-5_07o7cn5d'
CHARACTER SET AL32UTF8
;
Das Keyword SET ist dabei zusätzlich hinzuzufügen und wichtig, weil sonst dieses Kommando fehlschlägt, da der Datenbankname nicht zum Header der Datendateien passt.

Damit die Datenbank gestartet werden kann, kopiert man am einfachsten das SPFile der Primär Datenbank und ändert entsprechende Parameter ab. Hierzu gehören insbesondere die Parameter Audit_file_dest, db_recovery_file_dest, diagnostic_dest und control_files. Neu ist auch der init.ora Parameter CLONEDB, der auf TRUE gesetzt sein sollte, da ansonsten der Clone mit einem ORA-01511 und ORA-01141 fehlschlägt. Hier eine Beispiel initclone.ora in dem die wichtigsten Änderungen rot markiert sind.
db_name='CLONE'
memory_target=512M
processes = 150
audit_file_dest='/opt/oracle/admin/clone/adump'
audit_trail ='db'
db_block_size=8192
db_domain=''
db_recovery_file_dest='/opt/oracle/fast_recovery_area'
db_recovery_file_dest_size=2G
diagnostic_dest='/opt/oracle'
dispatchers='(PROTOCOL=TCP) (SERVICE=ORCLXDB)'
open_cursors=300
remote_login_passwordfile='EXCLUSIVE'
undo_tablespace='UNDOTBS1'
control_files = (/nfsmount/backup/clone/clone.ctl)
compatible ='11.2.0'
clonedb = TRUE
Danach kann die Datenbank mit dieser initclone.ora gestartet und das Create Controlfile ausgeführt werden:
$ export ORACLE_SID=clone
$ sqlplus / as sysdba
SQL> startup nomount;
ORACLE instance started.

Total System Global Area  534462464 bytes
Fixed Size                  2230072 bytes
Variable Size             327157960 bytes
Database Buffers          201326592 bytes
Redo Buffers                3747840 bytes

SQL> @createclonecontrolfile.sql

Control file created.
Nun kommt der eigentliche Teil, den DNFS Clone zu aktivieren. Hierzu wird für jede einzelne Datendatei ein Clone erzeugt:
begin
dbms_dnfs.clonedb_renamefile(
  '/nfsmount/backup/data_D-ORCL_I-1340774340_TS-SYSTEM_FNO-1_04o7cn44',
  '/nfsmount/backup/clone_system.dbf');
dbms_dnfs.clonedb_renamefile(
  '/nfsmount/backup/data_D-ORCL_I-1340774340_TS-SYSAUX_FNO-2_03o7cn3a',
  '/nfsmount/backup/clone_sysaux.dbf');
dbms_dnfs.clonedb_renamefile(
  '/nfsmount/backup/data_D-ORCL_I-1340774340_TS-UNDOTBS1_FNO-3_05o7cn4t',
  '/nfsmount/backup/clone_undo.dbf');
dbms_dnfs.clonedb_renamefile(
  '/nfsmount/backup/data_D-ORCL_I-1340774340_TS-USERS_FNO-5_07o7cn5d',
  '/nfsmount/backup/clone_users.dbf');
end;
/

PL/SQL procedure successfully completed.
Dieser Befehl erzeugt nun die "Copy on Write" Snapshot Dateien. Diese müssen sich explizit ebenfalls in einem Verzeichnis befinden, welches über DNFS angesprochen wird. Lokale Dateien sind hier nicht möglich.

Dass diese Dateien kaum Platz brauchen, erkennt man nicht mit einem ll sondern mit Hifle des Linux du Befehls:
$ ll
total 2023848
-rw-r----- 1 oracle oinstall 859840512 Apr 18 21:34 clone_sysaux.dbf
-rw-r----- 1 oracle oinstall 775954432 Apr 18 21:34 clone_system.dbf
-rw-r----- 1 oracle oinstall 419438592 Apr 18 21:34 clone_undo.dbf
-rw-r----- 1 oracle oinstall   5251072 Apr 18 21:34 clone_users.dbf
-rw-r----- 1 oracle oinstall 859840512 Apr 18 10:54 data_D-ORCL_I-1340774340_TS-SYSAUX_FNO-2_03o7cn3a
-rw-r----- 1 oracle oinstall 775954432 Apr 18 10:55 data_D-ORCL_I-1340774340_TS-SYSTEM_FNO-1_04o7cn44
-rw-r----- 1 oracle oinstall 419438592 Apr 18 10:55 data_D-ORCL_I-1340774340_TS-UNDOTBS1_FNO-3_05o7cn4t
-rw-r----- 1 oracle oinstall   5251072 Apr 18 10:55 data_D-ORCL_I-1340774340_TS-USERS_FNO-5_07o7cn5d

$ du -k *
8       clone_sysaux.dbf
8       clone_system.dbf
8       clone_undo.dbf
8       clone_users.dbf
840512  data_D-ORCL_I-1340774340_TS-SYSAUX_FNO-2_03o7cn3a
758512  data_D-ORCL_I-1340774340_TS-SYSTEM_FNO-1_04o7cn44
410012  data_D-ORCL_I-1340774340_TS-UNDOTBS1_FNO-3_05o7cn4t
5140    data_D-ORCL_I-1340774340_TS-USERS_FNO-5_07o7cn5d
Die Dateien werden erst dann größer, wenn sich etwas an den Datendateien äntert.

Hat es sich beim Backup um ein HOT Backup gehandelt, ist für die geklonten Datendateien ein Recovery und ein "open resetlogs" notwendig. Da im neu erstellten Controlfile aber keine Informationen zu den Backups von Archivelogs enthalten sind, wird der RECOVER Befehl nach den entsprechen Archivelogs nachfragen.
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
ORA-00279: change 1081809 generated at 04/18/2013 10:54:34 needed for thread 1
ORA-00289: suggestion :
/opt/oracle/fast_recovery_area/CLONE/archivelog/2013_04_18/o1_mf_1_3_%u_.arc
ORA-00280: change 1081809 for thread 1 is in sequence #3

Specify log: {=suggested | filename | AUTO | CANCEL}
/nfsmount/fast_recovery_area/ORCL/archivelog/2013_04_18/o1_mf_1_2_8pzf4ly9_.arc

ORA-00279: change 1101791 generated at 04/18/2013 22:01:14 needed for thread 1
ORA-00289: suggestion :
/opt/oracle/fast_recovery_area/CLONE/archivelog/2013_04_18/o1_mf_1_4_%u_.arc
ORA-00280: change 1101791 for thread 1 is in sequence #4
ORA-00278: log file
'/nfsmount/fast_recovery_area/ORCL/archivelog/2013_04_18/o1_mf_1_3_8q0n8bdp_.arc
' no longer needed for this recovery

Specify log: {=suggested | filename | AUTO | CANCEL}
CANCEL
Media recovery cancelled.

SQL> ALTER DATABASE OPEN RESETLOGS;

Database altered.
Ab nun steht die Testdatenbank zur Verfügung und man kann mit dieser arbeiten. Dabei werden nur Änderungen an den Datenfiles in den geclonten Files gespeichert und die original Backup Dateien bleiben bestehen. Dies kann man auch gut anhand des Zeitstempels bzw. der Dateigröße sehen:
$ ll
-rw-r----- 1 oracle oinstall 859840512 Apr 18 22:04 clone_sysaux.dbf
-rw-r----- 1 oracle oinstall 775954432 Apr 18 22:04 clone_system.dbf
-rw-r----- 1 oracle oinstall 419438592 Apr 18 22:04 clone_undo.dbf
-rw-r----- 1 oracle oinstall   5251072 Apr 18 22:04 clone_users.dbf
-rw-r----- 1 oracle oinstall 859840512 Apr 18 10:54 data_D-ORCL_I-1340774340_TS-SYSAUX_FNO-2_03o7cn3a
-rw-r----- 1 oracle oinstall 775954432 Apr 18 10:55 data_D-ORCL_I-1340774340_TS-SYSTEM_FNO-1_04o7cn44
-rw-r----- 1 oracle oinstall 419438592 Apr 18 10:55 data_D-ORCL_I-1340774340_TS-UNDOTBS1_FNO-3_05o7cn4t
-rw-r----- 1 oracle oinstall   5251072 Apr 18 10:55 data_D-ORCL_I-1340774340_TS-USERS_FNO-5_07o7cn5d

$ du -k *     
13308   backup/clone_sysaux.dbf
8336    backup/clone_system.dbf
10968   backup/clone_undo.dbf
16      backup/clone_users.dbf
840512  backup/data_D-ORCL_I-1340774340_TS-SYSAUX_FNO-2_09o7dtre
758512  backup/data_D-ORCL_I-1340774340_TS-SYSTEM_FNO-1_0ao7dtrt
410012  backup/data_D-ORCL_I-1340774340_TS-UNDOTBS1_FNO-3_0bo7dtsn
5140    backup/data_D-ORCL_I-1340774340_TS-USERS_FNO-5_0do7dtt7
Selbstverständlich erlaubt dieses Feature auch das Anlegen mehrerer Testdatenbanken auf denselben Dateien. Wird die Testdatenbank nicht mehr benötigt, können die Files die zur Testdatenbank gehören einfach gelöscht werden. Dies hat keine Auswirkungen auf die Produktion oder das Backup der Produktion. Das Backup hingegen sollte nicht gelöscht werden, da sonst die Testdatenbanken nicht mehr funktionieren.

In der MOS Note "Clone your dNFS Production Database for Testing [ID 1210656.1]" ist zuzätzlich zu einem weiteren Beispiel auch ein Perl Skript enthalten, welches den Clone Prozess automatisiert und das Umbenennen der Dateien damit vereinfacht.

Die Funktionalität des DNFS Clone bietet eine schnelle, platzsparende und günstige Variante, Testdatenbanken aufzusetzen.

Anmerkungen: Linux als NFS Server Tipps & Tricks

Hat man keinen richtigen NAS Storage und NFS Server zur Hand, so tut es auch ein einfacher Linux Rechner zum Testen. Allerdings gibt es beim Aufsetzten des NFS Exports, des NFS Clients und von DNFS den einen oder anderen Stolperstein. Deswegen sind hier kurz die wichtigsten Optionen aufgelistet.

Die /etc/exports Datei für den NFS Server sollte zwingend folgende Parameter enthalten (für Single Instanz Datenbanken):

/opt/oracle        *(rw,sync,all_squash,insecure,anonuid=54321,anongid=54321)
Vergisst man z.B. "insecure", so quittiert der Clone dies mit einem "ORA-1511: error in renaming log/data files" und "ORA-17513: dNFS package call failed".

Mount Optionen beim Client /etc/fstab:
sccloud016:/opt/oracle  /nfsmount   nfs rw,bg,hard,nointr,tcp,vers=3,rsize=32768,wsize=32768,timeo=600  0 0
Aktivieren von DNFS im Oracle Exectuable unter 11.2:
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk dnfs_on
rm -f /opt/oracle/product/11.2.0.3/db/lib/libodm11.so; 
cp /opt/oracle/product/11.2.0.3/db/lib/libnfsodm11.so /opt/oracle/product/11.2.0.3/db/lib/libodm11.so
Optional /etc/oranfstab. Diese ist nicht notwendig, da DNFS automatisch auf die NFS Betriebssystem Mounts zugreift. Sollte die Clone Datenbank aber beim Starten "hängen", könnte dies an einem Bug im Linux Kernel liegen. In diesem Falle schafft ein neuer Linux Kernel (beim Client) Abhilfe. Alternativ umgeht man dies elegant durch die Verwendung der /etc/oranfstab:
server: sccloud016.de.oracle.com
path: 10.165.244.198
local: 10.165.244.200
export: /opt/oracle mount: /nfsmount

Nützliche Links und Referenzen

  • Oracle Direct NFS Client with Oracle Database 11g Release 1
  • Clone your dNFS Production Database for Testing [ID 1210656.1]
  • DNFS: Example About How To Setup DNFS (Direct NFS) On Oracle Release 11.2 [ID 1452614.1]
  • Step by Step - Configure Direct NFS Client (DNFS) on Linux (11g) [ID 762374.1]
  • Zurück zur Community-Seite