Active dataguard
20 likes6,919 views
This document provides an overview of Oracle Active Data Guard, which allows standby databases to be open for read-only access while redo data is being shipped from the primary database. Key points include: - Active Data Guard enables offloading of queries and reporting to standby databases while maintaining high availability. - Fast incremental backups can be performed on standby databases, which are up to 20 times faster than full backups. - Real-time queries on standby databases always see the most up-to-date committed data from the primary with minimal latency.
![Apply Safely
Lost Write Detection
• What is a Lost Write:
• Storage loses a write that it has acknowledged to Oracle as complete
• Subsequent transactions read stale version of the block and either:
• Update the same block again
• Update another block
• Do something external: print a check, generate an invoice, issue an order
• Primary may continue running for hours or days
• It may generate an assortment of internal errors, e.g. ORA-00600:[4135],
or [4137], or [4152], or [qertbFetchByRowID], depending upon the objects
impacted and the writes that are lost
• Primary may eventually crash
• Any recovery of a block that is victim of a lost write will fail
• ORA-600 [3020] stuck recovery error
19](https://image.slidesharecdn.com/activedataguard-121101033122-phpapp02/85/Active-dataguard-19-320.jpg)
![Lost Write Happens
As Reported in SR - Oracle Database 10g Release 2
Lengthy outage impacting a multi-terabyte database
• Problems first surface on their standby database
ORA-00600: internal error code, arguments: [3020] , [648], [1182463], [2719091455], []
ORA-10567 : Redo is inconsistent with data block (file# 648, block# 1182463)
Recovery interrupted!
• Many hours later – production is down
Noticed odd query results on production
Noticed ORA-600 errors on production this morning for which SGA Heapdump was uploaded.
New info : I was rebuilding an index. After a few minutes, the database took an unexpected crash.
***please help. it's very urgent, production is down.***
• Problems traced to lost writes caused by faulty hardware
20](https://image.slidesharecdn.com/activedataguard-121101033122-phpapp02/85/Active-dataguard-20-320.jpg)
![Not a Problem for Data Guard 11g
Capability Unique to Oracle Database
• Detect lost writes using new initialization parameter
db_lost_write_protect
• Apply compares standby version of block to incoming redo
• ORA-752 if block SCN from primary is lower than standby
• 100% certain of a lost write on the primary database
• Resolve via failover to standby to restore data consistency
• ORA-600 [3020] if block SCN from primary is higher than standby
• Possibility of a lost write on the standby database
• Resolve by re-creating the standby database or affected files
21](https://image.slidesharecdn.com/activedataguard-121101033122-phpapp02/85/Active-dataguard-21-320.jpg)
![Fast-Start Failover
Configuration Options for Optimal RPO
• Immediate failover for user-configurable health conditions
ENABLE FAST_START FAILOVER [CONDITION <value>];
• Condition examples:
• Datafile Offline
• Corrupted Controlfile
• Corrupted Dictionary
• Inaccessible Logfile
• Stuck Archiver
• Any explicit ORA-xyz error
• Apps can request fast-start failover using API
DBMS_DG.INITIATE_FS_FAILOVER
36](https://image.slidesharecdn.com/activedataguard-121101033122-phpapp02/85/Active-dataguard-36-320.jpg)
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to Active dataguard (20)
Ad
Recently uploaded (20)
Active dataguard
- 1. Oracle Active Data Guard Standby on Steroids – DR Included Joe Meeks, Director, Product Management, Oracle Shawn Ormond, Database Administrator, Intermap Technologies Inc Yucheng Liu, Senior Database Administrator, Real Networks Krishna Kakatur, Senior. Database Administrator, Real Networks 1
- 2. Today’s Objectives Deep Dive Shine the Light 2
- 3. Program y db an St • Ship Redo / Apply Redo uar d G • Utilize your standby database Da t a • Active Data Guard • Snapshot Standby • Reduce downtime • Active Data Guard experiences • Real Networks • Intermap Inc • Resources - Q&A Focus on Oracle Database 11g and Redo Apply (physical standby) 3
- 4. Oracle Data Guard Best Protection at Lowest Cost Automatic Failover Active Standby Production Databases Database SYNC or ASYNC Redo Shipping Data Guard 4
- 5. Ship Redo Synchronous Redo Transport (SYNC)– Zero Data Loss User Transactions Online Queries, updates, DDL Queries, updates, DDL Co Redo User commit m Logs m it AC K Active Standby LGWR Database SGA Redo Buffer MRP LNS RFS LSP Standby MRP - physical Redo LSP - logical Logs Primary Database Oracle Net Queries, Reports Testing & Backups 5
- 6. Ship Smart Just the Redo . . . • Data Guard ships only redo records • SCN aware • Enables reliable recovery • Guarantees commits are applied in order • Storage remote-mirroring must ship every write • 7x greater volume and 27x more network I/Os than Data Guard • Round-trip network latency impacts EVERY write to EVERY file • Data Guard Compared to Storage Remote-Mirroring http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardRemoteMirroring.html 6
- 7. Ship Redo Asynchronous Redo Transport (ASYNC) User Transactions Online Queries, updates, DDL Queries, updates, DDL Co Redo User commit m Logs m it AC K Active Standby LGWR Database SGA Redo Buffer MRP LNS RFS LSP Standby MRP - physical Redo LSP - logical Logs Primary Database Oracle Net Queries, Reports Testing & Backups 7
- 8. Ship Redo ASYNC – If Network Can’t Keep Pace User Transactions Queries, updates, DDL Queries, updates, DDL Online Co Redo User commit m Logs m it AC K Active Standby LGWR Database SGA Redo Buffer MRP LNS RFS LSP Standby MRP - physical Redo LSP - logical Logs Primary Database Oracle Net Queries, Reports Testing & Backups 8
- 9. Shipping vs. Protection Mode Protection Mode Controls Response to Failure Events Mode Risk of data loss Transport If no acknowledgement from standby: Zero Data Loss Maximum Stall primary until acknowledgement is Protection Double Failure SYNC received from replica Protection Zero Data Loss Stall primary until acknowledgement is Maximum Availability Single Failure SYNC received or timeout threshold period expires Protection – then resume processing Maximum Potential for Primary never waits for standby Performance ASYNC acknowledgement Minimal Data Loss 9
- 10. Shipping vs. Protection Mode Protection Mode Controls Response to Failure Events Mode Risk of data loss Transport If no acknowledgement from standby: Zero Data Loss Maximum Stall primary until acknowledgement is Protection Double Failure SYNC received from replica Protection Zero Data Loss Stall primary until acknowledgement is Maximum Availability Single Failure SYNC received or timeout threshold period expires Protection – then resume processing Maximum Potential for Primary never waits for standby Performance ASYNC acknowledgement Minimal Data Loss NET_TIMEOUT parameter of LOG_ARCHIVE_DEST_n Data Guard 11g default = 30 seconds Data Guard 10g default = 180 seconds 10
- 11. Ship Redo Automatic Gap Resolution – Primary Pings Standby Transactions Oracle Net Redo Buffer SGA LGWR Primary Online Redo Database Logs ping ARCH Archived Redo Logs 11
- 12. Ship Redo Automatic Gap Resolution – Connect to Standby Active Oracle Net Standby Transactions Database Redo Buffer MRP SGA LSP LGWR Primary Online Redo Database Logs Queries ping Reports ARCH RFS Testing Backups Archived Redo Logs 12
- 13. Ship Redo Automatic Gap Resolution – Ship Log Gap Active Oracle Net Standby Transactions Database Redo Buffer SYNC MRP LNS RFS SGA ASYNC LSP LGWR Standby Primary Online Redo Redo Logs Database Logs Queries ping ARCH Reports ARCH RFS Testing Backups Archived Redo Logs 13
- 14. Ship Redo Automatic Gap Resolution – Gap Resolved Active Oracle Net Standby Transactions Database Redo Buffer SYNC MRP LNS RFS SGA ASYNC LSP LGWR Standby Primary Online Redo Redo Logs Database Logs Queries ping ARCH Reports ARCH RFS Testing Backups Archived Redo Logs 14
- 15. Ship Fast Network Compression for Gaps seconds 80 • To enable compression: 70 • Set Data Guard broker property, or 60 • Set compression attribute of redo transport destination 50 40 • Resolves gaps up to 3x faster 30 • Better data protection 20 • Given there is sufficient CPU 10 • Negligible impact on response time 0 • Negligible impact on throughput elapsed time to resolve gap • Requires Oracle Advanced uncompressed compressed Compression Option 11g 15
- 16. Ship Fast Enable Compression for ASYNC Transport _REDO_TRANSPORT_COMPRESS_ALL=TRUE • Useful when network volume exceeds bandwidth • Test case: • Network Bandwidth: 100Mbps network (12.5MB/s) • Redo Rate: 22MB/s • Results • Without compression, transport lag increased linearly over time • With compression enabled, transport lag ranged from 4-10 seconds • Compression ratio: 60% • Implementation details - see MetaLink Note 729551.1 16
- 17. Apply Redo Redo Apply (physical standby) Parallel Media Recovery • MEDIA RECOVERY COORDINATOR (MRP0) • Manages recovery session, merges redo by SCN from multiple instances, parses redo into change mappings partitioned by apply slave • APPLY SLAVES • Read data blocks, assemble redo changes from mappings, apply redo changes to data blocks Parallel Media Recovery - 4 CPU server apply slave (pr00) Media Recovery Coordinator (MRP0) apply slave (pr01) coordinator & thread merger apply slave (pr02) • Automatically configures the # of slaves = # CPUs - 1 17
- 18. Apply Fast 100% Faster than Oracle Database 10g 120 • Increased parallelism 100 112 • Less synchronization 80 • Better utilization of I/O and CPU resources MB/sec 60 • Optimizations for 40 47 48 direct-path loads 20 24 • Self-configuring* 0 OLTP Direct Path Load *for ASYNC I/O 10gR2 11gR1 18
- 19. Apply Safely Lost Write Detection • What is a Lost Write: • Storage loses a write that it has acknowledged to Oracle as complete • Subsequent transactions read stale version of the block and either: • Update the same block again • Update another block • Do something external: print a check, generate an invoice, issue an order • Primary may continue running for hours or days • It may generate an assortment of internal errors, e.g. ORA-00600:[4135], or [4137], or [4152], or [qertbFetchByRowID], depending upon the objects impacted and the writes that are lost • Primary may eventually crash • Any recovery of a block that is victim of a lost write will fail • ORA-600 [3020] stuck recovery error 19
- 20. Lost Write Happens As Reported in SR - Oracle Database 10g Release 2 Lengthy outage impacting a multi-terabyte database • Problems first surface on their standby database ORA-00600: internal error code, arguments: [3020] , [648], [1182463], [2719091455], [] ORA-10567 : Redo is inconsistent with data block (file# 648, block# 1182463) Recovery interrupted! • Many hours later – production is down Noticed odd query results on production Noticed ORA-600 errors on production this morning for which SGA Heapdump was uploaded. New info : I was rebuilding an index. After a few minutes, the database took an unexpected crash. ***please help. it's very urgent, production is down.*** • Problems traced to lost writes caused by faulty hardware 20
- 21. Not a Problem for Data Guard 11g Capability Unique to Oracle Database • Detect lost writes using new initialization parameter db_lost_write_protect • Apply compares standby version of block to incoming redo • ORA-752 if block SCN from primary is lower than standby • 100% certain of a lost write on the primary database • Resolve via failover to standby to restore data consistency • ORA-600 [3020] if block SCN from primary is higher than standby • Possibility of a lost write on the standby database • Resolve by re-creating the standby database or affected files 21
- 22. Program y db an St • Ship Redo / Apply Redo uar d G • Utilize your standby database Da t a • Active Data Guard • Snapshot Standby • Reduce downtime • Active Data Guard experiences • Real Networks • Intermap Inc • Resources - Q&A 22
- 23. Data Guard 11g Read-write Workload Real-time Real-time Reporting Queries Fast Incremental Backups Continuous redo shipping, validation & apply Production Physical Standby Database Database 23
- 24. Active Data Guard 11g Read-write Real-time Workload Reporting Real-time Real-time Reporting Queries Fast Incremental Fast Backups Incremental Backups Continuous redo shipping, validation & apply Production Active Standby Physical Standby Database Database • Offload read-only queries to an up-to-date physical standby • Use fast incremental backups on a physical standby – up to 20x faster 24
- 25. What’s so Different? Data Guard 11g Active Data Guard Option • Stop redo apply at 8am • Redo apply is always on • Open read-only for queries • Always open read only • By 4pm, data is 8 hours old • Queries and reports always see latest data • Any failover will be delayed • Failover is immediate when due to backlog of data that needed, standby database must be applied always up-to-date • Active Data Guard MAA Best Practices http://www.oracle.com/technology/deploy/availability/pdf/maa_wp_11gr1_activedataguard.pdf 25
- 26. Active Data Guard Utilize Standby Databases Better Performance and Increased Scalability 3000 2500 2690 2000 Before ADG TPS 1500 1530 After ADG 1000 500 630 290 0 Read/Write Read/Only Transactions Transactions 26
- 27. Active Data Guard Queries Return Up-to-date Results Latency Between Primary Commit and Ability to Read the Same Data on an Active Standby 1.2 1 0.8 Seconds 0.6 0.4 0.2 0 6:24:16 6:24:34 6:24:52 6:25:10 6:25:28 6:25:46 6:26:04 6:26:22 6:26:40 6:26:58 6:27:16 6:27:34 6:27:52 6:28:10 6:28:28 6:28:46 6:29:04 6:29:22 6:29:40 6:29:58 dw4 27
- 28. Oracle Business Intelligence Suite Release 10.1.3.4 Certified for Active Data Guard • Oracle Business Intelligence Suite EE Plus • Suite of BI products offering full range of analysis and reporting • Includes Oracle Hyperion reporting products • Oracle BI server runs on an Active Standby Database • Oracle BI server is a read-mostly application • Configuration highlights • Disable BIEE server from creating temp tables on standby • Create read-only connection pool • Create a write-back connection pool to redirect writes to the primary or a local ‘scratch’ database • Oracle Business Intelligence and Active Data Guard MAA Best Practices http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm 28
- 29. Offload Backups RMAN Block Change Tracking • Offload fast incrementals to an Active Data Guard Standby • Block change tracking eliminates full scans • Incremental backups complete 20x faster (8.3 min vs 2.8 hrs) • Minimal overhead on standby database – less than 3% • If currently using a split mirror to offload backups – consider repurposing that storage • Deploy a local standby database instead • Realize better HA, better data protection and more reliable backups. • Use standby to offload query workload and/or serve as test system • S298772 - Oracle Recovery Manager (RMAN) Best Practices for Oracle Data Guard and Oracle Streams, Wednesday, 11:30 am – 12:30 pm, Moscone South Room 103 29
- 30. Test System Oracle MAA Partners Helping with Active Data Guard Testing EMC CX3-40F UltraScale Storage Systems • Flare Release 26 • 4 GB RAM per SP • Write Cache = 2GB • Read Cache = 1GB per SP • 60 146GB FC drives @ 15K RPM • All LUNs bound as 1+1 Raid 10 • Non Vault DATA LUNs 133 GB • Vault DATA LUNS 99 GB • LUN Prefetch set to Variable with default settings Dell 6950s • 4 way Dual-Core AMD Opteron Processor 8212 • 8 GB RAM • OEL 4.5 x86_64 (2.6.9-55.0.0.0.2.ELsmp) 30
- 31. Snapshot Standby – Data Guard 11g Convert Standby Database to Read-Write Test System Updates Queries Updates redo data Primary Physical Standby Snapshot Standby Database Database Database DGMGRL> convert database <name> to snapshot standby; 31
- 32. Snapshot Standby – Data Guard 11g Convert Back to Synchronized Standby Updates Queries Updates redo data Primary Snapshot Standby Physical Standby Physical Standby Database Database Database DGMGRL> convert database <name> to physical standby; 32
- 33. Snapshot Standby 11g Simpler and with better RTO/RPO than Data Guard 10g 10.2 – Steps Required 11.1 – Steps Required Standby Standby > alter database recover managed standby database > alter database convert to snapshot standby; cancel; PERFORM TESTING, ARCHIVE LOGS CONTINUE TO BE > create restore point before_lt guarantee flashback SHIPPED database; > alter database convert to physical standby; Primary > alter system archive log current; > alter system set log_archive_dest_state_2=defer; Standby > alter database activate standby database; > startup mount force; > alter database set standby database to maximize performance; > alter system set log_archive_dest_state_2=defer; > alter database open; PERFORM TESTING, ARCHIVE LOGS NOT SHIPPED > startup mount force; > flashback database to restore point before_lt; > alter database convert to physical standby; > startup mount force; > alter database recover managed standby database disconnect from session; Primary > Alter system set log_archive_dest_state_2=enable 33
- 34. Program y db an St • Ship Redo / Apply Redo uar d G • Utilize your standby database Da t a • Active Data Guard • Snapshot Standby • Reduce downtime • Active Data Guard experiences • Real Networks • Intermap Inc • Resources - Q&A 34
- 35. Fast-Start Failover Reduce Unplanned Downtime • Maximum Availability Observer • SYNC redo transport • RPO = zero • Maximum Performance • ASYNC redo transport FastStartFailoverLagLimit • Default RPO = 30 seconds • minimum threshold = 10 seconds Primary Site Standby Site Standby Site Primary Site • Client Failover MAA Best Practices in a Data Guard Configuration www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_ClientFailoverBestPractices.pdf 35
- 36. Fast-Start Failover Configuration Options for Optimal RPO • Immediate failover for user-configurable health conditions ENABLE FAST_START FAILOVER [CONDITION <value>]; • Condition examples: • Datafile Offline • Corrupted Controlfile • Corrupted Dictionary • Inaccessible Logfile • Stuck Archiver • Any explicit ORA-xyz error • Apps can request fast-start failover using API DBMS_DG.INITIATE_FS_FAILOVER 36
- 37. Rolling Database Upgrades Use Physical Standby to Reduce Planned Downtime release n Database A release n+1 Database B Install new Oracle version in seperate homes on A & B, set guaranteed PROD Synchronize – Redo apply PSTBY restore point (GRP) on A Convert B to logical using KEEP IDENTITY (11g), upgrade and resync PROD Synchronize – SQL Apply LSTBY LSTBY Switchover, flashback A to GRP, mount in new/upgraded home, PSTBY SWITCHOVER PROD convert to physical Upgrade via redo stream and resync PSTBY Synchronize – Redo Apply PROD • Rolling Upgrade Best Practices using Transient Logical Standby http://www.oracle.com/technology/deploy/availability/pdf/maa_wp_11g_transientlogicalrollingupgrade.pdf 37
- 38. Data Guard Switchover Reduce downtime for other planned events • Scheduled power outages and site maintenance • Data center moves • Migrations to ASM and/or RAC • Technology refresh – servers and storage • Windows/Linux migrations * • 32bit/64bit migrations* • HP-UX/PA RISC to HP-UX/IPF migrations* • Implement major database changes in rolling fashion • e.g. ASSM, initrans, blocksize * see Metalink Note 413484.1 38
- 39. Program y db an St • Ship Redo / Apply Redo uar d G • Utilize your standby database Da t a • Active Data Guard • Snapshot Standby • Reduce downtime • Active Data Guard Experiences • Real Networks • Intermap Inc • Resources - Q&A 39
- 40. 11g Active Data Guard Yucheng Liu – Sr. Oracle DBA, RealNetworks [email protected] Krishna Kakatur – Sr. Oracle DBA, RealNetworks [email protected]
- 41. What is so Cool About Real Networks
- 42. Goals • Consolidate HA and Reporting Data Guard instances • Off load read-only traffic • Off load I/O intensive database backups • Guarantee data and object consistency • Reduce management of complex mview replication • Simplify deployment of read-only instances
- 43. Current Architecture APP1 APP2 APP3 …... APPn mviews ws ews ws vie vie mvi m m During a code deployment, each database is subject to a lengthy maintenance for Data DDL and mview refreshes. Farm Content DB
- 44. Current Architecture Challenges • Lengthy and complex deployment for DDL changes Each Read-only instance needs ddl scripts + mview refreshes • Publishing stops if a read only database is down • No guarantees of data and object consistency Errors can occur, missing indexes, failed mview replication Harder to manage five database images • Difficult to deploy new nodes for scaling Publishing code must be rewritten for each new node
- 45. Future Architecture APP1 APP2 APP3 …... APPn 11G Active Data Guards During a code deployment, we can release to one database and rely on active Data Guard to replicate the changes. Data Farm Content DB
- 46. Future Architecture Benefits • Shorter and simpler deployment for DDL changes Deploy changes to Primary instance only No need to rebuild mview logs after a lengthy replication stop • Guaranteed data and object consistency • Fewer distinct databases to manage • New nodes can be deployed without publication outages • Significant reduction of I/O Backup one instance instead of 4 No mview log maintenance No complete or fast refreshes
- 47. Active Data Guard Implementation Proof of Concept Test • 1 primary + 5 DGs. Primary in MaxAvailability mode. 4 DGs with SYNC redo transport mode, 1 DG with ASYNC mode. 2 DGs with connect-time failover setup. • Read only queries worked as expected on active DGs. • Changes populated from primary to active DG as expected. • Flashback primary + flashback DG tested. No need to recreate DGs. • Connect-time failover worked correctly on active DGs. (Wow!)
- 48. Lessons Learned Notes • No downtime on primary. Manual flashback on needed on DG. • Weapons you need: spfile, service management, Data Guard Broker, Flashback, Grid Control, RMAN • Switchover bug (#7032374): dbms_service.stop_service does not stop services on standby • Grid bug (#6379706): Grid does not use RMAN catalog for standby backups • Export dump (expdp) error: ORA-16000: database open for read- only access
- 49. Oracle 11g Active Data Guard High Availability, Disaster Recovery & Resource Offloading Presented By: Shawn Ormond, Database Administrator
- 50. Who is Intermap Technologies Inc.? Intermap is a digital mapping company that is proactively remapping entire countries across the world and building uniform high-resolution 3D digital national data sets which we call NEXTMap®. Intermap uses proprietary airborne Interferometric Synthetic Aperture Radar (IFSAR) to collect raw elevation data. Intermap produces elevation data models and geometric images of unprecedented accuracy from the IFSAR data. These NEXTMap® data sets are used in various commercial and government spatial applications within a many industries: Automotive Safety & Fuel Efficiency Insurance Flood Modeling Global Positioning Systems (GPS) Environmental Planning Wind Power Planning Wireless Communication Planning Other 3D Visualization Applications © 2008 Intermap Technologies. All rights reserved.
- 51. Using Oracle 11g & Active Data Guard © 2008 Intermap Technologies. All rights reserved.
- 52. Business Requirements The Need The Solution Disaster recovery site in order to maintain Oracle Active Data Guard business continuity. (Fast-Start Failover) Secure data hosting platform for public Oracle Active Data Guard internet applications. (Read Only Physical Standby) 24x7 availability for customers to retrieve Oracle Active Data Guard and use Intermap data. (Stays up while applying redo) Easy storage management to maintain a Oracle Automatic Storage Management large database (10 TB and growing). (Seamless storage integration for using various storage vendors) Manage and maintain spatial datasets Oracle Spatial within Oracle. © 2008 Intermap Technologies. All rights reserved.
- 53. Lessons Learned Configuring LUN sizes larger than 2 TB for use in disk groups is not supported by ASMLib in Oracle 11g (11.1.0.6). This has been fixed in 11.1.0.7. • https://metalink.oracle.com/metalink/plsql/showdoc?db=Bug&id=6453944 Some Oracle GeoRaster procedures do not work on a Standby Database as they do on a Primary Database. Specifically SDO_GEOR.mosaic. Oracle provided Intermap Technologies Inc., with a fix to bypass the using of temporary tables on the Physical Standby when assembling tiles of GeoRaster images and instead assembling the tiled GeoRasters into allocated RAM. © 2008 Intermap Technologies. All rights reserved.
- 54. The Oracle Experience Oracle Active Data Guard – Prior to Oracle 11g Active Data Guard there was no out-of-the-box solution to meet the business requirements of a co-located geospatial database that was an exact replica of our main production geospatial database and maintain 24x7 availability. Active Data Guard was by far the easiest component to set up. Since production implementation Intermap Technologies Inc. has experienced no problems and has maintained 100% uptime. © 2008 Intermap Technologies. All rights reserved.
- 55. Conclusion Standby on Steroids Yesterday Today Disaster protection only HA/DR and performance protection Complex schemes required Quick win – simple & fast to offload query workload Systems & storage dedicated Flexible use of resources for to offload backups multiple purposes Test environments that are a Test environments that are a poor match for production mirror image of production Low ROI High ROI 55
- 56. Conclusion by 9i Stand Active Standby Database 56
- 57. Resources • Oracle Data Guard on OTN http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardOverview.html • Oracle HA Portal on OTN http://www.oracle.com/technology/deploy/availability/ • Maximum Availability Architecture (MAA) white papers and demonstrations http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm • Oracle HA Customer Success Stories on OTN: http://www.oracle.com/technology/deploy/availability/htdocs/HA_CaseStudies.html • Taneja Group - New Approaches to Data Protection and DR http://www.oracle.com/technology/deploy/availability/htdocs/analysts/tanejagroupdatabasestorage.pdf • Enterprise Strategy Group – Data Protection and Disaster Recovery http://www.oracle.com/technology/deploy/availability/htdocs/analysts/enterprisestrategygroupdataguard.pdf 57
- 58. HA Sessions, Labs, Demos From Oracle Development Mon, Sep 22 Wed, Sep 24 (contd.) • 2:30 pm - Database 11g: Next-Gen HA, Moscone South 103 • 5:00 pm - EM in Secure MAA, Moscone West 2001 Tue, Sep 23 • 5:00 pm - E-Business Suite HA, Moscone West 2002/04 • 9:00 am - Active-Active Data Centers, Moscone South 103 Thu, Sep 25 • 11:30 am - Sharding with Oracle, Moscone South 302 • 9:00 am - Oracle Secure Backup, Moscone South 102 • 11:30 am - HA with Oracle VM, Moscone West 3024 • 10:30 am - Streams Replication, Moscone South 102 • 1:00 pm - Active Data Guard, Moscone South 104 • 12:00 pm - Rolling Database Upgrades, Moscone South 103 Wed, Sep 24 • 1:30 pm - Streams Performance, Moscone South 102 • 9:00 am - Fusion Middleware Grid HA, Marriott Nob Hill AB • 3:00 pm - Oracle Grid Computing, Moscone South 303 • 11:30 am - RMAN Best Practices, Moscone South 103 • 3:00 pm - E-Business Suite R12 MAA, Moscone West 2007 • 1:00 pm - Database in the Cloud, Moscone South 305 • 3:00 pm - Siebel MAA, Moscone South 308 • 5:00 pm - Data Guard & Real Application Testing, Moscone 102 • 3:00 pm - Fusion SOA HA & Scalability, Marriott Salon 14/15 Hands On Labs - Thu, Sep 25 DEMOgrounds, Mon-Thu • 10:30 - 11:30 am, 12:00 - 1:00 pm - Active Data • Active Data Guard, Streams, Oracle Secure Guard, Marriott Golden Gate A3 Backup, RMAN/Flashback, MAA 58