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

3. Data Guard Architecture & Features
1. Introduction
2. concepts and architecture
3. process architecture
4. data protection mode
5. data guard implementation
6. role management
7. summary
8. Q&A

4. Oracle High Availability Features
Oracle provides the following features for high availability:
- Oracle Real Application Clusters
- Oracle Data Guard
- Oracle Streams
- Oracle Flashback Technology
- Automatic Storage Management
- Recovery Manager
- Flash Recovery Area
- Oracle Security Features
- Fast-Start Fault Recovery
- LogMiner
- Hardware Assisted Resilient Data (HARD) Initiative

5. Oracle High Availability Solutions for Unplanned Downtime

6. Oracle’s Integrated HA Solutions
System Failures
Real Application Clusters
Unplanned Downtime
Automatic Storage Management Flashback RMAN & Flash Recovery Area H.A.R.D Data Guard
Data Failures
System Changes
Online Reconfiguration Rolling Upgrades
Planned Downtime
Data Changes
Online Redefinition

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

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

9. Data Guard Overview Primary Standby Site Site Data Guard Broker
Clients
Clients
Primary
Site
Standby
Site
Data Changes
Data Guard Broker
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.

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

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

12. process architecture Log Writer Process (LGWR)
Archiver Processes (ARCn)
By default, redo transport services use ARCn processes to archive the online redo log files on the primary database.
on the LOG_ARCHIVE_DEST_n initialization parameter to control the automated transfer of redo data from the primary database to other destinations.
must specify either the LOCATION attribute to archive to a local
destination or the SERVICE attribute for remote archival.
Log Writer Process (LGWR)
can optionally enable redo transport services to use the LGWR process to transmit redo data to remote destinations.

13. process architecture Log Writer Process (LGWR)
Using the LGWR process differs from ARCn processing, because instead of waiting for the online redo log to switch at the primary database and then writing the entire archived redo log at the remote destination all at once.
The transmission to the remote destination will either be synchronous or asynchronous, based on whether the SYNC or the ASYNC attribute is set on the LOG_ ARCHIVE_DEST_n parameter.
The SYNC attribute performs all network I/O synchronously, in conjunction with each write operation to the online redo log file, and waits for the network I/O to complete.

14. LGWR SYNC Archival to a Remote Destination with Standby Redo Log Files

15. process architecture
The ASYNC attribute performs all network I/O asynchronously and control is returned to the executing application or user immediately, without waiting for the network I/O to complete.
If you configure a destination to use the LGWR process, but
for some reason the LGWR process becomes unable to archive to
the destination, then redo transport will revert to using the ARCn
process to complete archival operations.
LNSn process
collecting redo data from the online redo log files and transmitting it over Oracle Net to the RFS process on the standby database.

16. LGWR ASYNC Archival with Network Server (LNSn) Processes

17. process architecture fetch archive log (FAL)
uses the fetch archive log (FAL) client and server to send archived redo log files to standby destinations following a network outage, for automatic gap resolution, and resynchronization.
remote file server process (RFS)
On the remote destination, the remote file server process (RFS) will, in turn, write the redo data to an archived redo log file from a standby redo log file.
Log apply services use Redo Apply (MRP process1) or SQL Apply (LSP process2) to apply the redo to the standby database.

18. Data Guard Process Architecture (9i)
Oracle Net
Physical/Logical
Standby
Database
Backup /
Reports
Primary
Database
Transactions
LGWR
Online Redo Logs
MRP/ LSP
Transform Redo
to SQL for
SQL Apply
LNS
RFS
Standby
Redo
Logs
FAL
Archived Redo Logs
ARCH
Archived Redo Logs
ARCH 7

19. Data Guard Process Architecture (10g)
FAL
Oracle Net
Primary
Database
Transactions
Physical/Logical
Standby
Backup /
Reports
LGWR
Online Redo Logs
RFS
Redo
Logs
Archived Redo Logs
ARCH
MRP/ LSP
Transform Redo
to SQL for
SQL Apply
LNS
sync
async 7

20. Process Architecture – 10g Release 2
Physical/Logical
Standby
Database
Transactions
Oracle Net
LGWR
LNS
MRP/ LSP
RFS
sync
async
Online Redo Logs
Primary
Database
arch
Transform Redo
to SQL for
SQL Apply
Standby
Redo
Logs
FAL
Backup /
Reports
ARCH
Archived Redo Logs
Archived Redo Logs
ARCH 7

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

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

23. Data Type and DDL Support on a Logical Standby Database
Logical standby databases support the following data types:
‧ BINARY_DOUBLE ‧BINARY_FLOAT ‧ DATE
‧ BLOB ‧CHAR ‧CLOB and NCLOB
‧ CLOB and NCLOB ‧INTERVAL YEAR TO MONTH
‧ INTERVAL YEAR TO MONTH ‧ LONG
‧ INTERVAL DAY TO SECOND ‧ LONG RAW
‧ NCHAR NUMBER ‧ NVAR ‧ CHAR2RAW
‧ TIMESTAMP ‧ TIMESTAMP WITH LOCAL TIMEZONE
‧ TIMESTAMP WITH TIMEZONE ‧ VARCHAR2 and VARCHAR

24. Data Type and DDL Support on a Logical Standby Database
Logical standby databases do not support the following data types:
‧ ROWID ‧ UROWID
‧ BFILE ‧Encrypted columns
‧ XMLType ‧ User-defined types
‧ Collections (including VARRAYS and nested tables)
‧ Multimedia data types (including Spatial, Image, and Context)

25. Skipped SQL Statements on a Logical Standby Database
By default, the following SQL statements are
automatically skipped by SQL Apply:
‧ALTER DATABASE ‧ALTER MATERIALIZED VIEW ‧ALTER SESSION
‧ALTER SESSION ‧CREATE CONTROL FILE ‧CREATE DATABASE
‧ALTER SYSTEM ‧CREATE DATABASE LINK ‧LOCK TABLE
‧SET CONSTRAINTS ‧ ALTER MATERIALIZED VIEW LOG ‧ SET ROLE
‧SET TRANSACTION ‧CREATE MATERIALIZED VIEW ‧EXPLAIN
‧LOCK TABLE ‧CREATE PFILE FROM SPFILE
‧SET ROLE ‧CREATE SPFILE FROM PFILE
‧CREATE SCHEMA AUTHORIZATION ‧DROP DATABASE LINK
‧DROP MATERIALIZED VIEW ‧ DROP MATERIALIZED VIEW LOG
All other SQL statements executed on the primary
database are applied to the logical standby database.

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

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

28. Data Guard Configuration Before Switchover

29. Data Guard Environment After Switchover

30. Failover to a Standby Database

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

32. Minimum Requirements for Data Protection Modes

33. LOG_ARCHIVE_DEST_n Parameter Attributes
■ AFFIRM
specifies that all disk I/O to archived redo log files and standby redo log files is performed synchronously and completes successfully before the log writer process continues.
■ NOAFFIRM
specifies that all disk I/O to archived redo log files and standby redo log files is performed asynchronously; the log writer process on the primary database does not wait until the disk I/O completes before continuing.

34. Confirm the configuration is perating in the new protection mode
Query the V$DATABASE view to confirm the Data Guard configuration is operating in the new protection mode.
SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL
FROM V$DATABASE;
PROTECTION_MODE PROTECTION_LEVEL
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY

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

36. Data Guard Broker
Distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations
Create and enable Data Guard configurations, including setting up redo transport services and log apply services
Manage an entire Data Guard configuration from any system in the configuration
Manage and monitor Data Guard configurations that contain Real Application Clusters primary or standby databases
Management operations can be performed locally or remotely through easy-to-use interfaces:
Use either the Oracle Enterprise Manager graphical user interface (GUI) or
Data Guard Broker’s command-line interface (DGMGRL)
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).

37. Real Time Apply
Redo data is applied to the standby database as soon as it is received from the primary database
If the real-time apply feature is enabled, log apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived.
Enables real-time reporting, faster switchovers/failovers.
If real-time apply is enabled, Data Guard recovers redo data directly from the current standby redo log file as it is being filled up by the RFS process.
For Redo Apply : (physical standby databases)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT
LOGFILE
For SQL Apply : (logical standby databases)
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”

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

39. Applying Redo Data to a Standby Destination Using Real-Time Apply

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

41. SQL Apply – Rolling Database 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
Run in mixed mode to test
Redo 3
X+1 X A B
Switchover to B, upgrade A
Redo 4
Upgrade
X+1 B A
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

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

48. Switched!

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

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

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

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

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