Delphix versus Oracle Snap Clone for Oracle Database Logical Recovery

Background

More frequently than we care to imagine, customers require to be able to recover quickly from scenarios where a database table or data is lost from production either through physical storage corruption or logical mistakes.  Due to the size and complexity of the environments these issues can take a long time to recover from.  Frequently we find that a customer's recovery time objective is challenging to meet.

Many customers use storage replication for HA and DR, however this does not protect against physical storage corruption nor logical mistakes.  Any such corruption would be replicated intact.  Corruption issues can be identified by application users but frequently they are identified much later during backups using RMAN block validation.

An Oracle standby database using database flashback still does not solve the problem because of the time taken to flashback a database and the administration overhead of managing flashback recovery areas.

Customers require a solution that can start up a clone or virtual copy database in minutes, from a specific point in time, to quickly source a database object that can be used to restore the production copy.

Most of the end-to-end recovery time is consumed locating, restoring and recovering the right version of the database.  It is an iterative process to find the most recent non-corrupted database copy.

Both Delphix and Oracle Snap Clone could be viewed as alternative solutions to implement Logical Recovery.

Key Requirements for Logical Recovery

There are three key requirements to implement a logical recovery solution.

1.    Synchronising with Source Database(s)

This solution requires that you have access to a continuous rolling window of backups since you will need to restore database objects (usually tables) from a version of the production database immediately prior to the corruption or fault occurring.  You want to restore the latest good copy of the database object(s).

2.    Provisioning Database Copies

The solution must also be able to provision a database copy to a point-in-time extremely quickly as this may have to be performed several times before the most up-to-date ‘good’ version of the object is located.

3.    Simplicity

The entire recovery process must be automated, easy to use and fast.  Recovery scenarios are stressful events and intuitive ease of use avoids artificial delays during the recovery process itself.

Oracle EM 12c DBaaS Snap Clone for Logical Recovery

1.    Synchronising with Source Database(s)

For continuous synchronisation with a source database Oracle requires a replication method to maintain an up-to-date Test Master from which all clones will be provisioned.

The replication method is typically an Oracle Data Guard physical standby.

The storage on which the standby is running is limited to Sun Storage, NetApp or EMC.  You can use any other storage as long as you have a server running Solaris to create and manage a ZFS file system on that storage.

Challenges

1.     Requires a licensed database server to run the standby database instance

2.     Enough storage for a full physical copy of the source databases

3.     Administration overhead managing the standby database, for example, synchronising nologging operations on the source database and physical changes including datafile addition and deletion

4.     Limited set of storage options

5.     Additional licenses are required if using 3^rd party, NetApp or EMC, snapshots capabilities 

2.    Provisioning Database Copies

Oracle Snap Clone can provision point-in-time clones of the Test Master from storage snapshots.

Challenges

1.     All target servers where clones are deployed must be licensed with

·       Oracle Database Lifecycle Management Pack

·       Cloud Management Pack

3.    Simplicity

Even customers who are familiar with Enterprise Manager may find that installing, configuring and managing DBaaS Snap Clone is non-trivial.

Delphix for Logical Recovery

1.    Synchronising with Source Database(s)

Delphix synchronises with source database seamlessly using an RMAN initial full backup and incremental forever backups including transaction log files.  All the ingested data is compressed to typically 50% of the size.  The compression saves storage for the source and virtual copies but more importantly improves the IO performance of virtual copies.

When we perform an incremental synchronisation (SnapSync) we can also validate the integrity of the database using validated synchronisation.  This will ensure that the backup copy we have can be used for recovery and the data is intact.  It also speeds up the process of provisioning a virtual copy.  The validated SnapSync could be run as frequently as required to support the recovery time objective.

Advantages

• With Delphix there is no requirement for a Standby Database
• Synchronisation is automatic regardless of any database changes (nologging, physical etc)
• Easy to define a retention policy for the span of time you want to keep backups
• Validated Sync can continuously check for corruptions and recoverability of the Delphix database copy
• No additional Oracle licenses required

2.    Provisioning Database Copies

Delphix can provision a virtual copy of a database in minutes to any point-in-time within the retention period of the source copy.  Provisioning can be performed via the GUI, CLI or API.  You can also provision as many copies as you want concurrently, from independent points in time to accelerate the time to restore service.

3.    Simplicity

                       

Delphix is easy to install, has automated discovery of source systems, once synchronisation is established with a retention period and one or more target servers are configured to provision virtual databases to there is very little monitoring or maintenance required.

Key advantages of Delphix over Oracle DBaaS Snap Clone 

1.     Easy to install and configure

2.     Complete automation of restore and recover process

3.     No requirement for multiple standby environments, avoiding setup, maintenance, monitoring, server capacity and licenses.

4.     Continuous validation and recovery of ingested backups as a further safeguard against corruptions and providing early detection of issues.

5.     Reduced Storage requirement

6.     Lower maintenance

7.     Minimal Licensing, with no additional licenses required if want to expand usage for provisioning non-production database copies

8.     More References

If you could give every developer a copy of the database, would you?

The simple truth is that databases can’t be given to every developer like source code.

Databases can be large, complex, and extremely difficult to copy. It is rare to see developers or even development groups that have a copy of the full production database to use for their tasks.

On the other hand, developers almost always have access to a full copy of the application code stack. Source control methods like git make it easy to clone, fork, and track code from the component level to the entire codebase.

For databases, the typical strategies are:

1. Share a full copy of the source database across a group
2. Provide small subsets of data from the source database to developers
3. Allocate schema only ‘databases’ per developer

Each of these strategies presents their own problems.

Sharing a database across a group of developers means that any change one developer makes can impact the other developers. There is no automated way to protect a group of developers from the changes of a single developer. To protect development problems that can be caused by new changes, the changes have to be reviewed. Reviews can take up to a couple of weeks, meaning the coder who wants to implement these changes has to wait. The first in a long line of delays as a result of inadequate database resources.

If developers are given subsets of the database (partial copies, only some data) or empty skeleton schemas, it will easily lead to code that has not been tested on the full range of data that is present in production. This of course opens the door to untested bugs born from outliers in the data and queries that are not optimized on the full set of data. Finding these bugs late in the development cycle is more costly by far than finding them immediately with the developer writing the code.

With Delphix you can........

Version data like code

How does it work?

According to one of our customers...

"Delphix maintains a continuous streaming backup of our production databases and allows us to create as many full copies as we want.  Copies can be masked or unmasked and are created in minutes, using minimal storage.   Delphix enables us to deliver projects faster whilst saving us time and money.”

Agile or Fragile

At a recent DevOps presentation by Gene Kim I was reminded of some startling facts on what differentiates high performing IT organisations from everyone else.

High performing  IT organisations do not have code freezes, in fact they make more changes during the periods that would otherwise be code freeze periods.  This seems counter intuitive, how is this even possible?   A code freeze typically occurs at peak periods of customer activity and hence no one wants to make changes which might upset the running of live applications.   Sounds sensible but what it really means is that just at the very time when changes could have the most beneficial impact you don’t make them because of a more fundamental issue, you are not able to make changes safely, in other words your code release process is fragile.

Agile development advocates that you can make changes frequently, but for that you must be able to make changes safe in the knowledge that these changes will not regress the functionality or performance of live applications.  High frequency changes also means you can experiment and prove the value of alternative solutions in production, testing not the stability of the change but the suitability of the change.

Agile development teams don’t measure releases per year but deployments per day.  A deployment is any change to any component of the application, environment or infrastructure.  Which reminds me of another startling observation, another top predictor of IT performance is “version control for all production artifacts”.  We all know that there are just as many configuration changes as there are source code changes and version control allows you to provision, compare and debug holistically.   The first question anyone asks when something breaks is “what changed?” which is relatively easy to answer for source code using source code control but is usually difficult and time consuming to answer for everything else.

So how does Delphix virtual data help with agile development?  A key to implementing agile development is making environments available early in the development cycle.  For database based applications that means provisioning a full read write copy of the database for every developer, tester and batch test activity.   A de-sensitised copy of the production database is a crucial artifact in the set of components which make up a non-production clone environment.  For most customers this is just not feasible, but with Delphix full database copies can be version controlled, can be versioned in seconds and can be provisioned or switched between versions in minutes.  Delphix allows you to manipulate and control databases versions as quickly and easily as source code files.

The example below shows how Delphix allows developers to submit regression tests on demand by automating and accelerating the data provisioning process in line with automated test suites.  Making environments available early in the development lifecycle allows a developer to get fast feedback on the success and implications of his or her proposed change.  You also get better value from your test environments as a greater ratio of time is spent running tests rather than preparing to run tests.

With more tests run more frequently and earlier in the cycle, the net result is that problems are discovered early and fixed more quickly, as illustrated below.

Virtual databases are a key enabler to Agile Development, allowing IT to produce higher quality releases, faster.  Be Agile not Fragile.