Oracle Backup/Recovery

 

Oracle Recovery Appliance Architecture

Oracle’s Recovery Appliance turns backup/recovery into an extension of the Oracle database engine.   The Recovery Appliance ingests only CHANGED data and organizes it into a quasi-database called the Delta Store.  The Recovery Appliance dynamically constructs Virtual Full Backups when needed for database restore.

screen-shot-2017-01-03-at-3-29-11-pm

 

Zero Data Loss

The Zero Data Loss Recovery Appliance (ZDLRA) has put Oracle teams and customers on a mission to eliminate ALL sources of data loss in backup/recovery solutions on the market today.  ZDLRA provides unprecedented data protection capabilities that are simply unmatched by any other product.  After nearly 20 years since release of the Recovery Manager (RMAN) product, the Oracle development team has extended RMAN into a complete Data Protection solution embodied in ZDLRA.

End to End Data Protection

ZDLRA is more than a backup/recovery solution. It’s an extension of the Oracle DBMS.  The software needed to integrate Oracle databases with ZDLRA is part of the Oracle12c code, and is a simple download for previous releases.  Once the database software is configured, there is no separate agent to maintain.  This simple fact extends to the full range of backup/recovery features, and impacts database operations in myriad positive ways, both large and small.

Protecting The Latest Transactions

ZDLRA protects the leading edge of the redo stream through a feature called “Real Time Redo Protection”, which guards data up to the last transmitted SCN (System Change Number).  The active online redo log buffers are copied from the memory of DB servers to memory on the ZDLRA, which is quite different from remote mirroring of the log files.  This feature is technically asynchronous, but it has proven extremely robust.  Data is literally protected up to the last SCN, so this is even more granular than the last log switch.

Other Sources of Data Loss

While Real Time Redo Protection is an absolutely unprecedented fearure, there are myriad other sources of data loss that are encountered by customers even more frequently.  I spent a number of years at Oracle working as a sort of database paramedic, rescuing data after database crashes where backups were also corrupted.  While the incidence of these sorts of problems is low, the impact is often catastrophic. ZDLRA provides protection from these problems in a number of ways as we shall see.

The Policy Governs

Databases are enrolled and associated with Data Protection Policies in ZDLRA, and the policy can be set to govern data retention.  Commands that DELETE backups will fail if the policy is violated. Accidents are vastly more common than malicious attacks, and this feature protects against both.

Data protection policies govern both local data retention, as well as downstream replication of that data, and copying backups to external storage locations on tape, virtual tape, pools of conventional disk, or to cloud storage.  Data replicated to ZDLRA at a remote site is also managed by data protection policies in the replica.

Data Validation vs. Recovery Validation

The Oracle DBMS has always included data integrity checks, and Oracle has worked with storage vendors for more than 20 years to enable low-level sanity checks of Oracle data within storage. For example, Oracle can calculate a checksum on each database block, and many storage vendors can recalculate and verify those checksums to ensure a block has not been altered.

Low-level sanity checks like checksum validation ensures against block corruption as blocks are moved between memory and disk.  ZDLRA builds upon this foundation, extending these protections and others into the database backup.

ZDLRA is the only solution on the market that provides validation of recoverability. Other solutions only strive to ensure data isn’t lost, but aren’t able to determine if data was never sent.

Change-Based Capture

ZDLRA captures changes to databases each day.  All other RMAN Backup Set based solutions MUST perform periodic FULL backups, normally at least once per week.  Eliminating weekly (or even daily) full backups provides significant savings in disk I/O, SAN data transfer, processing, transmission, and storage.

De-Dupe = Discarding Un-Changed Data

De-duplication appliances take the opposite approach to ZDLRA, by attempting to identify and discard un-changed data.  This is an extremely inefficient approach for Oracle databases, because it still requires periodic full backups.  The de-duplication processing is also applied to incremental backups and redo logs which, by definition do not contain duplicates.  De-duplication technologies do not distinguish between different types of data being backed-up, and simply apply the same rules to all data.

The Database Knows What Changed

The main purpose of any database engine is to track and manage changes to data. ZDLRA simply taps into those fundamental mechanisms, extending database capabilities from the core engine into the backup solution. The developers of Oracle RMAN (Recovery Manager) have effectively completed the job by extending RMAN.

Saving I/O

ZDLRA eliminates FULL backups, which saves significant I/O, even for customers who only run full backups weekly.  FULL backups have additional negative impact beyond just the I/O that it drives.  FULL backups also impact the storage cache by flooding it with data that doesn’t need to be cached for normal processing.  Database servers also need to process data from the full backup, placing significant stress on the servers and degrading end-user performance.

Minimizing Network Traffic

Because ZDLRA only processes changed data, network trafffic related to backups is minimized as well.  Customers have reported that network infrastructure is one of the top costs in any data center. Making more judicious use of network resources delivers benefits to the business.

50-75% Data Reduction

ZDLRA typically requires 1/2 to 1/4 as much space as other solutions for a 50-75% reduction in data volume.  ZDLRA is not the least expensive on a cost per space basis, but it needs less space.

Cost Effective

The greater space efficiency of ZDLRA makes it extremely cost effective against all solutions we have encountered on the market.  ZDLRA is not necessarily the lowest “cost per terabyte” but it needs fewer terabytes. ZDLRA is built using additional hardware components (CPU, DRAM, PCIe cards, etc,) that bring higher performance and help it achieve greater space efficiency.  Traditional “cost per terabyte” measures don’t apply, so customers should look at overall solution cost.

ZDLRA accumulates only changed data as the data retention period grows, while other solutions accumulate another full backup at least once per week.  The chart below shows that ZDLRA is more space efficient than a NAS storage target.  Starting at week 1, the NAS target solution has to retain 2 full backups at a minimum.  Each successive week (every 7 days), the NAS  target stores another full backup in a Weekly Full Daily Differential Incremental strategy.

screen-shot-2017-01-03-at-3-40-11-pm

ZDLRA needs 1/3 to 1/4 as much space as compared to a NAS target.  The fundamental operating principal behind ZDLRA means it only captures the specific blocks of data that have changed.  All other solutions are less efficient.

Cost Per Protected Terabyte

One of our customers suggested that “cost per protected terabyte” as a more meaningful measure.  We have developed tools to help analyze database space, change rates, and redo generation rates to produce accurate ZDLRA space estimates. We also compare these estimates versus competitor space requirements to derive estimates of cost savings as compared to those solutions.