news

December 2014

Oracle ZDLRA

Zero Data Loss Recovery Appliance

Page 2 / 6

Oracle ZDLRA

When Larry Ellison announced the new Oracle Backup Appliance at the Oracle Open World 2013 with the DBLRA (Database Backup Logging Recovery Appliance), he promised numerous features. These features clearly differentiate this solution from others in the market. Just before the introduction into the market the product name was changed from DBLRA to ZDLRA (Zero Data Loss Recovery Appliance). It is obvious that the new product name stresses the minimisation of data loss.

Larry's core message was that up to now, solu-tions have not been developed for databases but rather for files and thus for file systems. But

what are the decisive modifications necessary for taking an appliance system designed for file systems and optimising it for Oracle databases? What's more, it is legitimate to ask whether the concepts and features Ellison announced are indeed delivered by the Oracle ZDLRA.

The Oracle Zero Data Loss Recovery Appliance is a total package. It consists of hardware and software for the backup of Oracle databases in large environments. With low administrative overhead, thousands of databases can be ba-cked up effectively and reliably. The product is the official cloud solution for database backups.

Which Advantages Does the ZDLRA Offer Compared to TraditionalBackup Solutions?

• Replaces the typical backup window

• Reduces the resource load of the database servers

• Minimisation of data loss

• Mirroring of backups over large distances

• High degree of scalability

• Autonomous archiving on tapes

• Central control and monitoring, end-to-end visibility

Moreover, the ZDLRA guarantees the option of point-in-time recovery of databases, as is the case with traditional RMAN backups.

When is it feasible to use a DBLRA? From an en-vironment as small as 100 databases or for very

large databases, the use of the appliance is well worth considering. In your calculation, you should take into account the reduced overhead for administration. In terms of pricing, Oracle is positioned vis-à-vis comparable backup pro-ducts.

Page 3 / 6

Oracle ZDLRA

How Does the ZDLRA Work?From a technical standpoint, the ZDLRA is an Exadata platform with special pre-installed software. Exadata already has the features built in and can be immediately used for the backup. The core of this system is a RAC data-base, which serves as central RMAN catalogue. Here the meta data of all backups are saved in

ASM disc groups with “high redundancy”. The backups are saved in the ASM with "normal re-dundancy". An enlargement of the appliance is possible by increasing database and storage nodes in the same way as it is done with Exada-ta.

For traditional database backups, there is a ba-ckup window at night and on the weekend for full backups. This is intended to restrict the pe-riods of increased resource loads on the I/O subsystem or network. With the growth of da-tabases, there are in fact ever increasing con-flicts with applications that run in 24/7 mode

or are dependent on nightly batch runs. The ZDLRA replaces this window with an "in-cremental forever strategy". After a complete initial backup of the database, only the redo log files, i.e. change deltas, are backed up. This achieves a significant relief of database server resources. The backup stream distributes itself

Page 4 / 6

Oracle ZDLRA

automatically and homogeneously throughout the time slot. All the costly activities of backups are pushed from the database server onto the appliance.

With traditional backups, the archived redo log data are backed up externally on the backup medium in particular intervals. The frequency varies from hourly to multiple hours. In case of a total failure of the database server, there can be a loss of log data in the range of several

hours. The backup of the redo log data on the ZDLRA only occurs asynchronously, yet in near real-time.

The concept provides for mirroring of the ba-cked-up data on a second appliance. After spe-cifying the backup policies, the backup occurs automatically on the closer appliance and the replication occurs on the distant appliance. In case the closer appliance fails, the recovery oc-curs from the distant appliance, without requi-

ring intervention in the configuration. This type of mirroring can also be easily realised over large distances, i.e. between Frankfurt/London or San Francisco/New York.

Via the definition of security policies, it is pos-sible to divide up the types of backups into groups. For instance, a "Gold Policy" could be created for "mission-critical", a "Silver Policy" for "business-critical" and a "Bronze Policy" for test databases. The Gold Policy would provide

for mirroring onto a second appliance as well as an additional backup on tape.

Through the expansion of the existing appliance or the addition of more appliances, the ZDLRA offers a high degree of scalability. The backups can expand well into the petabyte range.

Backups can optionally be sent from the appliance to a tape library. Here as well, there is a continuous data stream instead of high

Page 5 / 6

Oracle ZDLRA

capacity in the backup window. The operations are performed with the resources of the ZDLRA and not with the resources of the database server.

The administration of the ZDLRA as well as the connected database servers occurs centrally

with the Oracle Enterprise Manager Cloud Control (OEM). The configuration is specified with the help of backup policies. Monitoring is integrated with preconfigured metrics. In addi-tion, the Enterprise Manager supports an end-to-end visibility that cannot be achieved with traditional backups solutions.

Key Features in Detail

A significant advantage compared to traditional backup is the Incremental Forever Strategy. Here you have a complete backup once, the In-itial Backup. After the Initial Backup only chan-ges are saved via “Delta Push”. Delta Push is used for the following: • Incremental Backups• Real-time Redo Transport

During an incremental backup only changed data is transferred to the ZDLRA. On the appli-ance this data is checked for corruption and sa-ved as compressed data in the ASM disk group. The backup of the changed data is done by the Delta Store.

What is meant by the designation “Real-Time Redo Transport”? The designation suggests a real-time backup and a 100 percent of data loss prevention. However, does this have a negative impact on the database performance? Oracle has found a good compromise to combine mi-nimal data loss and minimal decline in perfor-mance: The transfer of the Redo Records is im-mediate, real-time, but asynchronous.

This is why in normal operation data loss should be maximum one second and there is nearly no impact on database performance. Therefore the user does not wait for ZDLRA confirmation after giving a COMMIT-command like he would have to in the Maximum Protection Mode of Data Guard. As the Redo Record arrives at the ZDLRA it is written into the Redo Staging Area immediately and is persistent then. What fol-lows is the compression and writing into the Delta Store.

The technology for the transfer with Real-time Redo Transport is comparable with the Real-tie Apply by Data Guard. The transfer is performed by the Log Buffer of the protected database and happens parallel to writing into the local Redo Log Data.

The Delta Store is the central component of the appliance and helps the realization of the Incremental Forever Strategy. Arriving data is changed by incremental backups into a virtual representation of the Level 0 Backup (Initial Backup). This data is administrated by meta

Page 6 / 6

Oracle ZDLRA

Imprint

Date: December 2014

Author: Ronny Egner

Lutz Fröhlich

Contact: marketing@avato-consulting.com

www.avato-consulting.com © 2014 avato consulting ag

Further Information / Community

You will find further information here on the Oracle website.

Moreover, in the avato intranet you can discuss with our experts and suggest topics for news-letters.

Larry Ellison didn't promise too much: The ZDLRA is a complete hardware and software package for effective backups of Oracle databases in large environments. Its use is recom-mended for very large/very many databases. It offers a high degree of scalability and relie-ves the load on system resources. Moreover, it stands for near-zero data loss similar to Data Guard as well as an "incremental forever strategy".

data. From virtual point of view, the Level 0 Backup and the Level 1 Backup form a complete Backup at the Level 1 Backup point of time – without overwriting the Level 0 Backup. If RESTORE DATABASE is required, the Level 0

Backup and all Incremental Backups are read. The meta data tells the process whether to read a data block from the Initial Backup or from an Incremental Backup.