Post on 23-Jun-2020
<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
<Insert Picture Here>
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
<Insert Picture Here>
Program
Exadata & Data Guard
MAA Best Practices
Standby Instantiation
Configuration
Network Configuration
Availability
Return on Investment
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
<Insert Picture Here>
Program
Exadata & Data Guard
MAA Best Practices
Standby Instantiation
Configuration
Network Configuration
Availability
Return on Investment
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
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
<Insert Picture Here>
Program
Exadata & Data Guard
MAA Best Practices
Standby Instantiation
Configuration
Network Configuration
Availability
Return on Investment
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
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
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
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
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
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
Database serverDatabase serverDatabase server
Infin
iBa
nd
sw
itch
Database server
NET3 NET2 NET1 NET0 ILOM BOND0
Database serverDatabase serverDatabase serverDatabase serverDatabase serverDatabase serverStorage server
NET0 ILOM BOND0
Database serverDatabase serverDatabase server
Infin
iBa
nd
sw
itch
Database server
NET3 NET2 NET1 NET0 ILOM BOND0
Database serverDatabase serverDatabase serverDatabase serverDatabase serverDatabase serverStorage server
NET0 ILOM BOND0
Local Standby
Client Access
InfiniBand andData Guard Redo Transport
Network Key
Primary
MOS Note960510.1
22
<Insert Picture Here>
Program
Exadata & Data Guard
MAA Best Practices
Standby Instantiation
Configuration
Network
Availability
Return on Investment
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
Primary SiteRemote Site
Disaster Recovery
ASYNC
Data Guard
Local
Standby
Database
SYNC
Remote Standby
Database
2525
Local Failover
Database HA with Zero Data Loss
Primary SiteRemote Site
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
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
<Insert Picture Here>
Program
Exadata & Data Guard
MAA Best Practices
Standby Instantiation
Configuration
Network
Availability
Return on Investment
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