100% found this document useful (1 vote)
88 views58 pages

Active Dataguard

You need this for 11g DR

Uploaded by

hamed_555
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
88 views58 pages

Active Dataguard

You need this for 11g DR

Uploaded by

hamed_555
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 58

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
2
Todays Objectives
Deep Dive
Shine the Light
3
Program
D
a
t
a

G
u
a
r
d

S
t
a
n
d
b
y
Ship Redo / Apply Redo
Utilize your standby database
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)
4
Oracle Data Guard
Best Protection at Lowest Cost
Production
Database
SYNC or ASYNC
Redo Shipping
Automatic Failover Active
Standby
Databases
Data Guard
5
Ship Redo
Synchronous Redo Transport (SYNC) Zero Data Loss
Standby
Redo
Logs
RFS LNS
Online
Redo
Logs
Oracle Net
Primary
Database
LGWR
SGA
Redo
Buffer
MRP - physical
LSP - logical
Active
Standby
Database
Queries, Reports
Testing & Backups
MRP
LSP
C
o
m
m
i
t

A
C
K
User Transactions
Q
u
e
r
i
e
s
,

u
p
d
a
t
e
s
,

D
D
L

Q
u
e
r
i
e
s
,

u
p
d
a
t
e
s
,

D
D
L

U
s
e
r

c
o
m
m
i
t
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
7
Ship Redo
Asynchronous Redo Transport (ASYNC)
Standby
Redo
Logs
RFS LNS
Online
Redo
Logs
Oracle Net
Primary
Database
LGWR
SGA
Redo
Buffer
MRP - physical
LSP - logical
Active
Standby
Database
Queries, Reports
Testing & Backups
MRP
LSP
C
o
m
m
i
t

A
C
K
User Transactions
Q
u
e
r
i
e
s
,

u
p
d
a
t
e
s
,

D
D
L

Q
u
e
r
i
e
s
,

u
p
d
a
t
e
s
,

D
D
L

U
s
e
r

c
o
m
m
i
t
8
Ship Redo
ASYNC If Network Cant Keep Pace
Standby
Redo
Logs
RFS LNS
Online
Redo
Logs
Oracle Net
Primary
Database
LGWR
SGA
Redo
Buffer
MRP - physical
LSP - logical
Active
Standby
Database
Queries, Reports
Testing & Backups
MRP
LSP
C
o
m
m
i
t

A
C
K
User Transactions
Q
u
e
r
i
e
s
,

u
p
d
a
t
e
s
,

D
D
L

Q
u
e
r
i
e
s
,

u
p
d
a
t
e
s
,

D
D
L

U
s
e
r

c
o
m
m
i
t
9
Shipping vs. Protection Mode
Protection Mode Controls Response to Failure Events
Mode Risk of data loss Transport If no acknowledgement from standby:
Maximum
Protection
Zero Data Loss
Double Failure
Protection
SYNC
SYNC
ASYNC
Stall primary until acknowledgement is
received from replica
Maximum
Availability
Zero Data Loss
Single Failure
Protection
Stall primary until acknowledgement is
received or timeout threshold period expires
then resume processing
Maximum
Performance
Potential for
Minimal Data Loss
Primary never waits for standby
acknowledgement
10
Shipping vs. Protection Mode
Protection Mode Controls Response to Failure Events
Mode Risk of data loss Transport If no acknowledgement from standby:
Maximum
Protection
Zero Data Loss
Double Failure
Protection
SYNC
SYNC
ASYNC
Stall primary until acknowledgement is
received from replica
Maximum
Availability
Zero Data Loss
Single Failure
Protection
Stall primary until acknowledgement is
received or timeout threshold period expires
then resume processing
Maximum
Performance
Potential for
Minimal Data Loss
Primary never waits for standby
acknowledgement
NET_TIMEOUT parameter of LOG_ARCHIVE_DEST_n
Data Guard 11g default = 30 seconds
Data Guard 10g default = 180 seconds
11
Online
Redo
Logs
Oracle Net
Primary
Database
Transactions
LGWR
Archived
Redo Logs
Redo
Buffer
SGA
ping
Ship Redo
Automatic Gap Resolution Primary Pings Standby
ARCH
12
Online
Redo
Logs
Oracle Net
Primary
Database
Transactions
LGWR
Archived
Redo Logs
Redo
Buffer
SGA
ping
Ship Redo
Automatic Gap Resolution Connect to Standby
ARCH
Active
Standby
Database
Queries
Reports
Testing
Backups
MRP
LSP
RFS
13
Online
Redo
Logs
Oracle Net
Primary
Database
Transactions
LGWR
Archived
Redo Logs
Redo
Buffer
SGA
ping
Standby
Redo
Logs
RFS LNS
SYNC
ASYNC
ARCH
Ship Redo
Automatic Gap Resolution Ship Log Gap
ARCH
Active
Standby
Database
Queries
Reports
Testing
Backups
MRP
LSP
RFS
14
Online
Redo
Logs
Oracle Net
Primary
Database
Transactions
LGWR
Archived
Redo Logs
Redo
Buffer
SGA
ping
Standby
Redo
Logs
RFS LNS
SYNC
ASYNC
ARCH
Ship Redo
Automatic Gap Resolution Gap Resolved
ARCH
Active
Standby
Database
Queries
Reports
Testing
Backups
MRP
LSP
RFS
15
Ship Fast
Network Compression for Gaps
To enable compression:
Set Data Guard broker property, or
Set compression attribute of redo
transport destination
Resolves gaps up to 3x faster
Better data protection
Given there is sufficient CPU
Negligible impact on response time
Negligible impact on throughput
Requires Oracle Advanced
Compression Option 11g
0
10
20
30
40
50
60
70
80
el apsed ti me to resol ve gap
uncompressed compressed
seconds
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
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
Automatically configures the # of slaves = # CPUs - 1
Media Recovery Coordinator (MRP0)
coordinator & thread merger
apply slave (pr00)
Parallel Media Recovery - 4 CPU server
apply slave (pr01)
apply slave (pr02)
18
Apply Fast
100% Faster than Oracle Database 10g
0
20
40
60
80
100
120
MB/sec
OLTP Di rect Path Load
10gR2 11gR1
Increased parallelism
Less synchronization
Better utilization of I/O
and CPU resources
Optimizations for
direct-path loads
Self-configuring*
24
47 48
112
*for ASYNC I/O
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
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
Many hours later production is down
Problems traced to lost writes caused by faulty hardware
ORA-00600: internal error code, arguments: [3020] , [648], [1182463], [2719091455], []
ORA-10567 : Redo is inconsistent with data block (file# 648, block# 1182463)
Recovery interrupted!
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.***
21
Not a Problem for Data Guard 11g
Capability Unique to Oracle Database
Detect lost writes using new initialization parameter
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
db_lost_write_protect
22
Program
D
a
t
a

G
u
a
r
d

S
t
a
n
d
b
y
Ship Redo / Apply Redo
Utilize your standby database
Active Data Guard
Snapshot Standby
Reduce downtime
Active Data Guard experiences
Real Networks
Intermap Inc
Resources - Q&A
23
Data Guard 11g
Real-time
Queries
Physical Standby
Database
Production
Database
Continuous redo
shipping, validation & apply
Real-time
Reporting
Fast
Incremental
Backups
Read-write
Workload
24
Active Data Guard 11g
Real-time
Queries
Physical Standby
Database
Production
Database
Continuous redo
shipping, validation & apply
Real-time
Reporting
Fast
Incremental
Backups
Use fast incremental backups on a physical standby up to 20x faster
Fast
Incremental
Backups
Offload read-only queries to an up-to-date physical standby
Real-time
Reporting
Active Standby
Database
Read-write
Workload
25
Whats so Different?
Data Guard 11g Active Data Guard Option
Stop redo apply at 8am
Open read-only for queries
Redo apply is always on
Always open read only
By 4pm, data is 8 hours old Queries and reports always
see latest data
Any failover will be delayed
due to backlog of data that
must be applied
Failover is immediate when
needed, standby database
always up-to-date
Active Data Guard MAA Best Practices
http://www.oracle.com/technology/deploy/availability/pdf/maa_wp_11gr1_activedataguard.pdf
26
Active Data Guard
Utilize Standby Databases
Better Performance and Increased Scalability
0
500
1000
1500
2000
2500
3000
Read/Write
Transactions
Read/Only
Transactions
T
P
SBefore ADG
After ADG
290
630
1530
2690
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
0
0.2
0.4
0.6
0.8
1
1.2
d
w
4
6
:
2
4
:
1
6
6
:
2
4
:
3
4
6
:
2
4
:
5
2
6
:
2
5
:
1
0
6
:
2
5
:
2
8
6
:
2
5
:
4
6
6
:
2
6
:
0
4
6
:
2
6
:
2
2
6
:
2
6
:
4
0
6
:
2
6
:
5
8
6
:
2
7
:
1
6
6
:
2
7
:
3
4
6
:
2
7
:
5
2
6
:
2
8
:
1
0
6
:
2
8
:
2
8
6
:
2
8
:
4
6
6
:
2
9
:
0
4
6
:
2
9
:
2
2
6
:
2
9
:
4
0
6
:
2
9
:
5
8
S
e
c
o
n
d
s
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
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
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)
31
Snapshot Standby Data Guard 11g
Convert Standby Database to Read-Write Test System
Updates
Primary
Database
Physical Standby
Database
Queries
Snapshot Standby
Database
Updates
redo
data
DGMGRL> convert database <name> to snapshot standby;
32
Snapshot Standby Data Guard 11g
Convert Back to Synchronized Standby
Updates
Primary
Database
Physical Standby
Database
Queries
Snapshot Standby
Database
Updates
redo
data
DGMGRL> convert database <name> to physical standby;
Queries
Physical Standby
Database
33
Snapshot Standby 11g
Simpler and with better RTO/RPO than Data Guard 10g
11.1 Steps Required
Standby
> alter database convert to snapshot standby;
PERFORM TESTING, ARCHIVE LOGS CONTINUE TO BE
SHIPPED
> alter database convert to physical standby;
10.2 Steps Required
Standby
> alter database recover managed standby database
cancel;
> create restore point before_lt guarantee flashback
database;
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
34
Program
D
a
t
a

G
u
a
r
d

S
t
a
n
d
b
y
Ship Redo / Apply Redo
Utilize your standby database
Active Data Guard
Snapshot Standby
Reduce downtime
Active Data Guard experiences
Real Networks
Intermap Inc
Resources - Q&A
35
Fast-Start Failover
Reduce Unplanned Downtime
Standby Site
Primary Site
Observer
Primary Site Primary Site Standby Site
Maximum Availability
SYNC redo transport
RPO = zero
Maximum Performance
ASYNC redo transport
Default RPO = 30 seconds
minimum threshold = 10
seconds
FastStartFailoverLagLimit
Client Failover MAA Best Practices in a Data Guard Configuration
www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_ClientFailoverBestPractices.pdf
36
Fast-Start Failover
Configuration Options for Optimal RPO
Immediate failover for user-configurable health conditions
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
ENABLE FAST_START FAILOVER [CONDITION <value>];
DBMS_DG.INITIATE_FS_FAILOVER
37
Rolling Database Upgrades
Use Physical Standby to Reduce Planned Downtime
release n
release n+1
Database A Database B
Install new Oracle version in seperate
homes on A & B, set guaranteed
restore point (GRP) on A
PROD
PSTBY
Synchronize Redo apply
LSTBY
Synchronize SQL Apply
LSTBY PROD
Convert B to logical using KEEP
IDENTITY (11g), upgrade and resync
SWI TCHOVER
PROD
PSTBY
Switchover, flashback A to GRP,
mount in new/upgraded home,
convert to physical
PSTBY
Synchronize Redo Apply
PROD
Upgrade via redo stream and resync
Rolling Upgrade Best Practices using Transient Logical Standby
http://www.oracle.com/technology/deploy/availability/pdf/maa_wp_11g_transientlogicalrollingupgrade.pdf
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
39
Program
D
a
t
a

G
u
a
r
d

S
t
a
n
d
b
y
Ship Redo / Apply Redo
Utilize your standby database
Active Data Guard
Snapshot Standby
Reduce downtime
Active Data Guard Experiences
Real Networks
Intermap Inc
Resources - Q&A
11g Active Data Guard
11g Active Data Guard
Yucheng Liu Sr. Oracle DBA, RealNetworks [email protected]
Krishna Kakatur Sr. Oracle DBA, RealNetworks [email protected]
What is so Cool About Real Networks
What is so Cool About Real Networks
Goals
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
Content DB
Data
Farm
APP1 APP2 APP3 APPn
...
m
v
i
e
w
s
m
v
i
e
w
s
m
v
i
e
w
s
m
v
i
e
w
s
During a code deployment,
each database is subject to a
lengthy maintenance for
DDL andmviewrefreshes.
Current Architecture
Current Architecture
Current Architecture Challenges
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
Content DB
Data
Farm
APP1 APP2 APP3 APPn
...
11G Active Data Guards
Future Architecture
Future Architecture
During a code deployment,
we can release to one database
and rely on active Data Guard
to replicate the changes.
Future Architecture Benefits
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
Active Data Guard Implementation
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!)
Lessons Learned
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
Oracle 11g Active Data Guard
High Availability, Disaster Recovery & Resource Offloading
Presented By: Shawn Ormond, Database Administrator
Who is Intermap Technologies Inc.?
2008 Intermap Technologies. All rights reserved.
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
Using Oracle 11g & Active Data Guard
2008 Intermap Technologies. All rights reserved.
Business Requirements
Oracle Spatial Manage and maintain spatial datasets
within Oracle.
Oracle Automatic Storage Management
(Seamless storage integration for using
various storage vendors)
Easy storage management to maintain a
large database (10 TB and growing).
Oracle Active Data Guard
(Stays up while applying redo)
24x7 availability for customers to retrieve
and use Intermap data.
Oracle Active Data Guard
(Read Only Physical Standby)
Secure data hosting platform for public
internet applications.
Oracle Active Data Guard
(Fast-Start Failover)
Disaster recovery site in order to maintain
business continuity.
The Solution The Need
2008 Intermap Technologies. All rights reserved.
Lessons Learned
2008 Intermap Technologies. All rights reserved.
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.
The Oracle Experience
2008 Intermap Technologies. All rights reserved.
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.
55
Conclusion
Standby on Steroids
Today
Quick win simple & fast
Test environments that are a
mirror image of production
HA/DR and performance protection
Flexible use of resources for
multiple purposes
High ROI
Complex schemes required
to offload query workload
Test environments that are a
poor match for production
Disaster protection only
Systems & storage dedicated
to offload backups
Yesterday
Low ROI
56
Conclusion
Active
Standby
Database
9
i
S
ta
n
d
b
y
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
58
HA Sessions, Labs, Demos From Oracle Development
Mon, Sep 22
2:30 pm - Database 11g: Next-Gen HA, Moscone South 103
Tue, Sep 23
9:00 am - Active-Active Data Centers, Moscone South 103
11:30 am - Sharding with Oracle, Moscone South 302
11:30 am - HA with Oracle VM, Moscone West 3024
1:00 pm - Active Data Guard, Moscone South 104
Wed, Sep 24
9:00 am - Fusion Middleware Grid HA, Marriott Nob Hill AB
11:30 am - RMAN Best Practices, Moscone South 103
1:00 pm - Database in the Cloud, Moscone South 305
5:00 pm - Data Guard & Real Application Testing, Moscone 102
Wed, Sep 24 (contd.)
5:00 pm - EM in Secure MAA, Moscone West 2001
5:00 pm - E-Business Suite HA, Moscone West 2002/04
Thu, Sep 25
9:00 am - Oracle Secure Backup, Moscone South 102
10:30 am - Streams Replication, Moscone South 102
12:00 pm - Rolling Database Upgrades, Moscone South 103
1:30 pm - Streams Performance, Moscone South 102
3:00 pm - Oracle Grid Computing, Moscone South 303
3:00 pm - E-Business Suite R12 MAA, Moscone West 2007
3:00 pm - Siebel MAA, Moscone South 308
3:00 pm - Fusion SOA HA & Scalability, Marriott Salon 14/15
Hands On Labs - Thu, Sep 25
10:30 - 11:30 am, 12:00 - 1:00 pm - Active Data
Guard, Marriott Golden Gate A3
DEMOgrounds, Mon-Thu
Active Data Guard, Streams, Oracle Secure
Backup, RMAN/Flashback, MAA

You might also like