Blog CloneDB – Quick ‘n Easy

Oracle has quietly and secretly provided a new method to duplicate databases with Version 11.2.0.2 (yes, the patchset). CloneDB makes it possible to build up several databases on the basis of a RMAN image copy. Foundation for that is Direct NFS support in the database, introduced with version 11.1.0.6. With that it is possible to run an Oracle database on NFS storage over a special driver (dNFS). With CloneDB a new I/O layer will be implemented, so that reading access will be provided by a RMAN backup and writing access creates own unique files. In the view of the database it looks like there are completely normal data files in use. That means an administrator or an application can not recognize that a clone is in use.

Benefit of Copy-On-Write

CloneDB is easy to set up and the creation of a new clone is realized in minutes and consumes almost no space, the size of the source database doesn’t really matter. This will be achieved by the use of the copy-on-write method, which is already used by ZFS or btrfs file systems for example. The main idea behind copy-on-write (c.o.w.) is very simple. The copy will only be physically built up when it is changed. As long as the copy is not changed it is sufficient to store the original only one time. So at first the copy is still virtual and own data blocks will only be created on changes.

In our case this method will be realized with an RMAN image copy which is locally stored or also located on a NFS storage. This image copy represents our source with read-only access and a NFS share is provided for the referenced c.o.w. files. All together we get a complete clone database although this fact is transparent for the database itself and application accessing it. So far, so good. Until this moment we didn’t save any byte, needed probably more time by providing this instead of our reliable RMAN DUPLICATE. The trick showed up at the moment when you decide to build a second clone. Now we can take our already existing RMAN image copy and reference a second time on it and when we need a third clone also and so on. We didn’t need to work everything two, three or four times out. We didn’t need to transfer gigs or terabytes of data over the network many times. No. Theoretically it’s enough to when make an image one time and provide it. Theoretically because of the fact that every image in database context is at some time outdated. The next thing we have to consider is that, as more data blocks that we change in our test or development environment as more storage space is needed for the c.o.w. files. In an extreme case we have a fully changed copy of our database in our nfs storage. Another point in this context is the backup method. If we do not use image backups for our daily business than you create additional overhead. As last downer we have to be aware of the fact that performance testing is not convincing. Yes you can, but you have different storage technologies and the referential matching between backup and c.o.w. files produces extra I/O.

Everybody who can live with these restrictions and NFS shares doesn’t represents a problem in the own environment and for whom a clear benefit is on the bottom line should follow the next step-by-step instructions to create his own database clone environment with Oracle 11.2.0.2.

Step-by-Step to the clone database

CloneDB is documented in “My Oracle Support” under “Clone your dNFS Production for testing (Doc 1210656.1)”. A Perl script called “cloned.pl” is provided also in this document which is needed for the build-up of a clone. Meanwhile there is an entry in the Administrators Guide “Cloning a Database with CloneDB”. Here you can find an important hint: „The CloneDB feature is supported starting with Oracle Database 11g Release 2 (11.2.0.3).“ In this instruction I work with OE Linux and 11.2.0.4 so I have no problems with that.

This script creates by setting the parameter file two more SQL scripts. The first script „crtdb.sql“ executes only a CREATE CONTROLFILE and provides the basis for the second script. The magic script „dbren.sql“ now links with a DBMS_DNFS.CLONEDB_RENAMEFILE our backup database files with the copy-on-write database files.

If everything runs fine you get … sorry … an error message. No good deed goes unpunished. But chin up, the problem is that the not existent temp tablespace of our clone couldn’t dropped and created. So we had to do it ourselves.

When the scripts are fully executed and TEMP ERROR is corrected you get a working clone. From database perspective everything is fine we can’t find an advice of the existence of a cloned database beside the fact that it’s called CLONE.

Done. Our first clone is provided and testing can be started. And what do we have to do with the next clone? Everything again? Of course not. We have to create a second nfs directory, create a second clone instance on the target server and repeat cloning. When you’re familiar with these steps you can provide new clones in minutes.

With several clones we can go through several test scenarios now. While on clone 1 we test version 1 of our new application we test Version 2 on clone 2 which is must be much better, hopefully. On clone 3 we can now test our recovery scenario which we planned for a long time. As we dropped clone 4 we provide clone 5 because someone forgot the where clause during development. Shit happens…

Sebastian Winkler

6 comments on “CloneDB – Quick ‘n Easy”

Kim

question – have you actually done the 2 clone dbs from the same source on the same server? It sounds as if you need an NFS mount for each clonedb – correct? I am trying this and getting the dreaded ORA-17513: dNFS package call failed. Just looking for guidance.

Kim

Sebastian Winkler

Now I catched your problem… You should create subfolders for several clones behind the mount point that’s quite easier than creating a mount for every single clone but that’s also possible. In this example the CLONE_FILE_CREATE_DEST would be /u01/app/oracle/oradata/CLONE/clone1_subfolder … clone2_subfolder and so on.

Hector Barcelata Carvajal

Johannes Ahrends

The cloned database is acting as any other database. So you can simply drop it if you want and all files of the cloned database will be dropped as well. The original datafiles will not be touched – if that’s your question.