ORACLE DATA GUARD:

MAXIMUM DATA PROTECTION

AT MINIMUM COST

AGENDA
Oracle Data Guard a Quick Introduction
Data Guard Features in Oracle Database 10g
Customer Success Story Sun Microsystems
Summary & Q/A

WHAT IS ORACLE DATA GUARD?

Oracles disaster recovery solution for Oracle data
Feature of Oracle Database Enterprise Edition
Automates the creation and maintenance of one
or more transaction ally consistent copies
(standby) of the production (or primary) database

ORACLE DATA GUARD FOCUS

Data Failures & Site Disasters:

Data Protection
Data Availability
Data Recovery
All 3 are important!

Data is the core asset of

the enterprise!

Also addresses human errors & planned maintenances

ORACLE DATA GUARD

ARCHITECTURE
Physical Standby
Database

Sync or Async
Redo Shipping

Production
Database

Backup
Redo Apply

Network

DIGITAL DATA STORAGE

DIGITAL DATA STORAGE

Broker

Transform
Redo to SQL

Logical Standby
Database

SQL
Apply

Open for
Reports

Additional
Indexes & MVs

DATA GUARD REDO APPLY

Primary
Database

Data Guard
Broker

Physical Standby
Database
Redo Apply

Network
Redo Shipment

Backup
DIGITAL DATA STORAGE

Standby
Redo Logs

Physical Standby Database is a block-for-block copy of the primary database

Uses the database recovery functionality to apply changes
Can be opened in read-only mode for reporting/queries
Can also be used for backups, offloading production database

DATA GUARD SQL APPLY

Additional
Indexes &
Materialized Views

Primary
Database

Data Guard
Broker

Logical Standby
Database
Transform Redo
to SQL and Apply
Continuously
Open for Reports

Network
Redo Shipment

Standby
Redo Logs

Logical Standby Database is an open, independent, active database

Contains the same logical information (rows) as the production database

Physical organization and structure can be very different
Can host multiple schemas

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

AGENDA
Oracle Data Guard a Quick Introduction
Data Guard Features in Oracle Database 10g
Customer Success Story Sun Microsystems
Summary & Q/A

ORACLE DATA GUARD 10G

OBJECTIVES
Establish Data Guard as an extremely
easy-to-use
low-cost
comprehensive
reliable

Disaster Recovery solution for

enterprise data

OVERVIEW OF OBJECTIVES
Ease of use simplified SQL, easy to create,
manage and administer standby databases,
simplified GUI focused on best practices
Low cost businesses can leverage existing
resources to implement Data Guard, zero
integration costs
Comprehensive feature-rich and flexible
Reliable a rock-solid solution for protection of
mission critical business data

DATA GUARD 10G NEW

FEATURES
General new features
Real Time Apply
Flashback Database Integration

SQL Apply new features

Zero Downtime Instantiation
Rolling Upgrades
Additional Datatypes

Data Guard Broker & Enterprise Manager new features

RAC integration
Simplified browser-based interface focused on best practices

REAL TIME APPLY

Redo data is applied to the standby database as soon
as it is received from the primary database
In Oracle9i Data Guard this apply has to wait till an
archivelog is created on the standby database

For Redo Apply:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING
CURRENT LOGFILE

For SQL Apply:

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE

When real time apply is enabled, RECOVERY_MODE

column in V$ARCHIVE_DEST_STATUS displays MANAGED
REAL TIME APPLY

REAL TIME APPLY ARCHITECTURE

Oracle
Net

Transactions

LGWR

Online
Redo
Logs

Primary
Database

MRP/ LSP

RFS

Standby
Redo
Logs

ARCH

Real Time
Apply

ARCH

Archived
Redo Logs

An up-to-date
Physical/Logic
al
Standby
Database

Archived
Redo Logs

REAL TIME APPLY BENEFITS

Standby databases now more closely synchronized with
the primary
More up-to-date, real-time reporting
Faster switchover and failover times
Reduces planned and unplanned downtime
Better Recovery Time Objective (RTO) for DR

EXISTING SITE RECOVERY

TRADEOFFS
Primary Database

Standby
Database

Redo
Shipment

Reporting on
delayed data

Delayed
Apply

Log apply may be delayed to protect from user errors but:

Switchover/Failover gets delayed
Reports run on old data
After failing over to standby, production DB must be rebuilt

FLASHBACK DATABASE
A new strategy for point in time recovery
Eliminate the need to restore a whole
database backup
Integrated seamlessly with RMAN
Think of it as a continuous backup
Restores just changed blocks

Its fast - recover in minutes, not hours

Its easy - single command restore

RMAN> FLASHBACK DATABASE

TIMESTAMP to_timestamp
('2003-08-15 16:00:00',
'YYYY-MM-DD HH24:MI:SS');

ENHANCED DR WITH FLASHBACK

DATABASE
Primary Database
Redo
Shipment

Real Time
Apply

Standby Database

Real Time
Reporting

No
Delay!
Flashbac
k
Log

Primary: No
reinstantiation
after failover!
Flashback DB removes the need to delay application of logs
Flashback DB removes the need to reinstantiate primary after failover
Real-time apply enables real-time reporting on standby

Flashback
Log

SQL APPLY: ZERO DOWNTIME

INSTANTIATION
Logical standby database can now be created from an online
backup of the primary database, without shutting down or
quiescing the primary database
No shutdown implies no downtime of production system
No quiesce implies no wait on quiesce and no dependence on
Resource Manager

ROLLING UPGRADES
Upgra
de

Clients

Redo
A

Version X
1

Logs
Queue

Version X

Initial SQL Apply Config

X
2

X+1

X+1

Upgrade node B to X+1

Redo
Upgrade A

Redo
B

X+1

4 Switchover to B, upgrade A

X
3

X+1

Run in mixed mode to test

Patch Set
Upgrades
Major
Release
Upgrades

Cluster
Software &
Hardware
Upgrades

SQL APPLY: ADDITIONAL DATA

TYPES
SQL Apply now supports the following additional data types:
Multi-byte CLOB
NCLOB
LONG
LONG RAW
BINARY_FLOAT
BINARY_DOUBLE
IOT-s (without overflows and without LOB columns)

Allows logical standby databases to recover and protect a

wider variety of data, thus increasing the overall database
protection and recovery options for Data Guard

ENTERPRISE MANAGER NEW

FEATURES
Streamlined browser-based interface that enables
complete standby database lifecycle management
Focus on:
Ease of use
Management based on best practices
Pre-built integration with other HA features

RAC SUPPORT BROKER

Now possible to use the Broker to create and
manage configurations that contain RAC primary
and RAC standby databases
Data Guard Broker interfaces with Oracle
Clusterware such that it has control over critical
operations during specific Data Guard state
transitions
Switchovers, failovers, protection mode changes, state
changes

RAC Primary

Two standby dbs

Instance specific

EXAMPLE EASE OF USE

Switchover using Enterprise Manager is now literally two
mouse clicks

Switched!

AGENDA
Oracle Data Guard a Quick Introduction
Data Guard & Features in Oracle Database 10g
Customer Success Story Sun Microsystems
Summary & Q/A

CASE STUDY
Oracle Data Guard at Sun Microsystems
Darl Kuhn
Senior DBA, Staff Engineer
Business decision considerations
Architecture
Implementation
Features we use

PROJECT REQUIREMENTS

Patch and Knowledge databases for Sun Support

Services
7x24 High Availability
Minimize scheduled downtime
Minimize unscheduled downtime

Disaster Recovery (DR) protection

Do more with less resources
Minimize costs
Minimize complexity

SOLUTIONS WE INVESTIGATED
Backup the database, restore from tape
Operating System failover
Remote Mirroring
Quests SharePlex
Oracle Advanced Replication (OAR)
Oracle Real Application Clusters (RAC)
Oracle Data Guard (Standby)

WE CHOSE DATA GUARD

7x24 DR protection
Simple to implement
Requires DBA with B&R skills
Didnt need special System Administration skills or
consultants
Low maintenance (do more w/less DBAs)
No extra licensing (built into Oracle9i)

IMPLEMENTATION DECISIONS
Which data protection mode?
Maximum Protection
Maximum Availability
Maximum Performance

We chose Maximum Performance

Two identical servers
Directory structures the same
Database name the same
Introduce a delay in application of redo

MAXIMUM PERFORMANCE
Primary Database
Production Site

Standby Database
Server

Users

Fetch Archive
Log (FAL)

Remote File
Server (RFS)
Oracle
Net

Primary
Database

LGWR

On-line
Online
Redo
Redo

Copied
Copied
Archive
Archive
Redo
Redo

Managed
Recovery
Process (MRP)

ARCn

Local
Local
Archive
Archive
Redo
Redo

Standby
Database

DATABASE ARCHITECTURE

50M archive redo logs

1 Gig of redo per day
Primary in Colorado

Standbys in North Carolina, Holland and Singapore

Database size currently 60 Gig
Hardware Sun 6500, 280R, 4500
Storage T3 partner pair fiber channel

IMPLEMENTATION OF PHYSICAL
STANDBY
1. Ensure primary database is in archive log mode
Note: In Data Guard 10g, you also need to implement a
password file for both Primary and Standby

2. Take backup of primary database datafiles options:

RMAN

Hot

Cold

Do not backup controlfiles or online redo logs

USING RMAN TO BUILD STANDBY

On Primary:
a) RMAN> backup database;
b) Copy backup pieces to Standby
c) Create a Standby controlfile and copy to Standby
Then on Standby:
a)
b)
c)
d)

SQL> startup nomount;

SQL> alter database mount standby database;
RMAN> restore database;
SQL> alter database recover managed standby
database disconnect;

IMPLEMENTATION OF PHYSICAL
STANDBY
3. Copy backup datafiles to standby server
4. Create a standby controlfile
5. Copy the standby controlfile to standby server
6. Configure primary init.ora or spfile
7. Copy primary database init.ora file to standby
server and make modifications for standby database
8. Configure Oracle Net

IMPLEMENTATION OF PHYSICAL
STANDBY
9. Startup and mount standby database
SQL> startup nomount;
SQL> alter database mount standby database;

Startup syntax is simplified in Oracle Data Guard

10g
SQL> startup mount;

In Data Guard 10g, the startup will put the

Standby into read-only mode
SQL> startup;

IMPLEMENTATION OF PHYSICAL
STANDBY
10. Enable managed recovery mode on Standby
SQL> alter database recover managed standby
database disconnect;

Troubleshooting
$ tail f alert_BRDSTN.log

Almost all problems encountered were:

TNS set up incorrectly
Initialization parameters set wrong

PREVENTING USER ERRORS

Logs copied but not applied for 60 minutes
Used to have to manually script this
SQL> alter database recover managed standby
database delay 60 disconnect;
To disable delay:
SQL> alter database recover managed standby
database nodelay;

USE OF READ-ONLY STANDBY

7x24 business requirement for knowledge reporting
Primary database batch loaded once a day
How do we ensure that there will always be a database
available?
Create two (or more) Standby databases
Shut down one at a time, apply redo

USE OF READ-ONLY STANDBY

Primary Database
Production Site

Two Separate Read-Only

Standby Database Servers

Oracle
Net

Daily
Batch
Load

l3srv1
Standby 1
brdstn
Reports

Primary
Database

ARCn
l3srv2
Standby 2
brdstn

USE OF READ-ONLY STANDBY

Let Oracle Net connection figure out which read-only
physical Standby database available
brdstn=
(DESCRIPTION =
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=tcp)
(HOST=l3srv1)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=l3srv2)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=brdstn))
)

DISASTER HAPPENS
Havent had a complete disaster yet
We have had bad hardware cause failovers
We were able to easily failover to Standby
SQL> alter database activate standby database;

In Data Guard 9i, we keep 9i Primary init.ora on

Standby
In Data Guard 10g, VALID_FOR eliminates this need

ARCHIVE GAP MANAGEMENT

This is one of our favorite Data Guard 9i features
Addresses critical issues such as:
What if network or server is down?
After failure resolution, how is the standby caught up?

In Oracle8i Standby Database, we would manually fix

In Oracle9i:
Data Guard has automatic methods for gap resolution
Fetch Archive Log (FAL) processes
In our experience, very reliable

PROPAGATION OF DATAFILE
OPERATIONS
Another task automated in Data Guard 9i
In Oracle8i Standby Database, add/drop
tablespace/datafile commands not
automatically propagated
DBA had to intervene

In Oracle9i Data Guard

Fully automated
In Standby initialization file:
standby_file_management = auto

PROPAGATION OF DATAFILE
OPERATIONS
Example:
SQL> drop tablespace HRM_SALA including contents
and datafiles;

On standby the tablespace HRM_SALA will be

automatically dropped and all datafiles will be
deleted from disk
Note: If you rename a datafile, DBA must intervene

ORACLE DATA GUARD 10G BETA

FEEDBACK
Logical Standby easier to setup
Simplified SQL syntax
More helpful, feature-rich initialization parameters

AGENDA
Oracle Data Guard a Quick Introduction
Data Guard & Features in Oracle Database 10g
Customer Success Story Sun Microsystems
Summary & Q/A

MAXIMUM AVAILABILITY
ARCHITECTURE
Best Practices on:
General Data Guard configuration
Redo data transport mechanisms
Protection modes
Switchover/Failover
Media recovery
SQL Apply configuration
Network configuration
Integration with other HA
technologies

White papers1:
MAA detailed
Media Recovery
Site/Network configuration
Fast-Start Checkpointing
SQL Apply Best Practices
Role Management

1. Ref. http://otn.oracle.com/deploy/availability/htdocs/maa.htm for latest updates

DATA GUARD CUSTOMERS

Transportation
Telecom
Financial/
Insurance

Utilities

Government

Manufacturing
Health
Care
Other Industries
e-Commerce

CUSTOMER TESTIMONIALS
Data Guard automates disaster-recovery procedures
and reduces Fidelity's exposure to data loss by an
order of magnitude compared to previous approaches.

Jonathan Schapiro
Vice President
Data Architecture & Services
Global Equity Trading & Technology

CUSTOMER TESTIMONIALS
We needed to consider the safe-keeping of our
data, but we also needed to look at cost. Oracle
Data Guard provides everything for a high
availability solution at a lower cost than other
alternatives

Ann Collins
Technical Director

CUSTOMER TESTIMONIALS
We don't have to baby-sit it it just
works!

Darl Kuhn
Senior DBA & Staff Engineer
Database Services
Sun Services Global Engineering

WHY ORACLE DATA GUARD?

1.

Disaster Recovery & High Availability

2.

Complete data protection

3.

Flexible data protection/synchronization modes

Automatic resynchronization after restoration of network connectivity

6.

Standby databases can be used for reporting, backups, queries

Balance data availability against performance

5.

Enables zero data loss, safeguard against data corruptions

Efficient utilization of system resources

4.

Easy failover/switchover between primary and standby databases

Automatic archive gap detection and resolution with no manual intervention

Centralized and simple management

Push-button graphical interface for management and monitoring

NEXT STEPS

HIGH AVAILABILITY SESSIONS FROM ORACLE

Tuesday in Moscone Room 304
11:00 AM

How Oracle Database 10g

Revolutionizes Availability and
Enables the Grid

Wednesday in Moscone Room

304
8:30
AM
Oracle Database 10g - RMAN and ATA
Storage in Action

11:00 AM

3:30 PM

Oracle Recovery Manager (RMAN)

10g: Reloaded

Oracle Data Guard: Maximum Data

Protection at Minimum Cost

1:00 PM

5:00 PM

Proven Techniques for Maximizing

Availability

Oracle Database 10g Time Navigation:

Human-Error Correction

4:30 PM

Data Guard SQL Apply: Back to the

Future

For More Info On : http://www.xoomtrainings.com/course/oracle-data

NEXT STEPS

HIGH AVAILABILITY SESSIONS FROM ORACLE

Thursday
8:30 AM in Moscone Room 304

Oracle Database 10g Data

Warehouse Backup and Recovery:
Automatic, Simple, Reliable
8:30 AM in Moscone Room 104

Building RAC Clusters over

InfiniBand

Database HA Demos All Four

Days
In The Oracle Demo
Campground
Real Application
Clusters
Data Guard
Database Backup & Recovery
Flashback Recovery
LogMiner, Online Redefinition, and
Cross Platform Transportable
Tablespaces

For More Info On : http://www.xoomtrainings.com/course/oracle-datag

REMINDER
PLEASE COMPLETE THE
ORACLEWORLD ONLINE SESSION
SURVEY
THANK YOU.

Q&
A

QUESTIONS
ANSWERS