Creating database clones with ZFS really FAST

While working on my most recent project i tested an interesting ZFS feature: writeable snapshots aka “clones”.

While testing i came to the conclusion that with the help of clones oracle databases (and, of course – other databases as well) can be clones extremely fast with almost no disk space required. So i tested it.

Read on for the results…

Setup everything

Prior testing snapshots i had to install an oracle database and had to create a database. This wont be covered here.

From the output above you will most probably recognize the path for storing our SOURCE database: /u01/oradata/ORA10P.

In this article i will clone the database with the SID “ORA10P” located in “/u01/oradata/ORA10P” to a database with SID “ORA11P” located in “/u01/oradata/ORA11P”.

Cloning the database

Cloning the database uses the ability of ZFS to create snapshots and to mount them as a writable file system. In addition to that we clone an oracle database by re-creating the control files and changing the database SID.

In the following i will outline the required steps:

Step 1 – Create the Snapshot

For the first tests i created the snapshot while the database was closed:

root@oracle:~# zfs snapshot pool1/zones/oracle/db01@db_clone

Step 2 – Create and Mount the Clone

Create a writeable snapshot called “clone”:

zfs clone pool1/zones/oracle/db01@db_clone pool1/zones/oracle/db02

Set Mountpoint for that clone:

zfs set mountpoint=/u01/oradata/ORA11P pool1/zones/oracle/db02

Thats it. With these steps you created a writable snapshop of your database and mounted it at /u01/oradata/ORA11P.

The space shown by “zfs list” shows the occupied amount of space. Referenced blocks are not counted. Immediate after creating the clone all blocks in the clone refer to the original blocks thus taking up no space at all.

Edit them to reflect the new paths:
[…]
LOGFILE
GROUP 1 ‘/u01/oradata/ORA11P/redo01.log’ SIZE 50M,
GROUP 2 ‘/u01/oradata/ORA11P/redo02.log’ SIZE 50M,
GROUP 3 ‘/u01/oradata/ORA11P/redo03.log’ SIZE 50M
— STANDBY LOGFILE
DATAFILE
‘/u01/oradata/ORA11P/system01.dbf’,
‘/u01/oradata/ORA11P/undotbs01.dbf’,
‘/u01/oradata/ORA11P/sysaux01.dbf’,
‘/u01/oradata/ORA11P/users01.dbf’
CHARACTER SET WE8ISO8859P1
;
Note: This is the most important part here. You have to make sure you do not reference any file used by the source database here!

Delete EVERYTHING BELOW

Step 5 – Clone the database by re-creating the control file

After editing the script it should look like the following sample for re-naming the source database with SID “ORA10P” to “ORA11P”:

After setting everything everything up DELETE the control files of the source database located in the clone file system “/u01/oradata/ORA11P“. DO NOT DELETE THE CONTROL FILES OF YOUR SOURCE DATABASE IN “/u01/oradata/ORA10P”!!

After performing the steps above the just re-created control files and redo logs take 81.2 MB space because these blocks are not shared anymore.

The great picture

The example above is just a proof-of-concept. It shows there can be significant storage savings by using ZFs snapshot/cloning mechanism for instance to create database or development or testing purposes.

In addition to that cloing the database is extremely fast and does not depend on the size of the database being cloned. The whole procedure outlined here takes when done manually approx. 5 minutes regardless of the database size.

Most probably (i have not tested this yet) the database can be cloned online by putting the database in hot backup mode (“alter database backup begin”) before taking the snapshot.

indeed it is very promising. I dont think ZFS will be available in Linux withing say 1 year due to copyright problems (afaik).
Anyway with ZFS you can do “Active Dataguard” (i.e. open your database for running reports) without any costs.