Friday Apr 03, 2015

Oracle Data Protection: How Do You Measure Up? - Part 2

In part 1 of this blog series, we reviewed the results of a database protection survey conducted last year by Database Trends and Applications (DBTA) Magazine. In summary, the most prominent backup and recovery challenges faced by DBAs today are: 

• Poor performance and impact on productivity
• Management complexity
• Lack of continuous data protection

In today's blog, we will take a look at the reasons why these challenges still exist for databases, even after decades of advancements in backup and storage technologies.

Let’s review a few of today’s common approaches to database backup and recovery and the trade-offs that exist with each.

Weekly Full with Daily Incremental

This strategy involves weekly full (level 0) and daily incremental (level 1) backups to disk and/or tape. This means businesses incur the overhead of full backups every week – leading to the dilemma of the “backup window”, the period when backups are ideally performed with the least amount of disruption to production. But with larger data sets and longer production cycles, full backups increasingly extend past their backup windows and encroach on production systems, which become too stretched to support all production applications at normal performance levels. 

Incrementally Updated Backups

With this strategy, an initial image copy backup (level 0) is taken to disk, followed by daily incremental backups. The image copy is then ‘rolled forward’ by applying incrementals to produce a new on-disk copy that corresponds to the most recent or a previous incremental timestamp. The copy can be restored as needed; however, once the copy is rolled forward, it cannot be ‘rolled back’, thus constraining the range of recovery points. In addition, the act of applying the incrementals to the copy requires database resources and further impacts production systems.

Daily Full to Deduplication Appliances

In recent years, backups to deduplication appliances have become more prevalent, with the goal of driving down storage costs through automatic elimination of redundant backup data. In order to drive down storage costs, deduplication (i.e. savings) ratios must be driven up – thus, storage vendors generally recommend a full backup-only strategy to these appliances. However, for most enterprise databases, a full backup-only strategy is neither effective from a backup window nor system utilization perspective. 

Deduplication appliances are typically based on a single controller architecture, in which the compute power and bandwidth are fixed in a given appliance and cannot be altered per business needs. The user can add storage expansion shelves, but this only increases the total storage capacity managed by the system. Once the maximum storage limit is reached in a single appliance, the user must perform a forklift upgrade to the next higher model or buy additional, independently managed appliances, whose compute and storage resources cannot be shared, thereby increasing management complexity. 

Finally, single controller architecture systems severely limit the resilience of the system. Any single component failure in the controller can render the appliance unusable until the component is replaced, thus impacting backup service levels and the ability to support continuous data protection.

Storage Snapshots

Storage-based snapshots of production databases represent another ‘backup’ strategy whereby only new and changed data is stored. A file snapshot is just a set of pointers to all the unchanged and before-change blocks that make up the file, as of the snapshot time. Since a snapshot is tied to the production storage, it cannot serve as a true backup in event of storage corruption, loss, or site disaster. Since snapshots are created outside of the Oracle database, they are not validated for Oracle block correctness, until they are restored and the database is opened. Thus, snapshots by design cannot truly provide continuous data protection against storage corruptions and failures.

In summary, several shortcomings come to the fore with today’s backup technologies, illustrating their inability to address the backup and recovery challenges highlighted above:

Poor performance and impact on productivity

• Prolonged Backup Windows: As databases continue to grow, so do backup windows – and that can result in network and storage resources being tied up longer and more frequently, with much less efficient utilization of overall IT resources.

• Reduced Production Performance: Longer backup windows mean prolonged impact on production performance, stealing cycles and resources away from more critical production workloads.

Management complexity

• Fragmented Backup Processes: Storage appliances treat Oracle backups as just generic files, with no connection back to the databases they support, leading to a lack of visibility and no assurance that the backup is healthy and usable, whether it is on disk, tape, or a replica appliance.

Lack of continuous data protection

• Increased Data Loss Exposure: Data can only be recovered to the last good backup, e.g. hours or days ago. In addition, generic storage systems cannot inherently validate backups at an Oracle block-level for restore consistency.

• Reduced Operational Scalability: Storage appliances cannot easily scale to handle massive backup workloads and concurrent connections from hundreds to thousands of databases across the enterprise.

In the upcoming final blog post in the series, we will discuss how Oracle’s Zero Data Loss Recovery Appliance provides a comprehensive backup and recovery solution that directly addresses these shortcomings for Oracle databases of any size, providing continuous Oracle-validated database protection.

Wednesday Jul 30, 2014

Backup to Oracle Cloud - Introduction to Oracle Database Backup Service

Backup and recovery of application data is the fundamental protection strategy for maintaining enterprise business continuity. I would be extremely surprised to hear of any enterprise that has never backed up its mission critical or business critical data. Any such a scenario is basically a ticking time bomb.

Depending on the specific RTO (recovery time objective) and RPO (recovery point objective) for each database, different Oracle Maximum Availability Architecture (MAA) strategies can be deployed by the enterprise.

From the backup and recovery perspective, the following are general practice guidelines that customers typically follow to address RTO and RPO requirements:

•    Local Fast Recovery Area (FRA): Typically stores backups for up to 7 days
•    External Storage (NAS): up to 30 days
•    Tape media (if available): 1 to 6 months
•    Tape vaulting (offsite storage): months to years

In addition to the above backup storage tiers, sophisticated organizations take additional precautions to avoid single site failure and to reduce load from production resources. MAA best practices, for example, recommend that copies of the backup data be stored in an offsite location.

But consider the following complications:

Other than tape vaulting, there is no alternative that enables complete physical offsite storage for short- and long- term backups. 

  • Many IT shops don’t have the tape infrastructure required for long term archival. Hence they are restricted to using local disk backups or expensive backup appliances.
  • Organizations with multiple databases that have various RTO/RPO requirements may have certain 2nd or 3rd tier databases that never get backed up.
  • Due to compliance requirements, customers now have to store backups for many years. Storing large volumes of data on local disks can become prohibitively expensive.
  • Many enterprises don’t have the CAPEX budget in place to implement these additional data protection steps. 
  • And almost ALL enterprise want a solution that’s operational right away.

So what’s the answer?

Introducing Oracle Database Backup Service - A Cloud Storage Solution for your Oracle Database Backups

Oracle Database Backup Service addresses the above needs by providing a low cost alternative for storing backups in an offsite location.  It is an Oracle Public Cloud object-based storage offering that enables you to store your on-premises or cloud-deployed database backups. You can use Oracle Database Backup Service as the Primary backup for 2nd or 3rd tier databases, or use the cloud backup as a secondary copy for long term archival requirements.

If you are familiar with Oracle Recovery Manager (RMAN), it should take only a few minutes for you to start backing up your database to the cloud. Here’s all you need to do:

1. Subscribe to the Oracle Database Backup Service.

  • This offering is available as a month-to-month or longer-term subscription (1,2, or 3 years).  Note that the prescription model is subject to change.

2. Download Oracle Database Cloud Backup Module from OTN site.

  • Unzip file, which has a detailed README about the steps to execute.

3. Run the installation procedure.

  • Provide your Oracle Public Cloud credentials, which are securely stored in an Oracle wallet with your database. The installation script also configures certain configuration files.

4. Configure RMAN

  • By using CONFIGURE (persistent), SET or even BACKUP commands, you can instruct RMAN to use the backup service module for backups.

5. Start enabling your backups and restores.

  • Use regular RMAN BACKUP or RESTORE commands for backups. All operations involving BACKUP SET mode of backups/recovery are supported.
  • You can also perform backups from FRA and other disk-based backup locations to the cloud.

How does this process work?

The Oracle Database Cloud Backup Module (ODCBM) receives backup blocks from RMAN, then chunks them into 20MB blocks and transmits to Oracle cloud. During the restore process, the same module retrieves data from the Cloud. The Oracle Database Cloud Backup Module is configured as SBT (Tape).

What are some unique features that Oracle Database Backup Service offers ?

To name a few:

  • End-to-end security (RMAN encryption is performed at backup time and data is securely transmitted over WAN).  And by the way, you don’t have to purchase the Advanced Security Option (ASO) to use RMAN encryption. You can use Password based, Transparent Data Encryption (TDE), or dual-mode. Encryption is supported for EE, SE, and SE1 editions.
  • Backups can be compressed to reduce the volume of data being transmitted. For Oracle Database 10gR2 and 11gR1, you can use BASIC compression. For 11gR2 and above, you can choose from LOW, MEDIUM, BASIC, and HIGH.
  • There’s NO ADDITIONAL COST other than the subscription to Oracle Database Backup Service.
  • You can use any number of RMAN channels to parallelize your backup and restore operations.
  • There are NO new commands to learn. Use the familiar RMAN commands.
  • Because a large portfolio of applications are already available in Oracle Cloud, you can use your backup in the cloud to spin a new instance or use it for your other PaaS or SaaS requirements.

So what are you waiting for?  Do you want to check the network throughput before you sign up? Start with a no-obligation one month trial by clicking “Try Now” from

For more information,

In future blogs on Oracle Database Backup Service, I will discuss some best practices when deploying cloud-based backups.

Thursday Jun 12, 2014

Oracle Data Protection: How Do You Measure Up? - Part 1

This is the first installment in a blog series, which examines the results of a recent database protection survey conducted by Database Trends and Applications (DBTA) Magazine.

All Oracle IT professionals know that a sound, well-tested backup and recovery strategy plays a foundational role in protecting their Oracle database investments, which in many cases, represent the lifeblood of business operations. But just how common are the data protection strategies used and the challenges faced across various enterprises? In January 2014, Database Trends and Applications Magazine (DBTA), in partnership with Oracle, released the results of its “Oracle Database Management and Data Protection Survey”. Two hundred Oracle IT professionals were interviewed on various aspects of their database backup and recovery strategies, in order to identify the top organizational and operational challenges for protecting Oracle assets.
Here are some of the key findings from the survey:

  • The majority of respondents manage backups for tens to hundreds of databases, representing total data volume of 5 to 50TB (14% manage 50 to 200 TB and some up to 5 PB or more).
  • About half of the respondents (48%) use HA technologies such as RAC, Data Guard, or storage mirroring, however these technologies are deployed on only 25% of their databases (or less).
  • This indicates that backups are still the predominant method for database protection among enterprises. Weekly full and daily incremental backups to disk were the most popular strategy, used by 27% of respondents, followed by daily full backups, which are used by 17%. Interestingly, over half of the respondents reported that 10% or less of their databases undergo regular backup testing.

 A few key backup and recovery challenges resonated across many of the respondents:

  • Poor performance and impact on productivity (see Figure 1)
    • 38% of respondents indicated that backups are too slow, resulting in prolonged backup windows.
    • In a similar vein, 23% complained that backups degrade the performance of production systems.
  • Lack of continuous protection (see Figure 2)
    • 35% revealed that less than 5% of Oracle data is protected in real-time.
  •  Management complexity
    • 25% stated that recovery operations are too complex. (see Figure 1)
    •  31% reported that backups need constant management. (see Figure 1)
    • 45% changed their backup tools as a result of growing data volumes, while 29% changed tools due to the complexity of the tools themselves.

Figure 1: Current Challenges with Database Backup and Recovery

Figure 2: Percentage of Organization’s Data Backed Up in Real-Time or Near Real-Time

In future blogs, we will discuss each of these challenges in more detail and bring insight into how the backup technology industry has attempted to resolve them.


Musings on Oracle's Maximum Availability Architecture (MAA), by members of Oracle Development team. Note that we may not have the bandwidth to answer generic questions on MAA.


« July 2016