Everything You Need to Know About Oracle Exadata Backup and Recovery: Best Practices Andrew Babb, Consulting Member of Technical Staff, Oracle Donna Cooksey, Principal Product Manager, Oracle Harpreet Singh, Vice President, Database Management, Fidelity Investments
46
Embed
Everything You Need to Know About Oracle Exadata Backup ... · Everything You Need to Know About Oracle Exadata Backup and Recovery: Best Practices Andrew Babb, Consulting Member
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Everything You Need to Know About Oracle Exadata Backup and Recovery: Best Practices Andrew Babb, Consulting Member of Technical Staff, Oracle Donna Cooksey, Principal Product Manager, Oracle Harpreet Singh, Vice President, Database Management, Fidelity Investments
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
IT consumers are increasingly involved in technology decisions – The flexible, fast moving opportunities of the “3rd Platform” translate to
more IT initiatives being driven by Line of Businesses (LOB) – Applications, storage, servers … even data protection?
Technology in stealth mode makes a sound data protection even more important !
Business Requirements Meeting IT Head-on
Greater Complexity Causing More Data Center Downtime: http://www.datacenterdynamics.com/focus/archive/2012/09/greater-complexity-causing-more-data-center-downtime-0
The criticality and workloads of typical Exadata databases makes recovery strategies especially important:
– Batch load / NOLOGGING operation went south – Long-term, periodic archival backups (keep forever / until) – Application patches and upgrades – Backing out a bad transaction
Flashback Technologies are a suite of logical error investigation and correction capabilities built-in the Oracle database:
– Error investigation: Flashback query, version query and transaction query – Error correction: Flashback database, table, drop and transaction
Flashback Database operates on physical data blocks and is similar in effect to point-in-time recovery - other Flashback features operate at logical level
– Only Flashback feature which must be explicitly enabled by user as it generates logs
In applicable scenarios, Flashback features are more efficient than media recovery
Complements Physical Data Protection Strategy
Flashback Technologies Should be part of ALL Recovery Plans !
Flashback Database VS Point-in-Time Recovery Different Approaches and Multiple Use Cases
Flashback Database Traditional Point-in-Time Recovery Rewinds the database to SCN Restores then recovers the database to SCN
Advantages
• Significantly faster than point-in-time recovery - No restore and only limited redo needed
• Useful during database upgrades, application deployments, and efficient alternative to rebuilding a failed primary database after a Data Guard failover
• Provides continuous data protection
• Compatible with restore points
Works at the database or tablespace level
No additional logs necessary beyond redo
Compatible with restore points
Disadvantages
Requires Flashback logs and associated storage
Works at whole database level only
Flashback logging has some (minimal) overhead on database server
Oracle Database tool that automatically diagnoses data failures, presents repair options, and executes repairs at the user's request
Determines failures based on symptoms – Failure Information recorded in diagnostic Automatic Diagnostic Repository (ADR) – Flags problems before user discovers them, via automated health monitoring
Intelligently determines recovery strategies – Aggregates failures for efficient recovery, presents only feasible recovery
options and indicates any data loss for each option Can automatically perform selected recovery steps Accessed via RMAN or EM
Image copy – Disk only Same size as the database less temp
files Backupset – Disk or tape
Smaller than image copy full Can be compressed and/or encrypted
by RMAN Full backup consumes more overhead on the
production server and take more time than an incremental backup
Restoration may be faster than an incremental
RMAN Traditional Backup Strategies
Full / Incremental Schedule Backupset backups – Disk or tape Typical schedule – Week full with daily incremental
backups Typical retention:
– Days to weeks – On disk – Weeks to years – On tape – Full and corresponding incremental backup
should be treated as a group • Reduces backup window and overhead on servers • Ideal with low-medium change rate e.g. <20% • Database must be in archived log mode
Oracle Database 10g Release 2 Enterprise Edition > Incremental forever after initial full image copy Full image copy is rolled forward on user-defined schedule
• Roll-forward / merge does incur overhead on server • Offers SWITCH TO COPY capability
Typical retention – One to seven days Backup full or incremental to tape
Block Change Tracking (BCT) enables fast incremental backups – RMAN tracks 32k data file sections which include a changed block(s) – During an incremental backup, RMAN scans these 32k file sections to
determine which block(s) have changed Only these changed blocks are included in the incremental backup
Incremental Backup Scans Occur on Exadata Storage Cells
Note: Incremental backup without Block Change Tracking (BCT) enabled – all database blocks are scanned to determine what has changed
Database Server Exadata
Scan of blocks occurs on the database server
Scan of blocks is offloaded to the Exadata Storage Cells
Challenges with traditional infrastructure • 300TB of storage with over 60% annual growth rate • Performance challenges • Cost reduction pressures • Need to make failover/recovery more robust
Benefits gained with Exadata • 42x performance gains for reporting & 40% for OLTP • Reduced storage by 30% using compression • Consolidated physical servers from 10 to 4 • Reduced direct/indirect chargebacks by 30% • Significantly improved failover, backup & recovery strategy
30
Exadata Architecture
31
Pre-Exadata Backup Challenges
Over 60% annual data growth rate
Business needs growing and becoming more complex
Expensive software/hardw
are licenses
Costly to keep backups on the
disk
Backups hurting
database performance
Complicated recovery with “no-logging”
Concerns around non-logical DR software
32
Fundamental Data Protection Strategy
1st Line of Defense • Flashback: 48
hours • data deletion • logical corruption • user errors
2nd Line of Defense • Disk Backup: 24
Hours • application • system
3rd Line of Defense • Standby Database
(DR) • Building/site, region • HW failure
Last Line of Defense • Tape: 35 Days
• Offsite • multi-site failures
33
Pros Faster recovery Data recovery from tables, schema, or entire database Roll database back and forth repeatedly within the
flashback window for complex data restore
Cons Same location as production
– No protection from storage failure No protection from physical corruption
Flashback Disk Backup Standby Database Tape Backup
• Oracle Flashback Database • Primary and Standby Sites
Please refer to Oracle.com for additional information: http://www.oracle.com/us/corporate/features/database-backup-logging-recovery-appliance/index.html