Documente Academic
Documente Profesional
Documente Cultură
This document is for informational purposes. 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 in this document remains at the sole discretion of Oracle. This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. This document and information contained herein may not be disclosed, copied, reproduced or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.
Jeffrey McCormick
The Hartford
Agenda
Maximum Availability Architecture (MAA) The Hartford and MAA HA Best Practices, Tips and Results
Turbocharged Data Guard Oracle Snapshots and Clones More Uptime for Planned Downtime Transparent Client Failover for Disaster Recovery
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
Our Approach
Develop HA solutions and features Work closely with different development teams
Provide feedback early in the development cycles Integrate features and test before and after release
Deploy MAA on internal production systems Design and influence future solutions and features Partner with strategic infrastructure providers Document in best practice books and white papers
Jeff McCormick
Senior Data Architect The Hartford
$22.7 billion in revenue Leading provider of investment products, life insurance, employee benefits, auto, homeowner & business insurance Largest seller of individual annuities in U.S. 11,000 agencies, 100,000 broker/dealers 30,000 employees
Architecture Review
Focus on Business Continuity Assess information technology architectures Minimize/avoid planned & unplanned downtime Rapid recovery/failover to remote location Provide excellent service at lowest cost Retain flexibility to incorporate new technology
Database REDO
Database REDO
Data Guard Standby Data Guard Standby Data Guard Standby Data Guard Standby
Storage Array
Storage Array
Storage Array
Primary
Primary
Primary Site
Secondary Site
Tertiary Site
Implement a High Availability solution that offers considerable savings in cost, resources, and time.
Tune network device queues to eliminate packet losses and waits. Set device queues to a minimum of 10,000 (default 100)
* BDP = the product of the estimated minimum bandwidth and the round trip time between the primary and standby server
Default
10.8
Tuned
937
200
400
600
800
1000
Intra-file parallelism support for ARCH Up to 29 parallel remote archive processes Dedicated local ARCH
250 200 150 100 50 0 0ms 10ms 50ms 100ms 52 63 54 77 74 155 102
Network latency
25 20 15 10 5 0 1 2
Example: Less than 7 seconds of data loss exposure for high redo rates of 2-12 MB/sec with <=25 ms latency in our tests
Best Practice
Allocate additional I/O bandwidth for Online Redo Log Files
Performance Gains
For Redo rates less than 2 MB/sec, there is less than 5% impact on the primary database across different latencies For very high redo rates of 20 MB/sec, less than 10% impact on primary database even with latencies of 50 and 100 ms Overall, Oracle 10g Release 2 database throughput (redo rate) was 2-3 times faster than 10gR1 at high redo rates and latencies
Best Practices
Use Redo Apply (Physical Standby) For simplicity, use identical directory structures on the primary and standby databases
Directory structures can be different see best practice paper for details
Use RMAN Recovery Catalog so that backups taken on one database server can be restored on another
Use a catalog server physically separate from primary and standby sites
http://www.oracle.com/technology/deploy/availability/pdf/RMAN_DataGuard_10g_wp.pdf
Higher wait times for DBWR (db file parallel writes) result in
Contention for free buffers Increase in buffer busy waits
Oracle Solution
Database [guaranteed] restore points
Create restore point <snap1> [guarantee flashback database]
Restore points only captures one before image block for every changed blocks regardless of how many times it has been changed Flashing back to restore point is proportional to copying the changed blocks over and applying a small amount of recovery Not appropriate as a replacement for full backups
Oracle has all the tools to create a clone without the need of third party products
Clone Performance:
Resync vs Recreate
100 90 80 70 60 50 40 30 20 10 0 97 Time (Mins)
18.47
23.68
Best Practices:
Compare performance between Oracle and current approaches Sufficient IO bandwidth and storage implies faster flashback and resync performance Enable block change tracking on the primary Use RMAN parallelism
Best upgrade approach if RAC rolling upgrade is not possible and there are no data type restrictions
Best upgrade approach for customers that are currently using streams
With Streams, you can work around some data type restrictions by using
triggers to capture changes from an unsupported tables to a shadow tables that has supported data types Replicate the shadow table changes Use customized apply to apply the changes to the original tables on the target database
Phase 1: Preparation
1. Create shell of target database using new version 2. Create schemas in target database 3. Create physical standby if source and target hosts are different
QUESTIONS ANSWERS