Inside the InterconnectMarketed as Data Guard in Oracle 8.1.7 and above
Standby is identical copy of primary database
Redo changes
Planned (switchover / switchback)
Rate of redo generation / size of redo logs
Redo transport / apply configuration
Changes converted into logical change records (LCR)
Logical change records applied on standby (SQL Apply)
Standby database can be opened for updates
Can modify propagated objects
LCR apply can be less efficient than redo apply
Array updates on primary become single row updates on standby
juliandyke.com
Redo synchronously transported to standby database
Redo must be applied to at least one standby before transactions on primary can be committed
Processing on primary is suspended if no standby is available
Maximum availability - minimal data loss
Similar to maximum protection mode
If no standby database is available processing continues on primary
Maximum performance (default)
If no standby database is available processing continues on primary
juliandyke.com
LGWR background process - modes are:
ASYNC - asynchronous
read from SGA by LNSn background process
Oracle 10.2 and above
SYNC - synchronous
NOAFFIRM - do not wait
Switchover
No data loss
Failover
Original primary may need to be rebuilt
Possible data loss
(Managed) Recovery must be suspended
Reports can use temporary tablespaces
Sorts
juliandyke.com
Redo is transported immediately
Increases potential failover times
In Oracle 10.1 and above flashback database can be used as an alternative to delayed redo application
juliandyke.com
Managed using DGMGRL utility
Contains Data Guard configuration
Additional layer of complexity
Mandatory for some new functionality e.g.
Fast Start Failover
Automatically fails over to nominated standby database
Requirements include
DGMGRL must be used
MAXIMUM AVAILABILITY protection mode
Standby database archive log destination must be configured as LGWR SYNC
MAXIMUM PERFORMANCE protection mode
Oracle 11.1 and above
Using flashback logs
RAC licences not required if each site is a single-instance
Disadvantages
Network
Can be opened in read-write mode (for testing)
Redo transport continues
Redo apply delayed
Active Data Guard
Separately licensed option
Redo can continue to be applied
juliandyke.com
Same metric as primary (named user, CPU etc)
Standard Edition
Manually resolve archive log gaps
Enterprise Edition
Use Fetch Archive Logging to resolve archive log gaps
Additional licenses required for Active Data Guard
juliandyke.com
SAN level Replication technologies
Well proven technology
Spare capacity on standby often used for development or testing during normal operations
Relatively few sites run a logical standby
Streams is much more popular
Many sites enable flashback logging
In both development and production environments
Very few using Automatic Failover
Very few sites working with Oracle 11g yet
Consequently none using Active Data Guard
juliandyke.com
Time to failover database is minimal (5-10 minutes)
Time to failover infrastructure can be hours
Network configuration
Rebuild times
Can take much longer depending on reason for failover
juliandyke.com
References
http://www.juliandyke.com/References/References.html
Questions
info@juliandyke.com