of 35 /35
Oracle Data Guard Ensuring Disaster Recovery for Enterprise Data Wei Hu [email protected]

Data Guards Ppt

  • Upload
    swahab

  • View
    24

  • Download
    2

Embed Size (px)

Citation preview

Page 1: Data Guards Ppt

Oracle Data Guard Ensuring Disaster Recovery for Enterprise Data

Wei [email protected]

Page 2: Data Guards Ppt

2

Oracle’s High Availability (HA) Solution Stack

System Failure

Data Failure& Disaster

Human Error

Real Application ClustersContinuous Availability for all Applications

Data GuardZero Data Loss

Flashback QueryEnable Users to Correct their Mistakes

SystemMaintenance

Data Maintenance

Dynamic ReconfigurationCapacity on Demand without Interruption

Online RedefinitionAdapt to Change Online

UnplannedDowntime

PlannedDowntime

Page 3: Data Guards Ppt

3

Oracle Data Guard Focus

Data Failures & Site Disasters:

• Also addresses human errors & planned maintenances

– Data Protection– Data Availability– Data Recovery

Data is the core asset of the enterprise!All 3 are important!

Page 4: Data Guards Ppt

4

What Is Oracle Data Guard?

Database software infrastructure that automates the creation and maintenance of a duplicate, or standby copy, of the production (or primary) database

If the primary database becomes unavailable (disasters, maintenance), the standby database can be activated and can take over the data serving needs of the enterprise

Page 5: Data Guards Ppt

5

Data Guard Architecture Overview

Data Guard Broker

Bro

ker A

gent

Primary Site

PrimaryDatabase

Standby Site

StandbyDatabase

Data Changes

Clients Clients

Bro

ker A

gent

Bro

ker A

gent

Page 6: Data Guards Ppt

6

How Does It Work?

As primary database is modified, redo data is propagated to standby databases

Standby databases kept synchronized with primary

Primary database is open and active; standby database is either in recovery or open read-only / read-write

Standby database can be transitioned to the primary role as necessary

Page 7: Data Guards Ppt

7

Data Guard Configuration

Managed as a single configurationPrimary and standby databases can be Real Application Clusters or single-instance OracleUp to nine standby databases supported in a single configuration

PrimaryDatabase

StandbyDatabase

Standby Site A

StandbyDatabase

Standby Site B

Primary Site

Page 8: Data Guards Ppt

8

Oracle Data Guard Architecture

Network Broker

ProductionDatabase

Logical StandbyDatabase Open for

Reports

SQLApplyOptional

Delay

Transform Redo to SQL

AdditionalIndexes & MVs

Physical StandbyDatabase

Optional Optional DelayDelay

DIGITAL DATA STORAGE

DIGITAL DATA STORAGE

Backup

Redo Apply

Sync or Async Redo Shipping

Page 9: Data Guards Ppt

9

PrimaryDatabase

Physical/Logical Standby

DatabaseTransactions

Backup /Reports

LGWR(Synchronous/Asynchronous) MRP/ LSP

Online Redo Logs

ARCH(Synchronous)

RFS

StandbyRedo Logs

Affirm/NoAffirm

ARCH

FAL

Oracle Data Guard Process Architecture

Archived Redo Logs Archived Redo Logs

Oracle Net

Transform Redo to SQLfor SQL Apply

Page 10: Data Guards Ppt

10

Data Guard Redo Apply

Physical Standby Database is a block-for-block copy of the primary databaseUses the database recovery functionality to apply changesCan be opened in read-only mode for reporting/queriesCan also perform backup, offloading production database

Data Guard Broker

PrimaryDatabase

Physical StandbyDatabase

OptionalDelay

Sync or Async Redo Shipping

Network

Redo Apply

DIGITAL DATA STORAGE

Backup

Page 11: Data Guards Ppt

11

Data Guard SQL Apply

Logical Standby Database is an open, independent, active databaseContains the same logical information (rows) as the production databasePhysical organization and structure can be very differentCan host multiple schemas

Can be queried for reports while logs are being applied via SQLCan create additional indexes and materialized views for better query performance

Optional Delay

AdditionalIndexes &

Materialized Views

Sync or Async Redo Shipping

NetworkContinuously

Open for Reports

Transform Redo to SQL and Apply

Data Guard BrokerPrimary

Database Logical StandbyDatabase

Page 12: Data Guards Ppt

12

Standby Databases Are Not Idle

Standby database can be used to offload the primary database, increasing the ROI

Standby Server

StandbyDatabase

Read-Only / Read-Write

Reporting

BackupsTape

Page 13: Data Guards Ppt

13

Cascaded Redo Log Destinations

Standby database receives its redo data from another standby database and not from the original primary database

Primary database sends a set of redo data to only selected standby databases and not to all standby databases

Reduces the load on the primary system, and also reduces networktraffic and use of valuable network resources around the primary site

PrimaryDatabase

Redo Data RetransmittedPhysical Standby

Database

Physical Standby

Database

Page 14: Data Guards Ppt

14

Protection from Human Errors and Data Corruptions

The application of changes received from the primary can be delayed at standby to allow for the detection of user errors andprevent standby to be affected

The apply process also revalidates the log records to prevent application of any log corruptions

Primary Site

StandbyDatabase

Standby Site

ProductionDatabase

Optional Delayed Apply

Page 15: Data Guards Ppt

15

Switchover and Failover

Primary and Standby role transitionsSwitchover

– Planned role reversal– No database reinstantiation required– Used for maintenance of OS or hardware

Failover – Unplanned failure (e.g. disasters) of primary – Primary database must be reinstantiated

Initiated using simple SQL / GUI interfaceData Guard automates the processes involved

Page 16: Data Guards Ppt

16

Failover Example

Page 17: Data Guards Ppt

17

Flexible Data Protection Modes

Asynchronous redo shipping

Minimal data loss –usually 0 to few seconds

Maximum Performance

Synchronous redo shipping

Zero Data LossSingle Failure Protection

Maximum Availability

Synchronous redo shipping to 2 sites

Zero Data LossDouble Failure Protection

Maximum Protection

Redo ShipmentRisk of Data LossProtection Mode

Balance cost, availability, performance, and transaction protection

Page 18: Data Guards Ppt

18

Maximum Protection ModeMaximum Protection Mode

Highest level of data protectionConfiguration: LGWR SYNC, SRLsEnforces protection of every transactionIf last standby is unavailable, processing stops at primaryGood for financial systems where no data loss is acceptable

Synchronous redo shipping to 2 sites

Zero Data LossDouble Failure Protection

Maximum Protection

Redo ShipmentRisk of Data LossProtection Mode

ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION;

Page 19: Data Guards Ppt

19

Maximum Availability ModeMaximum Availability Mode

Enforces protection of every transactionConfiguration: LGWR SYNC, do not need SRLsIf last standby is unavailable, processing continues at primaryWhen the standby becomes available again, synchronization with the primary is automatic

Synchronous redo shipping

Zero Data LossSingle Failure Protection

Maximum Availability

Redo ShipmentRisk of Data LossProtection Mode

ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY;

Page 20: Data Guards Ppt

20

Maximum Performance ModeMaximum Performance Mode

Highest level of performanceConfiguration: LGWR ASYNC, or ARCHProtects from failure of any single componentLeast impact on production systemUseful for applications that can tolerate some data loss

Asynchronous redo shipping

Minimal data loss –usually 0 to few seconds

Maximum Performance

Redo ShipmentRisk of Data LossProtection Mode

ALTER DATABASE SET STANDBY TO MAXIMIZE PERFORMANCE;

Page 21: Data Guards Ppt

21

Automatic Gap Resolution & Resynchronization

Network connectivity problems may cause gaps in the sequence of log files in the standby

Data Guard automatically takes care of these gaps– Automatic Gap Handling

– FAL (Fetch Archive Log) Gap Handling

Page 22: Data Guards Ppt

22

GAP ResolutionAutomatic

– ARCH process idling away on the primary ‘pings’ all enabled standbys on a regular basis to see if they are missing any redo data

– If so it sends them the missing redo data

FAL– Gap discovered during apply process in physical standby– Based on FAL_SERVER and FAL_CLIENT settings, primary

notified, and it sends missing redo data

Page 23: Data Guards Ppt

23

Oracle Data Guard Broker

Distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations

Management operations can be performed locally or remotely through the Broker's easy-to-use interfaces:

– GUI-based Oracle Data Guard Manager– Data Guard command-line interface

Page 24: Data Guards Ppt

24

LogicalStandbyDatabase

PhysicalStandbyDatabase

PrimaryDatabase

Data Guard Broker Architecture

Oracle Management Server

JobService

EventService

Security Service

Discovery Service

Repository

DataGuardBroker

DataGuardBroker

DataGuardBroker

Data Guard Manager

OEMAgent

OEMAgent

OEMAgent

Page 25: Data Guards Ppt

25

Data Guard Manager

Simple, easy-to-use management and monitoring interface

Page 26: Data Guards Ppt

26

Local and Remote Standby Databases

Oracle Data Guard configuration can support both local and remote standby databases

Local standby database– Human error and data corruption protection– Appropriate for highest data protection modes– LAN links are cheap, reliable, have high bandwidth and low latency – Switchover operations are very fast

Remote standby database– Best solution for disaster recovery– WAN links are generally more expensive, less reliable, have lower

bandwidth and higher latency than LAN links– Suitable for highest performance asynchronous data protection mode

Page 27: Data Guards Ppt

27

Usage Examples

PrimaryDatabase

Chicago Dallas

StandbyDatabase

PrimaryDatabase

StandbyDatabase

Maximize primary andstandby resources

Example AExample AStandby Site

PrimaryDatabase

Primary Site A

PrimaryDatabase

Primary Site B

PrimaryDatabase

Primary Site C

StandbyDatabase

StandbyDatabase

StandbyDatabase

Standby machine must be powerful enough to support multiple production

instances after switchover / failover

Example BExample B

Page 28: Data Guards Ppt

28

Usage Examples

PrimaryDatabase

Primary Site

StandbyDatabase

Standby Site A Synchronous transportLAN attachedUsed to offload backupsFirst choice for switchover candidate

StandbyDatabase

Standby Site B

Synchronous transportLAN attachedUsed to offload reporting

StandbyDatabase

Standby Site C

Asynchronous transportWAN attachedDelayed applyProvides DR and data protection

Example CExample C

Page 29: Data Guards Ppt

29

Data Guard and RAC

Data Guard and Real Application Clusters are complementary and should be used together for a Maximum Availability Architecture

Real Application Clusters provides high availability– Provides rapid and automatic recovery from node failures or an

instance crash– Provides increased scalability

Data Guard provides disaster protection and prevents data loss– By maintaining transactionally consistent copies of primary database– Protects against disasters, data corruption and user errors– Does not require expensive and complex HW/SW mirroring

Page 30: Data Guards Ppt

30

Data Guard and StreamsStreams and Data Guard are independent features of Oracle Database Enterprise Edition, based on some common underlying technology

Data Guard: Disaster Recovery & Data Protection– Transactionally consistent standby databases– Zero data loss– Automated switchover/failover– Various data protection modes

Streams: Information Sharing/Distribution– Fine granularity and control over what is replicated – Bi-directional replication– Data transformations– Heterogeneous platforms

Because of business requirements, customers may choose to use Streams for DR/HA, and Data Guard SQL Apply for information distribution

Page 31: Data Guards Ppt

31

Data Guardfor DR

Streamsfor information

distribution

Financial Services Company Using Data Guard & Streams

Product Delivery Databases for Client Access

Data Transformation

Data Feed

Master Database

Physical Standby Database

Page 32: Data Guards Ppt

32

Data Guard and Remote Mirroring

Remote Mirroring is another way to protect enterprise dataHost-based and storage based Is a physical bit-for-bit copyThe copy can be remoteIs this a good substitute?

Page 33: Data Guards Ppt

33

Data Guard and Remote Mirroring

Better protection– Redo is validated logicallyGreater efficiency– Only redo is transferred instead of entire disk

block (7x bandwidth savings, 27x network I/Os)Cheaper– No reliance on specialized hardwareRemote mirroring is useful for non-Oracle data

Page 34: Data Guards Ppt

34

Why Oracle Data Guard?1. Disaster Recovery & High Availability

– Easy failover/switchover between primary and standby databases

2. Complete data protection– Enables zero data loss, safeguard against data corruptions

3. Efficient utilization of system resources– Standby databases can be used for reporting, backups, queries

4. Balance data availability against performance– Flexible data protection/synchronization modes

6. Centralized and simple management– Graphical interface for management and monitoring

5. Automatic resynchronization after restoration of network connectivity– Automatic archive gap detection and resolution with no manual intervention

Page 35: Data Guards Ppt

35

Resources

HA Portal on OTN: http://otn.oracle.com/deploy/availability/

Maximum Availability Architecture (best practice recommendations on Data Guard + RAC configuration): http://otn.oracle.com/deploy/availability/htdocs/maa.htm

Disaster Recovery page on OTN: http://otn.oracle.com/deploy/availability/htdocs/dr_overview.html

Data Guard Technical White Paper on OTN: http://otn.oracle.com/deploy/availability/pdf/DG92_TWP.pdf

Data Guard Technology Overview Presentation on OTN: http://otn.oracle.com/deploy/availability/pdf/DataGuardTechnologyOverview.pdf