Who's online

There are currently 0 users and 33 guests online.

Recent comments


Database Thin Cloning: Summary

This post is part of an ongoing series:


These blog posts on thin cloning have covered a number of ways to create database thin clones, yet there are still some challenges:

Database-managed Cloning with Oracle Clonedb

  • Performance issues
  • Requires dNFS
  • Oracle and higher only
  • No possibility of branching clones
  • No practical way to share datafiles from clones of the source DB at different points in time

Copy on Write with EMC COFW

  • Can cause write overhead on source filesystems
  • No branching of clones
  • Difficulty in maintaining efficient changes on secondary arrays
  • Limit of 16 snapshots per LUN

Redirect on Write with EMC VNX ROW

  • Limit of 256 snapshots per LUN
  • Difficulty maintaining efficient storage of changes from source database on secondary storage array

Write Anywhere File System with NetApp

  • Limit of 255 snapshots per file or LUN
  • Support provided for maintaining source database changes efficiently on a second array; however, they require a number of products and implementation overhead
  • Size limited to 16-100TB depending on the model of array

Allocate on Write with ZFS

  • Unlimited and instantaneous snapshots with no space overhead
  • Possibility of efficiently sending changes from a source array to a secondary array but no documentation exists for these methods

Each of these technologies faces different challenges. One obvious constraint is that any solution that depends on a vendor such as EMC, NetApp, or Oracle will tie the solution only to that storage solution. Some concepts such as Clonedb and Illumos ZFS can be run on any storage but have other constraints.

One of the consistent challenges across all of these technologies is the expert knowledge and extensive manual configuration that can impede implementation of these technologies to provide database thin clones. If database thin clones reduce storage so dramatically as well as reduce cloning times drastically, the technology normally would have taken off across multiple industries. This technology involving filesystem snapshots has existed since the mid 1990s—almost a decade and a half ago. In 1994, StorageTek introduced the virtual disk in their Iceberg release. In 1995 Iceberg started supporting filesystem snapshots. However after 15 years, database thin cloning is still rarely used.

The answer to this riddle lies in an analogy. The analogy is the Internet: it was around years before the browser was ever used. Before browsers one could do many things that they can do today on the Internet: use email, transfer files (via FTP), go to chat rooms, and use bulletin boards. But until the browser was created most activity on the Internet was from academics. It wasn’t until the introduction of the browser that usage of the Internet exploded. In a similar way it wasn’t until the introduction of Database Virtualization that usage of database thin cloning began to explode.

Stay tuned for new series on Data Virtualization for Databases, i.e. Database Virtualization.
Upcoming blog posts will discuss
  • OEM 12c Database as a Service (DBaaS) for Netapp
  • Snapshot Management Utility (SMU) for ZFS storage Appliance
  • Delphix any storage even JBODs