2. Oracle Data Guard: Maximum Data Protection at Minimum Cost
Session Id: 40056
Oracle Data Guard: Maximum Data Protection at Minimum Cost
Ashish Ray Senior Product Manager
Oracle Corporation
Darl Kuhn Senior DBA, Staff Engineer
Sun Microsystems

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

4. What is Oracle Data Guard?
Oracle’s disaster recovery solution for Oracle data
Feature of Oracle Database Enterprise Edition
Automates the creation and maintenance of one or more transactionally consistent copies (standby) of the production (or primary) database
If the primary database becomes unavailable (disasters, maintenance), a standby database can be activated and assume the primary role
Oracle Data Guard is the management, monitoring, and automation software that includes an Oracle production database and one or more Oracle standby databases to protect enterprise data from failures, disasters, errors, and corruptions that might otherwise take the database down. It protects critical data by automating the creation, management, and monitoring of the databases and other components in its configuration. It automates the otherwise manual process of maintaining a standby database that can be used if the production database is taken offline for routine maintenance or becomes damaged.

5. Oracle Data Guard Focus
Data Failures & Site Disasters:
All 3 are important!
Data Protection
Data Availability
Data Recovery
Data is the core asset of the enterprise!
A recent Information Week survey demonstrated that data recovery is the top-most priority of today’s business managers, with almost 100% of 350 business/IT managers indicating that it is an essential element in their business continuity plans.
Also addresses human errors & planned maintenances

6. Oracle Data Guard Architecture
Physical Standby
Database
Sync or Async
Redo Shipping
Backup
Production
Database
Redo Apply
Network
Broker
Logical Standby
Database
Transform
Redo to SQL
Open for
Reports
Oracle Data Guard consists of a production database (also known as the primary database) and one or more standby database(s), which are transactionally consistent copies of the production database. A standby database can either be a physical standby database, or a logical standby database. A physical standby database has on-disk database structures that are identical to the primary database on a block-by-block basis. A logical standby database is an independent database that contains the same data as the primary database. It is updated using SQL statements, and has the relative advantage that it can be used simultaneously for recovery and for other tasks such as reporting, and queries.
The transactional consistency between primary and standby databases is maintained using Oracle online redo logs. As transactions change information stored in the primary database, the changes are also written to the online redo logs. These changes are transferred to the standby destinations by Log Transport Services and applied to the standby databases by Log Apply Services.
Role Management Services work with Log Transport Services and Log Apply Services to reduce downtime of the primary database for planned outages and from unplanned failures by facilitating switchover and failover operations.
Data Guard provides several management interfaces, including SQL statements, initialization parameters, a PL/SQL package, and the Oracle Data Guard Broker. The Broker aggregates the primary and standby databases into a single, unified grouping that can be centrally managed and monitored by the Broker as a whole. This obviates the need for discrete and complex sequences of commands that would otherwise be required to manage and monitor the primary and standby databases separately.
SQL Apply
Additional
Indexes & MVs

7. Data Guard Redo Apply
Physical Standby
Database
Primary
Database
Data Guard
Broker
Redo Apply
Backup
Network
Redo Shipment
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
A physical standby database is kept synchronized with the primary database by applying the redo log data received from the primary. It is physically identical to the primary database on a block-for-block basis, because the Oracle media recovery mechanism is used to apply changes to a physical data block address. The database schemas, including indexes, are the same, and the standby database can be opened read-only.
While the standby database is in the read-only mode, the primary database continues to ship redo data to the standby site. Oracle Data Guard also offers the flexibility to enable the physical standby database to switch between recovery and read-only modes, e.g. a sequence could involve running in recovery mode, then opening in read-only mode to run reports, and then returning to recovery mode to apply outstanding redo data.
A physical standby server can be either of two modes:
Managed Recovery in which the MRP (Managed Recovery Process) applies logs allowing the standby to keep pace with changes applied to the primary database.
Open for read only to enable query reporting access
Oracle9i Recovery Manager is aware of the standby database concept so it can be used to offload backups from the primary database saving valuable CPU and I/O cycles.

8. Continuously Open for Reports
Data Guard SQL Apply
Additional
Indexes &
Materialized Views
Logical Standby
Database
Primary
Database
Data Guard
Broker
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
A logical standby database is kept synchronized with the primary database by transforming the redo log data received from the primary into SQL statements and then applying the SQL statements. It contains the same logical information (rows) as the production database, although physical organization and structure of the data can be very different.
Because the logical standby database is updated using SQL statements, it can remain open in read-write mode, and the tables that are being updated from the primary database can be used simultaneously for other tasks such as reporting, summations, and queries. These tasks can also be optimized by creating additional indexes and materialized views on the maintained tables to those used on the primary database. A logical standby database can host multiple database schemas, and users can perform normal data manipulation operations on tables in schemas that are not updated from the primary database.

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

10. Oracle Data Guard 10g Objectives
Establish Data Guard as an extremely
easy-to-use
low-cost
comprehensive
reliable
Disaster Recovery solution for enterprise data

11. 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

12. 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

13. 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”

14. Real Time Apply Architecture
An up-to-date Physical/Logical
Standby
Database
Oracle Net
Transactions
LGWR
MRP/ LSP
RFS
Standby
Redo
Logs
Online
Redo Logs
Real Time Apply
Primary
Database
ARCH
ARCH
Archived
Redo Logs
Archived
Redo Logs 7

15. 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

16. Existing Site Recovery Tradeoffs
Primary Database
Standby Database
Reporting on delayed data
Redo
Shipment
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

17. 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
It’s fast - recover in minutes, not hours
It’s easy - single command restore
RMAN> FLASHBACK DATABASE
TIMESTAMP to_timestamp
(' :00:00',
'YYYY-MM-DD HH24:MI:SS');

18. Enhanced DR with Flashback Database
Real Time Reporting
Real Time
Apply
No Delay!
Primary Database
Standby Database
Redo
Shipment
Flashback
Log
Flashback
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

19. 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

20. Rolling Upgrades Patch Set Major Release Upgrades
Initial SQL Apply Config
Clients
Redo
Version X 1 B A
Upgrade node B to X+1
Upgrade
Logs
Queue X 2
X+1 A B
Major
Release
Upgrades
Patch Set
Cluster Software & Hardware Upgrades
Switchover to B, upgrade A
Redo 4
Upgrade
X+1 B A
Run in mixed mode to test
Redo 3
X+1 X A B
Release Upgrades
Many changes
Often changes disk format, network protocols, views, packages
Relatively risky to apply to production system
Safety is primary goal
Apply in a rolling fashion across Data Guard nodes
Don’t need extra nodes or clusters to do a rolling upgrade
Can create a standby database on existing node or create an extra RAC instance on an existing node
Extra disk space and memory IS required

21. 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

22. 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

23. 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

24. RAC Primary
Two standby dbs

25. Instance specific

26. Example – Ease of Use
Switchover using Enterprise Manager is now literally two mouse clicks

32. Switched!

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

34. Case Study Oracle Data Guard at Sun Microsystems Darl Kuhn
Senior DBA, Staff Engineer
Business decision considerations
Architecture
Implementation
Features we use

35. 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

36. Solutions We Investigated
Backup the database, restore from tape
Operating System failover
Remote Mirroring
Quest’s SharePlex
Oracle Advanced Replication (OAR)
Oracle Real Application Clusters (RAC)
Oracle Data Guard (Standby)

37. We Chose Data Guard 7x24 DR protection Simple to implement
Requires DBA with B&R skills
Didn’t need special System Administration skills or consultants
Low maintenance (do more w/less DBAs)
No extra licensing (built into Oracle9i)

38. 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

39. Fetch Archive Log (FAL)
Maximum Performance
Primary Database
Production Site
Standby Database
Server .
Copied
Archive
Redo
Users
Remote File
Server (RFS)
Copied
Archive
Redo
Fetch Archive Log (FAL)
Oracle
Net
Primary
Database
LGWR
Managed
Recovery
Process (MRP)
ARCn
On-line
Redo
Online
Redo
Standby
Database
Local
Archive
Redo
Local
Archive
Redo

40. 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

41. 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

42. Using RMAN to Build Standby
On Primary:
RMAN> backup database;
Copy backup pieces to Standby
Create a Standby controlfile and copy to Standby
Then on Standby:
SQL> startup nomount;
SQL> alter database mount standby database;
RMAN> restore database;
SQL> alter database recover managed standby database disconnect;

43. 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

44. 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;

45. 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

46. 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;

47. 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

48. Use of Read-Only Standby
Primary Database
Production Site
Two Separate Read-Only
Standby Database Servers .
Oracle
Net
l3srv1
Daily
Batch
Load
Standby 1
brdstn
Reports
Primary
Database
ARCn
l3srv2
Standby 2
brdstn

49. 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)) )

50. Disaster Happens… Haven’t 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

51. 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

52. 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

53. 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

54. Oracle Data Guard 10g Beta Feedback
Logical Standby easier to setup
Simplified SQL syntax
More helpful, feature-rich initialization parameters

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

56. 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
Ref. for latest updates

57. Data Guard Customers Transportation Telecom Utilities Financial/
Insurance
Government
Manufacturing
Health Care
Other Industries
e-Commerce

58. 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

59. 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

60. 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

61. Why Oracle Data Guard? Disaster Recovery & High Availability
Easy failover/switchover between primary and standby databases
Complete data protection
Enables zero data loss, safeguard against data corruptions
Efficient utilization of system resources
Standby databases can be used for reporting, backups, queries
Balance data availability against performance
Flexible data protection/synchronization modes
Automatic resynchronization after restoration of network connectivity
Automatic archive gap detection and resolution with no manual intervention
Centralized and simple management
Push-button graphical interface for management and monitoring

62. Of Course …
Complete, out-of-the-box integration with Oracle database, at no extra cost!

63. Resources
Maximum Availability Architecture white papers:
HA Portal on OTN:
Data Guard home page on OTN:
Oracle Consulting Services:

64. Next Steps High Availability Sessions from Oracle
Tuesday in Moscone Room 304
Wednesday in Moscone Room 304
11:00 AM
How Oracle Database 10g Revolutionizes Availability and Enables the Grid
3:30 PM
Oracle Recovery Manager (RMAN) 10g: Reloaded
5:00 PM
Proven Techniques for Maximizing Availability
8:30 AM
Oracle Database 10g - RMAN and ATA Storage in Action
11:00 AM
Oracle Data Guard: Maximum Data Protection at Minimum Cost
1:00 PM
Oracle Database 10g Time Navigation: Human-Error Correction
4:30 PM
Data Guard SQL Apply: Back to the Future
For More Info On Oracle HA Go To

65. Next Steps High Availability Sessions from Oracle
Thursday
Real Application Clusters
Data Guard
Database Backup & Recovery
Flashback Recovery
LogMiner, Online Redefinition, and Cross Platform Transportable Tablespaces
Database HA Demos All Four Days
In The Oracle Demo Campground
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
For More Info On Oracle HA Go To

66. Reminder – please complete the OracleWorld online session survey Thank you.

67. Q
&
Q U E S T I O N S
A N S W E R S A