This particular feature is very helpful for DB cloning. In production it takes HR’s to clone a DB (multi tera byte DB) but with the help of this feature it now takes only minutes. So what’s the magic here??
In DB cloning most of the time is taken in moving/copying files from production to test environment.
Here we try to minimize that time. before this we must be clear what is file and how copy of file is performed.
FILE: a tradition file is composed of blocks and headers. whenever we need to move/copy file we just copy all of the blocks and headers and move it to target site. It’s nice and simple but inefficient. HOW???
With improvisioning technology when we need to copy or move a file Rather than copy all of the blocks ONLY HEADERS are moved. And when a block in file is being changed that particular block is sent over target site to keep files in Sync and now headers point to the correct block(Repointering happens). For this reason this technology is called COPY ON WRITE also.
Here minimum IO is required.
HERE WE BUILT THIS ON TOP OF FILE SYSTEM SO THAT UNDERLYING FILE SYSTEM CAN MAKE USE OF THIS.
THE OFFICIAL DOCUMENTATION IS AS FOLLOWED OR YOU CAN FOLLOW (https://blogs.oracle.com/oem/entry/what_is_snap_clone)
In one line, Snap Clone is a self service way of creating rapid and space efficient clones of large (~TB) databases.
Self Service – empowers the end users (developers, testers, data analysts, etc) to get access to database clones whenever they need it.
Rapid – implies the time it takes to clone the database. This is in minutes and not hours, days, or weeks.
Space Efficient – represents the significant reduction in storage (>90%) required for cloning databases
To best explain the benefits of Snap Clone, let’s look at a Banking customer scenario:
5 production databases total 30 TB of storage
All 5 production databases have a standby
Clones of the production database are required for data analysis and reporting
6 total clones across different teams every quarter
For security reasons, sensitive data has to be masked prior to cloning
Based on the above scenario, the storage required, if using traditional cloning techniques, can be calculated as follows:
5 Prod DB = 30 TB
5 Standby DB = 30 TB
5 Masked DB = 30 TB (These will be used for creating clones)
6 Clones (6 * 30 TB) = 180 TB
Total = 270 TB
Time = days to weeks
As the numbers indicate, this is quite horrible. Not only 30 TB turn into 270 TB, creating 6 clones of all production databases would take forever. In addition to this, there are other issues with data cloning like:
Lack of automation. Scripts are good but often not a long term solution.
Traditional cloning techniques are slow while, existing storage vendor solutions are DBA unfriendly
Data explosion often outpaces storage capacity and hurts ITs ability to provide clones for dev and testing
Archaic processes that require multiple users to share a single clone, or only supports fixed refresh cycles
Different priorities between DBAs and Storage admins
Snap Clone to the Rescue
All of the above issues lead to slow turnaround times, and users have to wait for days and weeks to get access to their databases. Basically, we end up with competing priorities and requirements, where the user demands self service access, rapid cloning, and the ability to revert data changes, while IT demands standardization, better control, reduction in storage and administrative overhead, better visibility into the database stack, etc.
EM 12c DBaaS Snap Clone tries to address all these issues. It provides:
Rapid and space efficient cloning of databases by leveraging storage copy-on-write (or similar) technology
Supports all database versions from 10g to 12c
Supports various storage vendors and configurations NAS and SAN
Lineage and association tracking between clone master and its various clones and snapshots
‘Time Travel’ capability to restore and access past data
Deep visibility into storage, OS, and database layer for easy triage of performance and configuration issues
Simplified access for end user via out-of-the-box self service portal
RESTful APIs to integrate with custom portals and third party products
Ability to meter and charge back on the clone databases
So how does Snap Clone work?
The secret sauce lies in the Storage Management Framework (SMF) plug-in. This plug-in sits between the storage system and the DBA, and provides the much needed layer of abstraction required to shield DBAs and users from the nuances of the different storage systems. At the storage level, Snap Clone makes use of storage copy-on-write (or similar) technology. There are two options in terms of using and interacting with storage:
1. Direct connection to storage: Here storage admins can register NetApp and ZFS storage appliance with EM, and then EM directly connects to the storage appliance and performs all required snapshot and clone operations. This approach requires you to license the relevant options on the storage appliance, but is the easiest and the most efficient and fault tolerant approach.
2. Connection to storage via ZFS file system: This is a storage vendor agnostic solution and can be used by any customer. Here instead of connecting to storage, the storage admin mounts the volumes to a Solaris server and format it with ZFS file system. Now all snapshot and clone operations required on the storage are conducted via ZFS file system,. The good thing about this approach is that it does not require thin cloning options to be licensed on the storage since ZFS file system provides these capabilities.
For more details on how to setup and use Snap Clone, refer to a previous blog post.
Now, lets go back to our Banking customer scenario and see how Snap Clone helped then reduce their storage cost and time to clone.
5 Prod DB = 30 TB
5 Standby DB = 30 TB
5 Masked DB = 30 TB
6 Clones (6 * 30 TB) = 180 TB
6 Clones (6 * 5 * 2 GB) = 60 GB
Total = 270 TB 90 TB
Time = days to weeks minutes
Assuming the clone databases will have minimal writes, we allocate about 2GB of write space per clone. For 5 production databases and 6 clones, this totals to just 60GB in required storage space. This is a whopping 99.97% savings in storage. Plus, these clones are created in matter of minutes and not the usual days or weeks. The product has out-of-the-box charts that show the storage savings across all storage devices and cloned databases. See the screenshot below.
Snap Clone Savings
Where can you use Snap Clone databases?
As i said earlier, Snap Clone is most effective when cloning large databases (~TBs). Common scenarios we see our customers best use Snap Clone are:
Application upgrade testing. For example, EBusiness suite upgrade to R12.
Functional testing. For example, testing using production datasets.
Agile development. For example, run parallel development sprints by giving each sprint its own cloned database.
Data Analysis and Reporting. For example, stock market analysis at the close of market everyday.
Its obvious that Snap Clone has a strong affinity to applications, since its application data that you want to clone and use. Hence it is important to add that the Snap Clone feature when combined with EM12c middleware-as-a-service (MWaaS) can provide a complete end-to-end self service application deployment experience. If you have existing portals or need to integrate Snap Clone with existing processes, then use our RESTful APIs for easy integration with third party systems.
In summary, Snap Clone is a new and exciting way of dealing with data cloning challenges. It shields DBAs from the nuances of different storage systems, while allowing end users to request and use clones in a rapid and self service fashion. All of this while saving storage costs.