Transcript Data Guard Technology Overview

Agenda
 Data Guard Architecture & Features
 Data Guard Success Stories & Benefits
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
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
Oracle High Availability Solutions for
Unplanned Downtime
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 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
Data Guard Overview
Clients
Clients
Primary
Site
Data Changes
Data Guard Broker
Standby
Site
Data Guard Configuration
Primary Site
Standby Site A
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
Oracle Data Guard Architecture
Physical Standby
Database
Sync or Async
Redo Shipping
Backup
Production
Database
Redo Apply
Network
DIGITAL DAT A ST ORAGE
DIGITAL DAT A ST ORAGE
Broker
Transform
Redo to SQL
Logical Standby
Database
SQL
Apply
Open for
Reports
Additional
Indexes & MVs
process architecture
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.
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.
LGWR SYNC Archival to a Remote
Destination with Standby Redo Log Files
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.
LGWR ASYNC Archival with Network
Server (LNSn) Processes
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.
Data Guard Redo Apply
Primary
Database
Data Guard
Broker
Physical Standby
Database
Redo Apply
Network
Redo Shipment




Backup
DIGITAL DAT A ST ORAGE
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

Logical Standby Database is an open, independent, active database





Standby
Redo Logs
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
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
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)
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.
Protection from Human Errors
and Data Corruptions
Primary Site
Optional Delayed
Apply
Standby Site
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
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
Data Guard Configuration
Before Switchover
Data Guard Environment
After Switchover
Failover to a Standby Database
Flexible Data Protection Modes
Protection Mode
Risk of Data Loss
Redo Shipment
Maximum Protection
Zero Data Loss
Double Failure Protection
Synchronous redo
shipping to 2 sites
Maximum Availability
Zero Data Loss
Single Failure Protection
Synchronous redo
shipping
Maximum Performance
Minimal data loss –
usually 0 to few seconds
Asynchronous redo
shipping
Balance cost, availability, performance, and transaction protection
Minimum Requirements for Data
Protection Modes
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.
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
--------------------MAXIMUM AVAILABILITY
PROTECTION_LEVEL
--------------------MAXIMUM AVAILABILITY
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
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)
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”
Real Time Apply Architecture
An up-to-date
Physical/Logical
Standby
Database
Oracle Net
Transactions
LGWR
Online
Redo
Logs
Primary
Database
MRP/ LSP
RFS
Standby
Redo
Logs
ARCH
Real Time
Apply
ARCH
Archived
Redo Logs
Archived
Redo Logs
Applying Redo Data to a Standby Destination Using
Real-Time Apply
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
SQL Apply – Rolling Database Upgrades
Upgrade
Redo
Clients
A
Version X
1
B
Logs
Queue
Version X
Initial SQL Apply Config
A
X
2
X+1
Upgrade node B to X+1
Redo
Redo
Upgrade
B
A
B
X+1
X+1
4 Switchover to B, upgrade A
A
X
3
B
X+1
Run in mixed mode to test
Patch Set
Upgrades
Major
Release
Upgrades
Cluster
Software &
Hardware
Upgrades
Example – Ease of Use
 Switchover using Enterprise Manager is now
literally two mouse clicks
Switched!
Agenda
 Data Guard Architecture & Features
 Data Guard Success Stories & Benefits
Data Guard Customers
Transportation
Telecom
Financial/
Insurance
Utilities
Government
Manufacturing
Health Care
Other Industries
e-Commerce
Usage Examples
Chicago
Dallas
Primary
Database
Standby
Database
Standby
Database
Primary
Database
Maximize primary and
standby resources
Example A
Example B
Standby machine must be powerful
enough to support multiple production
instances after switchover / failover
Primary
Site A
Primary
Database
Primary
Site B
Primary
Database
Primary
Site C
Primary
Database
Standby
Database
Standby
Database
Standby
Database
Standby Site
Data Guard Usage Examples
Primary Site
Standby Site A
Synchronous transport
LAN attached
Used to offload backups
First choice for switchover candidate
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
QUESTIONS
ANSWERS