Oracle Data Guard
Presented by
Satishbabu Gunukula
12+ Years of Experience in Oracle, SQLServer Database
Technologies
Oracle Certified Professional Oracle 8i,9i,10g
Oracle Certified Expert Oracle 10g RAC
 http://www.oracleracexpert.com

Agenda
 Data Guard and its benefits?
 Data Guard Architecture
 Types of Data guards and Benefits
 Advantages with different types of Data guards
 Processes and Services
 Data Guard Protection Modes
 Data Guard Role Transitions
 Data Guard Broker Architecture
 Data Guard features across versions
 Data Guard Setup

Why undertake Disaster Recovery?
 Disaster can strike at any time
 Unprepared organizations can loose
all the critical data.
 Even prepared companies can suffer
financial loss during system down time.
 Disasters can be natural calamities or
man-made problems

Origin …
 Impact of Disasters
 Customers across the globe will be effected
 High Availability Challenges
 Down time -- unplanned or planned
 Setup and Maintenance cost.
 Identifying the Disaster Recovery Site (DR Site)

Why Data Guard ?
Prior to Data Guard:
 Standby database
What is Standby database?
A standby database is a database replica created from a backup of
a primary database. By applying archived redo logs from the primary
database to the standby database, you can keep the two databases
synchronized
Used for :
 Disaster protection
 Protection against data corruption
 Supplemental reporting
Data guard is one of the most effective solutions available today in
terms of High Availability. Why?

Before Data guard…
Oracle Data Guard ensures high availability, data protection,
and disaster recovery for enterprise data. Data Guard
provides a comprehensive set of services that create,
maintain, manage, and monitor one or more standby
databases to enable production Oracle databases to survive
disasters and data corruptions.”

Pre-requisites:
 Same Oracle Enterprise Edition must be installed.
 primary database must run in ARCHIVELOG mode.
 Hardware and Operating System architecture must be same.
 Primary and Standby must have its own control file
 Can be configured on the same or different systems.
 Turn on FORCE LOGGING at the primary.
 SYSDBA privileges to user accounts.

Data Guard Benefits
 Disaster recovery, data protection, and high availability
 Complete data protection
 Efficient use of system resources
 Flexibility in data protection to balance availability against
performance requirements
 Automatic gap detection and resolution
 Centralized and simple management
 Integration with Oracle Database (no separate installation)
 Automatic role transitions

Processes Involved in the Architecture
Below are the main processes in DG configuration:
1) Logwriter (LGWr) Process
2) Archiver (ARCH) Process
3) Logwriter Network Server (LNS)
4) Fetch Archive Logs (FAL) for Client –Server mechanism
5) Remote File Server (RFS)
6) Managed Recovery Process (MRP) for Physical standby
7) Logical Standby Process (LSP) for Logical Standby
If Data Guard Broker is enabled :
8) Data Guard Broker Monitor (DMON) process

DataGuard Architecture

Redo log Data flow
Flow of Redo Data from Primary to Standby Database

Apply Services At High Level
 Data Guard comprises of two parts
 Redo Apply – For physical standby
 SQL Apply - for logical standby
 The Physical and logical standby databases utilize the same
redo transport and role management services, only apply
process is different.
 Either can be used to offload query and reporting from the
primary database. Either can be used to execute a rolling
database upgrade
 All standby databases are first created as physical standby
databases during the standby database instantiation process.
Several additional steps are required to convert a physical
standby database to a logical standby database.

Redo Apply
A physical standby database applies redo data received from
the primary using Oracle media recovery.
 The Redo Apply uses a specialized process, called the
Managed Recovery Process.
 As the RFS process is writing redo data to Standby Redo
Logs (SRLs), MRP reads the redo data and applies it to
the physical standby database.
 MRP is started on the physical standby database by
mounting the database and using the following command:
 SQL> alter database recover managed standby database
using current logfile disconnect from session;

Redo Apply
MRP may also transparently switch to reading from a
standby archived log if the SRL is archived before MRP can
complete reading of the.

SQL Apply
SQL Apply uses a collection of background processes that
perform the task of applying changes from the primary
database to the logical standby database.

Types of Dataguards: Physical Standby
 Physical standby
Provides a physically identical copy of the primary
database,
Identical to the primary database on a block-for-block
basis.
The database schema, including indexes, are the same.
Synchronized with the primary database, through Redo
Apply.

Data guard :Physical Standby Benefits
Benefits:
 Disaster recovery and high availability
Enables a robust and efficient disaster recovery and high
availability solution
 Data protection
Ensures no data loss, even in the face of unforeseen disasters.
Supports all data types, and all DDL and DML operations
 Reduction in primary database workload
 Oracle Recovery Manager (RMAN) can use to off-load backups from
the primary database saving valuable CPU and I/O cycles.
 Performance
 The Redo Apply technology applies changes using low-level
recovery mechanisms and is most efficient method for applying
high volumes of redo.

Types of Dataguard :Logical Standby
 Logical standby
Contains same logical information
physical organization and structure of the data can be different
Synchronized with the primary database, through SQL Apply
Can be used for queries and reporting at any time.

Logical Standby benefits
 Benefits:
 Along with disaster recovery, high availability, and data
protection;
 Efficient use of standby hardware resources
 Additional indexes and materialized views can be created to
improve query performance and suit specific business
requirements.
 Reduction in primary database workload

Services Involved:
•Log Transport Services
Transmit redo data from the primary system to the standby
systems in the configuration
Enforce the database protection modes
•Log Apply Services
Automatically apply archived redo logs on the standby
database
Maintains transactional synchronization with the primary
database
Allows transitionally consistent read-only access to the data.
 Redo Apply for Physical standby.
SQL Apply for Logical stand by.
•Role Management Services
An Oracle database operates in one of two roles: primary or
standby
Achieved by Switch over and Fail over operations.

Maximum Availability Architecture

Protection Modes
There are Three protection modes
 Maximum Availability
 Maximize Protection
 Maximize Performance
There are 3 ways of shipping redo data to a physical standby:
 LGWR SYNC
 LGWR ASYNC
 ARCH

Maximum Protection Mode
 This mode ensures that zero data loss occurs if a primary
fails. The default is Maximum Performance.
 In case if standby unavailable then processing stops at
primary. This the highest level of protection
 Maximum protection configuration - LGWR SYNC, SRLs
SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE
PROTECTION;

Maximum Availability Mode
 This mode provides highest level of data protection with
out compromising the availability of primary database
 If last standby is unavailable, processing continues at
primary. As long as network stys up - Zero Data Loss
 Maximum availability configuration - LGWR SYNC, do
not need SRLs
SQL> ALTER DATABASE SET STANDBY TO
MAXIMIZE AVAILABILITY

Maximum Performance Mode
 This mode provides the highest level of data protection that
is possible without affection the performance of a primary
database Highest level of performance
 This mode has least impact on system and protects from
failure of any single component
 Maximum performance configuration - LGWR ASYNC, or
ARCH
SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE
PERFORMANCE;

Role Transitions:
 A database operates in one of the following mutually exclusive
roles: primary or standby.
 Data Guard enables you to change these roles dynamically by
issuing the SQL statements , or by using either of the Data
Guard broker's interfaces.
 Oracle Data Guard supports the following role transitions:
 Switch over
 Failover

Switchover
 Allows the primary database to switch roles with one of its
standby databases.
 There is no data loss during a switchover.
 After a switchover, each database continues to participate in
the Data Guard configuration with its new role.

DataGuard Config Before Switchover

DataGuard Config AfterSwitchover

Failover
 A failover is typically used only when the primary database
becomes unavailable, and there is no possibility of restoring it
to service within a reasonable period of time.
 The specific actions performed during a failover vary based on
whether a logical or a physical standby database is involved in
the failover, the state of the Data Guard configuration at the
time of the failover, and on the specific SQL statements used
to initiate the failover

Failover to a Standby Database

Data guard Broker:
 The Data Guard broker is a distributed management
framework that automates and centralizes the creation,
maintenance, and monitoring of Data Guard configurations
 Can be administered either from Oracle Enterprise Manager
or Broker’s CLI (DGMGRL)
 List of operations that Broker automates :
 Creating and Enabling DG configurations – both Primary
and Physical/Logical
 Managing DG configuration from any site.
 Implementing Switchover and Failover operations

DG Broker Architecture:

Some Data Guard Features
across versions 9i,10g and
11g

DG features in Oracle 9.1:
9i : (9.1)
 Oracle 8i Standby renamed as Oracle 9i Data Guard
 Oracle9i Data Guard broker
 No data loss
 Database Switch over
 Archive gaps automatically detected
 Background managed recovery mode.
 Standby redo logs.

Enhancements in 9.2:
9i : (9.2)
 Logical Standby Database
 Data protection modes (Max
Protection/Availability/Performance)
 Cascading Redo Log Destinations
 Data Guard Broker
 Supports up to 9 Physical and Logical Standby databases
 For Failover and Switchover operations
 New Key words for REMOTE_ARCHIVE_ENABLE
(Send/Receive)

Data guard Enhancements in 10g :
 Fast –start Failover
 Logical standby
 LGWR ASYNC Redo Transport Enhancement
 Real Time Apply
 Rolling Upgrade

Dataguard Enhancements in 11g :
 Improved Data Protection
 High Availability
 Manageability
 Increased ROI

Improved Data Protection
 Faster redo transport
 Advanced Compression
log_archive_dest= ‘service=dbname ASYNC
COMPRESSION= ENABLE’
 Redo Compression
edit the broker property Redo Compression=Enable
 Lost–Write Protection

Higher Availability:
 Faster Redo apply and SQL apply
 Faster failover and switch over
 Enhanced Fast -start failover
 Transient logical standby
 NEW GC HA console

Manageability:
 SQL Apply –more automation
 Better RMAN integration
 Better Security
 Mixed Windows/linux
 Enhanced DG Broker

Increased ROI
 snapshot standby
 Active Data guard
 Enhanced Rolling upgrade
 Real –time query
 Fast incremental backup

Snapshot Standby:

Active Data guard
 Offload readonly queries to physical standby
 Offload increamental backups to physical standby

Rolling Database Upgrades
 The Rolling upgrade process involves upgrading the
logical standby database to the next release
 The patch set upgrade can be performed with near
zero database downtime.

Setup Overview :
Step 1: Prepare the Primary for Standby
Step 2: Configure Primary parameters
Step 3: Configure Primary listener and tnsnames
Step 4: Copy the necessary files and create Standby controlfile
Step 5: Configure the Standby Parameters
Step 6: Configure Standby listener and tnsnames
Step 7: Startup the Standby Site and Apply redo

Primary Database Req for DataGuard
FORCE LOGGING must be enabled:
SQL> Select name, database_role from v$database;
SQL> select force_logging from v$database;
SQL> alter database force logging;
Database must be in ARCHIVELOG mode and automatic archiving
must be enabled:
SQL> archive log list

Configure Primary parameters
control_files='/oradata/orclDB/control01.ctl,
‘/oradata/orclDB/control02.ctl' '
log_archive_config='DG_CONFIG=(orclDB,orclstd)' scope=both;
log_archive_dest_1='LOCATION=/oradata/orclDB/arch
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)‘
log_archive_dest_2='SERVICE=orclstd
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) LGWR
ASYNC REOPEN=10'

Configure Primary parameters
control_files='/oradata/orclDB/control01.ctl,
‘/oradata/orclDB/control02.ctl' '
log_archive_config='DG_CONFIG=(orclDB,orclstd)' scope=both;
log_archive_dest_1='LOCATION=/oradata/orclDB/arch
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)‘
log_archive_dest_2='SERVICE=orclstd
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) LGWR
ASYNC REOPEN=10'

Configure Primary Listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = orclDB.aligntech.com)
(ORACLE_HOME = /oracle/v10204)
(SID_NAME = orclDB)
)
)

Configure Primary tnsnames.ora
orclDB = (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = server1)(PORT =
1521))
(CONNECT_DATA = (SERVER = DEDICATED)
(SERVICE_NAME = orclDB.aligntech.com) ) )
orclstd = (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = server2)(PORT =
1521))
(CONNECT_DATA =
(SERVER = DEDICATED) (SERVICE_NAME =
orclDB.aligntech.com) ) )

Create Standby Controlfile
Shutdown the Primary database and copy the necessary files to
standby site
SQL> STATUP MOUNT
SQL>ALTER DATABASE CREATE STANDBY CONTROLFILE AS
'/oradata/orclDB/stdby01.ctl';
Copy the standby control file to standby site

Configure Standby parameters
control_files='/oradata/orclDB/stdby01.ctl,
/oradata/orclDB/stdby02.ctl'
log_archive_config='DG_CONFIG=(orclstd,orclDB)‘
log_archive_dest_1='LOCATION=/oradata/orclDBt/arch
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)’
log_archive_dest_2='SERVICE=orclDB
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) LGWR
ASYNC REOPEN=10'

Configure Standby parameters
log_archive_dest_state_1='enable'
log_archive_dest_state_2='enable'
FAL_CLIENT='orclstd'
FAL_SERVER='orclDB'
standby_archive_dest='/oradata/orclDB/arch'
standby_file_management='auto'
remote_login_passwordfile='EXCLUSIVE'

Configure Standby Listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = orclDB.aligntech.com)
(ORACLE_HOME = /oracle/v10204)
(SID_NAME = orclDB)
)
)

Configure Standby tnsnames.ora
orclDB = (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = server1)(PORT =
1521))
(CONNECT_DATA = (SERVER = DEDICATED)
(SERVICE_NAME = orclDB.aligntech.com) ) )
orclstd = (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = server2)(PORT =
1521))
(CONNECT_DATA = (SERVER = DEDICATED)
(SERVICE_NAME = orclDB.aligntech.com) )

Standby tnsnames.ora
orclDB = (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = server1)(PORT =
1521))
(CONNECT_DATA = (SERVER = DEDICATED)
(SERVICE_NAME = orclDB.aligntech.com) ) )
orclstd = (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = server2)(PORT =
1521))
(CONNECT_DATA = (SERVER = DEDICATED)
(SERVICE_NAME = orclDB.aligntech.com) )

Mount Standby Database and Apply redo
Keep the database in Standby mode
SQL>STARTUP MOUNT;
Start Redo Apply
SQL>ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE DISCONNECT FROM SESSION;
The DISCONNECT FROM SESSION option used to run
background session to apply Redo

Some important Dictionary Views
– V$ARCHIVE_DEST_STATUS
– V$ARCHIVE_GAP
– V$MANAGED_STANDBY
– V$STANDBY_LOG
– DBA_LOGSTDBY_EVENTS
– DBA_LOGSTDBY_LOG
– DBA_LOGSTDBY_NOT_UNIQUE
– DBA_LOGSTDBY_PARAMETERS
– DBA_LOGSTDBY_PROGRESS
– DBA_LOGSTDBY_SKIP
– DBA_LOGSTDBY_SKIP_TRANSACTION
– DBA_LOGSTDBY_UNSUPPORTED
– V$DATAGUARD_STATUS
– V$LOGSTDBY
– V$LOGSTDBY_STATS

Thank you.