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.

Friday Nov 14, 2014

Oracle Database 12c: RMAN Enhancements

Hello folks,



In this blog, I am going to provide an overview of new Oracle Recovery Manager (RMAN) features that were introduced in Oracle Database 12c. 


As an integral part of Oracle Database, RMAN offers a complete and integrated backup and recovery solution to address a variety of operations – from routine to very complex.  RMAN has steadily evolved over the past 16 years – mainly because Oracle has listened to our customers. We’ve continued to incorporate many valuable enhancements, including the following features that were introduced with Oracle Database 12.1.0.1.

 1. Fine grained recovery

With Oracle Database 12c, you can use a simple RECOVER TABLE command to perform a point-in-time recovery of a table/partition without having to go through a manual point-in-time recovery process. This command automatically performs the following steps: creation of the auxiliary instance, table recovery, exporting of the object, and importing it into the production database.

2. Support for multitenant databases

Oracle Database 12c offers this unprecedented consolidation feature called Oracle Multitenant. This capability simplifies database consolidation and management by enabling many individual pluggable databases (PDBs) to be “plugged-into” and supported within a container database (CDB).  Data protection is greatly simplified because you can perform backup and recovery at the CDB level, which includes and protects all the associated PDBs. For additional flexibility, you can still choose to perform backup and recovery for an individual PDB or a selected group of PDBs.

3. Improved RMAN duplication (cloning) performance

Duplicating an Oracle database can be performed in many ways. Today, customers use both Oracle features such as RMAN DUPLICATE or storage-based snapshot and cloning technologies. RMAN duplication can be performed by using an existing backup or by directly duplicating the database using ACTIVE DUPLICATE.  Prior to Oracle Database 12c,  the ACTIVE DUPLICATE process used production database processes to send image copies across the network. This could be a time-consuming activity because the duplication process is directly proportional to the database size. Now, with 12c, the database duplication process has been improved, with the use of backup sets instead of image copies. As a result, the database size is relatively smaller because RMAN skips unused blocks, committed undo blocks etc. Plus, you can use compression and multi-section options for even faster duplication. Moreover, auxiliary channels from the destination site are used to PULL the backups over the network, as opposed to the PUSH method, used prior to 12c.

4. Faster recovery in a Data Guard or Active Data Guard environment

You may already be aware of some cool RMAN features that are supported with Active Data Guard – for example, direct Block Media Recovery from the standby. However, in the event of either primary or standby datafile corruption (e.g. due to media errors), the traditional recovery process would be to copy the backup over the network and perform a restore/recovery.  With Oracle Database 12c, there is a new RMAN keyword  called “FROM SERVICE” whereby you can perform restores directly from the standby or from the primary (depending on which site has issues). This command creates a backup set and streams it over the network. This new process dramatically reduces the overall recovery time.

5. Expansion of Multi-section support

Prior to Oracle Database12c, parallelizing a single data file using MULTI SECTION was only supported with a level 0 backup or a full backup set. From 12c, Multi section is now supported with incremental backups as well as image copy backups.

6. Simplified cross-platform migration

Migrating the database from one platform to another can be performed in many ways. Oracle supports both database-level migration and tablespace-level migration. Database-level migration requires the endian type to be same on the source and destination platforms. Using tablespace migration, you can migrate across platforms and across endian formats. Oracle 12c introduces new keywords - FROM PLATFORM and TO PLATFORM. Using these keywords, RMAN takes care of converting the endian-ness,  so that the overall process is simplified. Depending on the availability requirements, tablespace migration can be performed with either long downtime or reduced downtime processes.
    

a) When using a longer downtime model, you place the tablespace(s) in read-only mode, take the full backup, and restore at the destination. You also take the metadata export of the tablespace at the source and then apply at the destination. Once you’re done, the tablespaces are made readable/writable at the destination.
  

 b) When using a reduced downtime model, you can keep your source database running for a longer time by doing incremental backups to the destination. Only the last step involves the procedure mentioned in (a).

7. Separation of Duty

A new role SYSBACKUP is introduced to separate backup administrator tasks from the SYS role. You can use this administrative privilege to perform backup and recovery operations from either RMAN or from SQL*Plus.



8. SQL interface in RMAN


 Beginning with Oracle Database12c, you no longer have to switch between the SQL*Plus interface and RMAN interface. The RMAN interface now supports SQL commands so you can directly run the commands from within RMAN.



I covered these topics in my Oracle Open World 2014 RMAN presentation.  The cloud backup solution Oracle Database Backup Serviceas well as our newly introduced Zero Data Loss Recovery Appliance are also covered in this presentation.


For further details, refer to Oracle Documentation.

If you would like me to provide further technical content on any of the above RMAN features or have questions, please register your comments below.

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 opc_installer.zip 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 https://cloud.oracle.com/database_backup.

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.

About

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.

Search

Categories
Archives
« May 2015
SunMonTueWedThuFriSat
     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
      
Today