Disaster Recovery for the Exadata Database Machine Maximum ... · Disaster Recovery for the Exadata Database Machine Maximum Availability Architecture Best Practices Joseph Meeks

<Insert Picture Here>

Disaster Recovery for the Exadata Database Machine

Maximum Availability Architecture Best Practices

Joseph Meeks

Director,

Product Management

Lawrence To

Senior Manager

MAA Development

Dan Dressel

Database Architect

Thomson Reuters

2


Program

Data Guard & Exadata

MAA Best Practices

Standby Instantiation

Configuration

Network

Availability

Return on Investment

Thomson Reuters

3

What is Oracle Data Guard?Best Data Protection and Availability for Oracle Databases

Standby SitePrimary Site

Data Guard

Data Guard SYNC / ASYNC

PrimaryDatabase

Active Standby

Database

Data Guard Broker

Enterprise Manager Grid Control

4

Exadata Database Machine and Data GuardBusiness as Usual – Taken to the Extreme

High Performance

Both OLTP and Data Warehouse

Very large databases

Consolidation – hosting multiple databases on a single machine

Exadata Hybrid Columnar Compression (EHCC)

Database File System for full-stack Disaster Recovery

Return on investment – full standby utilization

Maximum Availability Architecture (MAA) best practices

5

5.8 TB/hour archive rate

3 TB/hour load rate, full MAA configuration

2.7 TB/hour Data Guard redo transport rate

2.1 TB/hour Data Guard Redo Apply rate on standby

High PerformanceMAA Best Practice Benchmarks

6

3TB/Hour Load in a Data Guard ConfigurationUsing Complete MAA Best Practices

3 TB/hour

Archivelog mode

Force logging

Flashback Database

Corruption protection

db_block_checksum=typical, db_block_checking=off,

db_lost_write_protect=TRUE

Real Application Clusters

ASM redundancy

Data Guard ASYNC redo transport

7

Disaster Recovery for Exadata Database MachineOracle Data Guard Advantages

Best corruption protection

Least risk - always on

Highest availability

High ROI

High performance

Proven on Exadata

8


Program

Exadata & Data Guard

MAA Best Practices


Configuration

Network Configuration

Availability


Thomson Reuters

9

Standby Instantiation Using RMAN

Simplest : DUPLICATE TARGET DATABASE FOR

STANDBY FROM ACTIVE DATABASE

2.9 TB/hour, single InfiniBand and one RMAN session

0.4 TB/hour, a single GigE

If more throughput is needed, use multiple BACKUP AS

COPY commands with an RMAN session for each Oracle instance

– 6.1 TB/hour over two InfiniBand and two RMAN sessions

– 11.7 TB/hour over four InfiniBand and four RMAN sessions

– 3 TB/hour across eight GigE and eight RMAN sessions

• Testing with 10GigE and X2-8 planned

10

Standby Instantiation – Case Study

Scenario: 50 TB database, generates 1 TB redo/day

Time to instantiate a local standby on LAN

5.5 hours when using InfiniBand and 4 RMAN sessions

Time to instantiate a remote standby on WAN

18 hours when using GigE and 8 RMAN sessions if sufficient

WAN bandwidth.

If bandwidth constrained, investigate

F5 to optimize network utilization

• MOS Note 1206603.1

11

Exadata Primary, Exadata Standby

Why?

Exadata Hybrid Columnar Compression (EHCC)

Best Recovery Time Objective when using EHCC

Performance

Validated MAA Best Practices and proven customer

deployments

12


Program


MAA Best Practices


Configuration


Availability


Thomson Reuters

13

Base Configuration

Incorporate best practices during deployment time

MAA validated configuration best practices

MOS Note 757552.1: Oracle Exadata Best Practices

Oracle Data Guard: Disaster Recovery Best Practices for Sun

Oracle Database Machine and Exadata Cell

Recommended software and patch releases

MOS Note 888828.1: Exadata Database Machine 11g Release 2

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=757552.1&h=Y

http://www.oracle.com/technetwork/database/features/availability/maa-wp-dr-dbm-130065.pdf

http://www.oracle.com/technetwork/database/features/availability/maa-wp-dr-dbm-130065.pdf

14

ASMDisk Group Configuration and Deployment

1. Disk Group striped across all cells and disks

2. High Redundancy Disk Group

3. Optimal and validated file placement

4. OneCommand automation

http://www.oracle.com/technetwork/database/features/

availability/exadata-maa-131903.pdf

15

Flashback DatabaseConfigure for all Applications

Enable Flashback Database

Minimum impact to OLTP workloads (< 2%)

On primary: 3 TB/hour DW load in 11.2.0.2

On standby: 1.7 TB/hour redo apply rate

Operational best practices required

Use local extent managed tablespace

If loading, recreate objects instead of truncate operation

Size fast recovery area to a minimum of redo rate X

DB_FLASHBACK_RETENTION_TARGET

Refer MOS 565535.1

16

Data Corruption ProtectionConfiguration Best Practices

ASM auto repair, Exadata HARD compliant checks and

Active Data Guard auto-block repair are transparent

Set DB_BLOCK_CHECKSUM=TYPICAL | FULL and

DB_LOST_WRITE_PROTECT=TYPICAL

Less than 5% performance impact for DW and OLTP workloads

Evaluate DB_BLOCK_CHECKING = MEDIUM | FULL

performance impact varies with workload

Setting on the primary enables end to end physical and logical

block checking (11.2)

17


Program


MAA Best Practices


Configuration


Availability


Thomson Reuters

18

Network Best Practices

Network Configuration (MOS Note 960510.1)

TCP Socket Size = max (10MB, 3 X BDP) and

SDU=32K

Tune Log Buffer Size for high in-memory hit ratio

(Refer to MOS 951152.1)

19

Network Configuration – Shared GigE (Eth1)If combined application and Data Guard volume < 100 MB/sec per dbnode

Database serverDatabase serverDatabase server

Infin

iBa

nd

fab

ric

Database server

NET3 NET2 NET1 NET0 ILOM BOND0

Database serverDatabase serverDatabase serverDatabase serverDatabase serverDatabase serverStorage server

NET0 ILOM BOND0


Infin

iBa

nd

fab

ric

Database server



NET0 ILOM BOND0

Primary Site Disaster Recovery Site

Client Access andData Guard Redo Transport

InfiniBand

Network Key

MOS Note 960510.1

20

Network Configuration – Dedicated GigE (Eth3)If combined application and Data Guard volume > 100 MB/sec from dbnode


Infin

iBa

nd

fab

ric

Database server



NET0 ILOM BOND0


Infin

iBa

nd

fab

ric

Database server



NET0 ILOM BOND0

Disaster Recovery Site

Client Access

InfiniBand

Data Guard Redo Transport

Network Key

Primary Site

MOS Note 960510.1

21

Network Configuration – InfiniBandFor Data Guard if bandwidth requirement > GigE


Infin

iBa

nd

sw

itch

Database server



NET0 ILOM BOND0


Infin

iBa

nd

sw

itch

Database server



NET0 ILOM BOND0

Local Standby

Client Access

InfiniBand andData Guard Redo Transport

Network Key

Primary

MOS Note960510.1

22


Program


MAA Best Practices


Configuration

Network

Availability


Thomson Reuters

2323

Disaster Recovery

Primary

Database

Primary SiteRemote Site

Disaster Recovery

ASYNC

Data Guard

Remote Standby

Database

2424

High Availability & Disaster Recovery

Primary

Database


Disaster Recovery

ASYNC

Data Guard

Local

Standby

Database

SYNC

Remote Standby

Database

2525

Local Failover

Database HA with Zero Data Loss


Disaster Recovery

ASYNC

Data Guard

Primary

Database

Remote Standby

Database

26

Reduce Downtime for Planned MaintenanceUpgrades, Migrations, Database Rolling Upgrades

Upgrades and Migrations

Exadata DBM V1 to X2-2 (upgrade)

Exadata X2-2 to X2-2 or X2-8 (Linux)

Exadata X2-2 to X2-2 or X2-8 (Solaris x86)

Best Practices for Migrating to Sun Oracle Database Machine

and Exadata Cell

Simplified Database Rolling Upgrade

Applicable for any releases and system changes that are not

RAC rolling upgradeable, Bundle Patches, CPUs, Patchsets

and Major Release

Validate and Switchover

http://www.oracle.com/technetwork/database/features/availability/xmigration-11-133466.pdf





27

Database Rolling UpgradeFor Physical Standby Databases – Transient Logical Standby

Oracle supported script to automate rolling upgrade

The script automates the:

Temporary conversion of a physical standby to use SQL apply

Switchover of production to the standby after standby is upgraded

Original primary becomes a physical standby database

Upgrade and resynchronization of the original primary

A second switchover (optional) that returns all databases to their

original roles

What DBA’s needs to know: MOS Note 949322.1

28

Reduce Risk of Planned MaintenancePatch Assurance using Standby-First Patching - 11.2.0.2 onward

Patch Assurance –Standby First Patching

Always applicable for exadata patches

Support for most patchsets, CPUs, PSUs to be

applied on standby first

Validate on standby for maximum 48 hours

Switchover with minimum downtime and risk

29


Program


MAA Best Practices


Configuration

Network

Availability


Thomson Reuters

30

Increase Return on Investment on Standby Systems

Turn your standby into a production system

Active Data Guard

Cross-hosting of primary databases

Consolidate

Host multiple standby instances on a single database machine

Use standby system for development and test

Offload backups

Use standby to reduce planned downtime

Upgrade standby first then switchover

Minimize downtime and risk

THOMSON REUTERS EXADATA DATABASE MACHINE AND ORACLE DATA GUARD

DAN DRESSELSEPTEMBER 23, 2010

THOMSON REUTERS PROFESSIONAL LEGAL

• Exadata Database Machines

– 6 Exadata Full Racks

– 3 Exadata Quarter Racks

• Non Exadata Environment

– Over 800 Oracle Databases Deployed

• Mostly 2 Node RAC Database Clusters

– Over 2000 Oracle Instances Deployed

– Over 1 PB Of Allocated Database Storage

– Data Guard Used To Protect Most Databases

EXADATA DATABASE MACHINE ORACLE DATA GUARD IMPLEMENTATION

EXADATA PERFORMANCE BENEFITS

• Revenue and Usage Data Warehouse (DW)

• Fermi Data Warehouse

• Master Records Database (MRD)

TEST PERFORMANCE

METRIC

EXADTA IMPROVEMENT

DW Query Elapsed Time 1.3x faster (Exadata V2 versus Exadata V1)

Fermi Query Elapsed Time 4.4x faster (Exadata V2 versus Sun AMD)

MRD Query Elapsed Time 12x faster (Exadata V2 versus pSeries)

Logical IO 7x fewer (Exadata V2 versus pSeries)

DATA GUARD BUSINESS BENEFITS

• Business Applications

– Data Warehouse

– Content Publishing

• Business Benefits

– Standby Available For Read Only Processing

• Redirect Users Quickly If Needed

– Data Guard Standby is Considered Our Backup

• No Off Machine Backup Costs And Complexity

– Data Guard Standby Is Our Disaster Recovery System

CONFIGURATION

• No Special Configuration for Exadata

– Consistent With Our Non-Exadata Configurations

– Faster Apply Throughput

• 50 MB/Sec For Our Workload

• Setup And Configuration

– Duplicate from Active Database to Instantiate

– Forced Logging at the Database Level

– Asynchronous Transport Used

– Flashback Database

– Log Buffer Size Increased

FUTURE PLANS

• Implement Fast-Start Failover

• Increase Distance Between Primary and Standby

38

WAN

• Comprehensive protection from failures: server, storage, network, site, corruptions

• Correction from human errors: database, table, row, transaction

• Active DR: Real-time remote standby open for query offload

• Online indexing and table redefinition

• Online patching and upgrades

• Database rolling upgrades and migrations

Real Application

Clusters

ASM

Fast Recovery Area

Active Data Guard

Oracle Secure Backup

Oracle MAA with Database MachineComplete, Open, Integrated, Highly Available

39

Disaster Recovery for Exadata Database MachineOracle Data Guard Advantages

Best corruption protection

Least risk - always on

Highest availability

High ROI

High performance

Proven on Exadata

40

Documents

Disaster Recovery for the Exadata Database Machine Maximum ... · Disaster Recovery for the Exadata Database Machine Maximum Availability Architecture Best Practices Joseph Meeks