1© copyright 2010 emc corporation. all rights reserved. mel shum technical marketing engineer emc...

1© Copyright 2010 EMC Corporation. All rights reserved.

Mel ShumTechnical Marketing EngineerEMC Backup Recovery Systems

EMC Data Protection for Oracle Saving Time and Money

EMC Data Domain


Agenda

• Problems many database administrators

face

• Overview of Oracle Recovery Manager

(RMAN) functional components• Key features of EMC Data Domain

deduplication storage systems• Impact of Data Domain deduplication in an

Oracle environment

• Customer examples

• Summary


Problems Many Database Administrators FaceToo many for this talk so we’ll focus on just backup and recovery

• Non-stop growth and proliferation

• Backup windows remain approximately the same

• Recovery is just as important and often

overlooked

• Limited online retention

– Increased frequency of recovery for audits,

troubleshooting, updates, etc.

• Archive (aka, ILM) becoming increasingly

important

– Some data must be retained for 5 years, 7 years, forever….


RMAN – What Is It?For those in the audience that don’t already know:

• Oracle’s included backup / recovery utility

– Supports full, incremental, and image backups– Retains backup information in the control file

and (optionally) a separate database catalog– Many configuration options to tailor to users’

requirements– Automatically eliminates unused data blocks

from most backups


Overview of RMAN Functional Components

RMAN Repository (Control File)

Target Database



Target Database

RMAN Client




Target Database

RMAN Client

Disk

Backup



Third Party Media Managers

MML API

Backup


Target Database

RMAN Client

Disk

Backup




MML API

Backup


Target Database

RMAN Client

Disk

Backup

Tape




MML API

Backup


Target Database

RMAN Client

Disk

Backup

Recovery Catalog

Tape




MML API

Backup


Target Database

FRA

RMAN Client

Disk

Backup

Recovery Catalog

Tape



RMAN> ALLOCATE CHANNEL CH1 DEVICE TYPE DISK FORMAT ‘/backup/ora.weekly/%U’;RMAN> ALLOCATE CHANNEL CH2 DEVICE TYPE DISK FORMAT ‘/backup/ora.weekly/%U’;RMAN> BACKUP AS COPY TAG ‘MAY9’ DATABASE INCLUDE CURRENT CONTROLFILE;RMAN> BACKUP ARCHIVELOGS TAG ‘MAY9’ ALL NOT BACKED UP DELETE ALL INPUT;

Target DB

1 TB

Weekly: Full image backups (nightly would be preferred!)

Weekly Full Backup


RMAN> ALLOCATE CHANNEL CH1 DEVICE TYPE DISK FORMAT ‘/backup/ora.weekly/%U’;RMAN> ALLOCATE CHANNEL CH2 DEVICE TYPE DISK FORMAT ‘/backup/ora.weekly/%U’;RMAN> BACKUP AS COPY TAG ‘MAY9’ DATABASE INCLUDE CURRENT CONTROLFILE;RMAN> BACKUP ARCHIVELOGS TAG ‘MAY9’ ALL NOT BACKED UP DELETE ALL INPUT;

Target DB

1 TB

Much more than 1 TB to

keep a few days Limits Retention

Disk

1 TB

Disk

1 TB

Disks

1 TB

Full images

Weekly: Full image backups (nightly would be preferred!)

Weekly Full Backup


Disks

1 TB

Disks

1 TB

RMAN> ALLOCATE CHANNEL CH1 DEVICE TYPE DISK FORMAT ‘/backup/ora.weekly/%U’;RMAN> ALLOCATE CHANNEL CH2 DEVICE TYPE DISK FORMAT ‘/backup/ora.weekly/%U’;RMAN> BACKUP INCREMENTAL DATABASE ….

Daily: Incremental backup after weekly full

Target DB

1 TB

Weekly Fulls

Disks

1 TB

Daily Incremental Backup


1

32

.

.Disks

1 TB

1

32

.

.Disks

1 TB

RMAN> ALLOCATE CHANNEL CH1 DEVICE TYPE DISK FORMAT ‘/backup/ora.weekly/%U’;RMAN> ALLOCATE CHANNEL CH2 DEVICE TYPE DISK FORMAT ‘/backup/ora.weekly/%U’;RMAN> BACKUP INCREMENTAL DATABASE ….

Daily: Incremental backup with update

Target DB

1 TB

Well beyond 1TB of backup storage needed

Weekly Fulls

1

32

.

.Disks

1 TB

+ Daily Incrementals

Daily Incremental Backup


Before Data Domain…

18 Cabinets of IBM Tape


After Data Domain…

1 DD690 and 2 Expansion Shelves


Data Deduplication: Under The HoodStore more backups in a smaller footprint

Friday Full BackupFriday Full Backup

A B C D A E F G

BACKUP DATA LOGICAL ESTIMATED PHYSICAL REDUCTION


A B C D E F G


A B C D A E F G WEEKEND FULL 1 TB 2- 4x 250 GB




A B C D E F G H


A B C D A E F G

Mon IncrMon Incr A B H Monday Incr 100 GB 7-10x 10 GB

WEEKEND FULL 1 TB 2- 4x 250 GB




A B C D E F G H I


A B C D A E F G

Mon IncrMon Incr A B H

Tues IncrTues Incr C B I

Monday Incr 100 GB 7-10x 10 GB

Tuesday Incr 100 GB 7-10x 10 GB





A B C D E F G H I J


A B C D A E F G



Weds IncrWeds Incr E G J



Wednesday Incr 100 GB 7-10x 10 GB





A B C D E F G H I J


A B C D A E F G



Thurs IncrThurs Incr A C K




K


Thursday Incr 100 GB 7-10x 10 GB





Second Friday Full BackupSecond Friday Full Backup

B C D E F L G H

A B C D E F G H I J


A B C D A E F G



Thurs IncrThurs Incr A C K




K L


Thursday Incr 100 GB 7-10x 10 GB

2nd WEEKEND FULL 1 TB 50-60x 18 GB

TOTAL 2.4 TB 7.8x 308 GB





Deduplication at Backup / Recovery Speeds

• 102,400 lookups/sec.: is it already in the multi-TB

store?

– 800 MB/sec, for 8KB segment: >100K lookups per second

– If random lookups: very slow

– Each disk: 1 MB/sec

• E.g. for a 7.2KB RPM Seagate 1TB SATA drive: <120

seeks/second

• 120/second @ 8KB segment: 0.96 MB/sec/disk

– Would need 830 disks to go 800 MB/sec (like most dedupers

today)

• This is 4 full height racks of nothing but SATA disks (16 drives /

3U rack)

Same performance, in less than half a full height rack


SISL Scaling Architecture

• Check uniqueness with Summary

Vector

• Check in-memory fingerprint cache

• Key resultsSee: http://www.usenix.org/events/fast08/tech/full_papers/zhu/zhu.pdf

• Data Domain answer: SISL™– Stream-informed Segment Layout

includes:• Summary Vector in RAM says if segment is

new• Segment Localities minimize seeks if answer

is on disk


Data Integrity: Data Invulnerability ArchitectureTrust but verify – hope is not a strategy



• Data verification– CheckSum– Dedupe, write to disk– Verify




• Self-healing file system– Cleaning– Expired data– Defrag– Verify


• Other– RAID-6– NVRAM– Snapshots

• Self-healing file system– Cleaning– Expired data– Defrag– Verify




Disk

1 TB

Disk

1 TB

Disk

1 TB

RMAN> ALLOCATE CHANNEL CH1 DEVICE TYPE DISK FORMAT ‘/dd/backup/ora.weekly/%U’;RMAN> ALLOCATE CHANNEL CH2 DEVICE TYPE DISK FORMAT ‘/dd/backup/ora.weekly/%U’;RMAN> BACKUP AS COPY TAG ‘MAY9’ DATABASE INCLUDE CURRENT CONTROLFILE;RMAN> BACKUP ARCHIVELOGS TAG ‘MAY9’ ALL NOT BACKED UP DELETE ALL INPUT;

Target DB

1 TB

Weekly: Full image backups

Before: Without deduplication

Weekly Full Backup – With Deduplication



Target DB

1 TB


Full

500 GB500 GB

After: With deduplication




Target DB

1 TB

Deduplication applied to fulls requiring much less disk


Full

500 GB500 GB

After: With deduplication



Target DB

1 TB

RMAN> ALLOCATE CHANNEL CH1 DEVICE TYPE DISK FORMAT ‘/dd/backup/ora.weekly/%U’;RMAN> ALLOCATE CHANNEL CH2 DEVICE TYPE DISK FORMAT ‘/dd/backup/ora.weekly/%U’;RMAN> BACKUP INCREMENTAL DATABASE ….


500 GB Weekly Fulls

Incrementals after deduplication

Daily Incremental Backup – With Deduplication


Target DB

1 TB

RMAN> ALLOCATE CHANNEL CH1 DEVICE TYPE DISK FORMAT ‘/dd/backup/ora.weekly/%U’;RMAN> ALLOCATE CHANNEL CH2 DEVICE TYPE DISK FORMAT ‘/dd/backup/ora.weekly/%U’;RMAN> BACKUP INCREMENTAL DATABASE ….


500 GB Weekly Fulls

Daily Incrementals

Incrementals after deduplication

Daily Incremental Backup – With Deduplication


Benefits of Using Inline Deduplication

• Daily fulls instead of incrementals• Longer online retention of full backup

images• No requirement for other backup software

plug-ins• Non disruptive introduction into RMAN

process• Simplified replication using EMC Data

Domain Replicator• Ideal location for Flashback Recovery Area• Incrementally updated backups


Full

Sun Wed ThuMon Tue SatFri

DB Snap

Snap

Snap

Snap

Snap

Snap

Incremental MergeEMC Data Domain combines rapid cloning and deduplication

• Results in up-to-date nightly full images available for rapid recovery

Incremental

First image backup2X storage savings

• Nightly take cumulative incremental; apply to snapshot of weekly full


Alternatives

• RMAN to 3rd Party Backup MML/SBT– Makes random access disk look like streaming tape. Not cost

effective– Limits the options available to the DBA for backing up, cloning,

merging, etc.– RMAN communicates through MML to agent on 3rd party backup

application media server– Can front a Data Domain system as either disk-based backup or

VTL– All RMAN I/O is via MML which presents only a DEVICE TYPE TAPE

Data Domain can work with an enterprise backup application but does not require it.


Oracle Customers Leveraging Data Domain

• RMAN and db2backup to NFS mounts on DD690 and DD880 systems replicating to DD690 and DD580 systems

• 4 week retention schedule, 10% average daily change rate, archive logs backed up hourly

• All database backups replicated again to SunGard

• Sustained deduplication ratios of >6:1 (includes archive logs)

CN Rail – A Large Canadian Freight Railroad


Oracle Customers Leveraging Data Domain

• Oracle tablespace archive for data warehouse

• Large table spaces are written to Data Domain systems and flagged as read only and used for data mining

• Sustained deduplication ratios of >7:1

Large California-based clothing retailer


“EMC Data Domain is just disk to me. Changing RMAN scripts to go straight to Data Domain disk was simple.”DBA Manager

Oracle RMAN to DiskNational supermarket chain testimonial

“We used to have to go through our backup team for recovery requests and 90% of our actual restore time was spent waiting on tape and administration. With Data Domain, I don't have to wait for someone else to satisfy a restore request or a tape recall.” DBA Manager


Summary

• How deduplication benefits Oracle/RMAN backups

• Simplification

• Savings


More Information…

• For more information on EMC Data Domain and Oracle, visit

http://www.datadomain.com/solutions/oracle.html



1© copyright 2010 emc corporation. all rights reserved. mel shum technical marketing engineer emc...

Documents

tb rman

emc corporation

incremental backup slide

tb of backup storage

backup information

backup recovery utility

backups slide

money emc data domain