Showing posts with label Cloning. Show all posts
Showing posts with label Cloning. Show all posts

Wednesday, 21 September 2016

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 3rd 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



Monday, 26 October 2015

Delphix versus Storage Snapshots

Many customers ask, "What is the difference between Delphix and Storage Snapshots?" This article lists some of the key capabilities that Delphix provides over and above Storage Snapshot based cloning solutions to meet the increasing business demand for Agile Development.

First it is useful to contrast the distinct goals and implementation behind Storage Snapshots and Delphix.

Storage Snapshots


The primary use for storage snapshots is to enable backups of active database or file systems.  A backup takes a long time and most database systems cannot be suspended for the entire duration of a backup.  Storage snapshots allow a database to be queisced for a brief duration whilst the snapshot is taken.  The database can then be un-queiesced allowing transactions to proceed and a consistent backup of the database can then be taken asynchronously via the snapshot.  So a single snapshot can be used to provide a consistent view of a database.  Storage snapshot solutions also allow cloning enabling multiple snapshots.  These read write clones can be used to provision database copies quickly and with low storage overhead, consuming only changed blocks per snapshot.

Supporting clones has an impact on storage performance and hence clones are usually driven off a full copy of production maintained on a separate storage server.  This mitigates the performance impact of clones on the production storage array at the cost of maintaining a replication method and additional storage.

Delphix


Delphix is designed to support Agile Development not just backups and clones.  Agile Development requires fully automated end-to-end provisioning of database copies, ready to use running database environments and fast database manipulation operations exposed through self-service.   Like storage snapshots Delphix virtual databases can be created in minutes and each copy consumes very little incremental storage however a virtual database can be manipulated directly by the end user, typically a developer or tester, through self-service.

Aside from provisioning database copies, virtual databases support the full range of developer and tester activities such as bookmarking (saving and sharing a database state), running multiple database versions (branches), rewinding for repeated consistent tests and refreshing for operating on up-to-date data.  All of these operations are fully automated, complete in minutes and can be applied to a set of databases and optionally the application stack, and treated as a single entity.  All this is done without consuming additional database and application server resources.

Delphix synchronises with source databases with zero impact.  There is no need to replicate or copy the source databases as Delphix synchronises directly with the production database or via backups.


Accelerating Release Cycles


Delphix provides the following benefits for all Software Development Life Cycles:

1.    Manage multiple data sources as one

Many applications rely on more than one data source that must be kept synchronized. Delphix can provision and manipulate a set of databases, folders and data files as a single consistent entity.

2.    Masking and non-production data preparation

Delphix allows you to prepare a copy of production data for non-production by modifying or masking a single virtual database (VDB) once and then creating virtual copies from that single master VDB, executing the preparation phase once and enabling all downstream copies to benefit from that operation.

3.    Performance

Delphix' compression and caching reduces the workload on the underlying storage making it possible to run multiple workloads on Delphix enabled storage faster than using physical storage directly.

4.    Ease of Use

Delphix has class leading end-to-end automation covering deployment, synchronisation, administration, security, provisioning, and replication exposed through self-service user interfaces and leveraged APIs.

5.    Storage efficient

Delphix uses minimum storage when synchronising, provisioning and archiving data and is more storage efficient than storage snapshot based solutions.  All data held in Delphix is compressed and implicitly de-duplicated.

6.    Storage Agnostic

Delphix is storage agnostics allowing customers to switch storage vendors and leverage new developments in storage technologies.

7.    Provenance

Delphix has the best provenance of any Data as a Service (DaaS) solution with over 120 of the Fortune 500 companies doubling their application release frequency using Delphix.

In Summary


If you want to take backups you can use storage snapshots to give you a consistent discrete view of the data, however you could backup directly from Delphix from any point in time, avoiding impacting your production storage.

If you want to save storage you could use storage snapshots but Delphix saves even more storage and is storage independent.

If you want to support agile development through agile provisioning and agile manipulation of full sized data sets then Delphix is your only option.

Delphix is simpler, faster, more storage efficient and supports agile development more effectively than storage snapshots.