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
Copy on Write with EMC COFW
Redirect on Write with EMC VNX ROW
Write Anywhere File System with NetApp
Allocate on Write with ZFS
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.