2. Agenda Data Guard Architecture & Features
Data Guard Success Stories & Benefits

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

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

5. Data Guard Overview Primary Standby Site Site Data Guard Broker
Clients
Clients
Primary
Site
Standby
Site
Data Changes
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. Later I will talk more about these two types of standby databases.
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 is a distributed management framework that automates the creation and management of Data Guard configurations through the Data Guard Manager graphical user interface or its command-line interface.
Data Guard Broker

6. Data Guard Configuration
Standby Site A
Primary Site
Standby Site B
Standby
Database
Primary
Database
Standby
Database
Managed as a single configuration
Primary and standby databases can be Real Application Clusters or single-instance Oracle
Up to nine standby databases supported in a single configuration

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

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

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

10. Protection from Human Errors and Data Corruptions
Primary Site
Standby Site
Optional Delayed Apply
Data Changes
Application of changes received from the primary can be delayed at standby to allow for the detection of user errors and prevent standby to be affected
Administrators may choose not to configure any delay – if both primary and standby are affected, then they can be simply flashed back [10g]
The apply process also revalidates the log records to prevent application of any log corruptions
When a primary database is open and active and transactions, are in progress, redo log data is generated and shipped to standby sites. It is possible to delay the application of redo data already received at one or more standby databases. The ability to delay the application of changes to standby databases enables not only the protection of production data from data center disasters, but also provides a window of protection from user errors or corruptions. Of course, the apply process also revalidates the log records to prevent application of log corruptions.
If operating under the maximum protection or the maximum availability mode, Data Guard will ensure zero data loss even with this delayed apply in effect.

11. Switchover and Failover
Primary and Standby role transitions
Switchover
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 / flashed back [10g]
Initiated using simple SQL / GUI interface
Data Guard automates the processes involved
Oracle Data Guard offers two easy-to-use methods to handle planned and unplanned outages of the production site. These methods are called Failover and Switchover, and they are easily initiated using SQL or through the Data Guard Broker interface.
The switchover option is the planned role reversal of the primary and standby databases, to handle planned maintenance on the primary database. The main difference between a switchover operation and a failover operation is that switchover does not require re-instantiation of the database. This allows the primary database to resume its role as the standby database almost immediately. As a result, scheduled maintenance can be performed more frequently. For example, switchover may be used to perform an upgrade on the primary site by switching over all of the database clients to the standby site as hardware is upgraded on the primary site.
Failover is the operation of taking the primary database offline on one site and bringing one of the standby databases online as the new primary database. A failover operation can be invoked when an unplanned catastrophic failure occurs on the primary database, and there is no possibility of recovering the primary database in a timely manner. The failover operation is invoked on the standby database that will assume the primary role. After a failover, the original primary database must be re-instantiated to resume its role as a standby database.
Both failover and switchover operations guarantee zero data loss if Data Guard was being run in the maximum protection mode or maximum availability mode at the time of the failover or switchover.
Failover and switchover operations also work seamlessly when multiple standby databases are included in the configuration. For example, if multiple standby databases are configured and the primary database goes down, the administrator has the flexibility to choose one of the available standbys to become the primary. Data Guard fully automates the process of redirecting the other standby databases to use the new primary, including shipping any missing logs or incomplete logs.

12. Flexible Data Protection Modes
Risk of Data Loss
Redo Shipment
Maximum Protection
Zero Data Loss
Double Failure Protection
Synchronous redo shipping to 2 sites
Maximum Availability
Single Failure Protection
Synchronous redo shipping
Maximum Performance
Minimal data loss – usually 0 to few seconds
Asynchronous redo shipping
Oracle Data Guard provides three high-level modes of data protection to balance cost, availability, performance, and transaction protection. Using a simple SQL statement on the primary database, the Data Guard environment can be configured to maximize data protection, availability, or performance:
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
To determine the appropriate data protection mode to use, enterprises need to weigh their business requirements for data availability against user demands for response time and performance. The following slides talk about the details of each mode.
Balance cost, availability, performance, and transaction protection

13. Automatic Resynchronization
Network connectivity problems may occur
Data Guard automatically resynchronizes standbys after network connectivity restored
Implicit
ARCH process idling away on the primary ‘pings’ all standbys on a regular basis to see if they are missing any redo data
If so it sends them the missing redo data
Explicit
Gap discovered during apply process in physical standby
Based on FAL_SERVER and FAL_CLIENT settings, primary notified, and it sends missing redo data

14. 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 easy-to-use interfaces:
Oracle Enterprise Manager
Data Guard Broker’s command-line interface
Data Guard broker is the management and monitoring component that helps you create, control, and monitor a primary database protected by one or more physical standby databases as a single standby database configuration. The broker automates the previously manual process of configuration. Once it has created the Data Guard configuration, the broker monitors the activity, health, and availability for all systems in the Data Guard configuration.
All management operations can be performed locally or remotely through the Broker's easy-to-use interfaces: Oracle Data Guard Manager, which is the Broker's graphical user interface (GUI) and the Data Guard command-line interface (CLI).

15. Real Time Apply
Redo data is applied to the standby database as soon as it is received from the primary database
Without this support, apply has to wait till an archivelog is created on the standby database
Enables real-time reporting, faster switchovers/failovers
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”

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

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

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

24. Switched!

25. Agenda Data Guard Architecture & Features
Data Guard Success Stories & Benefits

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

27. Usage Examples Example B Example A Chicago Dallas Standby Site
Primary
Database
Chicago
Dallas
Standby
Maximize primary and
standby resources
Standby Site
Primary
Database
Site A
Site B
Site C
Standby
Standby machine must be powerful enough to support multiple production instances after switchover / failover
Example A

28. Data Guard Usage Examples
Standby Site A
Synchronous transport
LAN attached
Used to offload backups
First choice for switchover candidate
Primary Site
Standby Site B
Synchronous transport
LAN attached
Used to offload reporting
Standby Site C
Example C
Asynchronous transport
WAN attached
Delayed apply
Provides DR and data protection

29. What Fidelity Says
“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

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