Blog 
Database virtualization and instant cloning … and 12c

Clone Wars

When we’re hearing „Clone“, most people will associate it with Star Wars the Clone Wars … something like that, The main idea behind the clones was that they are identically as possible with identical functions, that means that they have the same power, strength and what else.

When we think about cloning databases, it’s not really different. Target is to create a copy of the production environment which is preferably as much identical as we can get it, for testing and development purposes. In most cases it will not stop with only one copy. Over the time different requirements need different copies and more and more copies have to be provided. At the end it comes to our „Clone War“ between the tasks that a DBA has to accomplish and the modest requirements of the developers.

In this blog series I will shortly describe different methods for cloning to give then an example for cloning with CloneDB feature for Oracle 11gR2 databases, snapshot copy for our new 12c Multitenant database and at the an extremely fancy high-end solution by a third-party developer called Delphix.

  • I   – Database virtualization and instant cloning … and 12c
  • II  – CloneDB – Quick ‘n Easy
  • III – 12c Snapshot Copy – Plug ‘n Clone
  • IV – Delphix – Database virtualization for Pros

Capabilities of cloning

The need to copy databases for testing or development almost exists as long as databases exists. Usually there will be made a backup of the database and after that recovered on another server. The required time and the required space are normally the limiting factors. That means you have to make some compromise regarding the actuality and the number of copies.

Since Oracle 11g a very simple method exists for cloning a database with RMAN. You have to login to the source database (TARGET) and an existing instance on the target system (AUXILARY) and use the DUPLICATE command to create a copy. Don’t get confused by TARGET (source database) and AUXILARY (clone database).

% rman target sys/manager@PROD auxiliary sys/manager@MYCLONE RMAN> DUPLICATE TARGET DATABASE; 

For building the database RMAN uses an existing backup of the primary database and with the help of archived Redolog files the clone database can rolled out to any given moment.

Since Oracle 11g Release 2 even direct cloning is possible without a previous backup of the primary database. The command doesn’t change significantly:

RMAN> DUPLICATE TARGET DATABASE FROM ACTIVE DATABASE; 

Of course there are various options, for example the declaration of the directories for the database files but in general this short statement really is sufficient to create a clone.

So, what’s the problem?

Certainly for one clone this procedure is enough, but what is when we have to create several clones. The backup charged the production. It means negative effects for our performance besides the running time for backup and cloning. You will not copy a database in one or two hours which has several terabytes of data. But much more important is the fact that every new clone needs the same space as the production. With that fact you’re really fast on natural limits and the limit of possible clones in your environment.

A lot of companies get by with this problem by using Data Pump. Instead of the whole database only a little part or the part that is really needed for the project will be copied. That saves space but is usually slower because you need to create a database body and as we all know Data Pump is not the fastest method for copying big amounts of data. In spite of using the parameter NETWORK_LINK without temporary storing the dump files like the DUPLICATE this method is space-consuming and time-consuming.

Maybe we can learn from virtualization

In the meantime some methods are established in virtual environments, which uses a reading and a altered version of one date. That means many guest systems access the same resource for reading and only altered parts will be stored in a unique copy. This so called copy-on-write (c.o.w.) is used by ZFS storage for example. The advantage is obvious: Less storage is needed or by the way consumed and the clone can be provided much faster because only links on existing files must be provided.

Expire how we get with patchset 11.2.0.2 on the quiet a possibility to save a lot of time and storage and which role copy-on-write plays at that on the following article “CloneDB – Quick ‘n Easy

No comments on “Database virtualization and instant cloning … and 12c

Leave a Reply

Your email address will not be published. Required fields are marked *

What can CarajanDB do for you?