Oracle zero data loss recovery appliance.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
The Oracle Zero Data Loss Recovery Appliance is a computing platform that includes Oracle Corporation Engineered Systems hardware and software built for backup and recovery of the Oracle Database. Oracle’s Zero Data Loss Recovery Appliance is an engineered data-protection solution that helps eliminate Oracle Database data-loss exposure throughout an.
 
 

Zero Data Loss Recovery Appliance Documentation.

 
The Zero Data Loss Recovery Appliance: Overview course introduces Oracle’s Zero Data Loss Recovery Appliance (Recovery Appliance) as a ground-breaking data protection solution that tightly integrates with the Oracle Database in order to address these requirements head-on. Oracle’s Zero Data Loss Recovery Appliance (Recovery Appliance) is a ground-breaking data protection solution that tightly integrates with the Oracle Database to address these requirements head-on. It eliminates data loss and dramatically reduces data . Welcome to the Zero Data Loss Recovery Appliance Documentation Library. The Recovery Appliance is a ground-breaking data protection solution that is completely integrated with the Oracle Database. In addition, the Recovery Appliance easily protects all databases in the data center with a massively cloud-scale architecture, ensures end-to-end data validation, and fully .

 

Introduction to Recovery Appliance

 

Most enterprises have adopted one or more of the database backup strategies described in this section:. Weekly Full and Daily Incremental Backups. Third-Party Storage Snapshots.

One popular approach, shown in Figure , is to use RMAN to take a weekly full backup, and then daily incremental backups. To improve incremental backup performance, Oracle recommends enabling block change tracking. These backups occur when activity on the database is lowest. An advantage of this technique is that backup windows, which affect the production server, are relatively brief on the days when incremental backups occur. A disadvantage is that when the database is continuously active, as when serving multiple global time zones, no easily accommodating backup window is available.

One solution is to set up Oracle Data Guard, and then back up the standby database, thereby removing the backup load from the production server. However, protecting all databases with Oracle Data Guard is often impractical. In this way, the database copy on disk is “rolled forward” every day. You must have sufficient disk space to keep a copy of the whole database on disk, and the archived redo log files required to recover it.

Only one physical copy of the database exists. You select the point in time at which to keep the copy, so you can recover to subsequent points in time. The disadvantages are:. The closer your recovery point in time is to the current time, the more incremental backups you must restore and apply to the copy. This technique adds time to the overall recovery time objective.

As an alternative to RMAN incremental backups and tape drives, some customers use third-party deduplicating appliances to process backup streams. Figure depicts three databases writing to a centralized third-party appliance. The third-party software searches for patterns at the byte and sub-byte level to eliminate redundant data from backup to backup.

For example, if a full database backup is almost identical to the backup taken a week before, then the software can attempt to prune the redundant bits from the incoming backup stream.

To reduce network load, one optional technique utilizes source-side deduplication so that backup streams are deduplicated on the database host instead of the third-party appliance. These third-party appliances do not recognize or validate Oracle Database blocks. From the perspective of the appliance, a database backup is the same as a file system backup: a stream of bytes.

Deduplication is only effective for full database backups that have a high degree of redundancy. Strategies that use incremental backups often do not achieve good deduplication ratios. The third-party appliance dictates which Oracle Database features to use rather than the other way around.

Often, adapting to the requirements of the appliance means rewriting existing backup scripts. A third-party storage snapshot is a set of pointers to storage blocks not Oracle blocks that existed when the snapshot was created. The virtual copies reside on the same storage array as the original data.

Figure depicts a copy-on-write snapshot , which is a type of third-party snapshot. After a snapshot is taken, when the first change to a storage block occurs, the array copies the before-image block to a new location on disk C and writes the new block C’ to the original location. An initial copy of the database is not necessary because snapshots are not stored as physical copies of blocks.

Thus, less storage is consumed than in RMAN strategies. Snapshots can be extremely fast. You put the database in backup mode unless storage does not meet the requirements for snapshot storage optimization , and then take the snapshot. The snapshot needs to store physical blocks only when the blocks change, so a backup of an unchanged file is a metadata-only operation.

Snapshots use storage efficiently. A backup of a file with a single changed block requires only one additional version of the block to be stored—either the old version or new version of the block, depending on the snapshot technique. Snapshots have no knowledge of an Oracle Database block structure, and thus cannot validate Oracle blocks. Because snapshots reside on the same storage array as the source database, they are vulnerable to storage failures and data corruptions.

If the array is inaccessible, or if the storage contains data block corruptions, then the snapshots cannot be used for recovery. Restoring a snapshot in place voids all snapshots that were taken after it unless the snapshot is fully restored to an alternate location. Oracle Database Backup and Recovery User’s Guide to learn more about using Storage Snapshot Optimization to take third-party snapshots of the database.

The role of information technology in the modern business is going through a tremendous transformation. The key drivers for this transformation are:. Many organizations continue to experience exponential growth, which creates a greater challenge for efficient data management and protection. What works well for dozens of databases may not work well for hundreds or thousands of databases, often running on different platforms and on multiple physical servers.

Organizations are increasingly dependent on data analysis for critical real-time decisions. This dependency increases the pressure to maintain data integrity and prevent data loss. The protection strategies described in ” Traditional Database Backup Techniques ” are not designed to solve the challenges created by this transformation.

Enterprises find themselves without a consistent backup and recovery strategy. The following shortcomings are common to most or all of the traditional backup techniques:.

A database is only recoverable to its last valid backup, which may have occurred hours or days ago. In addition, storage snapshots and third-party appliances cannot validate Oracle data blocks, and so cannot detect Oracle block-level corruptions.

As database sizes increase, the lengths of the backup windows also increase, creating additional load on production systems. Critical databases cannot afford to be deprived of resources used for daily backups and related maintenance activities. Because most third-party backup snapshot and Recovery Appliances lack Oracle integrated data block and database backup validation, restore and recovery operations tend to fail.

Such failures result in extended downtime and potentially larger data loss. As the number of databases increases exponentially, so the ease of manageability decreases. Backup scripts proliferate and change. New DBAs may struggle to understand what the legacy scripts do. Questions about the status, backup location, and recovery point objective RPO of a particular database become harder to answer.

The traditional techniques fail to provide a comprehensive and efficient Oracle-integrated data protection solution that meets the demands of a large-scale, enterprise Oracle environment.

A new approach is required. Recovery Appliance is a cloud-scale Engineered System designed to protect all Oracle databases across the enterprise. Most database backup and restore processing is performed by the centralized Recovery Appliance, making storage utilization, performance, and manageability of backups more efficient.

The Recovery Appliance stores and manages backups of multiple Oracle databases in a unified disk pool, using an RMAN incremental-forever strategy. The Recovery Appliance continually compresses, deduplicates, and validates backups at the database block level, while creating virtual full backups on demand.

A virtual full backup is a complete database image as of one distinct point in time, maintained efficiently through Recovery Appliance indexing of incremental backups from protected databases. A virtual full backup can correspond to any incremental backup that was received. Figure shows an overview of a sample Recovery Appliance environment.

As shown in Figure , a protected database is a client database that backs up data to a Recovery Appliance. The Recovery Appliance metadata database , which resides on each Recovery Appliance, manages metadata stored in the RMAN recovery catalog , and backups located in the Recovery Appliance storage location. The catalog is required to be used by all protected databases that send backups to Recovery Appliance. Databases may use Recovery Appliance as their recovery catalog without also using it as a backup repository.

Cloud Control provides a “single pane of glass” view of the entire backup lifecycle for each database, whether backups reside on disk, tape, or another Recovery Appliance. The Recovery Appliance uses various mechanisms to protect against different types of data loss, including physical block corruption. This section contains the following topics:.

Protection of Ongoing Transactions. End-to-End Data Validation. In traditional backup approaches, if the online redo log is lost, then media recovery loses all changes after the most recent available archived redo log file or incremental backup. A recovery point objective RPO of a day or more that might result from a traditional approach may be unacceptable. Recovery Appliance solves the RPO problem through a continuous transfer of redo changes to the appliance from a protected database.

This operation is known as real-time redo transport. Using delta push, the Recovery Appliance is a remote destination for asynchronous redo transport services from Oracle Database 11 g and Oracle Database 12 c databases.

See ” Delta Push ” for more information. This technology is based on the real-time redo transport algorithms of Oracle Data Guard. To avoid degrading the performance of the protected database, protected databases transfer redo asynchronously to the Recovery Appliance. If a protected database is lost, zero to subsecond data loss is expected in most cases. To protect against server or site outage, one Recovery Appliance can replicate backups to a different Recovery Appliance.

Figure shows the simplest form of replication, called one-way Recovery Appliance replication , in which an upstream Recovery Appliance backup sender transfers backups to a downstream Recovery Appliance backup receiver.

In Figure , a protected database sends an incremental backup to the Recovery Appliance, which then queues it for replicating to the downstream Recovery Appliance. When the upstream Recovery Appliance sends the incremental backup to the downstream Recovery Appliance, it creates a virtual full backup as normal.

The downstream Recovery Appliance creates backup records in its recovery catalog. When the upstream Recovery Appliance requests the records, the downstream Recovery Appliance propagates the records back.

If the local Recovery Appliance cannot satisfy virtual full backup requests, then it automatically forwards them to the downstream Recovery Appliance, which sends virtual full backups to the protected database. A robust backup strategy protects data against intentional attacks, unintentional user errors such as file deletions , and software or hardware malfunctions.

Tape libraries provide effective protection against these possibilities. Figure show the traditional technique for tape backups, with a media manager installed on each host. Figure shows the Recovery Appliance technique for tape backups. The fundamental difference in the two approaches is that the Recovery Appliance backs up to tape, not the protected databases.

Thus, installation of a media manager is not necessary on the protected database hosts. When Recovery Appliance executes a copy-to-tape job for a virtual full backup, it constructs the physical backup sets, and copies them to tape, and then writes the metadata to the recovery catalog.

If desired, the Recovery Appliance can also copy successive incremental backups and archived redo log file backups to tape. Whereas the backup on the Recovery Appliance is virtual, the backup on tape is a non-virtual, full physical backup. The Recovery Appliance automatically handles requests to restore backups from tape, with no need for administrator intervention. The Recovery Appliance performs all tape copy operations automatically, with no performance load on the protected database host.

Tape backups are optimized. Recovery Appliance intelligently gathers the necessary blocks to create a non-virtual, full backup for tape. Oracle Secure Backup is preinstalled, eliminating the need for costly third-party media managers. You may deploy tape backup agents from third-party vendors on the Recovery Appliance for integration with existing tape backup software and processes.

In this configuration, the agents must connect to their specialized media servers, which must be deployed externally to the Recovery Appliance. Tape drives and tape libraries function more efficiently because Recovery Appliance is a single large centralized system with complete control over them. In other tape solutions, hundreds or thousands of databases can contend for tape resources in an uncoordinated manner. Copying Backups to Tape with Recovery Appliance.

Oracle Secure Backup Administrator’s Guide. A basic principle of backup and recovery is to ensure that backups can be restored successfully. To ensure that there are no physical corruptions within the backed-up data blocks, backups require regular validation. Recovery Appliance provides end-to-end block validation, which occurs in the following stages of the workflow:. Secure Backup Licensing Information. Licensing information for Oracle Secure Backup Release Notes Release Notes. Deployment Owner’s Guide.

Describes data center site planning, network configuration, hardware and software installation, and maintenance of Oracle’s Recovery Appliance. Safety and Compliance Guide. PDF for offline viewing. Administration Administrator’s Guide. Explains how to configure, back up, and recover client protected databases that use Recovery Appliance for data protection.