D79232GC10 sg1

Edutronic Global Services EฺIฺRฺL
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2014, Oracle and/or its affiliatesฺ
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
Oracle
A BE ble l Database 12c: Data
E LIZ sfera
C I A tranGuard Administration
I
TR non-
PA
Student Guide – Volume I

D79232GC10
Edition 1.0 | December 2016 | D85496
Learn more from Oracle University at education.oracle.com

Author Copyright © 2014, Oracle and/or it affiliates. All rights reserved.
Mark Fuller Disclaimer
This document contains proprietary information and is protected by copyright and

Technical Contributors other intellectual property laws. You may copy and print this document solely for your
own use in an Oracle training course. The document may not be modified or altered
and Reviewers in any way. Except where your use constitutes "fair use" under copyright law, you
Christopher Andrews may not use, share, download, upload, copy, print, display, perform, reproduce,
publish, license, post, transmit, or distribute this document in whole or in part without
Maria Billings the express authorization of Oracle.
Trevor Bowen
The information contained in this document is subject to change without notice. If you
Harald van Breederode find any problems in the document, please report them in writing to: Oracle University,
500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
Larry Carpenter warranted to be error-free.
Al Flournoy
Restricted Rights Notice
Joe Fong
Gerlinde Frenzen If this documentation is delivered to the United States Government or anyone using
the documentation on behalf of the United States Government, the following notice is
Joel Goodman applicable:
Uwe Hesse
s a
) ha
U.S. GOVERNMENT RIGHTS
Nitin Karkhanis The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
Donna Keesling
l ฺ om
disclose these training materials are restricted by the terms of the applicable Oracle
c
ai ฺ
license agreement and/or the applicable U.S. Government contract.
Sean Kim
m
g ide
Trademark Notice
Jerry Lee,
9 @
9 nt G u
Stephen Moriarty
u i z
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
pr tude
may be trademarks of their respective owners.
Juan Quezada Nunez
(
Veerabhadra Rao Putrevu
R ON his S
Puneet Sangar
Thorsten Senft B AR use t
U IZ e to
H R icens
Ira Singer
Branislav Valny
T
A BE ble l
Editors
L IZ fera
DanielA E ns
C I Milne
I Kumarn- t r a
TRAnwesha
Raj
PA noRay
Publishers
Joseph Fernandez
Veena Narasimhan
Contents
1 Introduction to Oracle Data Guard

Objectives 1-2
What Is Oracle Data Guard? 1-3
Types of Standby Databases 1-4
Types of Data Guard Services 1-6
Role Transitions: Switchover and Failover 1-7
Oracle Data Guard Broker Framework 1-9
Choosing an Interface for Administering a Data Guard Configuration 1-10 s a
Oracle Data Guard: Architecture (Overview) 1-11 ) ha
Primary Database Processes 1-12
l ฺ c om
Standby Database Processes 1-13 m ai ฺ
@ g
Physical Standby Database: Redo Apply Architecture 1-14
9 u ide
i z 9 nt G
Logical Standby Database: SQL Apply Architecture 1-15
u
pr tude
(
Automatic Gap Detection and Resolution 1-16
Data Protection Modes 1-17
R ON his S
AR use t
Data Guard Operational Requirements: Hardware and Operating System 1-19
B
IZ e to
Data Guard Operational Requirements: Oracle Database Software 1-20
U
H R icens
Benefits of Implementing Oracle Data Guard 1-21
T
BE ble l
Quiz 1-22
A
E LIZ sfera
Summary 1-24
Practice 1: Overview 1-25
I C IA -tran
TR2 Creating
non a Physical Standby Database by Using Enterprise Manager Cloud
PA Control
Objectives 2-2
Prerequisites for Using Oracle Enterprise Manager Cloud Control 12c 2-3
Accessing the Add Standby Database Wizard 2-4
Creating a New Standby Database 2-6
Creating a Physical Standby Database Step 1: Backup Type 2-7
Creating a Physical Standby Database Step 2: Backup Options 2-8
Creating a Physical Standby Database Step 3: Database Location 2-9
Creating a Physical Standby Database Step 4: File Locations 2-10
Creating a Physical Standby Database Step 5: Configuration 2-12
Creating a Physical Standby Database Step 6: Review 2-13
Creating a Physical Standby Database Job Activity 2-14
iii
Creating a Physical Standby Database Job Task Details 2-15

Data Guard Administration Page 2-16
Verifying Configuration 2-17
Performing Routine Maintenance 2-18
Configuring Fast-Start Failover 2-19
Editing Primary Database Properties: General Properties 2-20

Editing Primary Database Properties: Standby Role Properties 2-21
Editing Primary Database Properties: Common Properties 2-22
Test Application 2-23
Quiz 2-24
Summary 2-26
s a
3 Oracle Net Services in a Data Guard Environment
) ha
Objectives 3-2
l ฺ c om
Oracle Net Services Overview 3-3
m ai ฺ
Understanding Name Resolution 3-4
9 @ g
u ide
Local Naming Configuration Files 3-5
i z 9 nt G
Local Naming: tnsnames.ora 3-6 u
pr tude
(
ON his S
Connect-Time Failover: Planning for Role Reversal 3-7
R
B AR use t
Listener Configuration: listener.ora 3-8
Dynamic Service Registration 3-9
U IZ e to
H R icens
Static Listener Entries: listener.ora 3-10
T
Optimizing Oracle Net for Data Guard 3-11
A BE ble l
Quiz 3-13
LIZ sfera
Summary 3-15
E
I C IA -tran
TR non
PA 4 Creating a Physical Standby Database by Using SQL and RMAN Commands
Objectives 4-2
Steps to Create a Physical Standby Database 4-3
Preparing the Primary Database 4-4
FORCE LOGGING Mode 4-5
Configuring Standby Redo Logs 4-7
Standby Redo Log Usage 4-8
Using SQL to Create Standby Redo Logs 4-9
Viewing Standby Redo Log Information 4-10
Setting Initialization Parameters on the Primary Database to Control Redo
Transport 4-11
Setting LOG_ARCHIVE_CONFIG 4-12
Setting LOG_ARCHIVE_DEST_n 4-14
iv
Specifying Role-Based Destinations 4-15

Combinations for VALID_FOR 4-17
Defining the Redo Transport Mode 4-18
Setting Initialization Parameters on the Primary Database 4-19
Specifying Values for DB_FILE_NAME_CONVERT 4-20
Specifying Values for LOG_FILE_NAME_CONVERT 4-21

Specifying a Value for STANDBY_FILE_MANAGEMENT 4-22
Specifying a Value for FAL_SERVER 4-23
Example: Setting Initialization Parameters on the Primary Database 4-24
Creating an Oracle Net Service Name for Your Physical Standby Database 4-25
Creating a Listener Entry for Your Standby Database 4-26
Copying Your Primary Database Password File to the Physical Standby
Database Host 4-27
s a
Creating an Initialization Parameter File for the Physical Standby Database 4-28
) ha
l ฺ c om
Creating Directories for the Physical Standby Database 4-29
Starting the Physical Standby Database 4-30
m ai ฺ
9 @ g
u ide
Creating an RMAN Script to Create the Physical Standby Database 4-31
i z 9 nt G
Creating the Physical Standby Database 4-33
Real-Time Apply (Default) 4-34 u
pr tude
(
ON his S
Starting Redo Apply in Real-Time 4-36
R
Database 4-37 B AR use t
Preventing Primary Database Data Corruption from Affecting the Standby
U IZ e to
H R icens
Special Note: Data Guard Support for Oracle Multitenant 4-39
T
Special Note: Standby Database on the Same System 4-40
A BE ble l
Creating a Physical Standby Without Using RMAN 4-41
LIZ sfera
Quiz 4-42
E
I C IA -tran
Summary 4-44
TR non Practice 4: Overview 4-45
PA
5 Using Oracle Active Data Guard
Objectives 5-2
Oracle Active Data Guard 5-3
Using Real-Time Query 5-4
Enabling Real-Time Query 5-5
Disabling Real-Time Query 5-6
Checking the Standby’s Open Mode 5-7
Understanding Lag in an Active Data Guard Configuration 5-8
Monitoring Apply Lag: V$DATAGUARD_STATS 5-9
Monitoring Apply Lag: V$STANDBY_EVENT_HISTOGRAM 5-10
Allowed Staleness of Standby Query Data 5-11
Configuring Zero Lag Between the Primary and Standby Databases 5-12
v
Setting STANDBY_MAX_DATA_DELAY by Using an AFTER LOGON Trigger 5-13

Example: Setting STANDBY_MAX_DATA_DELAY by Using an AFTER LOGON
Trigger 5-14
Forcing Redo Apply Synchronization 5-15
Creating an AFTER LOGON Trigger for Synchronization 5-16
Active Data Guard: DML on Temporary Tables 5-17

Active Data Guard: Support for Global Sequences 5-18
Active Data Guard: Support for Session Sequences 5-19
Benefits: Temporary Undo and Sequences 5-20
Supporting Read-Mostly Applications 5-21
Example: Transparently Redirecting Writes to the Primary Database 5-22
Enabling Block Change Tracking on a Physical Standby Database 5-23
Creating Fast Incremental Backups 5-24
s a
Enabling Block Change Tracking 5-25
) ha
Monitoring Block Change Tracking 5-26
l ฺ c om
Data Guard 12c: Far Sync 5-27
m ai ฺ
Far Sync: Redo Transport 5-28
9 @ g
u ide
i z 9 nt G
Far Sync: Alternate Redo Transport Routes 5-30
u
pr tude
Oracle Data Guard 12c: Far Sync Creation 5-31
(
Benefits: Far Sync 5-32
R ON his S
B
Real-Time Cascade 5-34
AR use t
Far Sync: Alternate Design 5-33
U IZ e to
H R icens
Traditional Multi-Standby Database Architecture 5-35
T
Benefits: Real-Time Cascade 5-36
A BE ble l
Quiz 5-37
LIZ sfera
Summary 5-38
E
I C IA -tran
TR non
PA 6 Creating and Managing a Snapshot Standby Database
Objectives 6-2
Snapshot Standby Databases: Overview 6-3
Snapshot Standby Database: Architecture 6-4
Converting a Physical Standby Database to a Snapshot Standby Database 6-5
Activating a Snapshot Standby Database: Issues and Cautions 6-6
Snapshot Standby Database: Target Restrictions 6-7
Viewing Snapshot Standby Database Information 6-8
Snapshot Standby Space Requirements 6-9
Converting a Snapshot Standby Database to a Physical Standby Database 6-10
Quiz 6-11
Summary 6-12
vi
7 Creating a Logical Standby Database

Objectives 7-2
Benefits of Implementing a Logical Standby Database 7-3
Logical Standby Database: SQL Apply Architecture 7-5
SQL Apply Process: Architecture 7-6
Preparing to Create a Logical Standby Database 7-7

Unsupported Objects 7-8
Unsupported Data Types 7-9
Identifying Internal Schemas 7-10
Checking for Unsupported Tables 7-11
Checking for Tables with Unsupported Data Types 7-12
SQL Commands That Do Not Execute on the Standby Database 7-13
Unsupported PL/SQL-Supplied Packages 7-14
s a
Ensuring Unique Row Identifiers 7-15
) ha
Adding a Disabled Primary Key RELY Constraint 7-17
l ฺ c om
ai ฺ
Creating a Logical Standby Database by Using SQL Commands 7-18
m
9 @ g
Step 1: Create a Physical Standby Database 7-19
u ide
i z 9 nt G
Step 2: Stop Redo Apply on the Physical Standby Database 7-20
u
pr tude
Step 3: Prepare the Primary Database to Support Role Transitions 7-21
(
ON his S
Step 4: Build a LogMiner Dictionary in the Redo Data 7-22
R
B AR use t
Step 5: Transition to a Logical Standby Database 7-23
Step 6: Open the Logical Standby Database 7-24
U IZ e to
H R icens
Step 7: Verify That the Logical Standby Database Is Performing Properly 7-25
T
Creating a Logical Standby Database by Using Enterprise Manager 7-27
A BE ble l
Using the Add Standby Database Wizard 7-28
LIZ sfera
Securing Your Logical Standby Database 7-31
E
I C IA -tran
Automatic Deletion of Redo Log Files by SQL Apply 7-32
TR non Managing Remote Archived Log File Retention 7-33
PA Creating SQL Apply Filtering Rules 7-34
Deleting SQL Apply Filtering Rules 7-35
Viewing SQL Apply Filtering Settings 7-36
Using DBMS_SCHEDULER to Create Jobs on a Logical Standby Database 7-37
Quiz 7-38
Summary 7-40
8 Oracle Data Guard Broker: Overview

Objectives 8-2
Oracle Data Guard Broker: Features 8-3
Data Guard Broker: Components 8-4
Data Guard Broker: Configurations 8-5
vii
Data Guard Broker: Management Model 8-6

Data Guard Broker: Architecture 8-7
Data Guard Monitor: DMON Process 8-8
Benefits of Using the Data Guard Broker 8-9
Comparing Configuration Management With and Without the Data Guard
Broker 8-10
Data Guard Broker Interfaces 8-11
Broker Controlled Database Initialization Parameters 8-12
Using the Command-Line Interface of the Data Guard Broker 8-13
Using Oracle Enterprise Manager Cloud Control 8-16
Data Guard Overview Page 8-17
Benefits of Using Enterprise Manager 8-18
Quiz 8-19
s a
Summary 8-21
) ha
l ฺ c om
9 Creating a Data Guard Broker Configuration
m ai ฺ
Objectives 9-2
9 @ g
u ide
Data Guard Broker: Requirements 9-3
i z 9 nt G
Data Guard Broker and the SPFILE 9-5 u
pr tude
Data Guard Monitor: Configuration File 9-7 ON
( S
R h i s
Data Guard Broker: Log Files 9-8
A R se t
Creating a Broker Configuration Z9-9
I B o u
U t
H R Locations
Clear Redo Transport Network
e n se on Primary 9-10
T Database
Connecting to the Primary
E l ic with DGMGRL 9-11
Defining the A B bl e
Broker Configuration and the Primary Database Profile 9-12
L I Z r a
Adding
A E a Standby
n s feDatabase to the Configuration 9-13
I t a Sync to the Configuration 9-14
Adding arFar
ICEnabling
-
T R n
no the Configuration 9-15
PA Broker Support for Complex Redo Routing 9-16
Defining RedoRoutes by Using DGMGRL 9-17
RedoRoutes Usage Guidelines 9-18
How to Read Redo Routing Rules 9-19
Far Sync Example with RedoRoutes 9-20
Changing Database Properties and States 9-21
Managing Redo Transport Services by Using DGMGRL 9-22
Managing the Redo Transport Service by Using the LogXptMode Property 9-26
Setting LogXptMode to ASYNC 9-27
Setting LogXptMode to SYNC 9-28
Setting LogXptMode to FASTSYNC (New in Oracle Database 12c) 9-29
Disabling Broker Management of the Configuration or Standby Database 9-30
Removing the Configuration or Standby Database 9-31
viii
Quiz 9-32
Summary 9-33
10 Monitoring a Data Guard Broker Configuration

Objectives 10-2
Monitoring the Data Guard Configuration by Using Enterprise Manager Cloud
Control 10-3
Viewing the Data Guard Configuration Status 10-4
Monitoring Data Guard Performance 10-5
Viewing Log File Details 10-6
Enterprise Manager Metrics and Alerts 10-7
Data Guard Metrics 10-8
s a
Managing Data Guard Metrics 10-9
) ha
Viewing Metric Value History 10-10
l ฺ c om
Viewing Data Guard Diagnostic Information 10-11
m ai ฺ
9 @ g
u ide
Using Monitorable Database Properties to Identify a Failure 10-13
i z 9 nt G
Using the SHOW CONFIGURATION DGMGRL Command to Monitor the
Configuration 10-14 u
pr tude
(
ON his S
Using the SHOW DATABASE VERBOSE DGMGRL Command to Monitor the
R
Configuration 10-15
B AR use t
Viewing Standby Redo Log Information in V$LOGFILE 10-17
U IZ e to
H R icens
Viewing Standby Redo Log Information in V$STANDBY_LOG 10-18
T
Identifying Destination Settings 10-19
A BE ble l
Setting the LOG_ARCHIVE_TRACE Initialization Parameter 10-20
LIZ sfera
Viewing Redo Transport Errors by Querying V$ARCHIVED_DEST 10-22
E
I C IA -tran
Evaluating Redo Data by Querying V$DATAGUARD_STATS 10-23
TR nonViewing Data Guard Status Information by Querying
PA V$DATAGUARD_STATUS 10-24
Monitoring Redo Apply by Querying V$MANAGED_STANDBY 10-25
Monitoring SQL Apply by Querying V$LOGSTDBY_TRANSACTION 10-26
Quiz 10-27
Summary 10-29
11 Configuring Data Protection Modes

Objectives 11-2
Data Protection Modes and Redo Transport Modes 11-3
Data Protection Modes 11-4
Maximum Protection Mode 11-5
Maximum Availability Mode 11-6
ix
Maximum Performance Mode 11-7

Comparing Data Protection Modes 11-8
Setting the Data Protection Mode by Using Enterprise Manager 11-9
Setting the Data Protection Mode by Using DGMGRL 11-11
Setting the Data Protection Mode by Using SQL 11-12
Quiz 11-13
Summary 11-14
12 Performing Role Transitions

Objectives 12-2
Role Management Services 12-3
Role Transitions: Switchover and Failover 12-4
s a
Switchover 12-5
) ha
Switchover: Before 12-6
l ฺ c om
Switchover: After 12-7
m ai ฺ
9 @ g
u ide
Performing a Switchover by Using Enterprise Manager 12-8
i z 9 nt G
Validating Databases for Switchover by Using DGMGRL 12-11
u
pr tude
Performing a Switchover by Using DGMGRL 12-14
(
ON his S
Preparing for a Switchover Using SQL 12-15
R
B AR use t
Performing a Switchover by Using SQL 12-16
Considerations When Performing a Switchover to a Logical Standby
U IZ e to
H R icens
Database 12-17
T
Situations That Prevent a Switchover 12-18
A BE ble l
Failover 12-19
LIZ sfera
Types of Failovers 12-20
E
I C IA -tran
Failover Considerations 12-21
TR nonPerforming a Failover by Using Enterprise Manager 12-22
PA Performing a Failover to a Physical Standby Database 12-25
Performing a Failover to a Logical Standby Database 12-26
Performing a Manual Failover by Using DGMGRL 12-27
Reenabling Disabled Databases by Using DGMGRL 12-28
Quiz 12-29
Summary 12-31
13 Using Flashback Database in a Data Guard Configuration

Objectives 13-2
Using Flashback Database in a Data Guard Configuration 13-3
Overview of Flashback Database 13-4
Configuring Flashback Database 13-5
x
Configuring Flashback Database by Using Enterprise Manager 13-6

Using Flashback Database Instead of Apply Delay 13-8
Using Flashback Database and Real-Time Apply 13-9
Using Flashback Database After RESETLOGS 13-10
Flashback Through Standby Database Role Transitions 13-12
Using Flashback Database After Failover 13-13

Quiz 13-14
Summary 13-15
14 Enabling Fast-Start Failover

Objectives 14-2
Fast-Start Failover: Overview 14-3
s a
When Does Fast-Start Failover Occur? 14-4
) ha
Installing the Observer Software 14-5
l ฺ c om
Fast-Start Failover Prerequisites 14-6
m ai ฺ
Configuring Fast-Start Failover 14-7
9 @ g
u ide
i z 9 nt G
Step 1: Specify the Target Standby Database 14-8
u
pr tude
Step 2: Set the Protection Mode 14-9
(
ON his S
Step 3: Set the Fast-Start Failover Threshold 14-10
R
B AR use t
Step 4: (Optional) Set Additional Fast-Start Failover Properties 14-11
Setting the Lag-Time Limit 14-12
U IZ e to
H R icens
Configuring the Primary Database to Shut Down Automatically 14-14
T
Automatic Reinstatement After Fast-Start Failover 14-15
A BE ble l
Configuring Automatic Reinstatement of the Primary Database 14-17
LIZ sfera
Setting a Connect Identifier for the Observer 14-18
E
I C IA -tran
Setting an Observer Override 14-19
TR nonSetting Observer Reconnection Frequency 14-20
PA Step 5: Configure Additional Fast-Start Failover Conditions 14-21
Configuring Fast-Start Failover Conditions 14-23
Step 6: Enable Fast-Start Failover 14-24
Step 7: Start the Observer 14-25
Step 8: Verify the Configuration 14-27
Initiating Fast-Start Failover from an Application 14-28
Viewing Fast-Start Failover Information 14-30
Determining the Reason for a Fast-Start Failover 14-32
Prohibited Operations After Enabling Fast-Start Failover 14-33
Disabling Fast-Start Failover 14-34
Disabling Fast-Start Failover Conditions 14-36
Using the FORCE Option 14-37
Stopping the Observer 14-38
xi
Performing Manual Role Changes 14-39

Manually Reinstating the Database 14-40
Using Enterprise Manager to Enable Fast-Start Failover 14-41
Changing the Protection Mode and Disabling Fast-Start Failover 14-47
Using Enterprise Manager to Disable Fast-Start Failover 14-48
Using Enterprise Manager to Suspend Fast-Start Failover 14-49

Moving the Observer to a New Host 14-50
Quiz 14-51
Summary 14-53
15 Backup and Recovery Considerations in an Oracle Data Guard Configuration

Objectives 15-2
s a
Using RMAN to Back Up and Restore Files in a Data Guard Configuration 15-3
) ha
Offloading Backups to a Physical Standby 15-4
l ฺ c om
Restrictions and Usage Notes 15-5
m ai ฺ
9 @ g
Association and Accessibility of RMAN Backups 15-6
u ide
i z 9 nt G
Backup and Recovery of a Logical Standby Database 15-7
u
pr tude
Using the RMAN Recovery Catalog in a Data Guard Configuration 15-8
(
ON his S
Creating the Recovery Catalog 15-9
R
B AR use t
Registering a Database in the Recovery Catalog 15-11
Setting Persistent Configuration Settings 15-12
U IZ e to
H R icens
Setting RMAN Persistent Configuration Parameters on the Primary Database 15-14
T
Setting RMAN Persistent Configuration Parameters on the Physical Standby
A BE ble l
Database 15-16
LIZ sfera
Setting RMAN Persistent Configuration Parameters on the Other Standby
E
I C IA -tran
Databases 15-17
TR nonConfiguring Daily Incremental Backups 15-18
PA Recovering from the Loss of a Data File on the Primary Database 15-20
Using a Backup to Recover a Data File on the Primary Database 15-21
Using a Physical Standby Database Data File to Recover a Data File on the Primary
Database 15-22
Recovering a Data File on the Standby Database 15-24
Enhancements to Block Media Recovery 15-25
Executing the RECOVER BLOCK Command 15-27
Excluding the Standby Database 15-28
Quiz 15-29
Summary 15-31
xii
16 Enhanced Client Connectivity in a Data Guard Environment

Objectives 16-2
Connecting to the Appropriate Environment 16-3
Understanding Client Connectivity in a Data Guard Configuration 16-4
Preventing Clients from Connecting to the Wrong Database 16-5
Managing Services 16-6

Creating Services for the Data Guard Configuration Databases 16-7
Connecting Clients to the Correct Database 16-8
Creating the AFTER STARTUP Trigger for Role-Based Services 16-9
Configuring Service Names in the tnsnames.ora File 16-10
Configuring Role-Based Services Using Oracle Clusterware 16-11
Adding Standby Databases to Oracle Restart Configuration 16-13
Example: Configuring Role-Based Services 16-14
s a
Automatic Failover of Applications to a New Primary Database 16-15
) ha
Data Guard Broker and Fast Application Notification (FAN) 16-16
l ฺ c om
ai ฺ
Automating Client Failover in a Data Guard Configuration 16-17
m
Client Failover: Components 16-18
9 @ g
u ide
Client Failover: Best Practices 16-19
i z 9 nt G
Automating Failover for OCI Clients 16-20 u
pr tude
(
ON his S
Automating Failover for OLE DB Clients 16-22
R
B AR use t
Configuring OLE DB Clients for Failover 16-23
Automating Failover for JDBC Clients 16-24
U IZ e to
H R icens
Configuring JDBC Clients for Failover 16-25
Quiz 16-26 T
A BE ble l
Summary 16-28
LIZ sfera
E
I C IA -tran
TR17 Patching
non and Upgrading Databases in a Data Guard Configuration
PA Objectives 17-2
Data Guard Standby-First Patch Apply 17-3
Upgrading an Oracle Data Guard Broker Configuration 17-6
Upgrading Oracle Database in a Data Guard Configuration with a Physical Standby
Database 17-7
Upgrading Oracle Database in a Data Guard Configuration with a Logical Standby
Database 17-9
Using SQL Apply to Upgrade the Oracle Database 17-10
Requirements for Using SQL Apply to Perform a Rolling Upgrade 17-11
Performing a Rolling Upgrade by Using SQL Apply 17-12
Identifying Unsupported Data Types 17-13
Logical Standby: New Data Type Support for Oracle Database 12c 17-14
xiii
Performing a Rolling Upgrade by Using an Existing Logical Standby

Database 17-15
Performing a Rolling Upgrade by Creating a New Logical Standby Database 17-21
Performing a Rolling Upgrade by Using a Physical Standby Database 17-22
Rolling Upgrades Using DBMS_ROLLING and Active Data Guard 17-28
DBMS_ROLLING: Concepts 17-29

DBMS_ROLLING: Key Features 17-31
Database Rolling Upgrade: Specification and Compilation Stages 17-32
Specification Stage Examples 17-33
Compilation Stage Examples 17-34
Database Rolling Upgrade: Execution Stage 17-35
Quiz 17-36
Summary 17-38
s a
) ha
18 Optimizing a Data Guard Configuration
l ฺ c om
Objectives 18-2
m ai ฺ
9 @ g
u ide
Monitoring Configuration Performance by Using Enterprise Manager Cloud
Control 18-3
i z 9 nt G
u
pr tude
Optimizing Redo Transport Services 18-4
(
ON his S
Setting the ReopenSecs Database Property 18-5
R
B AR use t
Setting the NetTimeout Database Property 18-6
Optimizing Redo Transmission by Setting MaxConnections 18-7
U IZ e to
H R icens
Setting the MaxConnections Database Property 18-8
T
Compressing Redo Data by Setting the RedoCompression Property 18-9
A BE ble l
Delaying the Application of Redo 18-10
LIZ sfera
Setting the DelayMins Database Property to Delay the Application of Redo 18-11
E
I C IA -tran
Using Enterprise Manager to Delay the Application of Redo 18-12
TR nonOptimizing SQL Apply 18-13
PA Adjusting the Number of APPLIER Processes 18-14
Adjusting the Number of PREPARER Processes 18-15
Quiz 18-17
Summary 18-19
19 Oracle Database Exadata Cloud Service Overview

Objectives 19-2
Introducing Exadata Cloud Service 19-3
Service Configuration Options 19-5
Service Connection Options 19-7
Service Architecture 19-9
Service Availability 19-10
xiv
Data Security 19-11

Management Responsibilities 19-12
Storage Configuration 19-14
Storage Management Details 19-16
Simple Web-Based Provisioning 19-17
Simple Web-Based Management 19-18

REST APIs 19-19
Backup and Recovery 19-20
Migrating to Exadata Cloud Service 19-22
Summary 19-23
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
xv
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
I t d ti
Introduction to
t Oracle
O l Data
D t Guard
G d
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Copyright © 2014, IZ and/or
Oracle
e titsoaffiliates. All rights reserved.
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
Objectives
After completing this lesson, you should be able to:

• Describe the basic components of Oracle Data Guard

• Explain the differences between physical and logical
standby databases
• Explain the benefits of implementing Oracle Data Guard
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
Oracle Database 12c: Data Guard Administration 1 - 2

What Is Oracle Data Guard?
Primary Standby
database Redo transport database
Oracle Net
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr Database de
Database ( t u
R ON his Scopy
B AR use t
U
Oracle
R
H icen s
T
E le l
Oracle Data Guard A
is B
a b component of an integrated Oracle Database High Availability
central
L I Z r a
(HA) solutionEset that helps
A n s fe organizations ensure business continuity by minimizing the
I C I
various kinds
- t a and unplanned down time that can affect their businesses.
of rplanned
A TR Data
Oracle n onGuard is a management, monitoring, and automation software infrastructure that
P works with a production database and one or more standby databases to protect your data
against failures, errors, and corruptions that might otherwise destroy your database. It
protects critical data by providing facilities to automate the creation, management, and
monitoring of the databases and other components in a Data Guard configuration. It
automates the process of maintaining a copy of an Oracle production database (called a
standby database) that can be used if the production database is taken offline for routine
maintenance or becomes damaged.
In a Data Guard configuration, a production database is referred to as a primary database.
A standby database is a synchronized copy of the primary database. By using a backup copy
of the primary database, you can create from 1 to 30 standby databases. The standby
databases, together with the primary database, make up a Data Guard configuration.
All Data Guard standbyy databases can enable up-to-date read access to the standby y
database while redo being received from the primary database is applied. This makes all
standby databases excellent candidates for relieving the primary database of the overhead of
supporting read-only queries and reporting.

Types of Standby Databases
• Physical standby database:

– Is identical to the primary database on a block-for-block

basis
– Is synchronized
y with the p
primary
y database through
g
application of redo data received from the primary database
– Can be used concurrently for data protection and reporting
• Logical standby database
– Shares the same schema definition a
– Is kept synchronized with the primary database by ) has
o m
ilฺc
transforming the data in the redo received from the primary
a
database into SQL statements and then executing
@ gmthe SQL
i d eฺ
statements
i z 99 nt Gu
pru tudreporting,
– Can be used concurrently for data protection,
( e and
N S
database upgrades RO is
R se th
A
B ou
I Z
U and/or
Copyright © 2014, Oracle tits affiliates. All rights reserved.
R s e
T H icen
Physical Standby A BE ble l
Database
E LIZdatabase
A physical standby s f e ra is physically identical to the primary database, with on-disk
C
databaseI Astructures
t r a nthat are identical to the primary database on a block-for-block block for block basis. The
T RI nstandby
physical o n- database is updated by performing recovery using redo data that is received
PAfrom the primary database. Oracle Database12c enables a physical standby database to
receive and apply redo while it is open in read-only mode.
Logical Standby Database
A logical standby database contains the same logical information (unless configured to skip
certain objects) as the production database, although the physical organization and structure
of the data can be different. The logical standby database is kept synchronized with the
primary database by transforming the data in the redo received from the primary database
into SQL statements and then executing the SQL statements on the standby database. This is
done with the use of LogMiner technology on the redo data received from the primary
database. The tables in a logical standby database can be used simultaneously for recovery
and for other tasks such as reporting, summations, and queries.
Note: For more information about LogMiner,
LogMiner see Using LogMiner to Analyze Redo Log Files
in Oracle Database Utilities12c Release 1 (12.1) documentation.

Types of Standby Databases
• Snapshot standby database:

– Is a fully updatable standby database

– Is created by converting a physical standby database
– Can be used for updates, but those updates are discarded
before the snapshot standby database is converted back into
a physical standby database
– Can be used for testing
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
Snapshot Standby A BE ble l
Database
E LIZ database
f e ra is a database that is created by converting a physical standby
A snapshot standby
C
databaseI r a ns standby database. The snapshot standby database receives redo
Ainto atsnapshot
T RIthe nprimary
from o n- database, but does not apply the redo data until it is converted back into a
PAphysical standby database. The snapshot standby database can be used for updates, but
those updates are discarded before the snapshot standby database is converted back into a
physical standby database. The snapshot standby database is appropriate when you require
a temporary, updatable version of a physical standby database.

Types of Data Guard Services
Data Guard provides three types of services:

• Redo transport services

• Apply services
– Redo Apply
– SQL Apply
• Role management services
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A Bservices
The following types
L I Z erab are available with Data Guard:
of
• Redo transport
A f
E nsservices: Control the automated transmittal of redo information from
the
t I
IC n-tr
e p
primary
a y a
database to o
onee o
or more
o e sta
standby
dby databases o or aarchival
c a dest
destinations.
at o s
R
T• Applyno services: Control when and how data is applied to the standby database.
PA - Redo Apply: Technology used for physical standby databases. Redo data is
applied on the standby database by using Oracle media recovery.
- SQL Apply: Technology used for logical standby databases. The received redo
data is first transformed into SQL statements, and then the generated SQL
statements are executed on the logical standby database.
• Role management services: A database operates in one of two mutually exclusive
roles: primary or standby. Role management services operate in conjunction with redo
transport services and apply services to change these roles dynamically as a planned
transition (called a switchover operation) or as a result of database failure due to a
failover operation.

Role Transitions: Switchover and Failover
Oracle Data Guard supports two role-transition operations:

• Switchover
– Planned role reversal
– Used for OS or hardware maintenance
• Failover
– Unplanned role reversal
– Emergency use
a
– Zero or minimal data loss (depending on choice of data-
) has
protection mode) om
a
– Can be initiated automatically when fast-start failover ilฺc
is
enabled @ gm ideฺ
9 u 9 nt G
u i z
( pr tude
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
Data Guard enables A BEto change
you l e
b the role of a database dynamically by issuing SQL
L I Z r a
e of the Data Guard broker’s interfaces. Data Guard supports two
statements or
A Eby using
n s feither
I
C n-tra
role-transition
I operations:
R no to one
T• Switchover: The switchover feature enables you to switch the role of the primary
PA database of the available standby databases. The chosen standby database
becomes the primary database, and the original primary database then becomes a
standby database.
• Failover: You invoke a failover operation when a catastrophic failure occurs on the
primary database. During a failover operation, the failed primary database is removed
from the Data Guard environment,
environment and a standby database assumes the primary
database role. You invoke the failover operation on the standby database that you want
to fail over to the primary role. You can also enable fast-start failover, which allows Data
Guard to automatically and quickly fail over to a previously chosen synchronized
standby database.
Note: Fast-start failover is discussed in detail in the lesson titled “Enabling Fast-Start
Failover.”

Databases that are disabled after a role transition are not removed from the broker
configuration, but they are disabled in the sense that the databases are no longer managed
by the broker. To reenable broker management of these databases, you must reinstate or re-
create the databases.
Note: See the lesson titled “Performing Role Transitions” for detailed information.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Oracle Data Guard Broker Framework

Oracle
Management
Server
Repository
Agent Agent
Primary Standby
database database
s a
) ha
Data Data
Guard Guard
broker Enterprise Manager b k
broker
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tudclient e
(
CLI management
R ON his S
B AR use t
U
Oracle
H icenR s
T l
The Oracle Data GuardA BEbroker l e
b distributed management framework that automates and
is a
L I Z r a
centralizes the
A
creatingIthe Datara
sfemaintenance,
E creation,
n
Guard
and monitoring of Data Guard configurations. After
configuration, the broker monitors the activity, health, and availability
of R C n-int the configuration.
allIsystems
T no of using Oracle Data Guard broker include:
PAThe benefits
• Enhanced disaster protection
• Higher availability and scalability with Oracle Real Application Clusters (Oracle RAC)
Databases
• Automated creation of a Data Guard configuration
g
• Easy configuration of additional standby databases
• Simplified, centralized, and extended management
• Simplified switchover and failover operations
• Fast Application Notification (FAN) after failovers
• Built-in monitoring and alert and control mechanisms
• Transparency to the application

Choosing an Interface for Administering

a Data Guard Configuration
• Data Guard broker configuration:
– DGMGRL command-line interface

– Enterprise Manager Cloud Control
– SQL commands to query data dictionary views
• Non–Data Guard broker configuration:
– SQL commands
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
You can use Oracle A BE blManager
Enterprise e Cloud Control or the Data Guard broker’s own
L I Z r a
E nsfe interface (DGMGRL) to take advantage of the broker’s
specialized command-line
A
I C I
management
tra
capabilities.
-
T R
Enterprise n
oManager Cloud Control provides a web-based interface that combines with the
PAbroker’s ncentralized management and monitoring capabilities so that you can easily view,
monitor, and administer primary and standby databases in a Data Guard configuration.
You can also use DGMGRL to control and monitor a Data Guard configuration. You can
perform most of the activities that are required to manage and monitor the databases in the
configuration from the DGMGRL prompt or in scripts.
If you do not create a Data Guard broker configuration, you can manage your standby
databases by using SQL commands.

Oracle Data Guard: Architecture

Primary
(Overview)
MRP or Standby
database
LSP
transactions database
LNSn RFS
Redo
buffer
LGWR (Real-time
Oracle net
apply)
Standby Backup
Online redo logs a
s
) ha
redo
logs
g Reports
ARC0 l ฺ c om
Gap
m ai ฺ
ARC0 resolution
9 @ g
u ide
i z 9 nt G
u
pr Archived de redo
( t u
Archived redo
logs R ON his S logs
B AR use t
U
Oracle
H icenR s
T l
Oracle Data Guard A BE bthe
leverages l e existing database redo-generation architecture to keep the
L I Z r a
standby databases
A E ninsthe feconfiguration synchronized with the primary database. By using the
existing Iarchitecture,
r a Oracle Data Guard minimizes its impact on the primary database.
I C - t
A TR Data
Oracle n onGuard uses several processes to achieve the automation that is necessary for
P disaster recovery and high availability. Some of these processes support Oracle Database in
general, and other processes are specific to a Data Guard environment.

Primary Database Processes

Primary
MRP or Standby
database
LSP
NSSn RFS
Redo
buffer
LGWR (Real-time
Oracle net
apply)
Standby Backup
Online redo logs a
s
) ha
redo
logs
g Reports
ARCn l ฺ c om
Gap
m ai ฺ
ARCn resolution
9 @ g
u ide
i z 9 nt G
u
pr Archived de redo
( t u
Archived redo
B AR use t
U
Oracle
H icenR s
T l
A BEData l e
L I Z erab
On the primary database, Guard uses the following processes:
• Log writer
I A E (LGWR):
a n sf LGWR collects transaction redo information and updates the online
R ICedo
redo logs.
ogs
n - tr
For
o eac
each sy
synchronous
c o ous (S (SYNC) C) sta
standbydby database, LGWR G passes tthee redo
edo to
T an nNSS o (Network Server SYNC) process, which ships the redo directly to the remote file
PA server (RFS) process on the standby database. LGWR waits for confirmation from the
NSS process before acknowledging the commit. For asynchronous (ASYNC) standby
databases, independent redo transport slave processes (TTnn) read the redo from
either the redo log buffer in memory or the online redo log file, and then ship the redo to
its standby database. Other than starting the asynchronous TTnn processes, LGWR has
no interaction with any asynchronous standby destination.
• Archiver (ARCn): The ARCn process creates a copy of the online redo log files locally
for use in a primary database recovery operation. ARCn is also responsible for shipping
redo data to an RFS process at a standby database and for proactively detecting and
resolving gaps on all standby databases. There can be 30 archiver processes. The
default value is four.

Standby Database Processes

Primary
MRP or Standby
database
LSP
NSSn RFS
Redo
buffer
LGWR (Real-time
Oracle net
apply)
Standby Backup
Online redo logs a
s
) ha
redo
logs
g Reports
ARCn l ฺ c om
Gap
m ai ฺ
ARCn resolution
9 @ g
u ide
i z 9 nt G
u
pr Archived de redo
( t u
Archived redo
B AR use t
U
Oracle
H icenR s
T l
A BEData l e
L I Z erab
On the standby database, Guard uses the following processes:
• Remote
I A Efile server
a n sf (RFS): RFS receives redo information from the primary database
R IC
and
a d ca
can
n - tr e redo
write
te the
t edo into to standby
sta dby redo
edo logs
ogs o or d
directly
ect y to a archived
c ed redo
edo logs.
ogs Eachac
T NSSn
PA Note: noThe
and ARCn process from the primary database has its own RFS process.
use of standby redo logs is discussed in more detail in the lesson titled
“Creating a Physical Standby Database by Using SQL and RMAN Commands.”
• Archiver (ARCn): The ARCn process archives the standby redo logs.
• Managed recovery (MRP): For physical standby databases only, MRP applies archived
redo log information to the physical standby database. If you start managed recovery
with
ith th
the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE SQL statement, t t t
this foreground session performs the recovery. If you use the optional DISCONNECT
[FROM SESSION] clause, the MRP background process starts. If you use the Data
Guard broker to manage your standby databases, the broker always starts the MRP
background process for a physical standby database.
• Logical standby (LSP): For logical standby databases only, LSP controls the
application of archived redo log
g information to the logical
g standby
y database.

Physical Standby Database:

Redo Apply Architecture
Production Physical standby
database database
Redo Redo
transport apply
Redo
stream s a
m ) ha
ฺco
Backup
a il
@ gm ideฺ
i z 99 nt Gu
u de
prPhysical
Primary (
N is Sdatabase tu standby
database O
A RR se th
I Z B ou
R U and/or
Copyright © 2014, Oracle
e tits affiliates. All rights reserved.
H icen s
T l
A BEstandby l e
L I Z erab
The Data Guard physical Redo Apply architecture consists of:
I A E (primary)
• A production
a n sf database, which is linked to one or more standby databases (up
R IC
to 30) that
t
n
at
- t r
are
a e identical
de t ca copies
cop es o of tthe
epproduction
oduct o database
database. The e limitt o
of 30 sta
standby
dby
T databaseso is imposed by the LOG_ARCHIVE_DEST_n parameter. In Oracle Database
PA 12cnRelease 1 (12.1), the maximum number of destinations is 31. One is used as the
local archive destination, leaving the other 30 for uses such as the Far Sync or standby
databases.
• The standby database, which is updated by redo that is automatically shipped from the
primary database. The redo can be shipped as it is generated or archived on the primary
database Redo is applied to each standby database by using Oracle media recovery
database. recovery.
During planned down time, you can perform a switchover to a standby database. When
a failure occurs, you can perform a failover to one of the standby databases. The
physical standby database can also be used to back up the primary database.

Logical Standby Database:

SQL Apply Architecture
Production Logical standby
database database
Redo SQL
transport Apply
Transform redo
information into s a
SQL ) ha
l ฺ c om
m ai ฺ
9 @ u ide
g Reports
i z 9 nt G
u
prLogical destandby
Primary ( t u
database
R ON his Sdatabase
B AR use t
U
Oracle
H icenR s
T l
In a logical standby A BE bconfiguration,
database l e Data Guard SQL Apply uses redo information
L I Z r a
shipped fromEthe primary
A n s fesystem. However, instead of using media recovery to apply changes
I C I
(as in the physical
- t r astandby database configuration), the redo data is transformed into
R noSQL
equivalent
T n statements by using LogMiner technology. These SQL statements are then
A
P applied to the logical standby database. The logical standby database is open in read/write
mode and is available for reporting capabilities. By opening the logical standby database in
read/write mode, additional reporting structures such as indexes or materialized views can be
created that do not exist in the primary database.
A logical standby database can be used to perform rolling database upgrades, thereby
minimizing down time when upgrading to new database patch sets or full database releases
releases.

Automatic Gap Detection and Resolution

Primary
MRP or Standby
database
LSP
LNSn RFS
Redo
buffer
LGWR (Real-time
Oracle net
apply)
Standby
Online redo logs Backup a
s
) ha
redo
logs
g Reports
p
ARC0 l ฺ c om
ARCH ping
m ai ฺ
ARC0
9 @ g
u ide
Redo to
i z 9 nt G
resolve u
pr tArchived de redo
gap ( u
Archived redo
B AR use t
Copyright © 2014,U IZ and/or
Oracle
H icen R s
T l
If connectivity is lost A BE bthe
between l e primary database and one or more standby databases, redo
L I Z r a
data that is being
A E generatedn s fe on the primary database cannot be sent to those standby
I C I
databases. When
- t r a
a connection is reestablished, Data Guard automatically detects that there
are
T Rmissing
n o n
archived redo log files (referred to as a gap), and then automatically transmits the
A
P missing archived redo log files to the standby databases by using the ARCn processes. The
standby databases are synchronized with the primary database without manual intervention
by the DBA.

Data Protection Modes
Select the mode to balance cost, availability, performance, and

data protection:
• Maximum protection
• Maximum availability
• Maximum performance
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
Data Guard provides A BE high-level
three b l e modes of data protection that you can configure to
L I Z r a
A n s feperformance, and transaction protection. You can configure the
balance cost,Eavailability,
I C I
Data Guard
- t r a
environment to maximize data protection, availability, or performance.
A TR noProtection
Maximum n
P This protection mode guarantees that no data loss occurs if the primary database fails. For
this level of protection, the redo data that is needed to recover each transaction must be
written to both the local online redo log and the standby redo log (used to store redo data
received from another database) on at least one standby database before the transaction
commits. To ensure that data loss does not occur, the primary database shuts down if a fault
preventst it from
f writing
iti its
it redo
d stream
t tto att least
l t one remote
t standby
t db redo
d log.
l

Maximum Availability
This protection mode provides the highest possible level of data protection without
compromising the availability of the primary database. As with maximum protection mode, a
transaction does not commit until the redo needed to recover that transaction is written to the
local online redo log and to at least one remote standby redo log. Unlike maximum protection
mode, the primary database does not shut down if a fault prevents it from writing its redo
stream to a remote standby redo log. Instead, the primary database operates in an
unsynchronized mode until the fault is corrected and all the gaps in the redo log files are
resolved. When all the gaps are resolved and the primary database is synchronized with the
standby database, the primary database automatically resumes operating in maximum
availability mode.
This mode guarantees that no data loss occurs if the primary database fails, but only if a
second fault does not prevent a complete set of redo data from being sent from the primary
database to at least one standby database.
Maximum Performance (Default)
s a
) ha
The default protection mode provides the highest possible level of data protection without
affecting the performance of the primary database. This is accomplished by allowing a
l ฺ c om
transaction to commit as soon as the redo data needed to recover that transaction is written to
m ai ฺ
the local online redo log. The primary database’s redo data stream is also written to all
@ g ide
ASYNC standby databases and is written asynchronously with respect to the commitment of
9 u
the transactions that create the redo data.i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Data Guard Operational Requirements:

Hardware and Operating System
Primary database systems and standby database systems
may have different:

• CPU architectures
• Operating systems
• Operating system binaries (32-bit or 64-bit)
• Oracle Database binaries (32-bit or 64-bit)
s a
Many restrictions exist. ) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A
Hardware and OperatingB b
L IZ feraSystem Requirements
Erequirements
These are the
A n s for Data Guard:
•RIC
I
The hardware
a
-tr for the primary and standby database systems can be different different. For
T n o n
PA example, the
differ.
number of CPUs, the memory size, and the storage configuration can
• The operating systems for both databases and operating system binaries can be
different.
If the primary and standby databases are both on the same server, you must ensure that the
operating
ope at g syste
system e
enables
ab es you to mount
ou t ttwo
o databases with
t tthe
e sa
same
e name
a eoon tthe
e sa
samee
system simultaneously. Certain parameters must be specified to support this configuration, as
discussed in the lesson titled “Creating a Physical Standby Database by Using SQL and
RMAN Commands.”
Refer to My Oracle Support notes 413484.1, 395982.1, and 414043.1 for additional
information.

Data Guard Operational Requirements:

Oracle Database Software
• The same release of Oracle Database Enterprise Edition
must be installed for all databases except when you

perform a rolling database upgrade by using a logical
standby database.
• If any database uses ASM or OMF, all databases should
use the same combination.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
• You must install A B
the same b release of Oracle Database Enterprise Edition for the primary
L I Z r a
database
A fe databases in your Data Guard configuration. Oracle Data
E andnallsstandby
I C I
Guard
- t r a only as a feature of Oracle Database Enterprise Edition; it is not
is available
TR available
non with Oracle Database Standard Edition.
PA Note: See the documentation titled Oracle Data Guard Concepts and Administration for
information about simulating a standby database environment when using Oracle
Database Standard Edition.
• If you use Oracle Automatic Storage Management (ASM) and Oracle Managed Files
(OMF) in a Data Guard configuration, you should use ASM and OMF symmetrically on
th primary
the i and
d standby
t db d database.
t b If any ddatabase
t b iin your D
Data
t GGuard
d configuration
fi ti
uses ASM, OMF, or both, then every database in the configuration should use the same
combination (that is, ASM, OMF, or both).
Note: An exception to this guideline is if you are using Data Guard as a technique to
migrate to ASM and/or OMF.

Benefits of Implementing
Oracle Data Guard
Oracle Data Guard provides the following benefits:
• Continuous service during disasters or crippling data

failures
• Complete data protection against corruption and data loss
• Elimination of idle standby systems
• Flexible configuration of your system to meet requirements
for business protection and recovery
a
• Centralized management ) has
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BE With
• ContinuousZservice: b l ethe use of switchover and failover between systems, your
business L I r a
feneed to halt because of a disaster at one location.
A E doesnnot s
• IC I
Complete
Co
- a pprotection:
p etetrdata otect o Data ata Guard
Gua d guarantees
gua a tees tthat at tthere
e e iss no
o data loss
oss a and
d
R n
no a safeguard against data corruption and user errors. Redo data is validated
T provides
PA when applied to the standby database.
• Elimination of idle standby systems: Standby databases can be used for reporting
and ad hoc queries in addition to providing a safeguard for disaster recovery. You can
also use the physical standby database to off-load backups of the primary database.
• Flexible configurations: You can use Data Guard to configure the system to your
needsd b
by using
i ththe protection
t ti modes d andd severall ttunable
bl parameters.
t
• Centralized management: You can use Enterprise Manager Cloud Control to manage
all configurations in your enterprise.

Quiz
Which of the following are types of standby databases?

a. Physical
b. Primary
c Logical
c.
d. Snapshot
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
I ferab
Answer: a, c, d Z
L
A E ns
I
IC n-tra
T R no
PA

Quiz
What is the maximum number of standby databases supported

by the Data Guard Broker?

a. 10
b 20
b.
c. 30
d. 40
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: c
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Summary
In this lesson, you should have learned how to:

• Describe the basic components of Oracle Data Guard

• Explain the differences between physical and logical
standby databases
• Explain the benefits of creating a Data Guard environment
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Practice 1: Overview
This practice covers the following topics:

• Introducing the lab environment

• Starting and stopping a virtual machine
• Starting and stopping the Oracle Management Server
• Starting and stopping the Oracle Agent
• Accessing Oracle Enterprise Manager
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
Creating
C ti a Physical
Ph i l Standby
St db Database
D t b by
b
Using Enterprise Manager Cloud Control
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
Objectives
After completing this lesson, you should be able to use Oracle

Enterprise Manager Cloud Control 12c to:

• Create a Data Guard broker configuration
• Create a physical standby database
• Verify a Data Guard configuration
• Edit database properties related to Data Guard
• Test a Data Guard configuration a
s
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Prerequisites for Using Oracle Enterprise

Manager Cloud Control 12c
To use Oracle Enterprise Manager Cloud Control 12c for Data
Guard, the following prerequisite steps must be performed:

• Install Oracle Enterprise Manager Cloud Control 12c
• Install agents on each host in the Data Guard environment
• Install Oracle Database software binaries on each host in
the Data Guard environment
• Deploy the Oracle Database plug-in to each remote agent
a
• Verify the agent status on each host ) has
om
• Define preferred credentials for each host
a ilฺc
• Create or identify the primary database gm ideฺ
z 9 9@ t Gu
p r ui den
O N ( is Stu
A RR se th
I Z B ou
R U and/or
H icen s
T l
Oracle EnterpriseZ A BE Cloud
Manager b l e Control 12c can automate much of the process of creating
L I
both physicalEand logical r a
festandby databases. Before using Oracle Enterprise Manager for a
I
Data GuardA a n
environment,
s some prerequisite steps must be performed. At a minimum, Oracle
I C
R noManager
Enterprise n - t r should be installed and configured on a server host. For each additional
A T
P server that is to participate in a Data Guard environment, the software binaries for both the
Oracle Database and the Oracle Enterprise Manager agent must be installed. These are
installed into distinct Oracle Home locations. A default installation of the Oracle Enterprise
Manager agent does not install plug-ins to the agent. Deploy the latest version of the Oracle
Database plug-in to each agent and verify the status of the agents. Create a basic security
g
configuration byy defining
g named credentials for normal and pprivileged
g users for the host target
g
type. Define individual target credentials for each host by referencing the named credentials.

Accessing the Add Standby Database Wizard

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A
The screenshot inZthe Bslide b the home page for the primary database, with the top level
shows
menu structureL I r a
fe the following items: Oracle Database, Performance, Availability,
E containing
n s
Schema,IA
R IC n-tra
and Administration.
T access
To nothe
PAselect Add
Add Standby Database wizard, navigate to the primary database target and
Standby Database from the Availability menu. The Add Standby Database menu
item is the only Data Guard option on the Availability menu if a Data Guard configuration does
not already exist. After a Data Guard configuration is defined, the Availability menu will also
contain menu items for Data Guard Administration, Data Guard Performance, and Verify Data
Guard Configuration.
Before
B f you invoke
i k th
the Add St
Standby
db DDatabase
t b wizard,
i d verify
if th
thatt th
the primary
i d
database
t b
instance was started with a server parameter file (SPFILE) and that archiving is enabled.
Note: Actual webpages may differ with each version of Oracle Enterprise Manager. The
screenshots used in this lesson were taken with Oracle Enterprise Manager Cloud Control
12c Release 2 with patch set update (PSU) two installed (12.1.0.2.2).

Accessing the Add Standby Database Wizard

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
The above webpage A BE bshows
snippet l e the Add Standby Database wizard after logging in for the
L I Z r a
first time. It provides
A E nthe s fefollowing options:
• IC I
Create
C eate a new
- tera physical
p ys ca sta
standby
dby database
R
T• Create n
no a new logical standby database
PA • Manage an existing standby database with Data Guard broker
• Create a primary database backup only
If you are not connected to the primary database when you select Add Standby Database
from the Availability menu, a Database Login window appears. You will then be able to select
from an existing named credential, or you can create a new credential. You must be
connected to the primary database with SYSDBA credentials to use the Add Standby
Database wizard.

Creating a New Standby Database
The standby database creation process performs the following:

• Performs an online backup (or optionally uses an existing

backup) of the primary database control file, datafiles, and
archived redo log files
• Transfers the backup pieces from the primary host to the
standby host
• Creates other needed files (for example, initialization and
password files) on the standby host a
• Restores the control files,
files datafiles
datafiles, and archived redo log ) has
om
files to the specified locations on the standby host ailฺc
• Adds online redo logs and other files to the 9 gm ideฺ
standby
@
database as needed i z 9 nt Gu
( pru tude
• Configures the recovered database ON assaSphysical or logical
R h i
R
A use t
Z B
I and/or
UOracle
Copyright © 2014,
R e titsoaffiliates. All rights reserved.
H icen s
T l
The Add StandbyZ A BE wizard
Database l e
b can create both physical and logical standby databases.
L I r a
fe in the slide, the wizard will prepare the primary database to
In addition toEthe task listed
A
support IData Guard a n s
operations including additional tasks such as:
I C - t r
A T•R Creating
n on standby redo logs on the primary if needed
P • Starting the Data Guard broker process
• Creating the Data Guard broker configuration files
• Adding primary and standby database to the Data Guard broker configuration
• Enabling the Data Guard broker configuration
• Adjusting initialization parameters such as LOG_ARCHIVE_CONFIG,
LOG ARCHIVE CONFIG
LOG_ARCHIVE_DEST_n, and STANDBY_FILE_MANAGEMENT.

Creating a Physical Standby Database

Step 1: Backup Type
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
The screenshot inZthe A Bslide b step one of six steps in creating a physical standby
shows
database. Step L I r a
fe the type of backup to be used for creating the standby
A E onendefines
s
I C I
database—either
- t r a
one that you create by performing an online backup, or an existing backup.
A TR Guard
Data
n onuses Oracle Recovery Manager (RMAN) to perform the backup.
P The online backup option can be performed using a direct copy approach that does not
require staging areas, or it can utilize staging directories. The staging directories can be
retained for future standby database creations, or they can be deleted after the standby
database is created. A backup performed into a staging area can be compressed to reduce
file size and transfer time, but it may also slow down datafile backup and restoration.
The existing
Th i ti bbackup
k option
ti requires
i a llevell 0 (f
(full)
ll) or llevell 1 (i
(incremental)
t l) RMAN b
backup
k ththatt
is typically performed as part of a regular backup strategy. You will be prompted for both the
existing RMAN backup location and a new staging area location on the primary database host
if you select this option.
Note: The actual Enterprise Manager webpages will vary depending on the options selected.
For example, if the Add Standby Database wizard is used to create a logical standby
y SQL Apply.
database, this step would also show all of the tables that are unsupported by y


Step 2: Backup Options
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
The screenshot inZthe A Bslide b step two of six steps in creating a physical standby
shows
fe “Backup Options.” For an online direct backup, the degree of
A E twonisstitled
I C I
parallelism
- t r a as a backup option. In this step, you must supply the primary host
is specified
R nousing
credentials,
T n either an existing named credential or by creating a new credential. If the
A
P primary database does not currently have standby redo logs, this step will also require that
they be created. Oracle Enterprise manager will automatically determine the correct size and
number of groups to create for standby redo logs. You can select the option to use Oracle-
managed files (OMF) for the standby redo log files or you can explicitly name and locate the
standby redo logs that will be created on the primary database.
For backup types other than online direct backups
backups, you supply the staging area locations
locations,
existing RMAN backup locations, backup compression features, and whether to retain the
backups for future use depending on which backup method was chosen.


Step 3: Database Location
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
The screenshot inZthe A Bslide b step three of six steps in creating a physical standby
shows
L I r a
e “Database Location.” This step contains three sections. In the
E threensisftitled
database. Step
A
StandbyIDatabase r aAttributes section, you define the instance name of the standby database
and I C
Rwhether - t
nthe standby database will use file system storage or Automatic Storage
A T n o
P Management (ASM). In the Standby Database Location section, you define the host name for
the server to which the standby database will be transferred and the existing Oracle home
software location on that server. In the Standby Host Credentials section, you specify host
credentials to be used on the standby server machine (you can use existing named
credentials or you may create new credentials).


Step 4: File Locations
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
The screenshot inZthe A Bslide b step four of six steps in creating a physical standby
shows
fe “File Locations.” This step contains two sections, Standby
A E fournisstitled
Database
I C I - t r a and Listener Configuration. If a file system was selected in step three
File Locations
as
T Rthe database
n o n storage location, the Standby Database File Location section of this window
A
P allows you to keep the same files names and locations as the primary database uses, or
allows you to create a new directory structure compliant with Oracle Optimal Flexible
Architecture (OFA). If ASM was chosen in step three as the database storage location, Oracle
Enterprise Manager will prompt you to log in to the ASM instance to determine available ASM
disk groups and allow you to specify which ASM disk groups to use for storage. With either
p
option selected, a Customize button in this section allows yyou to view all individual datafiles,
tempfiles, logfiles, control files, directory objects, and external files, and to define specific
names and locations.
If staging directories had been selected earlier, an additional section, Standby Host Backup
File Access, appears. This allows the specific directory on the standby host machine to be
defined along with the file transfer method, either HTTP/S or FTP. There is also an option for
the standby database to access the files directly from a shared directory such as an NFS
mount.
mount

In the Listener Configuration section of this step, you specify the listener name and port
number for the listener. A new listener will be created if the specified listener name and port
does not already exist.
Note: When the Next button is clicked,, a warning
g message
g will appear
pp if any
y files for external
tables located on the primary database host already exist on the standby database host.
These files will be overwritten by the Add Standby Database wizard.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA


Step 5: Configuration
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
The screenshot inZtheA Bslide b step five of six steps in creating a physical standby
shows
L
database. Step
I r a
fe “Configuration.” This step contains four sections. The first section,
A E fiveParameters,
StandbyIDatabase
is titled
n s
I C - t r a prompts for the standby DB_NAME parameter (for logical
A TR ndatabases
standby n only), standby DB_UNIQUE_NAME parameter, STANDBY_ARCHIVE_DEST
oand
P parameter, FAST_RECOVERY_AREA_SIZE parameter. You can also select to delete
applied archive redo logs when space is needed.
The Standby Database Monitoring Credentials section of this step allows you to override
normal default monitoring credentials and specify SYSDBA credentials for monitoring. This is
required for a mounted standby database.
The D
Th Data
t GGuarddBBroker
k section
ti iis only
l di
displayed
l d if no existing
i ti b broker
k configuration
fi ti iis ffound.
d It
allows you to delete the broker configuration after the standby database is created if desired.
If there is an existing broker configuration, this section is hidden.
The Data Guard Connect Identifiers section allows you to specify connect identifiers for both
the primary database and standby database. You can use Enterprise Manager connect
descriptors that are explicitly coded into the LOG_ARCHIVE_DEST_n parameters, or specify
g net service name that can be used by
an existing y all databases. If a connect identifier for the
primary database has already been created previously for other standby databases, you will
not be prompted for it again here.


Step 6: Review
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
The screenshot inZthe A Bslide b step six of six steps in creating a physical standby
shows
fe “Review” and it provides a recap of many of the settings entered
A E six isnstitled
I C I
on the previous
- t r a
five steps. The Standby Database Storage section can be expanded to show
all
T Rindividual
n o ndatafiles, tempfiles, logfiles, control files, directory objects, and external files that
A
P will be created on the standby database host. If everything is satisfactory, click Finish to
create a job to perform the tasks.
Note: There is no option to schedule the creation job to run at a future time. It will be an
immediate job submitted when the Finish button is clicked.


Job Activity
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
When you click the A BEbutton
Finish l e
b step six of the Add Standby Database wizard, an Oracle
in
L I Z r a
Enterprise Manager
E njob s feis created and an information dialog window appears that provides a
URL linkIAto viewrthe a The screenshot in the slide shows the job activity window for the job
job.
I C
Rwasncreated.
that - t
n The default refresh mode for this window is manual refresh. Change the
A T o
P auto refresh option to one of the available time frequency choices to see changes happen
while they are in progress or manually click the refresh icon when desired. The Log Report
button will show the output log for all SQL*Plus, RMAN, and Listener Control Utility
(lsnrctl) utility commands used. The Debug button will provide more details in the logs,
including the actual RMAN script that was used to duplicate the primary database.


Job Task Details
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
The screenshot inZthe A Bslide b the job activity window. The scroll bar on the right side of
shows
the window has L I r a
fe down to show individual job steps of the Create Standby
A E been n smoved
Database
I C I job. Each
- t r a or job step shows the target machine that the job step was run on,
row
the
T Rstatusnoofnthe job step, the start time of the job step, the end time of the job step, and a
A
P calculated elapsed time for the job step.

Data Guard Administration Page

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
After a Data Guard A BE blehas
configuration been defined, the Availability menu contains both Add
L I Z r a
e Guard Administration items. Clicking either one while on the
Standby Database
A E and n s fData
primary Idatabase r a page opens the Data Guard administration page.
home
I C - t
A TRscreenshot
The n on in the slide shows the Data Guard administration page. The Overview section
P on this page displays the Data Guard status for the configuration, the protection mode, and
whether Fast-Start Failover has been enabled. The Primary Database section of this page
shows the hostname of the primary database, current log sequence number, and an option to
edit primary database properties. The Standby Databases section of this page shows all
standby databases that are configured for this environment along with properties about each
database such as name
database, name, host machine on which it resides
resides, status
status, role
role, whether real-time
real time
query is enabled, last received redo log, last applied redo log, and an estimated failover time
for that particular standby database.
A chart on the Data Guard Administration page graphs both transport lag and apply lag for
each standby database. Transport lag is the time difference between the last update on the
primary database and the last received redo on the standby database. Apply lag is the time
difference between the last update on the primary database and the last applied redo on the
standby
t db d database.
t b A
An Add St
Standby
db DDatabase
t b b
button
tt on thi
this page iis used
d tto create
t additional
dditi l
standby databases, and links at the bottom navigate to performance monitoring and
verification.

Verifying Configuration
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
The screenshot inZthe A Bslide b the progress indicator of the Verify Configuration
shows
administrative L I r a
e be invoked from the Data Guard administration page. The verify
thatfcan
A Etask n s
I C I
configuration task
- t r a
performs a series of validation checks on the Data Guard configuration,
A TR naohealth
including n check of each database and agent. The Verify Configuration operation:
P • Determines the current data protection mode settings, including the current redo
transport mode settings for each database and whether the standby redo logs are
configured properly. If standby redo logs are needed for a database, a message
indicates this on the Detailed Results page. You can then add the standby redo logs.
• Validates each database for the current status
• P f
Performs a log
l switch
it h on th
the primary
i d
database
t b (f
(for non-RAC
RAC ddatabases)
t b ) and
d verifies
ifi
that the log was applied on each standby database
• Checks the agent status for each database. The verify process executes a SQL*Plus job
on the agent if credentials are available. If credentials are not available to run the job,
the agent is pinged instead. If errors occur, a message appears on the Results page.
• Displays the results of the Verify Configuration operation (including errors)
Note: You can cancel the Verify Configuration operation at any time by clicking Cancel.
Cancel

Performing Routine Maintenance
Use Enterprise Manager Cloud Control 12c to:

• Configure Fast-Start Failover

• Change the properties of a primary database
• Change the properties of a standby database
• Run a test application to generate a workload
• Manage apply services
• Set the redo transport mode s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A
You can use Enterprise BE b
Manager l e Cloud Control 12c to maintain your broker configuration.
L I Z r a
described finedetail in the next few slides.
Each task is E
C I A t r a ns
T RI non-
PA

Configuring Fast-Start Failover

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
Enterprise Manager A BE Control
Cloud l e
b 12c can manage the Fast-Start Failover feature for Data
Guard. This E L I Z r a
e discussed in more detail in lesson titled “Enabling Fast Start
feature willfbe
I
Failover.” A a n
The screenshot
s in the slide shows the Configure page for Fast-Start Failover. It
I C
R you
allows - t r
tonspecify which standby database Fast-Start failure will use as the failover target,
A T n o
P which host and alternate host will be used for the Data Guard observer process, failover
properties, and primary database properties related to the Fast-Start Failover configuration.

Editing Primary Database Properties:

General Properties
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
Enterprise Manager A BE Control
Cloud l e
b 12c can manage primary database properties related to
L I Z r a
the Data Guard fe In order to access the Edit Primary Database Properties page,
E configuration.
n s
navigateIAto the Data
r a Guard administration home page of the primary database and click the
Edit I C -
Rlink nbeside t
n the properties label of the primary database section. The screenshot in the
A T o
P slide shows the General tab for editing primary database properties. There is also a Standby
Role Properties tab and a Common Properties tab. The General tab allows the broker to be
disabled or enabled, redo transport to be started or stopped, and allows viewing of the alert
log of the primary database and standby database.


Standby Role Properties
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
Additional Data Guard A Bparameters
b that can be edited for the primary database can be found
L I Z r a
on the Standby
A s fe
E Rolenproperties tab and the common properties tab. The screenshot in the
I C I
slide shows
- t r a
the Standby Role Properties tab found on The Edit Primary Database Properties
A TR Compression
page. ontab yousetting
On this
n
can set the redo transport mode to SYNC, FASTSYNC, or ASYNC, the
P Redo to ENABLE or DISABLE, and you can specify the number of
seconds for Net Timeouts and the number of minutes for the Apply Delay. You can also
specify the Standby Archive location and turn on or turn off log shipping to the standby
database. The setting for standby archive location will only take effect after a role reversal,
which allows the current primary database to become a standby database.


Common Properties
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
The screenshot inZthe A Bslide b the Common Properties tab of the Edit Primary Database
shows
L
Properties page.
I r a
fetab, you can define redo routes, the Data Guard connect identifier for
A E Onnthis s
I C I
the primary
- t r a
database, the number of log archive process, and the trace level for Data Guard
A TR non
processes.
P

Test Application
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
The test application A BE ofbOracle
feature l e Enterprise Manager on the Data Guard administration
L I Z r a
webpage allows
A E a thorough
n s fe testing of Data Guard by generating a workload on the primary
database.
I C I - t r a
This workload will generation many transactions per second, cause log switching at
the
T Rprimary,
n o nand monitor the reception of the redo on the standby database and the
A
P application of the received redo. The screenshot in the slide shows the test application page
in progress of a running test. You have the ability to start, stop, or pause the test application.
Statistics show the current transactions per minute (33 in the screenshot). There are three
graphs on this page. The first graph shows the redo generation rate on the primary database
measured in kilobytes per second. The second graph shows both the current transport lag
pp y lag
and current apply g measured in seconds on the standby y database. The third g
graph
p shows
the apply rate measure in kilobytes per second on the standby database.

Quiz
Oracle Enterprise Manager Database Express 12c can be used

to create and configure a Data Guard configuration.

a. True
b False
b.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: b
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Quiz
The Verify Data Guard Configuration feature of Oracle

Enterprise Manager (EM) can also be performed using

DGMGRL.
a. True
b. False
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: b
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Summary


• Create a physical standby database
• Verify a Data Guard configuration
• Edit database properties related to Data Guard
• Test a Data Guard configuration
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA


• Creating a physical standby database using Enterprise

Manager
• Verifying and examining the Data Guard Environment
• Generating a test workload
• Preparing for command-line practices
• Creating a new primary database a
s
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
O
Oracle
l NNett S
Services
i in
i a Data
D t Guard
G d
Environment
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
Objectives

• Understand the basics of Oracle Net Services

• Configure client connectivity in a Data Guard configuration
• Implement Data Guard best practice solutions in
networking setup
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Oracle Net Services Overview

1 2 Dedicated
server
process
s a
3
) ha
Client Listener Database
l ฺ c om
m ai ฺ
Instance
9 @ g
u ide
i z 9 nt G
u
pr tude
(
Database as
R ON a client
h i s S another database
to
B AR use t
U
Oracle
H icenR s
T l
Oracle Net Services A BE enterprise-wide
provide b l e connectivity solutions in distributed,
L I Z r a
heterogeneous
A E computing
n s fe environments. It enables a network session from a client
I C I
application
- t a Database server.
to anrOracle
AATR
dedicated
n onserver process is a type of service handler that the listener starts when it receives
P a client request. The slide depicts the process of establishing a connection from a client to an
Oracle Database (non-shared server architecture) by using the following steps:
1. The listener receives a client connection request.
2. The listener starts a dedicated server process.
3. The listener provides the location of the dedicated server process in a redirect message.
g
4. The client connects directly to the dedicated server.
Note: Depending on the operating system and transport protocol, step three may be
eliminated. In this case, the dedicated server process inherits the connection request from the
listener. The result is the same—a network session established is between the client and the
dedicated server process.
If the client and database exist on the same computer, then the application initiating the
session can spawn a dedicated server process without going through the listener. This is
known as the bequeath protocol and is often used when starting a database instance.

Understanding Name Resolution
A naming method is a resolution method used by a client

application to resolve a connect identifier to a connect

descriptor when attempting to connect to a database service.
The following methods are available:
• Local naming (uses static text-based configuration files)
• Directory naming (uses a dynamic LDAP-compliant server)
• Easy Connect naming (uses simple hard-coded strings)
s a
• External naming (uses a third-party naming service)
) ha
SQL> connect hr@xyz
h
l ฺ c om
m ai ฺ
Resolved into:
9 @ g
u ide
SQL> connect hr@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) i z 9 nt G
u
pr tude
(HOST=host03.example.com)(PORT=1521))(CONNECT_DATA= (
(SERVICE_NAME=london.example.com)))
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A client application A BEa connect
needs b l e descriptor to create a network session. The connect
L I Z e r a
E ntwosfcomponents:
descriptor contains
A
• IC I
ocat o o
Location
-of ae listener
trtthe ste e through
t oug a p protocol
otoco address,
add ess, a also
so knowno as tthe
e listening
ste g e endpoint
dpo t
R n
no database service name or Oracle system identifier recognized by the listener
T• A specific
PA The connect descriptor can be explicitly specified as in the second example in the slide, which
does not require name resolution. This technique is used by the Data Guard broker when the
broker modifies the LOG_ARCHIVE_DEST_n parameters for redo transport. Also, a direct
TCP/IP address can be specified in place of the hostname to avoid additional lookups such as
using Domain Name Services (DNS).
In most cases though, a user initiates a connection request by providing a connection string
that can include a username, password, and a simplified connect identifier. This requires that
the simplified connect identifier be resolved into the appropriate details using one of the many
name resolution methods that are available. There are advantages and disadvantages to
each naming method. The sqlnet.ora file indicates which naming methods are available to
the client or server. This course will utilize the local naming method, which stores network
service names and their connect descriptors p in a localized configuration
g file named
tnsnames.ora.

Local Naming Configuration Files
The location of the local naming method configuration files is

specified by either the TNS_ADMIN or ORACLE_HOME operating

system environment variables. For ORACLE_HOME locations
consider:
• Multiple products each with a different ORACLE_HOME
• Multiple versions of the same product, each with a different
ORACLE_HOME
a
• Same product version installed multiple times for business
isolation or upgrade path requirements
requirements, each with a ) has
c om
different ORACLE_HOME ailฺ m ฺ
tnsnames.ora 9 @ g
listener.ora
u ide
sqlnet.ora i z 9 nt G
sqlnet.ora
u de
pr tnsnames.ora
( t u
Client ON
Database
R
S
h is
R
A use t
Z B
I and/or
UOracle
Copyright © 2014,
H icen s
T l
The local naming Z A BEuses
method b l e
text-based configuration files stored on both the client and the
database serverL I r a
fe network service names (connect identifiers) into detailed connect
A E to resolve
n s
I C I
descriptors.
- t r a
Operating-system environment variables determine the location of these files.
The
T RTNS_ADMIN
n o n variable is checked first. It allows the configuration files to be centrally
A
P located (for example, on a cluster file system and shared among many machines).
If the TNS_ADMIN variable is not defined, then the ORACLE_HOME variable is used to locate
the configuration files. Several different ORACLE_HOME locations can be present on the same
host machine for different reasons. Each may contain network configuration files if desired.
For example, the tnsnames.ora and sqlnet.ora file could be found in the ORACLE_HOME
location for each of the grid infrastructure software,
software database software
software, middleware software
software,
and Enterprise Manager software products. The value of the ORACLE_HOME environment
variable will point to a single ORACLE_HOME location at a time. The listener.ora
configuration file is used only for database software ORACLE_HOME locations.
Note: In a Real Application Cluster environment, the Oracle Database listener usually runs
from the ORACLE_HOME of the Grid Infrastructure software and not the ORACLE_HOME of the
database software. The ORACLE_HOME of the Grid Infrastructure software will need
networking
t ki configuration
fi ti if ASM iis b
being
i ddeployed.
l d If separation
ti off d
duties
ti exist
i tb between
t th
the
cluster software administrator and the database administrator, the database listener could run
from the ORACLE_HOME of the database software.

Local Naming: tnsnames.ora
Database parameter file (spfileNAME.ora/initNAME.ora)

LOG_ARCHIVE_DEST_2='SERVICE=london …'
Oracle Net Configuration (on database host machine):

$ORACLE_HOME/network/admin/tnsnames.ora
LONDON =
(DESCRIPTION =
a
has
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL=TCP)(HOST=host03.example.com)
m )
o
(PORT=1521)(SEND_BUF_SIZE=10485760)
a ilฺc
gm ideฺ
(RECV_BUF_SIZE=10485760))
) @
99 nt Gu
(SDU=65535) i z
( pru tude
(CONNECT_DATA=(SERVICE_NAME=london.example.com))
) ON s S R h i
R
A use t
Z B
I and/or
UOracle
Copyright © 2014,
H icen s
T l
The slide shows an A BE bofleusing
example the local naming method for a Data Guard environment.
L I Z r a
Located inside
A Eattribute
n s fe parameter file, the LOG_ARCHIVE_DEST_n parameter with
of the database
I C I
the SERVICE
- t r a used to define the remote Oracle database instance to which redo
is
R will nbeosent.
data
T n A network service name (shown in the slide with the value LONDON) will be
A
P resolved into the connect descriptor using the local naming method. The connect descriptor
provides the protocol and address information needed to contact the listener on its listening
endpoint. After the listener is contacted, a network session is requested for the specified
SERVICE_NAME. There is no requirement that the network service name (LONDON) have the
same value or similarly named value as the SERVICE_NAME(london.example.com).

Connect-Time Failover: Planning for Role

Reversal
Connect-time failover is turned on by default for multiple
address lists (ADDRESS_LIST used) and does not have to be
specified.
PRMY =
(DESCRIPTION =
(ADDRESS_LIST =
(FAILOVER=on)
a
has
m )
(PORT=1521)(SEND_BUF_SIZE=10485760) l ฺc o
a i
@ gm ideฺ
99 nt Gu
)
(SDU=65535) i z
( pru tude
(CONNECT_DATA=(SERVICE_NAME=prmy.example.com))
) ON is S
A RR se th
I Z B ou
R U and/or
H icen s
T l
Role-reversal operations A BEsuchbas l e failover and switchover can modify which host the primary
L I Z e r a
A E nissfcurrently
or standby database running on. The client configuration should include a connect
descriptor
I C I - t r a
that includes all potential host that a particular service can run on. This can be
R nobynspecifying an ADDRESS_LIST with multiple listening endpoints or addresses
configured
T
A
P within it. Connect-time failover instructs Oracle Net to fail over to a different listener if the first
listener fails. The use of the ADDRESS_LIST clause turns on connect-time failover by default.
It is not necessary to use the FAILOVER=on statement, as indicated by the red text in the
slide.
When the application connections are being made, if they should happen to attempt to
connect to an old primary host that is unavailable
unavailable, the connection attempt to that host should
last no longer than 3 seconds. This allows for connection attempts to get through the
ADDRESS_LIST quickly until a new primary host is found. This can be configured with the
following entry placed into the sqlnet.ora file:
SQLNET.OUTBOUND_CONNECT_TIMEOUT=3
Note: The ADDRESS_LIST clause is optional. Multiple addresses can be defined without
explicitly using the ADDRESS_LIST syntax. In this case, the failover mode would default to be
off and it would explicitly require the FAILOVER=on syntax to enable connect-time failover.

Listener Configuration: listener.ora
Oracle Net Configuration (on database host machine):

$ORACLE_HOME/network/admin/listener.ora
The following entry defines two listening endpoints:

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(PORT=1521)(SEND_SDU=10485760) a
(RECV_SDU = 10485760)))
) has
(DESCRIPTION = om
a
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)))ilฺc
)
@ gm ideฺ
ADR_BASE_LISTENER = /u01/app/oracle
i z 99 nt Gu
LISTENER2 = …
( pru tude
N
ADR_BASE_LISTENER2 = /u01/app/oracle S
R RO this
B A use
Z
I and/or
UOracle
Copyright © 2014, titsoaffiliates. All rights reserved.
R s e
T H icen
E le l
Bwith
A listener is configured
I Z A r a b or more listening protocol addresses, information about
one
L
supported services,
Eis storedandfe
s parameters that control its runtime behavior. The listener
C I A
configuration
t r a n in a configuration file named listener.ora. Because the
I -
R nonparameters have default values, it is possible to start and use a listener with no
configuration
A T
P configuration. In an Oracle Data Guard environment, best practices usually indicate a need to
adjust the session data unit (SDU) buffer to improve network performance. This is especially
important on a wide area network (WAN) that has long delays. Modifying this value will
require that the listener.ora file be created with non-default values.
The red and blue text in the slide indicates the name of a listener. This name is used in
commands that refer to the listener such as lsnrctl start LISTENER2.
LISTENER2 If the default
name is used, it is not necessary to identify it in most commands. For example, the command
lsnrctl start will start a listener with the default name of LISTENER.
One listener can listen for many databases, or there can exist a single listener for each
database. Inside of a single listener.ora file, multiple listener configurations can be
created by duplicating the contents of the file and changing the listener name to a different
value for each occurrence. In the slide, the blue text shows a second listener named
LISTENER2 Each
LISTENER2. E h separate t listener
li t requires
i a di
distinct
ti t lilistening
t i endpoint.
d i t Thi
This ttechnique
h i can
allow the listener to be started and stopped separately for each database on the same host
machine.

Dynamic Service Registration
Dynamic service registration allows the database instance to

identify its available services to the listener. Available service

names are determined by the following parameters:
• DB_UNIQUE_NAME, DB_NAME, and DB_DOMAIN
• SERVICE_NAMES
• INSTANCE_NAME
• LOCAL_LISTENER and REMOTE_LISTENER
s a
) ha
l ฺ c om
Listener
m ai ฺ
registration
9 @ g
u ide
process (LREG) z9
i n t G
u
pr tude
(
Listener
R ON his S Database
Instance
B AR use t
U
Oracle
R
H icen s
T l
A BE bis lconfigured
Dynamic service registration e in the database initialization file. It does not require
L
any configuration I Z thefe r a
A E inparameter
n s listener.ora file. If not specified, the value for the
I C I
SERVICE_NAMES
- t r a defaults to the global database name, a name comprised of the
A TR ndefined,on theandDB_UNIQUE_NAME
DB_UNIQUE_NAME DB_DOMAIN parameters in the initialization parameter file. If not
P explicitly parameter defaults to the value DB_NAME. The value
for the INSTANCE_NAME parameter defaults to the Oracle system identifier (SID). All of these
names can be explicitly defined to non-default values.
SERVICE_NAMES specifies one or more names by which clients can connect to the instance.
The instance registers its service names with the listener. You can specify multiple service
names to distinguish among different uses of the same database.
database For example:
SERVICE_NAMES=PROD,DG_PRMY,DG_RW,MAIN_REPORTING
By default, the LREG process registers service information with its local listener on the default
local address of TCP/IP, port 1521. To have the LREG process register with a local listener
that does not use TCP/IP, port 1521, configure the LOCAL_LISTENER parameter in the
initialization parameter file to locate the local listener.
A remote listener is a listener residing on one computer that redirects connections to a
database instance on another computer. You can configure registration to remote listeners
using the REMOTE_LISTENER parameter.

Static Listener Entries: listener.ora
Static listener entries are needed for Recovery Manager and

Data Guard broker operations.

SID_LIST_LISTENER =
(SID LIST =
(SID_LIST
(SID_DESC =
(GLOBAL_DBNAME = london.example.com)
(ORACLE_HOME =
/u01/app/oracle/product/12.1.0/dbhome_1)
a
has
(SID_NAME = london))
(SID_DESC =
m )
o
(GLOBAL_DBNAME = london_DGMGRL.example.com)
a ilฺc
(ORACLE_HOME = m deฺ
/u01/app/oracle/product/12.1.0/dbhome_1) @g ui
9 9 G
(SID_NAME = london))
r u iz ent
) (p ud N is St
O
A RR se th
I Z B ou
R U and/or
H icen s
T l
A BE ballows
Dynamic service registration l e the listener registration process (LREG) of a database
L I Z r a
instance to identify
A fe
E nitssavailable services to the listener without entries in the listener.ora
I
configuration file.ra
IC ninstance
-t
The listener then acts as a port mapper for those services. However, when
the
T Rdatabase
n o is stopped, the listener discards all information for the dynamic
A
P services related to that database. Any attempt to establish a network session to the unknown
service will usually receive the error message “ORA-12514: Listener does not currently know
of service requested in connect descriptor.” Static registration allows the listener to know of a
service even if the database instance is not running. This is often important with tools and
utilities that try to remotely start and stop a database instance. Configuration of static service
information is necessaryy in the following g cases:
• Use of external procedure calls
• Use of heterogeneous services
• Use of Oracle Data Guard
• Remote database startup from a tool other than Oracle Enterprise Manager Cloud
Control
To enable DGMGRL to restart instances during the course of broker operations
operations, a static
service must be registered with the local listener and assume a static service name of
db_unique_name_DGMGRL.db_domain.

Optimizing Oracle Net for Data Guard
• Calculate the TCP Socket buffer size by multiplying the

bandwidth delay product (BDP) by 3.

TCP Socket Buffer size=BDP*3=network bandwidth*latency*3
• Set the send and receive buffer sizes to the larger of
BDP*3 or 10 MB in both the tnsnames.ora and
listener.ora.
(SEND_BUF_SIZE=10485760)
(RECV_BUF_SIZE=10485760) s a
) ha
• IIncrease the
th session
i data
d t unit
it (SDU) to
t 64 KB in
i both
b th ฺthe
l th
c om
i
tnsnames.ora and listener.ora. ma ฺ
(SDU=65535) 9 @ g
u ide
i z 9 nt G
• Disable the TCP Nagle algorithm in (the u
pr sqlnet.ora de file.
N S t u
TCP.NODELAY=YES
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BEthroughput,
l e l
To achieve high network
I Z A r a b especially for a high-latency, high-bandwidth network,
L
the minimumErecommended
s fe setting for the sizes of the TCP send and receive socket buffers
I A
is the bandwidth-delay
C t r n
a product (BDP) of the network link between the primary and standby
I
R nBDP
systems. -
n is the product of the network bandwidth and latency. Tests have shown
A T o
P incremental throughput increases with socket buffer settings up to three times the BDP.
Socket buffer sizes are set using the Oracle Net parameters RECV_BUF_SIZE and
SEND_BUF_SIZE. For example, if bandwidth is 622 Mbit/s per second and latency is 30 ms,
you would calculate the minimum size for the RECV_BUF_SIZE and SEND_BUF_SIZE
parameters as follows: 622,000,000 / 8 x 0.030 = 2,332,500 bytes. Then, multiply the BDP
2,332,500 x 3 for a total of 6,997,500. Set the send and receive buffer sizes at either the value
you calculated or 10 MB (10485760), whichever is larger.
Oracle Net buffers data into what is called a session data unit (SDU), with a default size of
8192 bytes. These data units are then sent to the network layer when they are either full,
flushed, or read by the client. Generally Data Guard sends redo in much larger chunks than
8192 bytes, so this default is insufficient, because you can end up having to send more pieces
(chopping up the data) to Oracle Net Services. Increase this to 64 KB.
T preemptt delays
To d l iin b
buffer
ff flushing
fl hi in
i the
th TCP protocol
t l stack,
t k disable
di bl th
the TCP N
Nagle
l
algorithm by setting TCP.NODELAY to YES in the sqlnet.ora file on both the primary and
standby systems.

The actual value of the SEND_BUF_SIZE and RECV_BUF_SIZE parameters may be less than
the value specified because of limitations in the host operating system or due to memory
constraints. The default values for these parameters are operating-system specific. The
following are the defaults for the Linux operating system:
SEND_BUF_SIZE: 131,072 bytes (128 KB)
RECV_BUF_SIZE: 174,700 bytes
These values are typically modified to be higher when the oracle-rdbms-server-12cR1-

preinstall package is installed, but the modified values are still lower than the Data Guard
best practice recommended values.
The default and maximum amount for the receive socket memory can be determined with:
# cat /proc/sys/net/core/rmem_default
# cat /proc/sys/net/core/rmem_max
s a
The default and maximum amount for the send socket memory can be determined with: ) ha
# cat /proc/sys/net/core/wmem_default
l ฺ c om
m ai ฺ
ide
# cat /proc/sys/net/core/wmem_max
@ g
9
9 nt G u
u i z
Adjust values with the following commands:
( pr tude
# echo 'net.core.wmem_max=10485760' >>
R ON s S
/etc/sysctl.conf
h i
# echo 'net
'net.core.rmem_max=10485760'
core rmem max 10485760'
B et
AR >>us/etc/sysctl.conf
/etc/sysctl conf
U IZ e to
H Rinitial
You must also set minimum size,
T e n s and maximum size in bytes:
size,
A BE ble lic10240 131072 10485760' >>

# echo 'net.ipv4.tcp_rmem=
LIZ sfera
/etc/sysctl.conf
E
# echoIA
I C - t r an
'net.ipv4.tcp_wmem= 10240 131072 10485760' >>
A TR non
/etc/sysctl.conf
P
Reload the changes made by using the following command:
# sysctl –p
Note: Starting with Oracle Database 12c Release 1 (12 (12.1),

1) Oracle Net supports large session
data unit (SDU) sizes, with a new upper limit of 2 MB. The larger SDU size can be used to
achieve better utilization of available network bandwidth in networks that have high bandwidth
delay products and host resources, according to application characteristics. At the moment in
time of writing this course, current best practices recommend a value of 64 KB. This may
change in the future with additional testing.

Quiz
Running the oracle-rdbms-server-12cR1-preinstall

package is sufficient to set up operating system kernel

parameters for an Oracle Linux Data Guard environment using
best practice guidelines.
a. True
b. False
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: b
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Quiz
In order to use the connect-time failover feature, the failover

clause must be included in the tnsnames.ora file.

a. True
b False
b.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: b
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Summary

• Understand the basics of Oracle Net Services

• Configure client connectivity in a Data Guard configuration
• Implement Data Guard best practice solutions in
networking setup
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA


• Declaring Oracle Net naming methods

• Creating Oracle Net service names
• Implementing best practice values for the Oracle Net
configuration
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Creating
C ti a Physical
Ph i l Standby
St db Database
D t b by
b
Using SQL and RMAN Commands
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
Objectives

• Configure the primary database and Oracle Net Services

to support the creation of the physical standby database
and role transition
• Create a physical standby database by using the
DUPLICATE TARGET DATABASE FOR STANDBY FROM
ACTIVE DATABASE RMAN command
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Steps to Create
a Physical Standby Database
1. Prepare the primary database.
2. Set parameters on the physical standby database.

3. Configure Oracle Net Services.
4
4. Start the standby database instance
instance.
5. Execute the DUPLICATE TARGET DATABASE FOR
STANDBY FROM ACTIVE DATABASE RMAN command.
6. Start the transport and application of redo. a
s
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
You perform the steps A Blisted b the slide when using SQL and RMAN commands to create a
in
L I Z r a
physical standby
A E database.
n s fe Detailed information about each step is provided in the remaining
slides ofIthe
R IC n-tra lesson.
T SeeoOracle Data Guard Concepts and Administration for detailed information about
Note:
PAcreating na physical standby database by using only SQL commands.

Preparing the Primary Database
• Enable FORCE LOGGING at the database level.

• Create a password file if required.

• Create standby redo logs.
• Set initialization parameters
parameters.
• Enable archiving.
SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT; s a
SQL>
Q ALTER DATABASE ARCHIVELOG; ) ha
l ฺ c om
SQL> ALTER DATABASE OPEN;
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l whether the Oracle database server logs all changes
The FORCE LOGGING A B b
mode determines
in the databaseL IZ feforrachanges
(except to temporary tablespaces and temporary segments).
A E ns
I
IC n-tra
Notes:
T R noinformation about enabling FORCE LOGGING follows in this lesson.
Additional
PA Unless you have configured Oracle Advanced Security and public key infrastructure (PKI)
certificates, every database in a Data Guard configuration must use a password file, and the
password for the SYS user must be identical on every system for redo data transmission to
succeed. For details about creating a password file, see the Oracle Database Administrator’s
Guide.
A standby redo log is used to store redo received from another Oracle database
database.
Additional information about creating standby redo log files is provided in this lesson.
On the primary database, you define initialization parameters that control redo transport
services while the database is in the primary role. There are other parameters that you need
to add that control the receipt of the redo data and log apply services when the primary
database is transitioned to the standby role. Additional information about setting initialization
parameters is provided in this lesson.
Th D
The Data
t G
Guard dbbroker
k requires
i th
the use off a server parameter
t fil
file.
If archiving is not enabled, issue the ALTER DATABASE ARCHIVELOG command to put the
primary database in ARCHIVELOG mode and enable automatic archiving. See the Oracle
Database Administrator’s Guide for additional information about archiving.
FORCE LOGGING Mode
• FORCE LOGGING mode is recommended to ensure data

consistency.
• FORCE LOGGING forces redo to be generated even when
NOLOGGING operations
p are executed.
• Temporary tablespaces and temporary segments are not
logged.
• FORCE LOGGING is recommended for both physical and
a
logical standby databases.
) has
• Issue the following command on the primary database:com
a ilฺ
SQL> ALTER DATABASE FORCE LOGGING;
@ gm ideฺ
i z 99 nt Gu
( pru tude
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l whether the Oracle database server logs all changes in
A Bdetermines
rab to temporary tablespaces and temporary segments). The
FORCE LOGGING mode
LIZ sforfechanges
the databaseE(except
C
[NO]FORCE
I IA LOGGING
- t r an clause of the ALTER DATABASE command contains the following
A TR non
settings:
P • FORCE LOGGING: This setting takes precedence over (and is independent of) any
NOLOGGING or FORCE LOGGING settings that you specify for individual tablespaces and
any NOLOGGING setting that you specify for individual database objects. All ongoing,
unlogged operations must finish before forced logging can begin.
• NOFORCE LOGGING: Places the database in NOFORCE LOGGING mode. This is the
default.
default
The FORCE_LOGGING column in V$DATABASE contains a value of YES if the database is in
FORCE LOGGING mode.

Although the database can be placed in FORCE LOGGING mode when the database is OPEN,
the mode does not change until the completion of all operations that are currently running in
NOLOGGING mode. Therefore, it is recommended that you enable FORCE LOGGING mode
when the database is in the MOUNT state.
Note: You should enable FORCE LOGGING before performing the backup operation to create
the standby database, and then maintain FORCE LOGGING mode for as long as the Data
Guard configuration exists.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Configuring Standby Redo Logs
• Create standby redo logs on the primary database initially

(recommended).
• Create standby redo logs using the same file size as the
primary database online redo logs.
• Create one additional group more than the number of
online redo log groups.
Online Redo Standby
redo logs shipment Redo logs s a
) ha
l ฺ c om
m ai ฺ
RFS 9 @ g
u ide
i z 9 nt G
u
pr Standby de
( t u
Primary
database R ON hisdatabase S
B AR use t
U
Oracle
H icenR s
T l
A standby redo log A
is BE only
used b l e
when the database is in the standby role to store redo data
L I Z r a
received from
A Ethe primary
n s fe database. Standby redo logs form a separate pool of log file
groups. IConfiguring
r a standby redo log files is highly recommended for all databases in a Data
I C - t
A TR configuration
Guard
n on to aid in role reversal.
P You should create at least one more standby redo log group than you have online redo log
groups in the primary database. In addition, each standby redo log file must be at least as
large as the largest redo log file in the redo log of the redo source database.
A standby redo log is required to implement:
• Synchronous transport mode
• Real-time apply
• Cascaded redo log destinations
Note: By configuring the standby redo logs on the primary database, the standby redo logs
are created automatically on the standby database when you execute the DUPLICATE
TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE RMAN command. They will also
be automatically created on the Far Sync server as well when it is created, provided that they
already
l d existi t on th
the primary
i machine.
hi F
Far S
Sync will
ill b
be di
discussed
d llater
t iin th
the course.

Standby Redo Log Usage

Standby Archived
Redo from redo logs redo logs
primary database
RFS ARC0
s a
MRP/LSP ) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
r ude
pdatabase
Standby (
N is St
O
A RR se th
I Z B ou
R U and/or
H icen s
T l
If standby redo logs A BE
are b
availablel e and configured correctly, the RFS process will write the
L I Z r a
e database to the standby redo logs. Because the files are
redo received
A Efrom nthesfprimary
generally
I C I the same
- t r a as the online redo logs of the primary database, they should fill up
size
and
T Rswitchn oatna similar frequency as the online redo logs. There may be some delay due to
A
P the latency of the network transmission of the redo. The additional standby redo log group
should allow the log switch of the standby redo logs without causing wait states. At log switch
of the standby redo logs, the ARC0 process will create an archived redo log using the
completed standby redo log.
The RFS process creates and writes directly to an archived redo log file instead of the
standby redo log if any of the following conditions are met:
• There are no standby redo logs.
• It cannot find a standby redo log that is the same size as or larger than the incoming
online redo log file.
• All standby redo logs of the correct size have not yet been archived.
Note: In previous releases, the parameter STANDBY_ARCHIVE_DEST was used to identify
the location of the archived redo logs created on the standby database host that were created
from the standby redo logs. This parameter is now deprecated, because an appropriate
location is automatically chosen.

Using SQL to Create Standby Redo Logs
Create standby redo logs on the primary database to assist role

changes:
SQL> alter database add standby logfile

('/ 01/
('/u01/app/oracle/oradata/boston/stdbyredo01.log')
/ l / d t /b t / tdb d 01 l ')
size 50M;
Database altered.
or s a
) ha
SQL> ALTER DATABASE ADD STANDBY LOGFILE
l ฺ c om
2 '+DATA' SIZE 52428800; m ai ฺ
g e
Database altered. 9@ uid 9 nt G
u i z
( pr tude
R ON his S
B AR use t
U
Oracle
H icenR s
T l
You can create standbyA BE redob l
logse by using the ADD STANDBY LOGFILE clause of the ALTER
LIZ sAlthough
DATABASE statement.
E f era standby redo logs are used only when the database is
operating
I C r an role, you should create standby redo logs on the primary database
IAin the-tstandby
A TRthat switching
so
n on roles does not require additional DBA intervention.
P You should create standby redo log files on the primary database prior to using the
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE RMAN command
so that RMAN creates standby redo log files automatically on the standby database.
Create standby redo log file groups by using the following guidelines:
• Each standby redo log file must be at least as large as the largest redo log file in the
redo source database. For administrative ease, Oracle recommends that all redo log
files in the redo source database and the redo transport destination be of the same size.
• The standby redo log must have at least one more redo log group than the redo log on
the redo source database.

Viewing Standby Redo Log Information
View information about the standby redo logs:

SQL> SELECT group#, type, member FROM v$logfile

2 WHERE type = 'STANDBY';
GROUP# TYPE MEMBER
------ ------- -----------------------------------
4 STANDBY /u01/app/oracle/oradata/boston/stdbyredo01.log
s a
) ha
SQL> SELECT group#, dbid, thread#, sequence#, status
om
2 FROM v$standby
$ y_log;
g;
l ฺ c
ai ฺ
GROUP# DBID THREAD# SEQUENCE# STATUS
---------- ---------- ---------- ---------- ---------- m
4 2581955083 1 44 ACTIVE
9 @ g
u ide
5 UNASSIGNED 1 0 UNASSIGNED
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E logslewere l
To verify that standbyA Bredo b created, query V$STANDBY_LOG or V$LOGFILE. An
L I Z r a
example output
A E using n s fe
Automatic Storage Management (ASM) is shown below:
I
Q C SELECT
I'STANDBY‘;
SQL>
- tragroup#,
g p , type,yp , member FROM v$logfile $ g WHERE type
yp =
T R o n
PA GROUP#n TYPE MEMBER
---------- ------- ------------------------------------------------
4 STANDBY +SBDAT/london/onlinelog/group_4.266.711624939
+SBDAT/london/onlinelog/group 6 268 711624951
4 STANDBY +SBFRA/london/onlinelog/group_4.259.711624941
8 rows selected.

Setting Initialization Parameters on the

Primary Database to Control Redo Transport
Parameter Name Description

LOG_ARCHIVE_CONFIG Specifies the unique database name for each

database in the configuration
Enables or disables sending and receiving of
redo
LOG_ARCHIVE_DEST_n Controls redo transport services
LOG_ARCHIVE_DEST_STATE_n Specifies the destination state

s a
ARCHIVE_LAG_TARGET Forces a log switch after the specified ) ha
number of seconds l ฺ c om
m ai ฺ
LOG_ARCHIVE_TRACE Controls output generated by the archiver
process 9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
On the primary database,A BEyoubdefine
l e initialization parameters that control redo transport
L I Z r a
services while
A n s fe is in the primary role. These parameters are described in more
E the database
detail in Ithe
R IC n-tra following slides.
PA
T no

Setting LOG_ARCHIVE_CONFIG
Specify the DG_CONFIG attribute to list the DB_UNIQUE_NAME

for the primary database and each standby database in the

Data Guard configuration.
LOG ARCHIVE CONFIG 'DG CONFIG (b t
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,london)'
l d )'
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
Specify the DG_CONFIG A BEattributel e
b the LOG_ARCHIVE_CONFIG parameter to list the
of
L I Z r a
E nofsthe
DB_UNIQUE_NAME
A fe primary and standby databases in the Data Guard configuration. By
I C I
default, the r a
LOG_ARCHIVE_CONFIG
- t parameter enables the database to send and receive
T R ThenLOG_ARCHIVE_CONFIG
redo. o n parameter can be used to disable the sending of redo logs
A
P to remote destinations or disable the receipt of remote redo logs. The complete syntax for the
LOG_ARCHIVE_CONFIG parameter is as follows:
LOG_ARCHIVE_CONFIG = {
[ SEND | NOSEND ][ RECEIVE | NORECEIVE ]
[ DG_CONFIG=(remote_db_unique_name1
[, ... remote_db_unique_name9) | NODG_CONFIG ] }
Use the V$DATAGUARD_CONFIG view to see the unique database names defined with the
DB_UNIQUE_NAME and LOG_ARCHIVE_CONFIG initialization parameters; you can thus view
the Data Guard environment from any database in the configuration. The first row of the view
lists the unique database name of the current database that was specified with the
DB_UNIQUE_NAME initialization parameter. Additional rows reflect the unique database
names of the other databases in the configuration that were specified with the DG_CONFIG
DG CONFIG
keyword of the LOG_ARCHIVE_CONFIG initialization parameter.

The following example illustrates the use of V$DATAGUARD_CONFIG:
SQL> show parameter log_archive_config
NAME TYPE VALUE

------------------- ------- ---------------------------
log_archive_config string dg_config=(boston,london)
SQL> SELECT * FROM v$dataguard_config;
DB_UNIQUE_NAME
------------------------------
boston
s a
) ha
london
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Setting LOG_ARCHIVE_DEST_n
• Specify LOG_ARCHIVE_DEST_n parameters for:

– Local archiving
– Standby database location
• Include (at a minimum) one of the following:
– LOCATION: Specifies a valid path name
– SERVICE: Specifies a valid Oracle Net Services name
referencing a standby database
a
• Include a LOG_ARCHIVE_DEST_STATE_n parameter for
) has
each defined destination
destination. om
ilฺc
LOG_ARCHIVE_DEST_2=
g ma deฺ
'SERVICE=london
9 9 @ Gui
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
r u iz ent
DB_UNIQUE_NAME=london'
N (p Stud
LOG_ARCHIVE_DEST_STATE_2=ENABLE O is
A RR se th
I Z B ou
R U and/or
H icen s
T
BE ble l
By using the variousALOG_ARCHIVE_DEST_n attributes, you define most of the settings for
L I Z r a
the Data Guard fe The Redo Transport Service is directly controlled by these
E configuration.
n s
settings.IA
A numberr a of different attributes can be set for each LOG_ARCHIVE_DEST_n
I C
R noMost
parameter. - t
n have defaults that are adequate for most configurations. See Oracle Data
A T
P Guard Concepts and Administration for a complete list and a description of each.
You should specify a LOG_ARCHIVE_DEST_n parameter (where n is an integer from 1 to 31)
for the local archiving destination and one for the standby location. In previous versions of
Oracle Database, LOG_ARCHIVE_DEST_10 was set to USE_DB_RECOVERY_FILE_DEST
when the fast recovery area was being used. Beginning with Oracle Database 11g Release 2,
you must manually set a location to use the fast recovery area
area. Query the V$ARCHIVE_DEST
V$ARCHIVE DEST
view to see current settings of the LOG_ARCHIVE_DEST_n initialization parameter.
All defined LOG_ARCHIVE_DEST_n parameters must contain, at a minimum, either a
LOCATION attribute or a SERVICE attribute.
In addition, you must have a LOG_ARCHIVE_DEST_STATE_n parameter for each defined
destination. LOG_ARCHIVE_DEST_STATE_n defaults to ENABLE.

Specifying Role-Based Destinations
Primary Standby
database database
Not used
s a
) ha
log_archive_dest_2 = log_archive_dest_2
l hi d t 2 =
l ฺ c om
'service=london async 'service=boston asyncai
valid_for= valid_for=
@ gm ideฺ
(online_logfile, z 99 nt Gu
(online_logfile,
i
primary_role) ( pru tude
primary_role)
db_unique_name=london'
RON S
db_unique_name=boston'
h is
R
A use t
Z B
I and/or
UOracle
Copyright © 2014,
H icen s
T l
The VALID_FOR attributeA BEof the b l e initialization parameter enables you
L I Z r a LOG_ARCHIVE_DEST_n
to identify exactly
A E when n s fethe archive destination is to be used, as well as which type of log file it
I C I
is used for.
- t r a uses a keyword pair to identify the redo log type as well as the
The attribute
R nrole.
database
T o n Using this attribute enables you to set up parameters in anticipation of
A
P switchover and failover operations.
In the example in the slide, there is a destination on the standby database and the primary
database defined with the VALID_FOR setting shown. This destination is to be used on the
standby database only after a switchover, when the standby becomes a primary. The
destination on the old primary is ignored when it becomes a standby.
You supply two values for the VALID_FOR
VALID FOR attribute: redo_log_type
d l t and database_role.
d t b l
The redo_log_type keywords are:
• ONLINE_LOGFILE: This destination is used only when archiving online redo log files.
• STANDBY_LOGFILE: This destination is used only when archiving standby redo log files
or receiving archive logs from another database.
• ALL_LOGFILES: This destination is used when archiving either online or standby redo
l fil
log files.

The database_role keywords are the following:
• PRIMARY_ROLE: This destination is used only when the database is in the primary
database role.
STANDBY ROLE: This destination is used only when the database is in the standby
• STANDBY_ROLE:
(logical or physical) role.
• ALL_ROLES: This destination is used when the database is in either the primary or the
standby (logical or physical) role.

Note: Because the keywords are unique, the archival_source and database_role
values can be specified in any order.
For example,
p , VALID_FOR=(PRIMARY
( _ROLE,ONLINE
, ) is functionally
_LOGFILE) y equivalent
q
to VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE).
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Combinations for VALID_FOR
Combination Primary Physical Logical

ONLINE_LOGFILE, PRIMARY_ROLE Valid Ignored Ignored
ONLINE_LOGFILE, STANDBY_ROLE Ignored

g Ignored
g Valid
ONLINE_LOGFILE, ALL_ROLES Valid Ignored Valid
STANDBY_LOGFILE,STANDBY_ROLE Ignored Valid Valid

s a
STANDBY_LOGFILE, ALL_ROLES Ignored Valid Valid ) ha
l ฺ c om
ALL_LOGFILES, PRIMARY_ROLE Valid Ignored ai ฺ
Ignored
m
9 @ g
u ide
ALL_LOGFILES, STANDBY_ROLE Ignored z
Valid
i 9 ntValid G
u
pr tude
(
N is Valid S
ALL_LOGFILES, ALL_ROLES OValid Valid
R R t h
B A use
Z
I and/or
UOracle
R s e
T H icen
E le l
BValid
In the table in theZ
I A
slide,
r a bindicates that the archive log destination is used in a database
that is in theE L sfeby theandcolumn
role defined heading. Ignored means that the archive log
I
destination A is notra n
appropriate that a destination of this type is ignored. An ignored
RIC nodoes
destination
T n-t not generate an error.
PAThere is only one invalid combination: STANDBY_LOGFILE, PRIMARY_ROLE. Specifying this
combination causes an error for all database roles. If it is set, you receive the following error
at startup:
ORA-16026: The parameter LOG_ARCHIVE_DEST_n contains an invalid
attribute value
Note: Both single and plural forms of the keywords are valid. For example, you can specify
either PRIMARY_ROLE or PRIMARY_ROLES, as well as ONLINE_LOGFILE or
ONLINE_LOGFILES.

Defining the Redo Transport Mode
Use the attributes of LOG_ARCHIVE_DEST_n:

• SYNC and ASYNC

– Specify that network I/O operations are to be performed
synchronously
sy c o ous y o or asy
asynchronously
c o ous y whene ususing
g LGWR.
G
– ASYNC is the default.
• AFFIRM and NOAFFIRM
– Ensure that redo was successfully written to disk
on the standby destination. s a
– NOAFFIRM is the default when ASYNC is specified; ) ha
l ฺ c om
AFFIRM is the default when SYNC is specified.
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BofEthebLOG_ARCHIVE_DEST_n
The following attributes l e initialization parameter define the redo
L I Z r a
transport mode
A fe by the primary database to send redo to the standby database.
E thatnissused
• C I
ISYNC: p tra that redo data g
Specifies
- generated by y a transaction must have been received at a
R n
no that
T destination has this attribute before the transaction can commit; otherwise, the
PA destination is deemed to have failed. In a configuration with multiple SYNC destinations,
the redo must be processed as described here for every SYNC destination.
• ASYNC (default): Specifies that redo data generated by a transaction need not have
been received at a destination that has this attribute before the transaction can commit
• AFFIRM: Specifies that a redo transport destination acknowledges received redo data
after
ft writing
iti it tto th
the standby
t db redod llog
• NOAFFIRM: Specifies that a redo transport destination acknowledges received redo data
before writing it to the standby redo log
If neither the AFFIRM nor the NOAFFIRM attribute is specified, the default is AFFIRM when the
SYNC attribute is specified and NOAFFIRM when the ASYNC attribute is specified.
Note: Specifying the AFFIRM attribute without the SYNC attribute is deprecated and will not be
s pported in future
supported f t re releases.
releases

Setting Initialization Parameters

on the Primary Database
• Specify parameters when standby databases have disk or
directory structures that differ from the primary database.

• Use parameters when the primary database is transitioned
to a standbyy database.
Parameter Name Description
DB_FILE_NAME_CONVERT Converts primary database file names
s a
) ha
LOG_FILE_NAME_CONVERT Converts primary database log file names
STANDBY_FILE_MANAGEMENT Controls automatic standby file management

l ฺ c om
m ai ฺ
FAL_SERVER Specifies the fetch archive log server
@ g for aide
standby database
i z 9 nt Gu
9
( pru tude
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
The parameters listed A BinEthe slide
b l e are required if the disk configuration is not the same for the
L I Z r a
primary and E
A n s fe
standby databases. The parameters are also applicable when the primary
database
I C I - t r a
is transitioned to a standby database.
A TR non
P

Specifying Values for

DB FILE NAME CONVERT
DB_FILE_NAME_CONVERT
• DB_FILE_NAME_CONVERT must be defined on standby
databases that have different disk or directory structures

from the primary.
• Multiple
p p pairs of file names can be listed in the
DB_FILE_NAME_CONVERT parameter.
• DB_FILE_NAME_CONVERT applies only to a physical
standby database.
• DB_FILE_NAME_CONVERT can be set in the DUPLICATE a
RMAN script
script. ) has
om lฺc
a i
DB_FILE_NAME_CONVERT =('/oracle1/dba/',
@ gm ideฺ
'/ora1/stby_dba/',
z 9 9 t Gu
'/oracle2/dba/', i
ru uden
( p
N is St
'/ora2/stby_dba/')
O
A RR se th
I Z B ou
R U and/or
H icen s
T
E le l database, the DB_FILE_NAME_CONVERT parameter is
When files are added A B b
to the standby
L
used to convert
IZ datafefileraname
the on the primary database to a data file name on the standby
A E ns
I C I
database. The file
- t r amust exist and be writable on the physical standby database; if it is not, the
A TR nprocess
recovery on halts with an error.
P You specify the path name and file name location of the primary database data files followed
by the standby location by setting the value of this parameter to two strings. The first string is
the pattern found in the data file names on the primary database. The second string is the
pattern found in the data file names on the physical standby database. You can use as many
pairs of primary and standby replacement strings as required. You can use single or double
quotation marks.
marks Parentheses are optional.
optional
In the example in the slide, /oracle1/dba/ and /oracle2/dba/ are used to match file
names coming from the primary database. /ora1/stby_dba/ and /ora2/stby_dba/ are
the corresponding strings for the physical standby database. A file on the primary database
named /oracle1/dba/system01.dbf is converted to
/ora1/stby_dba/system01.dbf on the standby database.
Multiple pairs can be specified such as ('a','b','1','2').
Note: If the standby database uses Oracle Managed Files (OMF), do not set the
DB_FILE_NAME_CONVERT parameter. There is a 255-character limit on this parameter.

Specifying Values for

LOG FILE NAME CONVERT
LOG_FILE_NAME_CONVERT
• LOG_FILE_NAME_CONVERT is similar to
DB_FILE_NAME_CONVERT.
• LOG_FILE_NAME_CONVERT must be defined on standby
databases that have different disk or directory
y structures
from the primary.
• LOG_FILE_NAME_CONVERT applies only to a physical
standby database.
• LOG_FILE_NAME_CONVERT can be set in the DUPLICATE a
RMAN script
script. ) has
om
a ilฺc
@ gm ideฺ
LOG_FILE_NAME_CONVERT = ('/oracle1/logs/',
i z 99 nt Gu
pru tude
'/ora1/stby_logs/')
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
The LOG_FILE_NAME_CONVERTA BE ble parameter is used to convert the name of a redo log file on
L I Z r a
E nstofethe name of a redo log file on the standby database. Adding a redo
the primary database
log file toIA
the primary
r a database requires adding a corresponding file to the standby database.
I C
R thenstandby
When - t
n database is updated, this parameter is used to convert the log file name
A T o
P from the primary database to the log file name on the standby database. This parameter is
required if the standby database is on the same system as the primary database or on a
separate system that uses different path names.
Specify the location of the primary database online redo log files followed by the standby
location. The use of parentheses is optional.
Both DB_FILE_NAME_CONVERT
DB FILE NAME CONVERT and LOG_FILE_NAME_CONVERT
LOG FILE NAME CONVERT parameters perform simple
string substitutions. For example, ('a','b') will transform the following:
/disk1/primary/mya/a.dbf into
/disk1/primbry/myb/b.dbf
Multiple pairs can be specified such as ('a','b','1','2').
Note: If the standby database uses OMF, do not set the LOG_FILE_NAME_CONVERT
parameter. There
Th iis a 255
255-character
h lilimiti on this
hi parameter.

Specifying a Value for

STANDBY FILE MANAGEMENT
STANDBY_FILE_MANAGEMENT
• STANDBY_FILE_MANAGEMENT is used to maintain
consistency when you add or delete a data file on the

primary database.
– MANUAL (default)
— Data files must be manually added to the standby database.
– AUTO
— Data files are automatically added to the standby database.
— Certain ALTER statements are no longer allowed on the standby
s a
database.
) ha
• STANDBY_FILE_MANAGEMENT applies to physical standby l ฺ c om
m ai forฺ
databases only, but can be set on a primary database
role changes. 9 @ g
u ide
9 G iz ent
r u
STANDBY_FILE_MANAGEMENT = autoN (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
A BE ble l is set to AUTO, you cannot execute the following
When STANDBY_FILE_MANAGEMENT
commands onE LtheIZstandby
f e radatabase:
• C I A DATABASE
t r a ns RENAME
RIALTER
ALTER
T• o -
nDATABASE
PA n ADD/DROP LOGFILE [MEMBER]
• ALTER DATABASE ADD/DROP STANDBY LOGFILE MEMBER
• ALTER DATABASE CREATE DATAFILE AS ...
When you add a log file to the primary database and want to add it to the physical standby
database as well (or when you drop a log file from the primary and want to drop it from the
physical), you must do the following:
1. Set STANDBY_FILE_MANAGEMENT to MANUAL on the physical standby database.
2. Add the redo log files to (or drop them from) the primary database.
3. Add them to (or drop them from) the standby database.
4. Reset to AUTO afterward on the standby database.

Specifying a Value for FAL_SERVER
• FAL_SERVER is:
– Used to specify the name of the fetch archive log server,

usually the primary database
– Used onlyy by
y databases in the standbyy role
– Created on both primary and standby databases for role
reversal
• On the boston primary database:
s a
FAL_SERVER = london
) ha
l ฺ c om
• On the london standby database: m ai ฺ
9 @ g
u ide
FAL_SERVER = boston i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
The FAL_SERVER A BE bliseused
parameter to specify the Oracle Net service name of the fetch
L I Z r a
archive log (FAL)
A E server n s fe(typically this is the database running in the primary role). When the
London Idatabase r a
is running in the standby role, it uses the Boston database as the FAL
I C
R from
server - t
n to fetch (request) missing archived redo log files if Boston is unable to
which
A T n o
P automatically send the missing log files. It is assumed that the Oracle Net service name is
configured properly on the standby database system to point to the desired FAL server.

Example: Setting Initialization Parameters

on the Primary Database
Primary database: boston; standby database: london
DB_NAME=boston
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,london)'
CONTROL_FILES='/u01/app/oracle/oradata/boston/control01.ctl',
/ 1/ / l / d /b / l 1 l
'/u01/app/oracle/oradata/boston/control02.ctl'
LOG_ARCHIVE_DEST_2=
'SERVICE=london
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=london'
s a
LOG_ARCHIVE_DEST_STATE_2=ENABLE
) ha
REMOTE LOGIN PASSWORDFILE EXCLUSIVE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
l ฺ c om
LOG_ARCHIVE_FORMAT=arch_%t_%s_%r.log
m ai ฺ
g ide
FAL_SERVER=london
STANDBY_FILE_MANAGEMENT=auto 9 @
9 nt G u
DB_FILE_NAME_CONVERT='boston','london'
u i z
LOG_FILE_NAME_CONVERT='boston','london' ( pr tude
R ON his S
B AR use t
U
Oracle
H icenR s
T l
In the example in theA BE assume
slide, l e
b that the primary database is named boston and the
L I Z r a
standby is named
A E london.
n s fe For each, an Oracle Net Services name is defined.
Note: I traparameters can also be used to change ASM disk groups. For example:
ICThe convert
-
T R no n
PA
DB_FILE_NAME_CONVERT=('+DATA','+SBDAT')

Creating an Oracle Net Service Name

for Your Physical Standby Database
Use Oracle Net Manager to update the tnsnames.ora file:
LONDON =
(DESCRIPTION =
(ADDRESS_LIST =
)
(SDU=65535) a
(CONNECT_DATA=(SERVICE_NAME=london.example.com))
) has
) om
a ilฺc
@ gm ideฺ
i z 99 nt Gu
( pru tude
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A
Use Oracle Net ManagerBEto definel e
b a network service name for your physical standby
L I Z r a
database. The
A fe the entry in the tnsnames.ora file that was generated by Oracle
E slidenshows
s
I
IC n-tra
Net Manager.
R
T Thisoentry is used to connect to the standby database when invoking RMAN and
Note:
PAexecutingnthe DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
command. It is also used in the LOG_ARCHIVE_DEST_2 parameter for the SERVICE value to
define the redo transport to the standby database.

Creating a Listener Entry for Your

Standby Database
Use Oracle Net Manager to configure an entry for your standby
database in the listener.ora file:

SID_LIST_LISTENER =
(SID LIST =
(SID_LIST
(SID_DESC =
(GLOBAL_DBNAME = london.example.com)
(ORACLE_HOME =
/u01/app/oracle/product/12.1.0/dbhome_1)
s a
(SID_NAME = london) ) ha
)
l ฺ c om
) m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
Use Oracle Net Manager A BEto configure
b l e a new listener (if necessary) or to update the
L I Z r a
listener.ora
A E filenwiths fean entry for your physical standby database. The slide shows the
I C I
entry in the r a
listener.ora
- t file that was generated by Oracle Net Manager.
A TR This
Note: n n is needed because the instance is shut down and restarted during the
oentry
P standby database creation using RMAN.

Copying Your Primary Database Password File

to the Physical Standby Database Host
1. Copy the primary database password file to the
$ORACLE_HOME/dbs directory on the standby database

host.
2. Rename the file for y
your standby
y database: orapw<SID>.
p
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
You can create a Z A BE file
password l e
b your physical standby database by copying the primary
for
L I r a
E nfilesftoe the physical standby database host and renaming it.
database password
A
Note:
I I
CIt would - trapossible to use the orapwd utility to create a password file, but that
be
T R
technique n
noshould always be avoided with Data Guard. The Recovery Manager DUPLICATE
PADATABASE command is being used in this lesson and RMAN will automatically copy the
password file from the primary and replace the one that was created. Manual creation will not
work when creating other Data Guard servers such as Far Sync (to be discussed later in the
course).

Creating an Initialization Parameter File

for the Physical Standby Database
Create an initialization parameter file containing enough
information to match the network listener services entries:

File: $ORACLE_HOME/dbs/initlondon.ora
DB_NAME=london
DB NAME=london
DB_DOMAIN=example.com
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BEparameter
Create a text initialization b l e file containing only the DB_NAME and DB_DOMAIN
L I Z r a
initialization E
A
parameters.
n s fe
I a
C n-trparameter
This Iinitialization file is used to start the physical standby database in NOMOUNT
R
T prioroto the execution of the DUPLICATE TARGET DATABASE FOR STANDBY FROM
mode
PAACTIVE nDATABASE RMAN command. When you execute this command, RMAN creates a
server parameter file for the standby database.

Creating Directories
for the Physical Standby Database
Create the baseline directory structures needed on the physical
standby database host.
[oracle@host03]$ mkdir -p
/u01/app/oracle/admin/london/adump
/u01/app/oracle/oradata/london
a
has
/u01/app/oracle/oradata/london/pdbseed
p m )
o
/u01/app/oracle/oradata/london/dev1
a ilฺc
@ gm ideฺ
99
/u01/app/oracle/fast_recovery_area/london Gu iz ent
r u
N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BEstructurel e l
I Z A
Create an initial directory
r a b for the physical standby database in the
L
E nsfeand $ORACLE_BASE/oradata locations. The directories to be
$ORACLE_BASE/admin
C A
created Idepend
t on
r a whether the primary database is using file locations for data files or
I
R noStorage
Automatic -
n Manager. If multi-tenant architecture is being used, additional directories
A T
P are needed. The above example is for a file system–based, multi-tenant installation using a
single pluggable database named DEV1. Additional pluggable databases on the primary
server will require additional directories to be created if the file system is used for storage.

Starting the Physical Standby Database
Start the physical standby database instance in NOMOUNT

mode:
SQL> startup nomount

pfile=$HOME/dbs/initlondon.ora
fil $HOME/db /i itl d
ORACLE instance started.
Total System Global Area 150667264 bytes

Fixed Size 1298472 bytes s a
Variable Size 92278744 bytes ) ha
Database Buffers 50331648 bytes
l ฺ c om
Redo Buffers 6758400 bytes m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le lvariable to your physical standby database. Start the
Set the ORACLE_SID A B b
environment
L Z erainstance
Idatabase
A E nsf
physical standby in NOMOUNT mode by using the text initialization
parameter
I C I file. With
- t r a ASM installed, there will be multiple software home locations on each
A TR recommends
machine.
n on will require
This that the ORACLE_HOME and PATH location change accordingly.
P Oracle the oraenv utility to change environment variables provided entries exist
in the /etc/oratab file. The oraenv utility will adjust ORACLE_SID, ORACLE_BASE,
ORACLE_HOME, PATH, and LD_LIBRARY_PATH environment variables. The ORACLE_HOME
variable should point to the Grid Infrastructure software directories when starting the listener
by using the LSNRCTL utility. However, the ORACLE_HOME variable should point to the
database software directories when starting g the database.
Note: Because the initialization parameter file contains only entries for DB_NAME and
DB_DOMAIN, memory sizes for the System Global Area will use default values. Later the
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE RMAN command
will copy the initialization parameter values for memory sizing from the primary database
configuration.

Creating an RMAN Script

to Create the Physical Standby Database
Create an RMAN script to create the physical standby
database:
run {
allocate channel prmy1 type disk;
allocate auxiliary channel stby type disk;
s a
duplicate target database for standby ) ha
from active database l ฺ c om
m ai ฺ
Note: The script continues in the next slide. 9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le lthe DUPLICATE TARGET DATABASE FOR STANDBY FROM
A Bcontaining
Create an RMAN script b
L IZ command.
e r a
E nsf
ACTIVE DATABASE
A
I tra to using RMAN to create the standby database. They include:
ICare advantages
There -
T R n
no can create a standby database by copying the files currently in use by the
PA • RMAN primary database. No backups are required.
• RMAN can create a standby database by restoring backups of the primary database to
the standby site. Thus, the primary database is not affected during the creation of the
standby database.
• RMAN automates renaming g of files, including
g Oracle Managed
g Files ((OMF)) and
directory structures.
• RMAN restores archived redo log files from backups and performs media recovery so
that the standby and primary databases are synchronized.
Note: You can use the CONFIGURE … PARALLELISM integer command to configure
automatic channels for the specified device type. For additional information, see the Oracle
Database Backup and Recovery Reference.

Creating an RMAN Script

to Create the Physical Standby Database
spfile
parameter_value_convert 'boston','london'
set db_unique_name='london'
set db_file_name_convert='boston','london'
set log_file_name_convert='boston','london'
set log_archive_max_processes='10'
set fal_server='boston'
set log_archive_config='dg_config=(boston,london)'
set log_archive_dest_2='service=boston ASYNC a
valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE)
) has
db unique name boston'
db_unique_name=boston' om
nofilenamecheck; a ilฺc
} gm deฺ @ Gui
9 9
r u iz ent
N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BE the l e l
In the RMAN script,
I Z Aspecify
r a b settings for the physical standby initialization parameters. You
only need toE L fe
specify parameters
s that are different than those on the primary database.
C I
Parameters A related
t r a n
to directory paths for data files, control files, and online redo logs that are
I -
A TR ndoonot
different n have to be specified if DB_FILE_NAME_CONVERT and
P LOG_FILE_NAME_CONVERT are used.

Creating the Physical Standby Database
1. Invoke RMAN and connect to the primary database and

the physical standby database.

2. Execute the RMAN script (previous two slides) to create
the p
physical
y standby
y database.
RMAN> connect target sys/oracle_4U@boston

RMAN> connect auxiliary sys/oracle_4U@london
RMAN> @cr_phys_standby
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
Connect to the primary A Bdatabase
b instance (target) and physical standby database instance
L I Z r a
e that you created. The script can be run using the RMAN utility
E nthesfscript
(auxiliary). Execute
either onIA
the primary
r a database or standby database.
I C - t
A TR non
P

Real-Time Apply (Default)
RFS
Primary MRP
database Standby
redo log
files
s a
ARC0 ) ha
l ฺ c om
m ai ฺ
9 @ g
u i de
Archived
i z 9 nt G
redo log u
pr tuStandby de
(
files
R ON his S database
B AR use t
U
Oracle
H icenR s
T l
With the real-timeZ A BE
apply l e
b apply services apply the redo data from standby redo log
feature, log
L I r a
e time the log files are being written to) as opposed to recovering
E (at nthesfsame
files in real time
A
redo from
I C I archived
- t r a log files when a log switch occurs. If for some reason the apply
redo
R isnunable
service
T o n to keep up (for example, if you have a physical standby in read-only mode
A
P for a period of time), then the apply service automatically goes to the archived redo log files
as needed. The apply service also tries to catch up and go back to reading the standby redo
log files as soon as possible.
Real-time application of redo information provides a number of benefits, including faster
switchover and failover operations, up-to-date results after you change a physical standby
database to read
read-only
only, up-to-date
up to date reporting from a logical standby database
database, and the ability to
leverage larger log files on the primary database resulting in larger standby redo logs on the
standby database.
Having larger log files with real-time apply is desirable because the apply service stays with a
log longer and the overhead of switching has less impact on the real-time apply processing.
The RECOVERY_MODE column of the V$ARCHIVE_DEST_STATUS view contains the value
MANAGED REAL TIME APPLY when log apply services are running in real-time apply mode.

If you define a delay on a destination (with the DELAY attribute) and use real-time apply, the
delay is ignored.
For physical standby databases, the managed recovery process (MRP) applies the redo from
the standbyy redo log
g files after the remote file server ((RFS)) p
process finishes writing.
g
Note: Beginning with Oracle Database 12c, real-time apply is enabled by default during Redo
Apply. You can disable real-time apply by stopping the Redo Apply process, and you can
restart it with the USING ARCHIVED LOGFILE clause as follows:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING ARCHIVED
LOGFILE;
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Starting Redo Apply in Real-Time
• Execute the following command on the standby database

to start Redo Apply in real time:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE DISCONNECT;
• To disable real-time Redo Apply:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY s a
DATABASE CANCEL; ) ha
l ฺ c om
m ai ฺ
g ide
DATABASE USING ARCHIVED LOGFILE DISCONNECT; 9 @
9 nt G u
u i z
( pr tude
R ON his S
B AR use t
U
Oracle
H icenR s
T l
On the standby database,A BEissue l e
b ALTER DATABASE RECOVER MANAGED STANDBY
the
L I Z r a
DATABASE SQL
A E command n s fe to start Redo Apply. This statement automatically mounts the
database.
I C I - t r a
In addition, include the DISCONNECT FROM SESSION option so that Redo Apply
T R in anbackground
runs o n session. The FROM SESSION portion of syntax is no longer needed, but
A
P is acceptable.
The transmission of redo data to the remote standby location does not occur until after a log
switch. Issue the following command on the primary database to force a log switch:
SQL> ALTER SYSTEM SWITCH LOGFILE;
Note: The syntax option USING CURRENT LOGFILE of the ALTER DATABASE RECOVER
MANAGED STANDBY DATABASE statement t t t has
h been
b deprecated
d t d for
f Oracle
O l Database
D t b 12
12c
Release 1.

Preventing Primary Database Data Corruption

from Affecting the Standby Database
• Oracle Database processes can validate redo data before
it is applied to the standby database.

• Corruption detection checks occur on the primary
database during g redo transport
p and on the standby
y
database during Redo Apply.
• Implement lost-write detection by setting
DB_LOST_WRITE_PROTECT to TYPICAL on the primary
and standby databases. s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
Data Guard uses Z A BEprocesses
Oracle l e
b to validate redo data before it is applied to the standby
database. E L I fe r a
I A n s
IC detection
Corruption
R n - tra checks occur at the following key interfaces:
Corruption-detection
T o
PA • Onnthe primary database during redo transport by the LGWR, LNS, and ARCn
processes
• On the standby database during Redo Apply by the RFS, ARCn, MRP, and DBWn
processes
If redo corruption is detected by Redo Apply at the standby database, Data Guard will re-fetch
valid logs
g as ppart of archive log
gggap
p handling.
g
A lost write occurs when an I/O subsystem acknowledges the completion of a write but the
write did not occur in persistent storage. On a subsequent block read, the I/O subsystem
returns the stale version of the data block, which is used to update other blocks of the
database, thereby corrupting the database.
Set the DB_LOST_WRITE_PROTECT initialization parameter on the primary and standby
databases to enable the database server to record buffer cache block reads in the redo log so
that
h llost writes
i can bbe d
detected.
d

You can set DB_LOST_WRITE_PROTECT as follows:
• TYPICAL on the primary database: The instance logs buffer cache reads for
read/write tablespaces in the redo log.
• FULL on the primary database: The instance logs reads for read-only
read only tablespaces as
well as read/write tablespaces.
• TYPICAL or FULL on the standby database or on the primary database during
media recovery: The instance performs lost-write detection.

• NONE on either the primary database or the standby database (the default): No lost-
write detection functionality is enabled.
When a standbyy database applies
pp redo during
g managed
g recovery, y, it reads the corresponding
p g
blocks and compares the system change numbers (SCNs) with the SCNs in the redo log
before doing the following:
• If the block SCN on the primary database is lower than on the standby database, it
detects a lost write on the primary database and returns an external error (ORA-752).
• If the SCN is higher, it detects a lost write on the standby database and returns an s a
internal error (ORA-600 3020).
) ha
c om
In both cases, the standby database writes the reason for the failure in the alert log and trace
l ฺ
file.
m ai ฺ
@ e to the
gis to failidover
The recommended procedure to repair a lost write on a primary database9 u
G database, you
9 a standby
i
physical standby and re-create the primary. To repair a lost write
u zon n t
must re-create the standby database or affected files. (pr
t u de
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
A TR non
P

Special Note:
Data Guard Support for Oracle Multitenant
• A multitenant container database (CDB) can have a
physical standby database and/or a logical standby

database.
• Database role is defined at the CDB level only.y
• Individual pluggable databases (PDBs) do not have their
own roles.
• Role transitions are executed at CDB level.
a
• DDL related to role changes is executed in the root
) has
container (CDB$ROOT) of the CDB CDB. om
a i lฺc
• PDBs created from XML files or clones from a different
gm ideฺ
PDB will need their data files manually copied @ Gu
99 tontthe
i z
standby host. pru de
O N ( is Stu
A RR se th
I Z B ou
R U and/or
H icen s
T
Data Guard includes A BE bforlethel multitenant architecture in Oracle Database 12c Release
support
1 (12.1). DataE LIZ sisfmanaged
Guard era at the CDB level. Individual PDBs cannot have a different
database
I C IArole -than
t r an
that of the CDB. Role transitions such as switchover and failover are
R noatnthe CDB level. A primary database that is a CDB can have both physical and
performed
T
A
P logical standby databases. You are not required to have the same set of PDBs at the primary
database and standby. However, only tables that exist in the same container at both the
primary and standby are replicated.

Special Note:
Standby Database on the Same System
Primary Standby
/oracle/dba /oracle/standby/dba
• Standby database data files must be at a different location. a

• Each database instance must archive to different locations. ) has
om
• Service names must be unique. a ilฺc
m deฺ
gdisaster.
• This standby database does not protect against
9 @ ui 9 nt G
u i z
( pr tude
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
If you have a standby A B
database b on the same system as the primary database, you must use
the followingE L I Z
guidelines:fe r a
I A a s
nmust
• IC
R
The
n - t r
e data files
es ust be renamed.
e a ed The e actual
actua file e names
a es can ca be tthe e sa
same,
e, but at least
east tthe
e
no path must be different.
T directory
PA DB_FILE_NAME_CONVERT
This means that you must use the
and LOG_FILE_NAME_CONVERT parameters.
Note: If the standby database uses Oracle Managed Files (OMF), do not set the
DB_FILE_NAME_CONVERT or LOG_FILE_NAME_CONVERT parameters.
• If a standby database is located on the same system as the primary database, the
archival directories for the standby database must use a different directory structure
th the
than th primary
i database.
d t b Otherwise,
Oth i th
the standby
t db d database
t b may overwrite
it th
the primary
i
database files.
• If you do not explicitly specify unique service names and if the primary and standby
databases are located on the same system, the same default global name (consisting of
the database name and domain name from the DB_NAME and DB_DOMAIN parameters)
will be in effect for both the databases.
• If the standby database is on the same system as the primary database, it does not
protect against disaster. A disaster is defined as total loss of the primary database
system. If the standby database is on the same system, it will be lost as well. This
configuration should be used only for testing and training purposes.

Creating a Physical Standby Without Using RMAN
• Create a backup copy of the primary database data files.

• Create a control file for the standby database.

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS
'/tmp/london01
/tmp/london01.ctl
ctl';
;
• Create a parameter file from the server parameter file used
by the primary database, and then adjust the parameters.
SQL> CREATE PFILE='/tmp/initlondon.ora' FROM
s a
SPFILE;
m ) ha
o
• Transfer the complete backup, standby control file, a ilฺc
and
parameter file to the standby system.
@ gm ideฺ
u
99instance.
G
• z
Create a server parameter file and a startup
i
ru uden t
( p
• Restore the backup and start RedoN Apply.St
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
E le l
Bthe
If the database is Z
I A
using
r b system for storage instead of Automatic Storage Manager
file
a
(ASM), then E L e
a physical fstandby
sused database can be created without using RMAN. With ASM,
RMAN willI A
C n-t n
have rtoabe to create the backup.
T
YouRIcan o any backup copy of the primary database to create the physical standby
use
PAdatabase,n as long as you have the necessary archived redo log files to completely recover the
database. A standby control file will have to be created on the primary database, and
transferred to the standby database. A text-based parameter file will need to be created from
the primary database binary server parameter file. The file needs adjusting in the same way
as shown earlier in the lesson. It will then need to be transferred to the standby system and
converted to a binary server parameter filefile.

Quiz
The DB_FILE_NAME_CONVERT parameter is required when

Oracle Managed Files (OMF) are being used exclusively.

a. True
b False
b.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: b
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Quiz
A standby database cannot be created on the same system as

the primary database.

a. True
b False
b.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: b
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Summary

• Enable FORCE LOGGING

• Create standby redo logs
• Set initialization parameters on the primary database
to support the creation of the physical standby database
and role transition
• Configure Oracle Net Services
a
• Create a physical standby database by using the ) has
DUPLICATE
C TARGET
G DATABASE S FORO STANDBY
S O ฺcom
FROM
ACTIVE DATABASE RMAN command a il
m ฺ g de
• Start the transport and application of redoz9 9 @ u i
i n t G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA


• Preparing the primary database prior to creating a physical

standby database
• Creating the physical standby database
• Verifying that the physical standby database is performing
correctly
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
U i O
Using Oracle
l AActive
ti Data
D t Guard
G d
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
Objectives

• Use real-time query to access data on a physical standby

database
• Enable RMAN block change tracking for a physical
standby database
• Use Far Sync to extend zero data loss protection for
intercontinental configurations
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Oracle Active Data Guard
• Is an option for Oracle Database 12c Enterprise Edition

• Enhances quality of service by offloading resource-

intensive activities from a production database to a
standbyy database
• Includes the following features:
– Physical standby with real-time query
– Fast incremental backup on physical standby
a
– Automatic block repair
) has
– Active Data Guard Far Sync om
– Global Data Services a ilฺc
@ gm ideฺ
– Real-time cascade
i z 99 nt Gu
– Application continuity
( pru tude
– ON Guard
Rolling upgrade using Active Data is S
A RR se th
I Z B ou
R U and/or
H icen s
T l
Oracle Active Data A BEincreases
Guard b l e performance, availability, data protection, and return on
L I Z r a
investment wherever
A E nsData fe Guard is used for real-time data protection and availability. An
I C I
Oracle Active Data
- t r a Guard standby database can be used to offload a primary database of
R nad
reporting,
T o nhoc queries, data extracts, and backups, making it a very effective way to
A
P insulate interactive users and critical business tasks on the production system from the
overhead of long-running operations. Oracle Active Data Guard provides read-only access to
a physical standby database while it is synchronized with a primary database, enabling
minimal latency between reporting and production data. Unlike other replication methods,
Active Data Guard is very simple to use, transparently supports all data types, and offers very
g p
high performance with complete
p read consistencyy at the reporting
p g database. Oracle Active
Data Guard automatically repairs physical corruption on either the primary or standby
database, increasing availability and maintaining data protection at all times. Oracle Active
Data Guard 12c reduces downtime for Oracle Database upgrades and other database
maintenance while avoiding error-prone manual procedures. Oracle Active Data Guard 12c
Far Sync enables zero data loss disaster protection (DR) across any distance without
impacting database performance. Oracle Active Data Guard 12c also includes Global Data
Services to extend the conceptsp of automated service failover and workload management
g to
globally distributed systems, and application continuity to provide transparent failover of in-
flight transactions in Data Guard configurations that do not use Oracle Real Application
Cluster (Oracle RAC).

Using Real-Time Query

Redo Redo
transport apply
Redo
Primary stream Physical standby Queries s a
database database
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
With Oracle Active A BEGuard,
Data l e
b can use a physical standby database for queries while
you
L I Z r a
redo is applied
A fe standby database. This feature enables you to use a physical
E to thensphysical
standby Idatabase r afor disaster recovery and to offload work from the primary database during
I C
R operation.
normal - t
n The physical standby is in a read-only mode, so no additional indexes or
A T n o
P materialized views may be created to support reporting activities.
Note: If you need to create additional structures (such as indexes and materialized views),
you can create a logical standby database as described in the lesson titled “Creating a
Logical Standby Database.”
In addition, this feature provides a loosely coupled read/write clustering mechanism for OLTP
workloads
kl d when h configured
fi d as ffollows:
ll
• Primary database: Recipient of all update traffic
• Several readable standby databases: Used to distribute the query workload
The physical standby database can be opened in read-only mode only if all files were
recovered up to the same system change number (SCN). Otherwise, the open fails.

Enabling Real-Time Query
1. Stop Redo Apply:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

CANCEL;
2 Open
2. O the
th database
d t b ffor read-only
d l access:
SQL> ALTER DATABASE OPEN READ ONLY;
3. Restart Redo Apply with the real-time default option: s a

) ha
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
l ฺ c om
DISCONNECT; ai
@ gm ideฺ
i z 99 nt Gu
( pru tude
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A physical standby A BE binstance
database l e cannot be opened if Redo Apply is active on a mounted
L I Z r a
instance of that
A E database.
n s fe In order to enable real-time query:
• IC I
Stop the ra Apply
t e Redo
- tedo pp y process
p ocess
R
T• Open n
nothe database for read-only access
PA • Restart the Redo Apply with the real-time option that is now the default mode for Oracle
Database 12c Release 1.
The COMPATIBLE database initialization parameter must be set to 11.0 or higher to use the
real-time query feature of the Oracle Active Data Guard option.
Note: When using the Oracle Data Guard broker,
broker it is not necessary to stop Redo Apply and
restart Redo Apply when enabling real-time query. Real-time query is not the same as real-
time apply, which was covered in the previous lesson. Real-time apply allows the recovery
mechanisms to read from the standby redo logs at the same time that redo is being written to
the standby redo logs. In the normal physical standby mode of operation, the database is only
at the mount mode and would not allow any queries against user tables, even though real-
time apply is enabled. Real-time query with Oracle Active Data Guard extends real-time apply
by allowing the database to be opened and queries performed against itit.

Disabling Real-Time Query
1. Shut down the standby database instance.

SQL> SHUTDOWN IMMEDIATE;
2 Restart the standby database instance in MOUNT mode.

2. mode
SQL> STARTUP MOUNT;
3. Restart Redo Apply services (real-time apply). s a

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE m ) ha
DISCONNECT; li ฺco
g ma deฺ
9 9 @ Gui
r u iz ent
N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BE you l e l
To disable real-time
I Z A
query,
r a b must shut down the standby database instance and restart it
L
E nsfe
in MOUNT mode.
I A
R IC n-tra
PA
T no

Checking the Standby’s Open Mode
• A physical standby database opened in read-only mode:

SQL> SELECT open_mode FROM V$DATABASE;

OPEN_MODE
--------------------
READ ONLY
• A physical standby database opened in real-time query

mode: a
s
SQL> SELECT open
p _mode FROM V$DATABASE; ) ha
l ฺ c om
ai ฺ
OPEN_MODE
m
g ide
--------------------
READ ONLY WITH APPLY 9 9 @ G u
r u iz ent
N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BE bcolumn l e l
I Z A
You can use the OPEN_MODE
r a of V$DATABASE to check the open mode of a physical
L
standby database.
E Ifnthe s fephysical standby database stops Redo Apply in order to open the
database
C I A t r a
in read-only mode, then the OPEN_MODE column will indicate “READ ONLY.”
I -
A TR thendatabase
After on has been opened read-only, Redo Apply can be restarted to enable Active
P Data Guard real-time query mode with the following command:
SQL> alter database recover managed standby database disconnect;
After Redo Apply has been started on an open read-only physical standby database, the
OPEN_MODE column will indicate “READ ONLY WITH APPLY.”

Understanding Lag in an Active Data Guard

Configuration
• A standby database configured with real-time apply can
lag behind the primary database as a result of:

– Insufficient CPU capacity
– High
g network latency y
– Limited bandwidth
• Queries on the standby database need to return current
results and/or be within an established service level.
a
• Ways to “manage” the standby database lag and take
) has
necessary action: om
– Configure Data Guard with a maximum data lag that a il
will
ฺc
trigger an error when it is exceeded. @ gm ideฺ
z 9 t Gu
9when
– Monitor the Redo Apply lag and take action
r i
u den the lag is
p
unacceptable. N ( Stu
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
E le l
Bimprove
Active Data GuardZcan
I A r a b performance by off-loading a read-only workload to a physical
standby database.L
E However, s fe due to hardware and network issues, the data on a standby
database
C I A
may lag
t r a n
behind the data on the primary database. The standby database may not
I
R benocurrent
always -
n with the primary database if it does not have the capacity to apply redo as
A T
P quickly as it is received. Limited bandwidth may prevent the primary database from shipping
redo as quickly as it is generated, particularly during periods of peak workload.
Oracle Database 12c Release 1 (12.1) includes features to enable you to determine the lag
time and take appropriate action.
You can establish a tolerance level for data staleness by configuring a maximum value for
apply
l llag. Query
Q results
lt are returned
t d to
t the
th application
li ti if the
th lag
l is
i within
ithi th
the acceptable
t bl
tolerance level; otherwise, an error results.
If you determine that you want your application to receive the results of a query, regardless of
the “staleness” of the data, you can monitor the apply lag via the V$DATAGUARD_STATS view
and then take appropriate action if the lag is unacceptable.

Monitoring Apply Lag: V$DATAGUARD_STATS
• Apply lag: This is the difference, in elapsed time, between

when the last applied change became visible on the

standby and when that same change was first visible on
the primary.
• The apply lag row of the V$DATAGUARD_STATS view
reflects statistics that are computed periodically and to the
nearest second.
SQL> SELECT name, value, datum_time, time_computed
s a
2> FROM v$dataguard_stats
) ha
3> WHERE name like 'apply
apply lag
lag';
;
l ฺ c om
NAME VALUE DATUM_TIME TIME_COMPUTED
m ai ฺ
--------- ------------- -------------------- --------------------
9 @ g
u ide
apply lag +00 00:00:00 27-MAY-2009 08:54:16 27-MAY-2009
i z 9 nt G 08:54:17
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
Apply lag is a measure A BofEthebdegree
l e to which a standby database lags behind the primary
L I Z r a
database, due
A E to delays
n s fein propagating and applying redo to the standby database. The
I C I
current apply lagris
- t a difference, in elapsed time, between when the last applied change
the
R nvisible
became
T o n on the standby and when that same change was first visible on the primary.
A
P This metric is computed to the nearest second.
The apply lag metric is computed using data that is periodically received from the primary
database. The DATUM_TIME column contains a timestamp of when this data was last
received by the standby database. The TIME_COMPUTED column contains a timestamp taken
when the apply lag metric was calculated. The difference between the values in these
columns should be less than 30 seconds
seconds. If the difference is larger than this
this, the apply lag
metric may not be accurate.

Monitoring Apply Lag:

V$STANDBY EVENT HISTOGRAM
V$STANDBY_EVENT_HISTOGRAM
• View the histogram of apply lag on a physical standby
database.
• Assess the value for STANDBY_MAX_DATA_DELAY.
• Focus on periods of time when the apply lag exceeds
desired levels so that issue can be resolved.
SQL> SELECT * FROM V$STANDBY_EVENT_HISTOGRAM
2> WHERE NAME = 'apply lag' AND COUNT > 0;
NAME TIME UNIT COUNT LAST_TIME_UPDATED

s a
) ha
--------- --------- -------- ----------- ------------------------
apply lag 0 seconds 79681 06/18/2009 10:05:00
l ฺ c om
ai ฺ
m
apply lag
apply lag
4
5
seconds
seconds
1
1
06/17/2009 11:43:51
9
06/17/2009 11:43:52@ g
u ide
i z 9 nt G
6 rows selected u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble lis a new view that is available on the standby database.
LIZtheshistogram
V$STANDBY_EVENT_HISTOGRAM
This view displays
E f era of the apply lag on the physical standby database.
C
Use Ithe
A traton focus on periods of time when the apply lag exceeds desired levels.
Ihistogram
T R nothe
Determine n-cause of the lag during those time periods and take steps to resolve the
PAexcessive lag. To evaluate the apply lag over a time period, take a snapshot of
V$STANDBY_EVENT_HISTOGRAM at the beginning of the time period and compare that
snapshot with one taken at the end of the time period.
Each distinct value of apply lag has its own bucket. The count in the bucket is incremented
when the physical standby database samples its data delay.

Allowed Staleness of Standby Query Data
• The STANDBY_MAX_DATA_DELAY session parameter

specifies a session-specific limit for the amount of time (in

seconds) allowed to elapse between when changes are
committed on the primary and when those same changes
can be queried on the standby database.
ALTER SESSION
SET STANDBY_MAX_DATA_DELAY = {INTEGER|NONE}
s a
) ha
• If the limit is exceeded
exceeded, an error message is returned:
l ฺ c om
ORA-3172 STANDBY_MAX_DATA_DELAY has been exceeded m ai ฺ
• This setting is ignored for the SYS user. 99@ Gui
g de
r u iz ent
N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BEthrough l e l
You can configure aAlimit b the use of the STANDBY_MAX_DATA_DELAY session
L I Z r a
parameter. Use
A fe parameter to specify a limit for the amount of time (in seconds)
E thisnsession
s
allowed Ito elapse r a
between when changes are committed on the primary database and when
I C - t
A TR same
those
n onchanges can be queried on the active standby database.
P If the specified limit cannot be met, an error is returned to the query as follows:
ORA-3172 STANDBY_MAX_DATA_DELAY has been exceeded
This guarantees that a query will not receive a “stale result” if the apply lag exceeds the
service level agreement. In addition, a warning message is written to the standby database
alert log.
The default value is NONE, which indicates that queries issued to the physical standby
database will be executed regardless of the apply lag on that database.

Configuring Zero Lag Between the Primary and

Standby Databases
• Certain applications have zero tolerance for any lag.
• A query on the standby database must return the same

result as if it were executed on the primary database.
• Enforce by setting STANDBY_MAX_DATA_DELAY
STANDBY MAX DATA DELAY to 0. 0
• The standby database must have advanced to a value
equal to that of the current SCN on the primary database
at the time the query was issued.
a
• Results are guaranteed to be the same as the primary has
database; otherwise,
otherwise an ORA-3172 returned. om)
ORA 3172 error is returned
a i lฺc
• The primary database must operate in maximum gm ideฺ
availability or maximum protection mode. 99 @ G u
i z t
• SYNC must be specified for redo transport. ( pru tuden
• Real-time query must be enabled. R ON his S
B AR use t
U
Oracle
H icenR s
T l
You can ensure that A BEapplication
your b l e querying data on the standby database sees all data
L I Z r a
that has been
A Ecommitted
n s feon the primary database by setting STANDBY_MAX_DATA_DELAY to
0. I
IC n-tra
R notonot
Tquery does
A execute until the query SCN on the standby database has advanced to a
PAvalue equal that of the current SCN on the primary database at the time the query was
issued.
To support zero lag, the primary database must operate in maximum availability or maximum
protection mode. Protection modes will be discussed later in the course.
Specify SYNC for redo transport mode.
Real-time query must be enabled as a prerequisite for configuring zero lag.

Setting STANDBY_MAX_DATA_DELAY by Using an

AFTER LOGON Trigger
Create an AFTER LOGON trigger that:
• Is database role–aware
– It uses DATABASE_ROLE, a new attribute in the USERENV
co e
context.
– SQL and PL/SQL clients can retrieve the database role
programmatically using the SYS_CONTEXT function.
– It enables you to write role-specific triggers.
• Sets STANDBY_MAX_DATA_DELAY when the application a
logs on to a real-time query enabled standby database m)
real time query–enabled has
l ฺ c o
• i
Allows for configuration of a maximum data delay without
g ma deฺ
changing the application source code 9@ ui
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BELOGON
You can create an AFTER b l e trigger that sets the STANDBY_MAX_DATA_DELAY session
L I Z r a
parameter when
A fe is a physical standby database that is operating in real-time
E thendatabase
s
I
C n-tra
query mode.
I
R o
T OraclenDatabase
In 12c Release 1 (12.1), the DATABASE_ROLE attribute of the USERENV
PAcontext enables you to determine the role of the database. SQL and PL/SQL clients can
retrieve this information by using the SYS_CONTEXT function. This enables you to write
triggers that perform certain actions based on the database role.

Example: Setting STANDBY_MAX_DATA_DELAY by

Using an AFTER LOGON Trigger
CREATE OR REPLACE TRIGGER sla_logon_trigger

AFTER LOGON
ON APP.SCHEMA
BEGIN
IF (SYS_CONTEXT('USERENV', 'DATABASE_ROLE')
IN ('PHYSICAL STANDBY'))
THEN execute immediate
s a
) ha
'alter session set standby_max_data_delay=5';
ENDIF;
END;
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E lofe an l
A
The slide presents an Bexample b AFTER LOGON trigger that is used to set the value of
L I Z r a
E nsfe based on the database role.
STANDBY_MAX_DATA_DELAY
A
I
IC n-tra
T R no
PA

Forcing Redo Apply Synchronization
• The ALTER SESSION SYNC WITH PRIMARY command:

– Performs a blocking wait on the standby database upon

execution
– Blocks the application
pp until the standby
y database is in sync
y
with the primary database as of the time this command is
executed
• When the ALTER SESSION SYNC WITH PRIMARY
command returns control, the session can continue to a
process queries without having to wait for standby Redo ) has
Apply. l ฺ c om
• An ORA-3173 Standby may not be synced with m ai ฺ
9 @ g
u i de
primary error is returned if Redo Apply zis9not active
t G or is
u i n
canceled before the standby database
( de with the
pr is intusync
N is S
ROthis hcommand
primary database as of the time is executed.
B AR use t
U
Oracle
H icenR s
T l
BE SESSION
You can execute theAALTER b l e SYNC WITH PRIMARY command to ensure that the
L I Z r a
standby database
A s fe
E isncompletely synchronized with the primary database at the time of
I C I
execution. The use
- t r a of this command is particularly applicable in a reporting environment.
A TR SESSION
ALTER
n on SYNC WITH PRIMARY performs a blocking wait on the standby database
P upon execution. This command causes the application to be blocked until the standby
database is in sync with the primary database as of the time this command is executed.
When the ALTER SESSION command returns control to the session, the session can continue
to process queries without having to wait for Redo Apply on the standby database.
If Redo Apply is not active or is canceled before the standby database is in sync with the
primary database, an ORA-3173 Standby may not be synced with primary error is
returned.

Creating an AFTER LOGON Trigger for

Synchronization
• Use an AFTER LOGON trigger to force a wait for
synchronization between primary and standby databases.

• Use for dedicated connection only.
• This ensures that the reporting application starts with the
current data without requiring a change to the application
source code.
CREATE TRIGGER adg_logon_sync_trigger
s a
) ha
AFTER LOGON ON user.schema
om
BEGIN
IF (SYS_CONTEXT('USERENV','DATABASE_ROLE') IN
l ฺ c
('PHYSICAL STANDBY'))
m ai ฺ
THEN
9 @ g
u ide
execute immediate 'alter session sync with primary';
i z 9 nt G
END IF; u
pr tude
(
END;
R ON his S
B AR use t
U
Oracle
H icenR s
T l
This type of trigger A
is BE when
useful b l e you are using the standby database for reporting and want
L I Z r a
to be sure that
E the reports
n s fe have the most current data. The standby-only AFTER LOGON trigger
executesIA the ALTERr a SYNC WITH PRIMARY command to force a wait for
I C - t SESSION
R non between the primary database and the standby database. A standby-only
synchronization
A T
P trigger is created and enabled on the primary database, and then becomes part of the redo
that is propagated to the standby database. However, the trigger logic is designed only to take
certain actions if the database role is set to “physical standby.”

Active Data Guard: DML on Temporary Tables
Supported by a new initialization parameter in Oracle Database

12c for all databases:

TEMP_UNDO_ENABLED = false | true
• Separates undo for temporary tables from undo for the

persistent table
– Temporary undo is not logged in redo.
– Temporary undo uses the temporary tablespace. s a
• Enables DML on temporary tables when using Active Data ) ha
l ฺ c om
Guard ai m ฺ
– It is set by default on an Active Data Guard standby
9 @ g
u ide
database. i z 9 nt G
u de tables
pr temporary
– Data definition language (DDL) to (
create
N is S t u
R Odatabase.
must be issued on the p primary
R y th
A use
Z B
I and/or
UOracle
Copyright © 2014,
H icen s
T
E le l
Redo generation on A
a Bread-onlyb database is not allowed. When a data manipulation language
L I Z r a
(DML) operation
E makes n s fea change to a global temporary table, the change itself does not
generateIA a it is only a temporary table. However, the undo generated for the
redo because
r
I C
R does,
change - t
nin turn, generate redo. Prior to Oracle Database 12c Release 1 (12.1), global
A T n o
P temporary tables could not be used on Active Data Guard standbys, which are read-only.
However, in Oracle Database 12c Release 1 (12.1), the temporary undo feature allows the
undo for changes to a global temporary table to be stored in the temporary tablespace instead
of in the undo tablespace. Undo stored in the temporary tablespace does not generate redo,
thus enabling redo-less changes to global temporary tables. This allows DML operations on
global temporary tables on Oracle Active Data Guard standbys.
standbys
To enable temporary undo on the primary database, use the TEMP_UNDO_ENABLED
initialization parameter. On an Active Data Guard standby, temporary undo is always enabled
by default, so the TEMP_UNDO_ENABLED parameter has no effect.
The temporary undo feature requires that the database initialization parameter COMPATIBLE
be set to 12.0.0 or higher. The temporary undo feature on Active Data Guard instances does
not support temporaryy binaryy and character large
g objects.
j

Active Data Guard: Support for Global Sequences
• Sequences created using the default CACHE and NOORDER

options can be accessed from an Active Data Guard

standby database.
• When first accessed by y the standby,
y, the primary
p y allocates
a unique range of sequence numbers.
• When all sequences within a range have been used, the
standby requests another range of numbers.
a
• Because each range assigned to a standby is unique,
there is a unique stream of sequences across the entire om)
has
Data Guard configuration. a ilฺc
• Sequences created with the ORDER and NOCACHE @ gmoptions
i d eฺ
9 t Gu
iz9 estandby
cannot be accessed on an Active DataruGuard n
( p u d
database. N St
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
E le l
Bapplications
To support read-mostly
I Z A r a b by using Active Data Guard, you might have to use
sequences with L
E global s fe
temporary tables. In an Active Data Guard environment, sequences
C A
created Iby
t r a
the primaryn database with the default CACHE and NOORDER options can be
I
R nfrom
accessed -
n standby databases as well. When a standby database accesses such a
A T o
P sequence for the first time, it requests that the primary database allocate a range of sequence
numbers. The range is based on the cache size and other sequence properties specified
when the sequence was created. Then the primary database allocates those sequence
numbers to the requesting standby database by adjusting the corresponding sequence entry
in the data dictionary. When the standby has used all numbers in the range, it requests
g of numbers.
another range
Because the standby’s requests for a range of sequences involve a round-trip to the primary,
be sure to specify a large enough value for the CACHE keyword when you create a sequence
for an Active Data Guard standby. Otherwise, performance could suffer.
In addition, the terminal standby should have a defined LOG_ARCHIVE_DEST_n parameter
that points back to the primary.

Active Data Guard:

Support for Session Sequences
• Session sequences are specifically designed for use with
global temporary tables that have session visibility.

– They return a unique range of sequence numbers within a
session.
– Session sequences are not persistent. The state of the
session sequences accessed during a session is lost when
the session terminates.
• Session sequences are created by the primary database a
and are accessed on any read-write or read-only ) has
database. om
a ilฺc
• To create a session sequence: gm deฺ @ Gui
9 9
r u iz ent
(p Stud
SQL> CREATE SEQUENCE … SESSION;
N
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BaEspecial l e l
A session sequence
I Z Ais
r a b type of sequence that is specifically designed to be used with
global temporaryL
E tables s fethat have session visibility. Unlike existing regular sequences
(referredIA
C t r a n
to as “global” sequences for the sake of comparison), a session sequence returns a
I
R range
unique -
nof sequence numbers only within a session, not across sessions. Session
A T n o
P sequences are not persistent. If a session goes away, so does the state of the session
sequences that were accessed during the session.
Session sequences support most of the sequence properties that are specified when the
sequence is defined. However, the CACHE/NOCACHE and ORDER/NOORDER options are not
relevant to them and are ignored.
Session
S i sequences mustt be b created
t db
by a read-write
d it d database,
t b b
butt th
they can b
be accessed
d on
any read-write or read-only database (either a regular database temporarily open as read-only
or a standby database).

Benefits: Temporary Undo and Sequences
• Reporting and other applications that are generally read-

only but require nonpersistent write access to the database

can be run on an Active Data Guard standby by using
temporary tables.
• Temporary undo reduces the redo volume if it is also
enabled on the primary database. Temporary undo:
– Is not logged in redo
– Improves primary database performance s a
– Reduces network bandwidth consumption ) ha
l ฺ c om
– Reduces standby I/O
m ai ฺ
• Applications that are read-only except for the 9
g ide
requirement
@ u
to generate unique sequences can beroffloaded u iz9 enttoGan
Active Data Guard standby database. N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BE12cbRelease
l e l
I Z A
Prior to Oracle Database
r a 1 (12.1), the inability to use global temporary tables
and sequences L
E for Active
s fe Data Guard limited some read-mostly applications from being
offloaded
C I A
from the
t r a n
primary database to a standby database.
I -
A TRnewntemporary
The on undo and sequences support for Active Data Guard provides many
P benefits. Additional reporting workload can now be migrated to a standby system to reduce
the overhead of system resources in general. Because temporary undo reduces the amount
of redo generated, the amount of redo needed to be shipped to standby database systems is
reduced and results in network performance improvements. The reduction in redo also implies
less redo being written to standby redo logs and local archiving of standby redo logs.
Therefore performance improvements are realized on the primary and standby database
Therefore,
systems and on the network between the two systems.

Supporting Read-Mostly Applications
• Read-mostly applications are predominantly read-only

applications, but require limited read-write database

access.
• Active Data Guard supports
pp the read-only
ypportion of read-
mostly applications if writes are redirected to the primary
database or a local database.
• Redirection of read-write workload does not require
application code changes. a
• Writes can be transparently redirected to the primary om)
has
database if the application adheres to the following:ailฺc
m ฺ
– Modified objects must not be qualified by a schema
9 @ g name.
u ide
– SQL commands must be issued directly i z
from
G not
9 thenclient,
t
u
pr tude
in stored procedures. N ( S
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
E le l
Bthat
Reporting applications
I Z A r a b predominantly read-only, but require limited read-write
are
L
database access fe to as “read-mostly” applications. Active Data Guard enables a
E arensreferred
C A
standby Idatabase
t r ato support the read-only portion of read-mostly applications if writes are
I -
A TR notonthe primary database or a local database.
redirected
P

Example: Transparently Redirecting Writes to the

Primary Database
• Application characteristics:
– Executes as user U
– Reads table U.R (R) and writes to table U.W (W)
– User S has S.R synonym for U.R and S.W synonym for
U.W@primary.
• Create an AFTER LOGON trigger on the standby database:
CREATE TRIGGER adg_logon_switch_schema_trigger
AFTER LOGON ON u.schema s a
BEGIN ) ha
IF (SYS
(SYS_CONTEXT('USERENV','DATABASE_ROLE')
CONTEXT('USERENV' 'DATABASE ROLE')
l ฺ c om
IN ('PHYSICAL STANDBY'))
m ai ฺ
THEN
9 @ g
u ide
execute immediate
i z 9 nt G
'alter session set current_schema = S'; u
pr tude
END IF; (
END;
R ON his S
B AR use t
U
Oracle
H icenR s
T l
Consider an application A BE b l e
as described in the slide. The application executes as user U, reading
L I Z r a
the U.R table
A Eand writing
n s feto the U.W table. The application connects as user U when
executing
I C I - t a
on therprimary database.
A TR S accesses
User
n on U.R with the S.R synonym and U.W with the S.W synonym.
P The AFTER LOGON trigger is created on the standby database for another user, R.
When the application executes on the standby database, it connects as the U user. The
AFTER LOGON trigger fires and transparently switches to the S schema. All reads on R
execute as reads to the U.R table on the standby database. All reads and writes to W execute
as reads and writes to U.W@primary.

Enabling Block Change Tracking

on a Physical Standby Database
• Enable block change tracking on a physical standby
database for fast incremental backups.

• Data file blocks that are affected by each database update
are tracked in a block changeg trackingg file.
• The block change tracking file is a binary file used by
RMAN to record changed blocks to improve incremental
backup performance.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A
With the Oracle ActiveBData b option, you can enable block change tracking on a
Guard
L I Z r a
physical standby
the blockIA
changera n sfe fileWhen
E database.
tracking
you back up the physical standby database, RMAN uses
to quickly identify the blocks that have changed since the last
RIC nonbackup.
incremental
T -t RMAN reads only the changed blocks rather than the entire data file.
PA

Creating Fast Incremental Backups
• Block change tracking optimizes incremental backups:

– Tracks the blocks that have changed since the last backup
• Oracle Database has integrated change tracking:
– A change tracking file is used
used.
– Changed blocks are tracked as redo is generated.
– Database backup automatically uses the changed-block list.
s a
List of changed blocks
1011001010110 g
Change-
m ) ha
CTWR 0001110100101 tracking lฺco
1010101110011 file ma
i
Redo ฺ
generation 9 @ g
u ide
SGA i z 9 Redon t Glog
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A
The goal of an incremental BE backup l e
b is to back up only those data blocks that have changed
L I Z r a
since a previous
A E backup. n s feYou can use RMAN to create incremental backups of data files,
I C I
tablespaces, or the
- t r a entire database. During media recovery, RMAN examines the restored
T Rto determine
files
n o n whether it can recover them from an incremental backup. RMAN always
A
P chooses incremental backups over archived redo logs because applying changes at a block
level is faster than reapplying individual changes.
If you enable the block change tracking feature, Oracle Database tracks the physical location
of all database changes in the change tracking file. RMAN uses this change-tracking data to
determine which blocks to read during an incremental backup, creating much faster
incremental backups by eliminating the need to read the entire data filefile. The maintenance of
this file is fully automatic and does not require your intervention. The size of the change
tracking file is proportional to the following:
• Database size in bytes
• Number of enabled threads in a RAC environment
• Number of old backups maintained by the change tracking file
The minimum size for the change tracking file is 10 MB; new space is allocated in 10 MB
increments. By default, the Oracle Database server does not record block-change
information.

Enabling Block Change Tracking

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
ALTER DATABASE i z 9 nt G
u
pr tude
{ENABLE|DISABLE} BLOCK CHANGE TRACKING (
[USING FILE '...']
R ON his S
B AR use t
U
Oracle
H icenR s
T l
You enable blockZ A BEtracking
change l e
b from the database home page. Click the Policy tab on the
Backup SettingsL I r a
e do not need to set the change tracking file destination if the
fYou
A E page. n s
I C I
DB_CREATE_FILE_DEST
- t r a initialization parameter is set, because the file is created as an
T R Managed
Oracle
n o n File (OMF) file in the DB_CREATE_FILE_DEST location. You can, however,
A
P specify the name of the change tracking file and place it in any location you choose.
You can also enable or disable block change tracking by using an ALTER DATABASE SQL
command. If the change tracking file is stored in the database area with your database files, it
is deleted when you disable change tracking.
You can rename the change tracking file by using the ALTER DATABASE RENAME SQL
command Your database must be in the MOUNT state to rename the tracking file
command. file. The ALTER
DATABASE RENAME FILE command updates the control file to refer to the new location. Use
the following syntax to rename the change tracking file:
ALTER DATABASE RENAME FILE '...' TO '...';

Monitoring Block Change Tracking

SQL> SELECT filename, status, bytes

2 FROM v$block_change_tracking;
SQL> SELECT file#, avg(datafile_blocks),

2 avg(blocks_read),
3 avg(blocks_read/datafile_blocks)
a
has
4 * 100 AS PCT_READ_FOR_BACKUP,
5 avg(blocks)
g m )
o
5 FROM v$backup_datafile
a ilฺc
6 WHERE used_change_tracking = 'YES' gm
@ i d eฺ
7 AND incremental_level > 0
i z 99 nt Gu
8 GROUP BY file#; pru de
O N ( is Stu
A RR se th
I Z B ou
R U and/or
H icen s
T
A BE ble l
The output of the V$BLOCK_CHANGE_TRACKING view shows where the change tracking file
L I Z r a
e change tracking (ENABLED/DISABLED), and the size (in bytes)
is located, the
A Estatusnofsfblock
I
C n-tra
of the file.
I
T R
Querying o V$BACKUP_DATAFILE view shows the effectiveness of block change tracking in
nthe
PAminimizing the incremental backup I/O (the PCT_READ_FOR_BACKUP column). A high value
indicates that RMAN reads most blocks in the data file during an incremental backup. You can
reduce this ratio by decreasing the time between incremental backups.
Sample Formatted Output from the V$BACKUP_DATAFILE Query
FILE#
# BLOCKS_IN_FILE BLOCKS_READ PCT_READ_FOR_BACKUP BLOCKS_BACKED_UP
----- -------------- ----------- ------------------- ----------------
1 56320 4480 7 462
2 3840 2688 70 2408
3 49920 16768 33 4457
4 640 64 10 1
5 19200 256 1 91

Data Guard 12c: Far Sync
What is a Far Sync?

• A lightweight Oracle database instance

– Only a standby control file, password file, standby redo logs,
and
a daarchive
c e logs
ogs
– No Oracle data files, no database to open for access, not
running Redo Apply
• Deployed within a distance such that the primary can
tolerate the impact of network latency on synchronous s a
transport
p ) ha m
l ฺ c o
– Looks like any other Data Guard destination to the primary
m ai ฺ
database
9 @ g
u ide
– With Data Guard 12c Fast Sync, further extends i z 9 nthe t Gpractical
distance between the primary and a(p
u
r Sync
Far de
t u
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A Data Guard FarZSync A BE l e
b Data Guard destination that accepts redo from the
is a remote
L
primary database
I fe r a
E and n sredistributes that redo throughout the Data Guard configuration. It is
similar toIA
a physical
r a standby database in that it manages a control file, receives redo into
I C
R nRedo
Standby - t
n Logs (SRLs), and archives those SRLs to local Archived Redo Logs
A T o
P (ARLs). However, unlike a standby database, a Far Sync does not manage data files, cannot
be opened for access, and cannot run Redo Apply. These limitations yield the benefit of using
fewer disk and processing resources. More importantly, a Far Sync provides the ability to fail
over to a terminal database with no data loss.
Many variables, such as the redo write size, available network bandwidth, round-trip network
latency and standby I/O performance while writing to the standby redo logs,
latency, logs impose practical
limitations on the distance that a standby can reside from a primary database. This includes a
Far Sync. A Data Guard 12c new feature called Fast Sync removes the standby I/O
performance from the limitations list and helps to extend the distance that a Far Sync can
reside from the primary database. Data Guard 12c Fast Sync will be discussed later in the
course.

Far Sync: Redo Transport

Primary ASYNC Standby

SYNC
Far Sync
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
The diagram in the A BEdisplays
slide l e
b flat projection of a world map showing North America,
a
L I Z r a
South America,
A E Europe,n s feand Africa. Somewhere in North America, an icon in the slide
I C I
represents
- t r a database system. Somewhere in Europe, an icon in the slide
the primary
R noanstandby database system. A short distance from the primary database system is
represents
T
A
P a new type of instance called a Far Sync that is introduced as a new feature with Data Guard
in Oracle Database 12c.
The redo transport uses synchronous (SYNC) transmission between the primary database
system and a Far Sync. This imposes a practical limit on the distance between the primary
database system and the Far Sync instance because it impacts the performance on the
primary database.
database The log writer (LGWR) process of the primary database system has to wait
for confirmation from the Network Server SYNC (NSS) process that the redo has been
transmitted over the network before it can proceed with the next transaction. Redo transport
from the Far Sync to the standby database system uses asynchronous communication. This
eliminates the requirement of waiting for acknowledgment from the Network Server ASYNC
(NSA) process on the Far Sync instance, creating near zero performance impact because of
network transmission even if intercontinental distances are involved.

Far Sync: Redo Transport
How does redo transport work with a Far Sync configuration?

• The Far Sync instance receives redo synchronously from

• The Far Sync instance forwards redo asynchronously in
real time to its final destination.
• Redo transport supports one local and up to 30 additional
local or remote destinations.
a
• Oracle Recovery Manager (Oracle RMAN) deletion polices
) has
are used to automate archive log management
management. om
a i lฺc
• A Far Sync instance can also compress redo transport.
gm ideฺ
@ u
• An alternate Far Sync can be used for HA. z99 t G r ui den
p
O N ( is Stu
A RR se th
I Z B ou
R U and/or
H icen s
T
E le l
A
In maximum availabilityBmode, bthe Far Sync instance is relatively close to the primary
L I Z r a
database to E
A n s fe latency, and the primary database services the Far Sync by
minimize network
I
C n-tra
using SYNC
I transport.
R nodisk atdatabase
T a primary
When services a Far Sync by using SYNC transport, all committed redo
PAresides on the Far Sync. That way, the Far Sync can use one of the terminal standby
destinations for a no-data-loss failover if the primary database is lost.
The Far Sync uses ASYNC transport to redistribute the incoming redo to terminal standbys
that can be much farther away. This extends no-data-loss protection to destinations that are
too far away for a primary database to feasibly service directly with SYNC transport because
off the
th resulting
lti d degradation
d ti iin ttransaction
ti throughput.
th h t This
Thi iis a case where
h aF
Far S
Sync iis
beneficial even if there is only one standby destination in the configuration.
The redo transport architecture for a Far Sync is configured like any other type of standby
database: Use the LOG_ARCHIVE_DEST_n parameter, which supports up to 30 destinations.
Other parameters, such as DB_UNIQUE_NAME, LOG_ARCHIVE_CONFIG, FAL_SERVER,
FAL_CLIENT, LOG_FILE_NAME_CONVERT, and DB_FILE_NAME_CONVERT, are also
g
configured in the same wayy as anyy other type
y of standby y database. With the Oracle Database
12c Advanced Security option, redo transport compression is also available.

Far Sync: Alternate Redo Transport Routes
Alternate Redo Destination

Physical Standby
Primary (london)
(b t )
(boston)
Far Sync (bostonFS)
LOG_ARCHIVE_DEST_STATE_2='ENABLE'
s a
LOG_ARCHIVE_DEST_2='SERVICE=bostonFS SYNC AFFIRM MAX_FAILURE=1
) ha
ALTERNATE=LOG ARCHIVE DEST 3 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
ALTERNATE=LOG_ARCHIVE_DEST_3 VALID FOR=(ONLINE LOGFILES,PRIMARY ROLE)
l ฺ c om
ai ฺ
DB_UNIQUE_NAME=bostonFS'
m
LOG_ARCHIVE_DEST_STATE_3='ALTERNATE'
9 @ g
u ide
i z 9 nt G
LOG_ARCHIVE_DEST_3='SERVICE=london ASYNC ALTERNATE=LOG_ARCHIVE_DEST_2 u
pr tude
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=london' (
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
A BE blewith
In the event that communication the Far Sync instance is lost, you can optionally
L I Z r a
A n s fe to automatically become the alternate destination. This will
configure theEterminal standby
I C I
reduce the amount
- t r a of data loss by allowing Oracle Data Guard to ship redo asynchronously
A TR from
directly
n onthe primary to the terminal standby, temporarily bypassing the Far Sync instance.
P This enables Oracle Data Guard to continue sending redo, asynchronously, to the terminal
standby london when it can no longer send the redo directly to the Far Sync instance
bostonFS. When the Far Sync instance becomes available again, Oracle Data Guard
automatically resynchronizes the Far Sync instance bostonFS and returns to the original
configuration in which the primary sends redo to the Far Sync instance and the Far Sync
instance forwards that redo to the terminal standby.
standby When the synchronization is complete
complete,
the alternate destination (LOG_ARCHIVE_DEST_3 in the example) will again become dormant
as the alternate.

Oracle Data Guard 12c:

Far Sync Creation
• Create a control file using the mounted primary database:
SQL> ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE

AS '/tmp/boston1.ctl';
• Copy th
C the parameter
t file
fil (PFILE) and
d password d file
fil used dbby
the primary database. (Several initialization parameters
must also be modified for the Far Sync instance.)
• Copy the control file to the Far Sync system. a
• Create standby redo log files as you would for any ) has
standby. om
a ilฺc
• Start the Far Sync instance and mount the control
@ gmfileidbyeฺ
using standard syntax. i z 99 nt Gu
• The DATABASE_ROLE column in V$DATABASE
( pru tude will contain
N S
the value FAR SYNC. RO this
B AR use
U
Oracle
R
H icen s
T l
You start creatingZ aA BE
Far Syncbby l eissuing a command on the primary database to create a new
L
Far Sync instance
I r a
fe file. The primary database must be mounted or open to issue the
A E controln s
command.
I C I - t r a
The syntax for creating a Far Sync instance control file is:
A TR ALTER
SQL>
n on DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS
P '/PATH/FILENAME';
Next, copy the resulting control file, along with a copy of the primary database parameter file
and the password file, to the machine that will host the Far Sync instance. It is assumed that
the database software has already been installed on the machine that will host the Far Sync
instance and a database listener has been configured. If the primary database uses a server
parameter file (SPFILE)
(SPFILE), create a parameter file (PFILE) before copying the file
file. The following
list of initialization parameters may need changing for the Far Sync instance:
DB_UNIQUE_NAME; CONTROL_FILES, FAL_SERVER, LOG_ARCHIVE_CONFIG, and
LOG_ARCHIVE_DEST_n.
On both the primary and Far Sync systems, use Oracle Net Manager to create a network
service name for the primary and standby databases that will be used by redo transport
services. This name will be supplied
pp in the LOG_ARCHIVE_DEST_n p parameter. Use standard
syntax to start and mount the Far Sync. After you mount the Far Sync, the DATABASE_ROLE
column in the view V$DATABASE shows ‘FAR SYNC’.

Benefits: Far Sync
Provides no-compromise data protection and primary offload

• Ideal combination of attributes

– Best data protection, least performance impact
– Lower cost and complexity compared to previous multisite
architecture
– No change in applications required
– Ideal for a combined near HA plus far DR model adopted by
a growing number of users s a
• Relevant to existing Data Guard ASYNC configurations ) ha
l ฺ c om
– Enables the implementation of SYNC zero data loss a i
where
only ASYNC was previously possible @ g m
i d eฺ
– Offloads overhead for redo transport compression i z 99 nt andGu for
servicing multiple destinations N (p
ru ude
O i s St
A RR se th
I Z B ou
R U and/or
H icen s
T l
There are many benefits A BEof abFar l eSync. A Far Sync transparently integrates in a maximum
L I Z r a
availability mode
A n s fe for no-compromise data protection. It requires no changes in
E configuration
I C I
applications
- t a
thatrcurrently use a primary database and standby database architecture. A Far
R hasnthe
Sync
T o nleast performance impact, because it does not manage data files, cannot be
A
P opened for access, and cannot run Redo Apply. Features such as redo transport compression
that would have a performance impact on a primary database can be offloaded to the Far
Sync host.
It is ideal for an HA model serving as a nearby archived log repository, yet still allows the
benefits of a far-away disaster recovery model by extending no-data-loss protection to
destinations that are too far away for a primary database to feasibly service directly by using
SYNC transport.

Far Sync: Alternate Design

Standby
Far Sync
Primary ASYNC
St db
Standby
Standby
s a
) ha
ASYNC
l ฺ c om
i
aStandby
@ g m
i d eฺ
i z 99 nt Gu
( pru tude
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
Up to this point inZ A
this Blesson, bthe discussion of a redo transport mechanism from a primary
database to E L I
a Far Syncfe r a
has used synchronous transmission. It is possible to also use
I A
asynchronous redo a n s
transport in a maximum performance Data Guard configuration.
I C - t r
A TR
In maximum
n onperformance mode, the primary database services the Far Sync destination by
P using ASYNC redo transport, regardless of the physical distance between the primary and the
Far Sync. High network latencies do not affect transaction throughput when a destination is
serviced with ASYNC transport.
In maximum performance mode, a Far Sync can benefit Data Guard configurations that
manage more than one remote destination. Each destination that a primary directly services
t k computing
takes ti resources away from
f applications
li ti running
i on th
the primary.
i Wh
When a F Far SSync
is used, the primary only has to service the Far Sync, which then services the rest of the
configuration. The performance benefit increases as the number of destinations increases.
The slide shows a world map with a primary database in North America using ASYNC redo
transport to a Far Sync located in Europe. The Far Sync is then used to cascade the primary
redo to multiple standby sites located throughout Europe and Africa. Upto 30 terminal
destinations are supported.

Real-Time Cascade
• Traditional cascaded standby database

– Primary redo is shipped to Standby 1 and then forwarded to

Standby 2.
– The redo is forwarded at the log
g switch, making
g Standby
y2
always in the past of Standby 1.
• Real-time cascade, new for Data Guard 12c
– Standby 1 forwards the redo to Standby 2 in real time, as it is
received. a
– There is no propagation delay of Standby 2 waiting for a ) has
om
primary log switch. ilฺc
g ma deฺ
SYNC or ASYNC ASYNC 9@
9 G ui
r u iz ent
N (p Stud
Primary Standby 1O is Standby 2
R R t h
B A use
Z
I and/or
UOracle
R s e
T H icen
BEstandby l e l
With traditional cascaded
I Z A r a b database configurations prior to Oracle Database 12c,
primary database L
E redo s fisetransported to a standby database and that standby database
cascades
C I Aor forwards
t r a n the primary redo to additional standby databases. However, traditionally
the I
Rredo nisonot -
n immediately cascaded. Primary database redo is written to the standby redo
A T
P log as it is received at a cascading standby database. This redo was cascaded only after the
standby redo log file that it was being written to had been archived locally.
Because standby redo logs are usually configured with the same size as the primary
database redo log files, the rate that a standby redo log switches and is archived locally
should be about the same time frequency as the primary database log switch rate. Depending
on the size of the redo logs and the rate of redo generation,
generation this log switch could take hours
hours. It
is also common that the time interval between switches varies. Even when the redo logs were
not full, forced log switches on the primary database were typically used to standardize the
time interval of log switches. However, the time meant that the final cascaded standby
database was guaranteed to lag behind the primary database.
As of Oracle Database 12c Release 1 (12.1), primary database redo is cascaded
immediately, as it is being written to the standby redo log file. The terminal destination,
th f
therefore, has
h minimal
i i l redod ttransportt llag with
ith respectt tto th
the primary
i d
database.
t b O
Only
l physical
h i l
standbys and Far Syncs can cascade redo.

Traditional Multi-Standby Database Architecture
Multiple standby database configurations, the gold standard of

WAN zero-data-loss architectures, consist of:

• A local SYNC standby database for zero-data-loss
p
protection
– Fast, local HA failover with zero data loss
– Offload RMAN backups, read-only workload, data extracts
– Real Application Testing using Data Guard Snapshot
Standby s a
– Database rolling maintenance and standby-first
standby first patching ) ha
l ฺ c om
• A remote ASYNC standby database for geo-protection
m ai ฺ
SYNC ASYNC 9 @ g
u ide
i z 9 nt G
Overhead on primary for u
pr2 locations de
( t u
Local Standby Primary R ON his S Remote Standby
B AR use t
U
Oracle
H icenR s
T l
A
Multiple standby database BE configurations
b l e are very common in zero-data-loss architectures,
L I Z r a
where the primary
A E database n s fe services one local standby database and one remote standby
database.
I C I The local
- t r a standby database may be located in the same data center with high-
T R LAN
speed
n o n
connections using synchronous redo transport. This provides very fast HA failover
A
P in the event of a problem with the primary database system. It is also often used for offloading
backups, read-only reporting, data extracts, rolling maintenance, and patching.
When the standby database is local to the primary database system, one disadvantage is
site-wide disasters (for example, hurricanes or tornadoes could potentially impact entire data
centers). To achieve zero data loss for all disasters, a second remote standby database is
often used.
used The remote distance often necessitates asynchronous redo transport.
transport
This multiple standby database configuration places additional performance overhead and
burden on the primary database system because of the need to ship redo to two different
locations. Traditional cascaded standby database configuration could not provide zero data
loss for the remote standby database system because of redo transport lag.

Benefits: Real-Time Cascade
Multiple standby database configurations can now use real-

time cascade.
• Less performance overhead
– The primary database ships to a single destination
destination.
• Less network volume at the primary database
SYNC ASYNC
s a
) ha m
l ฺ c o
Primary Local Standby ai ฺ
Remote Standby
m
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
With real-time cascade A Bintroduced
b in Oracle Database 12c, the terminal destination has
L I Z
minimal redoEtransport flag r a
e for the primary database. Therefore, the local standby can be used
I
to cascade A the redo a n s
to the remote standby. This reduces the volume of redo sent from the
I C - t r
A TR by
primary
n n which results in less performance impact on the primary database.
ohalf,
P

Quiz
The STANDBY_MAX_DATA_DELAY parameter can be set at the

system level.
a. True
b False
b.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: b
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Summary

• Use real-time query to access data on a physical standby

database
• Enable RMAN block change tracking for a physical
standby database
• Use Far Sync to extend zero data loss protection for
intercontinental configurations
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA


• Enabling Active Data Guard real-time query

• Enabling block change tracking
• Adding a Far Sync to the environment
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
C
Creating
ti and
d Managing
M i a Snapshot
S h t Standby
St db
Database
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
Objectives

• Create a snapshot standby database to meet the

requirement for a temporary, updatable snapshot of a
physical
p y standbyy database
• Convert a snapshot standby database back to a physical
standby database
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Snapshot Standby Databases: Overview
• A snapshot standby database is a fully updatable standby

database created by converting a physical standby

database.
• Snapshot
p standby
y databases receive and archive—but do
not apply—redo data from a primary database.
• When the physical standby database is converted, an
implicit guaranteed restore point is created and Flashback
Database is enabled. s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A snapshot standby A BE bislea lfully updatable standby database that is created by
database
converting aE LIZ sstandby
physical f era database to a snapshot standby database. A snapshot standby
database
C IAreceives
t r n archives—but does not apply—redo data from a primary database.
aand
Redo I
R data n -
received from the primary database is applied when a snapshot standby database
A T n o
P is converted back to a physical standby database, after discarding all local updates to the
snapshot standby database.
You can create a snapshot standby database by using DGMGRL commands or SQL
commands.
When the standby database is converted to a snapshot standby database, an implicit
guaranteed
t d restore
t point
i t is
i created
t d and
d Fl
Flashback
hb k DDatabase
t b iis enabled.
bl d Aft
After performing
f i
operations on the snapshot standby database, you can convert it back to a physical standby
database. Flashback Database will be discussed later in the course.
Data Guard implicitly flashes the database back to the guaranteed restore point and
automatically applies the primary database redo that was archived by the snapshot standby
database since it was created. The guaranteed restore point is dropped after this process is
completed.

Snapshot Standby Database: Architecture

Primary
database MRP Snapshot
transactions standby
database
LGWR NSSn RFS
Transactions
Oracle net
Online
redo Standby
logs redo logs
s a
) ha
ARC0 l ฺ c om
m ai ฺ
ARC0
9 @ g
u ide
i z 9 nt G
u
( u
Archived redo
B AR use t
U
Oracle
H icenR s
T l
A BEdatabase
After a physical standby l e
b is converted to a snapshot standby database, Redo Apply
L I Z r a
no longer applies
transportIA
E (SYNC
methodra n sfeor data.
the redo The redo data continues to be received using the defined
ASYNC), but it is not applied until the snapshot standby database is
RIC noback
converted
T n-tto a physical standby database.
PA

Converting a Physical Standby Database

to a Snapshot Standby Database
To convert a physical standby to a snapshot standby:
1. Stop Redo Apply if it is active.

2. Ensure that the database is mounted, but not open.
3 Ensure that the fast recovery area has been configured
3. configured.
4. Issue the following SQL statement to perform the
conversion:
SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
s a
) ha m
o
5. Open the snapshot standby database in read-write a ilฺc
mode.
@ gm ideฺ
SQL> ALTER DATABASE OPEN;
i z 99 nt Gu
( pru tude
R ON his S
B AR use t
U
Oracle
H icenR s
T l
The slide lists theZ A BE
steps l e
b to convert a physical standby database to a snapshot
necessary
L
standby database.
I r a
fe converting the standby database, Redo Apply must be stopped if it
A E Before n s
I C I
is running. If Redo
- t r aApply is running, the following error message will be returned:
R nalter
TSQL> on database convert to snapshot standby;
A
P alter database convert to snapshot standby
*
ERROR at line 1:
ORA-38784: Cannot create restore point
'SNAPSHOT_STANDBY_REQUIRED
Q _08/16/2013
/ /
16:25:49'.
ORA-01153: an incompatible media recovery is active

Activating a Snapshot Standby Database:

Issues and Cautions
When activating a snapshot standby database, be aware of:
• Potential data loss with a corrupted log file

• Lengthy conversion of the snapshot standby database to a
primary database in the event of a failure of the primary
database
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A
Keep the followingZin BE when
mind b l eactivating a snapshot standby database:
L I r a
fe when a log file is corrupted: The snapshot standby database
• Potential
A E datanloss
s
IC I
accepts redo
- tralog
edo og files
es but does not ot app
applyy tthem.
e If tthere e e is s a cocorrupted
upted redo
edo log
og file
e at tthe
e
R n
no standby
T snapshot database, it is not discovered until the database is converted back to
PA a physical standby database and the managed recovery process (MRP) is started. If the
primary database is unavailable at that time, there is no way to retrieve that log. Also,
the loss or corruption of a flashback log file might prevent conversion back to a physical
standby database.
• Lengthy conversion of the snapshot standby database to a primary database: In
the event of a failure of the primary database,
database the snapshot standby database can be
converted back to a physical standby database. The redo that has been received can
then be applied, and the database can be converted to a primary database. If the
snapshot standby database lags far behind the primary database, it may take a long
time to apply the redo that has been received and convert it to the primary database.

Snapshot Standby Database: Target Restrictions
A snapshot standby database cannot be:

• The only standby database in a maximum protection

configuration
• The target of a switchover
• A fast-start failover target
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
When you convertZthe A Bphysicalb standby database to a snapshot standby database, it cannot
L I r a
be the only standby
I
protectionA E ndatabase
mode.ra
sfe in the configuration if your configuration is in maximum
In addition, you cannot make changes to the configuration after converting
to R IC nstandby
a snapshot -t database that would create this situation. Protection modes will be
A T n o
P discussed later in the course.
You cannot perform a switchover to a snapshot standby database.
A snapshot standby database cannot be configured as a fast-start failover target.

Viewing Snapshot Standby Database Information
View the database role by querying V$DATABASE:

SQL> SELECT database_role FROM v$database;

DATABASE_ROLE
----------------
SNAPSHOT STANDBY
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E oflethe l
The DATABASE_ROLE A Bcolumn b V$DATABASE view indicates that the database is a
L I Z r a
snapshot standby
A n s fe
E database.
I
IC n-tra
T R no
PA

Snapshot Standby Space Requirements
Monitor the space requirements for enabling snapshot standby:

SQL> select file_type, number_of_files,

percent_space_used from v$recovery_area_usage;
FILE_TYPE NUMBER_OF_FILES PERCENT_SPACE_USED

------------------ --------------- ----------------
CONTROL FILE 0 0
REDO LOG 0 0 a
ARCHIVED LOG
BACKUP PIECE
106
1
41.81
17 m)
.17
has
0ฺc
l o
IMAGE COPY 0 i
FLASHBACK LOG 2 g ma.98deฺ
FOREIGN ARCHIVED LOG 0 9 9 @ Gui0
AUXILIARY DATAFILE COPY 0 ruiz ent 0 (p Stud
N
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BE notbhavel e l
Flashback Database
I Z Adoes
r a to be enabled to issue the command to convert a physical
L
standby database fe
E tonassnapshot database; however, the flash recovery area must be
C I
configured.A t a
The rcommand will automatically enable Flashback Database and create a
I
R norestore
guaranteed -
n point. This will result in a flashback logs being created in the flash
A T
P recovery area. If there is not enough space in the flash recovery area to create the flashback
logs, an error will occur and an error message written to the alert log. The longer the period of
time that the standby database is in the snapshot mode, the larger the flashback logs will
become. It will be necessary to monitor this space usage with the SQL statement presented in
the above slide. The above query monitors overall space usage in the flash recovery area. To
p
determine the specific space
p requirements
q for the g
guaranteed restore p point that was created,
the following query can be used:
SQL> SELECT NAME, STORAGE_SIZE FROM V$RESTORE_POINT;
NAME STORAGE_SIZE
--------------------------------------------- ------------
SNAPSHOT_STANDBY_REQUIRED_08/16/2013 16:41:11 52428800

Converting a Snapshot Standby Database

to a Physical Standby Database
To convert a physical standby to a snapshot standby:
1. On an Oracle Real Applications Cluster (Oracle RAC)

database, shut down all but one instance.
2 Ensure that the database is mounted
2. mounted, but not open
open.
3. Issue the following SQL statement to perform the
conversion:
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A
Use the CONVERT DATABASE BE bcommand l e to convert the database back to a physical standby
L I Z r a
database. The
A E snapshotn s fedatabase must have been opened at least once in read-write mode
before itIcan a
be converted
r back to a physical standby; otherwise the following error is
I C - t
A TR non
returned:
P SQL> alter database convert to physical standby;
alter database convert to physical standby
*
ERROR at line 1:ORA-16433: The database or pluggable database must
be opened in read/write mode.
Note: The above error was generated by attempting to immediately convert back to physical
standby before ever opening the snapshot standby database.
If the snapshot standby is currently open, it must be shut down and started back up in the
MOUNT mode to covert back to a physical standby. Otherwise the following error occurs:
ORA-01126: database must be mounted in this instance and not open
in any instance

Quiz
A snapshot standby database can be created from a logical

standby database.
a. True
b False
b.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: b
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Summary

• Create a snapshot standby database

• Convert a snapshot standby database back to a physical
standby database
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA


• Converting a physical standby database to a snapshot

standby database
• Updating the primary database and the snapshot standby
database
• Converting the snapshot standby database back to a
physical standby database
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
C
Creating
ti a Logical
L i l Standby
St db Database
D t b
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
Objectives

• Determine when to create a logical standby database

• Create a logical standby database
• Manage SQL Apply filtering
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Benefits of Implementing a
• Provides an efficient use of system resources:
– Open, independent, and active production database

– Additional indexes and materialized views can be created for
p
improved q
queryyp
performance
• Reduces workload on the primary database by offloading
the following workloads to a logical standby database:
– Reporting
– Summations s a
– Queries ) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A logical standby Z A BE provides
database b l e benefits in disaster recovery, high availability, and data
protection that L I r a
fe to those of a physical standby database. It also provides the
E are similar
n s
followingIA
R I C n-tra
specialized benefits:
no utilization
T• Efficient
PA independent,
of system resources: A logical standby database is an open,
and active production database. It can include data that is not part of the
primary database, and users can perform data manipulation operations on tables in
schemas that are not updated from the primary database. It remains open while the
tables are updated from the primary database, and those tables are simultaneously
available for read access. Because the data can be presented with a different physical
layout, additional indexes and materialized views can be created to improve your
reporting and query requirements and to suit your specific business requirements.
Note: Oracle Database 12c offers the Active Data Guard option. Active Data Guard
includes the real-time query feature, which enables you to open a physical standby
database in read-only mode while Redo Apply is active. However, you cannot add
additional structures to the physical standby database as you can with a logical standby
database.
• Reduction in primary database workload: The logical standby tables that are updated
from the primary database can be used for other tasks (such as reporting, summations,
and queries), thereby reducing the primary database workload.

Benefits of Implementing a
• Provides data protection:
– Primary database corruptions not propagated

• Provides disaster recovery capabilities:
– Switchover and failover
– Minimizes down time for planned and unplanned outages
• Can be used to upgrade Oracle Database software and
apply patch sets
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
• Data protection: A BAElogical
b l estandby database provides a safeguard against data
L I Z r a
corruption
E andnuser s feerrors. Primary-side physical corruptions do not propagate through
theIA
redo datar a are transported to the logical standby database. Similarly, user errors
that
I C - t
TR thatnmay
on cause the primary database to be permanently damaged can be resolved
PA before application on the logical standby through delay features.
• Disaster recovery: A logical standby database provides a robust and efficient disaster-
recovery solution. Easy-to-manage switchover and failover capabilities enable easy role
reversals between primary and logical standby databases, thereby minimizing the down
time of the primary database for planned and unplanned outages.
• Database upgrades: A logical standby database can be used to upgrade Oracle
Database software and apply patch sets with almost no down time. The logical standby
database can be upgraded to the new release and switched to the primary database
role. The original primary database is then converted to a logical standby database and
upgraded.
Note: See the lesson titled “Patching and Upgrading Databases in a Data Guard
Configuration” for additional information about using a logical standby database to
perform
f upgrades.

Logical Standby Database:

SQL Apply Architecture
Production Logical standby
database database
SQL
Redo transport Apply
Transform redo
information into s a
SQL ) ha
l ฺ c om
m ai ฺ
9 @ u ide
g Reports
i z 9 nt G
u
pr Logical destandby
Primary ( t u
database
R ON his Sdatabase
B AR use t
U
Oracle
H icenR s
T l
In a logical standby A BE bconfiguration,
database l e Data Guard SQL Apply uses redo information
L I Z r a
shipped fromEthe primary
A n s fesystem. However, instead of using media recovery to apply changes
I C I
(as in the physical
- t r astandby database configuration), archived redo log information is
R noninto equivalent SQL statements by using LogMiner technology. These SQL
transformed
T
A
P statements are then applied to the logical standby database. The logical standby database is
open in read/write mode and is available for reporting capabilities.

SQL Apply Process: Architecture
LCR
Reader Preparer LCR Builder

:
Redo Shared
records pool
Redo data from Logical change records not
primary database Log Mining grouped into transactions Transaction
groups
Apply processing
s a
) ha
Applier Coordinator Analyzer
l ฺ c om
m ai ฺ
Transactions to
be applied
Transactions
9
sorted@ in
g
u ide
i z 9 nt G
Data files
pr tuu dependency
de
( order
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A
SQL Apply uses aZcollection e l execution servers and background processes that
BE ofblparallel
apply changesE Lfrom ra database to the logical standby database as follows:
I thefeprimary
• ICTheIeAreader
eadetrpa ns reads
process
ocess eads redoedo records
eco ds fromo tthe ea archived
c ed redo edo logog files.
es
R o n
T• Thenpreparer-
processes convert the block changes into table changes or logical change
PA records (LCRs). At this point, the LCRs do not represent any specific transactions.
• The builder process assembles completed transactions from the individual LCRs.
• The analyzer process examines the records, possibly eliminating transactions and
identifying dependencies between the different transactions.
• The coordinator p
process ((LSP):
)
- Assigns transactions
- Monitors dependencies between transactions and coordinates scheduling
- Authorizes the commitment of changes to the logical standby database
• The applier process:
- Applies the LCRs to the database
- Asks the coordinator process to approve transactions with unresolved
dependencies, scheduled appropriately so that the dependencies are resolved.
- Commits the transactions

Preparing to Create a
Perform the following steps on the primary database before
creating a logical standby database:

• Check for unsupported objects.
• Be aware of unsupported DDL commands.
commands
• Ensure row uniqueness.
• Verify that the primary database is configured for
ARCHIVELOG mode.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BE
When creating a logical standbyb l edatabase, you must take several actions before you begin.
L I Z r a
The next slides
A E cover
n s fepreparation steps in detail.
the
I
IC n-tra
T R no
PA

Unsupported Objects
• User tables placed in internal schemas will not be

maintained.
• Log apply services automatically exclude unsupported
objects
j when applying
pp y g redo data to the logical
g standby
y
database.
• Unsupported objects:
– Tables and sequences in the SYS schema
a
– Tables used to support materialized views
) has
– Global temporary tables o m
a
– Tables with unsupported data types (listed in the next lฺc
islide)
m ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A
If the primary database Bcontains
b unsupported tables, log apply services automatically exclude
L I Z r a
these tablesE
A n s fe redo data to the logical standby database.
when applying
I
IC n-tra
T R no
PA

Unsupported Data Types
• Log apply services automatically exclude entire tables with

unsupported data types when applying redo data to the

logical standby database.
• Unsupported
pp data types:
yp
– BFILE
– ROWID and UROWID
– Collections (including VARRAYS and nested tables)
– Objects with nested tables and REFS s a
) ha
– The following Spatial types
l ฺ c om
MDSYS.SDO_GEORASTER
—
m ai ฺ
MDSYS.SDO_TOPO_GEOMETRY
—
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A
Ensure that your logicalBE b
standby l edatabase can support the data types of the database objects
L I Z e r a
that are defined
A E in your
n s fprimary database.
Note: I
ICSee Oracle
- traData Guard Concepts and Administration for additional information about
T R
unsupported n
no level
data types and objects. SecureFile LOBs are supported if the database
PAcompatibility is set to 11.2 or higher.

Identifying Internal Schemas
Query DBA_LOGSTDBY_SKIP on the primary database for

internal schemas that will be skipped:

SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT =
'INTERNAL SCHEMA' ORDER BY OWNER;
Owner
-----------------------------------------
ANONYMOUS
APPQOSSYS
AUDSYS
BI
s a
CTXSYS
) ha
…
l ฺ c om
SYSKM
m ai ฺ
g ide
SYSTEM
WMSYS 9 @
9 nt G u
XDB
u i z
XS$NULL ( pr tude
30 rows selected.
R ON his S
B AR use t
U
Oracle
H icenR s
T l
Some schemas that A BEwithbthe
ship l e Oracle database (for example, SYSTEM) contain objects
L I Z r a
that will be implicitly
A E nmaintained
s fe by SQL Apply. However, if you put a user-defined table in
SYSTEM,
I C I it will not
- t r a be maintained even if it has columns of supported data types. Query the
T R DBA_LOGSTANDBY_SKIP
view
n o n to indentify internal schemas as shown in the slide. Tables in
A
P these schemas that are created by Oracle will be maintained on a logical standby if the
feature implemented in the schema is supported in the context of logical standby. User tables
placed in these schemas will not be replicated on a logical standby database and will not
show up in the DBA_LOGSTDBY_UNSUPPORTED view.
Note: The query shown in the slide can return a different listing if it is run at the container
level or the PDB level in a multitenant architecture.
architecture Because Data Guard standby databases
are copies of the entire container database, you should run the query against each container
database and all pluggable databases within the container.
For the demo database used in the practices that contains 1 PDB with the sample schemas
installed, there are 29 internal schemas in the CDB, and 30 internal schemas in the PDB. The
following query returns over 1875 individual tables:
SELECT owner,table_name FROM dba_tables WHERE owner IN (SELECT
owner FROM dba_logstdby_skip WHERE statement_opt = 'INTERNAL
SCHEMA');

Checking for Unsupported Tables
Query DBA_LOGSTDBY_UNSUPPORTED on the primary

database for unsupported owners and tables:

SQL> SELECT DISTINCT OWNER,TABLE_NAME FROM
DBA_LOGSTDBY_UNSUPPORTED ORDER BY OWNER,TABLE_NAME;
OWNER TABLE_NAME
------------------------------ ------------------------------
IX AQ$_STREAMS_QUEUE_TABLE_G
IX AQ$_STREAMS_QUEUE_TABLE_H
…
s a
OE CATEGORIES_TAB
) ha
OE CUSTOMERS
l ฺ c om
OE PURCHASEORDER
m ai ฺ
g ide
PM PRINT_MEDIA
SH DIMENSION_EXCEPTIONS 9 @
9 nt G u
u i z
20 rows selected. ( pr tude
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
You can query DBA_LOGSTDBY_UNSUPPORTED_TABLE to determine which tables in the
L I Z r a
primary database
A E are n s fesupported by log apply services.
not
Note: I traowned by the schemas identified in the previous slide will not show up in
ICUser tables
-
R n
T query.oThis query will return different results if run against the container or pluggable
this
PAdatabasenin a multitenant architecture.

Checking for Tables

with Unsupported Data Types
Query DBA_LOGSTDBY_UNSUPPORTED on the primary
database for tables with specific unsupported data types:

SQL> SELECT table_name, column_name, data_type FROM
dba_logstdby_unsupported WHERE owner = 'OE';
TABLE_NAME COLUMN_NAME DATA_TYPE

--------------- -------------------- ----------
CUSTOMERS PHONE_NUMBERS VARRAY
PURCHASEORDER SYS_NC_ROWINFO$ OPAQUE
CATEGORIES_TAB CATEGORY_NAME VARCHAR2
s a
CATEGORIES_TAB CATEGORY_DESCRIPTION VARCHAR2
) ha
CATEGORIES TAB
CATEGORIES_TAB CATEGORY
CATEGORY_ID
ID NUMBER
l ฺ c om
CATEGORIES_TAB PARENT_CATEGORY_ID NUMBER
m ai ฺ
6 rows selected. 9 @ g
u ide
i z 9 nt G
u
pr tude
(
Note: Remove the WHERE clause for
R ONa full h i s S
listing.
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
You can query the DBA_LOGSTDBY_UNSUPPORTED data dictionary view to see all tables that
contain dataE L I Z r a
e not supported by logical standby databases. These tables are not
types that fare
I
maintained A (thatris, n s
a do not have DML applied) in the logical standby database. Changes
they
I C - t
R to nunsupported
made n data types, tables, sequences, or views on the primary database are
A T o
P not propagated to the logical standby database, and no error message is returned.
It is a good idea to query this view on the primary database to ensure that those tables that
are necessary for critical applications are not in this list before you create the logical standby
database. If the primary database includes unsupported tables that are critical, consider using
a physical standby database instead.
Note: This view does not show any tables from the SYS schema because changes to the SYS
schema object are not applied to the logical standby database.

SQL Commands That Do Not Execute

on the Standby Database
• ALTER DATABASE • EXPLAIN
• ALTER MATERIALIZED VIEW • LOCK TABLE

• ALTER MATERIALIZED VIEW LOG • SET CONSTRAINTS
• ALTER SESSION • SET ROLE
• ALTER SYSTEM • SET TRANSACTION
• CREATE CONTROL FILE
• CREATE DATABASE
• CREATE DATABASE LINK
• CREATE PFILE FROM SPFILE a
s
) ha
• CREATE MATERIALIZED VIEW
• CREATE MATERIALIZED VIEW LOG
l ฺ c om
• CREATE SCHEMA AUTHORIZATION
m ai ฺ
• CREATE SPFILE FROM PFILE
9 @ g
u ide
• DROP DATABASE LINK i z 9 nt G
u
• DROP MATERIALIZED VIEW (pr Stude
• DROP MATERIALIZED VIEW LOG ON is
R R t h
B A use
Z
I and/or
UOracle
R s e
T H icen
BE that l e l
I Z A
Not all data SQL commands
r a b are executed on the primary database are applied to the
logical standbyL
E database. s fe If you execute any of the commands (shown in the slide) on the
C A
primary Idatabase,
t r n
a are not executed on any logical standby database in your
they
I -
R nonYou must execute them on the logical standby database if needed to maintain
configuration.
A T
P consistency between the primary database and the logical standby database.

Unsupported PL/SQL-Supplied Packages
Unsupported PL/SQL-supplied packages include:

• DBMS_JAVA
• DBMS_REGISTRY
• DBMS_ALERT
DBMS ALERT
• DBMS_SPACE_ADMIN
• DBMS_REFRESH
• DBMS_REDEFINITION a
s
• DBMS_AQ ) ha
l ฺ c om
Packages supported only in the context of a rolling upgrade:
m ai ฺ
9 @ g
u ide
SQL> SELECT OWNER, PKG_NAME FROM DBA_LOGSTDBY_PLSQL_SUPPORT
i z 9 nt G
WHERE SUPPORT_LEVEL = 'DBMS_ROLLING'; u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
Oracle PL/SQL-supplied A BEpackages l e
b that do not modify system metadata or user data leave no
L I Z r a
footprint in the
A E archivedn s feredo log files, and therefore are safe to use on the primary database.
Examples
I C I of such
- t r apackages are DBMS_OUTPUT, DBMS_RANDOM, DBMS_PIPE,
A TR non DBMS_TRACE, DBMS_METADATA, and DBMS_CRYPTO.

DBMS_DESCRIBE,
P Oracle PL/SQL-supplied packages that do not modify system metadata but may modify user
data are supported by SQL Apply, as long as the modified data belongs to the supported data
types. Examples of such packages are DBMS_LOB, DBMS_SQL, and DBMS_TRANSACTION.
Oracle Data Guard logical standby supports replication of actions performed through the
following packages: DBMS_DDL, DBMS_FGA, SDO_META, DBMS_REDACT,
DBMS REDEFINITION DBMS_RLS,
DBMS_REDEFINITION, DBMS RLS DBMS_SQL_TRANSLATOR,
DBMS SQL TRANSLATOR DBMS_XDS,DBMS XDS
DBMS_XMLINDEX, and DBMS_XMLSCHEMA.
Oracle PL/SQL-supplied packages that modify system metadata typically are not supported
by SQL Apply, and therefore their effects are not visible on the logical standby database.
Examples of such packages are DBMS_JAVA, DBMS_REGISTRY, DBMS_ALERT,
DBMS_SPACE_ADMIN, DBMS_REFRESH, and DBMS_AQ.
Note: See Oracle Data Guard Concepts and Administration for additional information about
support for PL/SQL packages.

Ensuring Unique Row Identifiers
• Query DBA_LOGSTDBY_NOT_UNIQUE on the primary

database to find tables without a unique identifier:

SQL> SELECT * FROM dba_logstdby_not_unique;
OWNER TABLE_NAME BAD_COLUMN
------ -------------------------- ----------
APEX_040200 EMP_HIST Y
SCOTT BONUS N
SCOTT SALGRADE N
SH SUPPLEMENTARY_DEMOGRAPHICS N
s a
SH COSTS N
) ha
SH SALES N
l ฺ c om
m ai ฺ
• BAD_COLUMN indicates a table column is defined g using
i d ean
unbounded data type such as LONG or BLOB.
@
99 nt Gu
i z
ru udthat e SQL
• Add a primary key or unique index (
to pensure t
N is S
Oupdates.
Apply
pp y can efficientlyy apply pp y data
R spe th
R
A
B ou
I Z
U and/or
Copyright © 2014, Oracle tits affiliates. All rights reserved.
R s e
T H icen
BEa logical l e l
Because the row Z
I IDsA on
r a b standby database might not be the same as the row IDs on
L
E nsafedifferent mechanism must be used to match the updated row on the
the primary database,
C A
primary Idatabase
t r ato its corresponding row on the logical standby database. Primary keys and
I
R nunique
non-null -
n indexes can be used to match the corresponding rows. It is recommended
A T o
P that you add a primary key or a unique index to tables on the primary database (whenever
appropriate and possible) to ensure that SQL Apply can efficiently apply data updates to the
You can query the DBA_LOGSTDBY_NOT_UNIQUE view to identify tables in the primary
database that do not have a primary key or unique index with NOT NULL columns. Issue the
following query to display a list of tables that SQL Apply might not be able to uniquely identify:
SQL> SELECT OWNER, TABLE_NAME,BAD_COLUMN
2 FROM DBA_LOGSTDBY_NOT_UNIQUE
3 WHERE TABLE_NAME NOT IN
4 (SELECT TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED);

The key column in this view is BAD_COLUMN. If the view returns a row for a given table,
you may want to consider adding a primary or unique key constraint on the table.
A value of Y indicates that the table does not have a primary or unique constraint and that the
column is defined usingg an unbounded data typeyp ((such as CLOB).
) If two rows in the table
match except for values in their LOB columns, the table cannot be maintained properly and
SQL Apply stops.
A value of N indicates that the table does not have a primary or unique constraint, but that it
contains enough column information to maintain the table in the logical standby database.
However, the redo transport services and log apply services run more efficiently if you add a
primary key. You should consider adding a disabled RELY constraint to these tables (as
described in the next slide)
slide).
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Adding a Disabled Primary Key

RELY Constraint
You can add a disabled RELY constraint to uniquely identify
rows:
SQL> ALTER TABLE hr.employees
2 ADD PRIMARY KEY ((employee_id,
l id llast_name)
t )
3 RELY DISABLE;
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
If your applicationZ A BE thatblthe
ensures e lrows in a table are unique, you can create a disabled
primary key E LI constraint
RELY f e raon the table without incurring the overhead of maintaining a
C A on tthe
primary Ikey r a ns database.
primary
I constraint
RRELY n-
T
The
n o tells the system to log the named columns (in this example,
PAEMPLOYEE_ID and LAST_NAME) to identify rows in this table. Be careful to select columns for
the disabled RELY constraint that uniquely identify the row. If the columns selected for the
RELY constraint do not uniquely identify the row, SQL Apply does not apply redo information
to the logical standby database.
To improve the performance of SQL Apply, add a unique constraint/index to the columns to
id tif th
identify the row on th
the llogical
i l standby
t db d database.
t b F
Failure
il tto d
do so results
lt iin ffullll ttable
bl scans
during UPDATE or DELETE statements carried out on the table by SQL Apply.
Note: For this example, assume that the HR.EMPLOYEES table does not have a primary key.

Creating a Logical Standby Database

by Using SQL Commands
To create a logical standby database by using SQL commands:
1. Create a physical standby database.

2. Stop Redo Apply on the physical standby database.
3 Prepare the primary database to support a logical standby
3.
database.
4. Build a LogMiner dictionary in the redo data.
5. Transition to a logical standby database. a
6. Open the logical standby database. ) has
om
7. Verify that the logical standby database is performing
a ilฺc
properly. gm ideฺ
z 9 9@ t Gu
p r ui den
O N ( is Stu
A RR se th
I Z B ou
R U and/or
H icen s
T
E le l
A B
L IZ feraofbthese steps in detail.
The next slides cover each
Note: SomeE steps aresperformed on the primary database, and some steps are performed on
C I
the standby
I
A t r an
database.
-
A TR non
P

Step 1: Create a Physical Standby Database
a. Create a physical standby database.

b. Ensure that the physical standby database is current with

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
You create a logical A BE bdatabase
standby l e by first creating a physical standby database. Then
L I Z r a
you convert E
A
the physical
n s festandby database into a logical standby database.
I tra standby database:
IC thenphysical
To create -
T R no a physical standby database as described in the lesson titled “Creating a
PA a. Create
Physical Standby Database by Using SQL and RMAN Commands.”
b. Ensure that the physical standby database is current with the primary database by
allowing recovery to continue until the physical standby database is consistent with the
primary database, including all database structural changes (such as adding or dropping
data files).

Step 2: Stop Redo Apply

on the Physical Standby Database
• Before converting the physical standby database to a
logical standby database, stop Redo Apply.

• Stopping Redo Apply is required to avoid applying
changes
g p past the redo that contains the LogMiner
g
dictionary.

DATABASE CANCEL; a
s
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BE one l e
L I Z erab
To stop Redo Apply, issue of the following commands:
E nsf is not managed by the broker
• If the configuration
A
Q
SQLI
IC nALTER
>
- tra DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;;
R noconfiguration is managed by the broker
T• If the
PA DGMGRL > EDIT DATABASE '<database name>' set state='apply-off';
The Data Guard broker will be discussed later in the course.

Step 3: Prepare the Primary Database

to Support Role Transitions
Set the LOG_ARCHIVE_DEST_n initialization parameter for
transitioning to a logical standby role.

LOG_ARCHIVE_DEST_1=
'LOCATION /arch1/boston/
'LOCATION=/arch1/boston/
VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_3=
'LOCATION=/arch2/boston/ a
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) ) has
o m
ilฺc
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_3=ENABLE m a ฺ
9 @ g
u ide
Note: This step is necessary only if you plan i z 9 perform
to n t G
u
pr tude
switchovers. (
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A
If you plan to transitionBthe b database to the logical standby role, you must also modify
primary
L I Z r a
the parameters
A E so thatn s fnoe parameters need to change after a role transition:
• IC I
Changeg the
- traVALID_FOR attribute in the original g LOG_ARCHIVE_DEST_1 destination to
R
T archive n
no redo data only from the online redo log and not from the standby redo log.
PA • Include the LOG_ARCHIVE_DEST_3 destination on the primary database. This
parameter only takes effect when the primary database is transitioned to the logical
standby role.
When the boston database is running in the primary role, LOG_ARCHIVE_DEST_1 directs
archiving of redo data generated by the primary database from the local online redo log files
t the
to th local
l l archived
hi d redo
d llog fil
files iin /arch1/boston
/ / andd LOG_ARCHIVE_DEST_3 is i nott
used.
When the boston database is running in the logical standby database role,
LOG_ARCHIVE_DEST_1 directs archiving of redo data generated by the logical standby
database from the local online redo log files to the local archived redo log files in
/arch1/boston/.
LOG ARCHIVE DEST 3 directs archiving of redo data from the standby redo log files to the
LOG_ARCHIVE_DEST_3
local archived redo log files in /arch2/boston/.

Step 4: Build a LogMiner Dictionary

in the Redo Data
• Build a LogMiner dictionary in the redo data so that SQL
Apply can properly interpret changes in the redo.

• Supplemental logging is automatically enabled.
• Execute the procedure on the primary database:
SQL> EXECUTE DBMS_LOGSTDBY.BUILD;
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
SQL Apply requires A
a BLogMinerb dictionary in the redo data so that it can properly interpret
L I Z r a
changes in the
A E redo.nWhens fe you execute the DBMS_LOGSTDBY.BUILD procedure, the
LogMiner
I C I dictionary
- t r a is built and supplemental logging is automatically enabled for logging
T R key
primary
n o nand unique key columns. Supplemental logging ensures that each update
A
P contains enough information to logically identify the affected row.
Note: The DBMS_LOGSTDBY.BUILD procedure waits for all existing transactions to complete
so that long-running transactions executing on the primary database will affect its operation.

Step 5: Transition to a Logical Standby Database
a. Execute the following command on the standby database

to convert it to a logical standby database:

SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY
db name;
db_name;
b. Shut down the logical standby database instance and

restart it in MOUNT mode.
c. Adjust initialization parameters: LOG_ARCHIVE_DEST_n s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BE l e
L I Z erab
To prepare the physical standby database to transition to a logical standby database:
A E ALTER
a. Issue the
n s f
DATABASE RECOVER TO LOGICAL STANDBY db_name command to
IC I
continue
co t ue app
- t ray g redo
applying edo data to tthe ep physical
ys ca sta standby dby database u until
t itt is
s ready
eady to co
convert
et
R n
o standby database. Specify a database name (db_name) to identify the new
T to anlogical
PA logical standby database.
The redo log files contain the information needed to convert your physical standby
database to a logical standby database. The statement applies redo data until the
LogMiner dictionary is found in the redo log files.
b. Shut down the logical standby database instance and restart it in MOUNT mode.
c. Modify
M dif th
the LOG_ARCHIVE_DEST_n
LOG ARCHIVE DEST parameters t to
t specify
if separate
t local
l l destinations
d ti ti
for:
- Archived redo log files that store redo data generated by the logical standby
database
- Archived redo log files that store redo data received from the primary database

Step 6: Open the Logical Standby Database
a. Open the new logical standby database with the

RESETLOGS option:
SQL> ALTER DATABASE OPEN RESETLOGS;
b. Start the application of redo data to the logical standby

database:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY
s a
IMMEDIATE; ) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BE database l e
To open the logical
L I Z erab
standby and start SQL Apply:
a. On theE
A n s f database, issue the ALTER DATABASE OPEN RESETLOGS
logical standby
IC I
command
co raopen
a dtto
- ope tthee database
database.
R
Tb. Onnthe n
o logical standby database, issue the following command to start SQL Apply:
PA ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE

Step 7: Verify That the Logical Standby Database

Is Performing Properly
a. Verify that the archived redo log files were registered:
SQL> SELECT sequence#, first_time, next_time,

dict_begin, dict_end FROM dba_logstdby_log ORDER BY
sequence#;
b. Begin sending redo data to the standby database:

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; s a
m ) ha
c. Query the DBA_LOGSTDBY_LOG view to verify that the
i l ฺ co
a
archived redo log files were registered. gm deฺ @ Gui
9 9
r u iz ent
N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BEstandby l e l
I A
After creating yourZlogical
r a b database and setting up redo transport services and log
apply services,L
E younshould
s fe verify that redo data is being transmitted from the primary
database
C I A a the standby database.
and applied
t r to
I -
A TRverifynthat
To onthe logical standby database is functioning properly:
P a. Connect to the logical standby database and query the DBA_LOGSTDBY_LOG view to
verify that the archived redo log files were registered on the logical standby system:
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN,DICT_END
FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
b. Connect to the primary database and issue the following command to begin sending
redo data to the standby database:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
c. Connect to the logical standby database and requery the DBA_LOGSTDBY_LOG view as
shown in step a. This enables you to verify that the new archived redo log files were
registered.

Step 7: Verify That the Logical Standby Database

Is Performing Properly
d. Verify that redo data is being applied correctly:
SQL> SELECT name, value FROM v$logstdby_stats

WHERE name = 'coordinator state';
e. Query the V$LOGSTDBY_PROCESS view to see current

SQL Apply activity:
SQL> SELECT sid, serial#, spid, type, high_scn
FROM v$logstdby_process; s a
) ha
f. Check the overall progress of SQL Apply: l ฺ c om
m ai ฺ
SQL> SELECT applied_scn, latest_scn FROM 9 @ g
u ide
i z 9 nt G
v$logstdby_progress; u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
d. On the logical A BE database,
standby b l e query the V$LOGSTDBY_STATS view to verify that
L I Z r a
redo data
A E is being
n s feapplied correctly:
Q C
SQL>
I I - a , VALUE FROM V$LOGSTDBY
SELECT trNAME, $ _STATS WHERE NAME =
T R n
no state';
'coordinator
PA A value of INITIALIZING in the VALUE column indicates that log apply services are
preparing to begin SQL Apply, but that data from the archived redo log files is not being
applied to the logical standby database.
e. Query the V$LOGSTDBY_PROCESS view to see information about the current state of the
SQL Apply processes.
f. Query the V$LOGSTDBY_PROGRESS view on the logical standby database to check the
overall progress of SQL Apply:
SQL> SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS;

Creating a Logical Standby Database

by Using Enterprise Manager
s a
) ha
l ฺ c om
m ai ฺ
Select “Create a new logical
standby database.” 9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BE database
To create a logicalZstandby b l e by using Enterprise Manager:
L I r a
feDatabase on the Data Guard overview page to invoke the Add
1. Click Add
A E Standbyn s
IC
StaI
Standby ra Wizard.
dby Database
- tatabase ad
R
T Note: n
noIf the logical standby database is the first database to be created in your
PA configuration, access the Add Standby Database Wizard by clicking “Setup and
Manage” in the Data Guard section on the Availability page. Next, click the Add Standby
Database link to invoke the Add Standby Database Wizard.
2. Select “Create a new logical standby database” on the Add Standby Database page,
and click Continue.
3. The wizard guides you through a procedure that is similar to adding a physical standby
database.

Using the Add Standby Database Wizard

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
On the Add Standby A BE bleBackup
Database: Type page, you determine whether you have tables
L I Z e r a
A E arennotsfsupported
or columns that by SQL Apply. In the SQL Apply Unsupported Tables
section, Iselect r a
“Table Columns and Data Types” in the drop-down list and click Go to see the
I C - t
A TR nontables.
unsupported
P


s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
BE bleConfiguration
On the Add StandbyADatabase: page, specify the values for the DB_NAME and
L I Z r a
DB_UNIQUE_NAME
A s fe
E nparameters for your logical standby database. In addition, specify the
I C I
target name to be
- t r a
used by Enterprise Manager Cloud Control.
A TR
In on Database Monitoring Credentials section, you can choose between a non-
the Standby
n
P SYSDBA user such as DBSNMP to monitor the database or choose to use the SYSDBA
monitoring credentials.


s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
After completing all A BE in bthelewizard,
pages you see the Add Standby Database Review page.
L I Z r a
e this page and click Finish to submit a job to create your logical
E nsfon
Review the information
A
standby Idatabase.
R IC n-tra
PA
T no

Securing Your Logical Standby Database
• Configure the database guard to control user access to

tables.
• ALTER DATABASE GUARD command keywords:
– ALL: Prevents users from making changes to any data in the
database
– STANDBY: Prevents users from making changes to any data
maintained by Data Guard SQL Apply
– NONE: Normal security s a
• Q y the GUARD_STATUS column in V$DATABASE.
Query $ ) ha
l ฺ c om
• The database guard level is automatically set to ALL
m aiby ฺ
the broker on the logical standby database. 9@g uide
• The database guard level applies to allruusers nt G SYS.
iz9 eexcept
N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BE buser l e l
The database guard
I Z Acontrols
r a access to tables in a logical standby database. Use the
L
E GUARD
ALTER DATABASE
s fe command to configure the database guard.
I A
C itnis-not
By default,
n
trapossible for a nonprivileged user to modify data on a Data Guard SQL
R I
T database,
Apply o because the database guard is automatically set to ALL. With this level of
PAsecurity,nonly the SYS user can modify data.
When you set the security level to STANDBY, users are able to modify data that is not
maintained by the logical apply engine. A security level of NONE permits any users to access
the standby database if they have the appropriate privileges.
When creating a logical standby database manually with SQL commands, you must issue the
ALTER DATABASE GUARD ALL command before opening the database. Failure to do so
allows jobs that are submitted through DBMS_JOB.SUBMIT to be scheduled and to potentially
modify tables in the logical standby database.
Note: Be careful not to let the primary and logical standby databases diverge while the
database guard is disabled.

Automatic Deletion of Redo Log Files

by SQL Apply
Redo logs SQL Transform redo Logical

from Apply information into standby
primary SQL database
database s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
Delete redo log files u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
Archived redo logs A
onBtheElogical
b l estandby database are automatically deleted by SQL Apply
L I Z r a
A n s fe feature reduces the amount of space consumed on the logical
after they areEapplied. This
standby Idatabase r aand eliminates the manual step of deleting the archived redo log files.
I C - t
A TRcannenable
You on and disable the auto-delete feature for archived redo logs by using the
P DBMS_LOGSTDBY.APPLY_SET procedure. By default, the auto-delete feature is enabled.

Managing Remote Archived Log File Retention
The LOG_AUTO_DEL_RETENTION_TARGET parameter:

• Is used to specify the number of minutes that SQL Apply

keeps a remote archived log after completely applying its
contents
• Is applicable only if LOG_AUTO_DELETE is set to TRUE and
the flash recovery area is not being used to store remote
archived logs
• Has a default value of 1,440 minutes s a
m ) ha
SQL> execute DBMS_LOGSTDBY.APPLY_SET i l ฺ co
a
gm eฺ
('LOG_AUTO_DEL_RETENTION_TARGET','2880');
@ Guid
9 9
r u iz ent
N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
E le l
Bdeletes
By default, SQL Apply
I Z A r a ban archived redo log file after applying the contents. This
L
E nsbyfethe LOG_AUTO_DELETE parameter. During a flashback operation or
behavior is controlled
C I A
point-in-time a of the logical standby database, SQL Apply must stop and re-fetch all
recovery
t r
I -
A TR archived
remote
n on redo log files.
P In Oracle Database 12c, you use the LOG_AUTO_DEL_RETENTION_TARGET parameter to
specify a retention period for remote archived redo log files. You can modify
LOG_AUTO_DEL_RETENTION_TARGET by using the DBMS_LOGSTDBY.APPLY_SET and
DBMS_LOGSTDBY.APPLY_UNSET procedures.
Note: This parameter is applicable only when you are not using the fast recovery area.

Creating SQL Apply Filtering Rules
Procedures exist to create SQL Apply filtering rules.

• To skip SQL statements:
SQL> EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'DML',

schema_name => 'HR', object_name => '%');
• To skip errors and continue applying changes:
SQL> EXECUTE DBMS_LOGSTDBY.SKIP_ERROR('GRANT');
• To skip applying transactions: s a

) ha
SQL> EXECUTE DBMS_LOGSTDBY.SKIP_TRANSACTION
DBMS LOGSTDBY SKIP TRANSACTION
l ฺ c om
(XIDUSN => 1, XIDSLT => 13, XIDSQN => 1726);
m ai ฺ
• To skip all SQL statements for a container:99@ Gui
g de
r u iz ent
SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt
N (p S=> t ud
'CONTAINER', object_name => 'DEV1');
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
l
BEfiltersbtolecontrol
You can use SQLZ
I A
Apply
r a what to apply and what not to apply. To define a SQL
L
Apply filter, use fe
E thenDBMS_LOGSTDBY
s package with the SKIP, SKIP_ERROR, and
C I A
SKIP_TRANSACTION
t r a procedures. The first example in the slide uses the SKIP procedure to
I -
A TR allnDML
ignore onprocedure
changes made to the HR schema. The second example in the slide uses the
P SKIP_ERROR to ignore any error raised from any GRANT DDL command and
continue applying changes instead of stopping SQL Apply. The third example in the slide
uses the SKIP_TRANSACTION procedure and skips a DDL transaction with XIDUSN=1,
XIDSLT=13, and XIDSQN=1726. The following describes the fields used:
• XIDUSN NUMBER: Transaction ID undo segment number of the transaction being
skipped
• XIDSLT NUMBER: Transaction ID slot number of the transaction being skipped
• XIDSQN NUMBER: Transaction ID sequence number of the transaction being skipped
See the Oracle Database PL/SQL Packages and Types Reference for detailed information
about the DBMS_LOGSTDBY package and its procedures.

Deleting SQL Apply Filtering Rules
Procedures exist to delete SQL Apply filtering rules.

• To delete SQL statement rules:

SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(STMT => 'DML',
schema name =>
schema_name > 'HR',
HR , object_name
object name =>
> '%');
% );
• To delete error apply filter rules:

SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP_ERROR('GRANT');
s a
• To delete transaction filter rules: ) ha
l ฺ c om
SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP_TRANSACTIONai
(XIDUSN => 1, XIDSLT => 13, XIDSQN => 1726); @ gm ideฺ
i z 99 nt Gu
( pru tude
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E uselethel DBMS_LOGSTANDBY package with the
To delete a SQL Apply A Bfilter, b
L IZ feraand UNSKIP_TRANSCATION procedures. The syntax to delete a
E ns
UNSKIP, UNSKIP_ERROR,
A
I
SQL Apply
C n-t filter risaalmost identical to the syntax to create a SQL Apply filter.
T RIthe
See o Database PL/SQL Packages and Types Reference for detailed information
Oracle
PAabout thenDBMS_LOGSTDBY package and its procedures.

Viewing SQL Apply Filtering Settings
Query DBA_LOGSTDBY_SKIP to view SQL Apply filtering

settings:
SQL> SELECT error, statement_opt, name
2 FROM dba_logstdby_skip
dba logstdby skip
3 WHERE owner='HR';
ERROR STATEMENT_OPT NAME
---------- -------------------- ----------
N DML JOBS
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
You can query the DBA_LOGSTDBY_SKIP view on the logical standby database to determine
L I Z e r a
the SQL Apply
A E filtering
n s fsettings. The view contains the following columns:
• C I
Ithe - tra whether the statement should be skipped
ERROR: Indicates pp or should return an error for
T R o n
nstatement
PA • STATEMENT_OPT: Specifies the type of statement that should be skipped (It must be
one of the SYSTEM_AUDIT statement options.)
• OWNER: Name of the schema under which the skip option is used
• NAME: Name of the table that is being skipped
• USE_LIKE: Indicates whether the statement uses a SQL wildcard search when
matching names
• ESC: Escape character to be used when performing wildcard matches
• PROC: Name of a stored procedure that is executed when processing the skip option
You can query DBA_LOGSTDBY_SKIP_TRANSACTION to view settings for transactions to be
skipped.

Using DBMS_SCHEDULER to Create Jobs

on a Logical Standby Database
• Scheduler jobs can be created on a standby database.
• When a Scheduler job is created, it defaults to the local

role.
• Activate existing jobs by using the DATABASE_ROLE
DATABASE ROLE
attribute of DBMS_SCHEDULER.SET_ATTRIBUTE, which
has the following settings:
– PRIMARY: The job runs only when the database is in the role
of the primary database. a
– LOGICAL STANDBY: The jjob runs onlyy when the database m is ) has
c o
in the role of a logical standby. ailฺ
@ gm ideฺ
i z 99 nt Gu
( pru tude
R ON his S
B AR use t
U
Oracle
H icenR s
T l
Use the DBMS_SCHEDULER A BE package
b l e to create Scheduler jobs so that they are executed when
L I Z r a
intended. Scheduler
A E njobs s fecan be created on a standby database.
When I
ICa Scheduler
- trajob is created, it defaults to the local role. If the job is created on the
T R
standby o n
ndatabase, it defaults to the role of a logical standby. The Scheduler executes jobs
PAthat are specific to the current database role. Following a role transition (switchover or
failover), the Scheduler automatically switches to executing jobs that are specific to a new
role.
Scheduler jobs are replicated to the standby, but they do not run by default. However, existing
jobs can be activated under the new role by using the DBMS_SCHEDULER.SET_ATTRIBUTE
procedure.
d If you wantt a job
j b to
t run for
f allll d
database
t b roles
l on a particular
ti l h host,
t you mustt create
t
two copies of the job on that host: one with a database_role of PRIMARY and the other
with a database_role of LOGICAL STANDBY. Query the DBA_SCHEDULER_JOB_ROLES
view to determine which jobs are specific to which role.
See the Oracle Database PL/SQL Packages and Types Reference for detailed information
about using the DBMS_SCHEDULER package.

Quiz
By default, users are able to create additional indexes and

materialized views in a logical standby database.

a. True
b False
b.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: b
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Quiz
Scheduler jobs created on the primary database are replicated

to the logical standby database, but do not execute by default.

a. True
b False
b.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: a
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Summary

• Determine when to create a logical standby database

• Create a logical standby database
• Manage SQL Apply filtering
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

This practice covers using Enterprise Manager to create a

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
O
Oracle
l Data
D t Guard
G d Broker:
B k Overview
O i
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
Objectives
After completing this lesson, you should be able to describe:

• The Data Guard broker architecture

• Data Guard broker components
• Benefits of the Data Guard broker
• Data Guard broker configurations
• How to use Enterprise Manager to manage your Data
Guard configuration a
• How to invoke DGMGRL to manage your Data Guard ) has
om
configuration ilฺc
g ma deฺ
9 9 @ Gui
r u iz ent
N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
A BE ble l
E LIZ sfera
I C IA -tran
A TR non
P

Oracle Data Guard Broker: Features
• The Oracle Data Guard broker is a distributed

management framework.
• The broker automates and centralizes the creation,
maintenance,, and monitoringg of Data Guard
configurations.
• With the broker, you can perform all management
operations locally or remotely with easy-to-use interfaces:
– Oracle Enterprise Manager Cloud Control s a
– DGMGRL (a command-line
command line interface) ) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T
The following are Z A
some el
BofE theboperations
l that the broker automates and simplifies:
L I r a
feof Data Guard configurations incorporating a primary database, a
• Automated
A E creation
n s
IC I
e o
new or e
- tstrag sta
existing standby
dby database, redo edo transport
t a spo t services,
se ces, a andd log
og app
apply
y se
services
ces
R
T Note: n
noAny of the databases in the configuration can be a Real Application Clusters
PA (RAC) database.
• Adding new or existing standby databases to each existing Data Guard configuration,
for a total of one primary database and from one to 30 standby databases in the same
configuration
• Managing an entire Data Guard configuration (including all databases, redo transport
services, and log apply services) through a client connection to any database in the
configuration
• Invoking switchover or failover with a single command to initiate and control complex
role changes across all databases in the configuration
• Monitoring the status of the entire configuration, capturing diagnostic information,
reporting statistics (such as the log apply rate and the redo generation rate), and
detecting problems quickly with centralized monitoring
monitoring, testing,
testing and performance tools

Data Guard Broker: Components
• Client-side:
– Oracle Enterprise Manager Cloud Control

– DGMGRL (command-line interface)
• Server-side:
Server side: Data Guard monitor
– DMON process
– Configuration files
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BE l e
L IZ ferab
The Oracle Data Guard broker consists of both client-side and server-side components.
On the client,Eyou cansuse the following Data Guard components to define and manage a
C IA -tran
configuration:
I
A T•R Oracle
n onEnterprise Manager Cloud Control
P • DGMGRL, which is the Data Guard command-line interface (CLI)
On the server, the Data Guard monitor is a broker component that is integrated with the
Oracle database. The Data Guard monitor comprises the Data Guard monitor (DMON) process
and broker configuration files, with which you can control the databases of that configuration,
modifyy their behavior at run time,, monitor the overall health of the configuration,
g , and provide
p
notification of other operational characteristics.
The configuration file contains profiles that describe the current state and properties of each
database in the configuration. Associated with each database are various properties that the
DMON process uses to control the database’s behavior. The properties are recorded in the
configuration file as a part of the database’s object profile that is stored there. Many database
properties are used to control database initialization parameters related to the Data Guard
environment.
environment

Data Guard Broker: Configurations
The most common configuration is a primary database at one

location and a standby database at another location.
O
Oracle Net
Boston Boston London
Far Sync
ASYNC
s a
Oracle Net m ) ha
Primary London Standby
i l ฺ co
Far Sync a
Site gmSite eฺ @ Guid
ASYNC 9 9
r u iz ent
N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BE consists l e l
I Z A
A Data Guard configuration
r a b of one primary database and up to 30 standby databases
or Far Sync E L
locations. The
s fe databases in a Data Guard configuration are typically dispersed
C I A
geographically and
t r n
a connected by Oracle Net.
are
I -
AATR on broker configuration is a logical grouping of the primary, Far Sync, and standby
Data Guard
n
P databases in a Data Guard configuration. The broker’s DMON process configures and
maintains the broker configuration components as a unified group of resource objects that you
can manage and monitor as a single unit.

Data Guard Broker: Management Model
Data Guard Broker Configuration

Standby database
Broker-controlled Standby database
d t b
databases St db d
Standby database
t b
Standby database
Standby database
Standby database
Standby database
Standby database a
Primary database s
) ha
Standby database
Instances l ฺ c om
Instances
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A Bperforms
L I Z erab operations on the following logical objects:
The Data Guard broker
• Configuration
A f
E nofsdatabases
• IC
I -tr a
T R Singleo
database
n
PAA brokernconfiguration consists of:
• Configuration object: A named collection of database profiles. A database profile is a
description of a database object, including its current state, current status, and
properties.
• Database objects: Objects corresponding to primary or standby databases
• Instance objects: A database object may comprise one or more instance objects if it is
a RAC database.
The broker supports one or more Data Guard configurations, each of which includes a profile
for one primary database as well as profiles for up to 30 physical, logical, RAC or non-RAC
standby databases. Far Sync destinations are also counted towards the limit of 30 locations.

Data Guard Broker: Architecture
Graphical user interface

or
command-line interface
Data Guard Configuration Standby site 30

Standby site ..
Primary site Standby site 1
Configuration Configuration
files files
Standby
database
Standby
Primary redo logs Log
s a
database
Online
apply
) ha
Online DMON DMON
redo logs services
l ฺ c om
redo logs Archivedi
alogs
Archived @ g m
redo
i d eฺ
Log
redo logs Oracle z 9 9 t Gu
Net i
ru Standby en
transport
( p u d
services
O N is redo St logs
A RR se th
I Z B ou
R U and/or
H icen s
T
E le l
The Data Guard broker A Bhelps byou create, control, and monitor a Data Guard configuration.
L I Z r a
This configuration
A E consists n s fe of a primary database that is protected by one or more standby
databases.
I C I Afterrthe
- t a broker has created the Data Guard configuration, the broker monitors the
A TR health,
activity,
n on and availability of all systems in that configuration.
P The Data Guard monitor process (DMON) is an Oracle background process that runs on every
instance that is managed by the broker, including Far Sync instances. When you start the
Data Guard broker, a DMON process is created.
When you use Enterprise Manager or the Data Guard command-line interface (CLI), the DMON
process is the server-side component that interacts with the local instance and the DMON
processes that are running on other sites to perform the requested function
function. The DMON
process is also responsible for monitoring the health of the broker configuration and for
ensuring that every instance has a consistent copy of the configuration files in which the DMON
process stores its configuration data. There are two multiplexed versions of the configuration
file on each database.

Data Guard Monitor: DMON Process
• A server-side background process

• A part of each database instance in the configuration

• Created when you start the broker
• Performs requested functions and monitors the resource
• Communicates with other DMON processes in the
configuration
• Updates the configuration file a
• Creates the drc<SID> trace file in the location set by the ) has
m
DIAGNOSTIC_DEST initialization parameter li ฺco a
• gm ideasฺ
Modifies initialization parameters during role transitions
@
9 t Gu
necessary iz9
( pru tuden
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A
The Data Guard monitor BEcomprisesl e
b two components: the DMON process and the configuration
L I Z r a
file.
A E nsfe
I
IC process
The DMON
- trais an Oracle background process that is part of each database instance
T R
managed byn
o the broker. When you start the Data Guard broker, a portion of the SGA is
PAallocatednand a DMON process is created. The amount of memory allocated is typically less
than 50 KB per site; the actual amount on your system varies.
When you use Enterprise Manager or the CLI, the DMON process is the server-side
component that interacts with the local instance and the DMON processes running on other
sites to perform the requested function.
The DMON process is also responsible for monitoring the health of the broker configuration
and for ensuring that every database has a consistent copy of the broker configuration files in
which the DMON process stores its configuration data.
The DIAGNOSTIC_DEST parameter defines the location for diagnostic files such as trace files
and core files. The structure of the directory specified by DIAGNOSTIC_DEST is as follows:
<diagnostic_dest>/diag/rdbms/<dbname>/<instance_name>/
This location is known as the Automatic Diagnostic Repository (ADR) Home. The DMON
trace files are located in the <adr-home>/trace subdirectory.

Benefits of Using the Data Guard Broker
• Enhances the high-availability, data protection, and

disaster protection capabilities inherent in Oracle Data

Guard by automating both configuration and monitoring
tasks
• Streamlines the process for any one of the standby
databases to replace the primary database and take over
production processing
• Enables easy configuration of additional standby databases a
• Provides simplified
simplified, centralized
centralized, and extended management ) has
o m
• Automatically communicates between the databases a ilinฺca
Data Guard configuration by using Oracle Net @ gm ideฺ
Services
i z 99 nt Gu
•
( pru the
Provides built-in validation that monitors
u
health
d e of all
databases in the configuration ON s St
R R t h i
B A use
Z
I and/or
UOracle
R s e
T H icen
BErequired l e l
By automating theZtasks
I A r a b configure and monitor a Data Guard configuration, the
to
broker enhancesL fe
E thenhigh-availability,
s data protection, and disaster protection capabilities that
C I A
are inherent
t r a
in Oracle Data Guard. If the primary database fails, the broker streamlines the
I
R nforoany
process -
n one of the standby databases to replace the primary database and take over
A T
P production processing.
The broker enables easy configuration of additional standby databases. After creating a Data
Guard configuration consisting of two databases—a primary and standby—you can add up to
29 additional standby databases to the existing two for each Data Guard configuration.

Comparing Configuration Management

With and Without the Data Guard Broker
With the Broker Without the Broker
General Manage databases as one Manage databases separately
Creation of the Use Enterprise Manager Manually create files

standby database (EM) Cloud Control wizards
Configuration and Configure and manage from Set up services manually for
management single interface each database
s a
) ha
Monitoring • Monitor continuously Monitor each database
• Unified status and reports individually through views
l ฺ c om
• Integrate with EM events
m ai ฺ
@ g ofide
Control Invoke role transitions with Coordinate9 sequences
9 nt G u
a single command multiple i zcommands across
( pru tusites
database defor role
R ON transitions
h i s S
B AR use t
U
Oracle
R
H icen s
T l
The table in the slide A BE ban
provides l e overview of configuration management with and without the
L I Z r a
Data Guard E
A n s fe Table 1-1, “Configuration Management With and Without the
broker (source:
Broker,”Iin Oracle r a Guard Broker).
Data
I C - t
A TR non
P

Data Guard Broker Interfaces
• Command-line interface (CLI):

– Is started by entering DGMGRL at the command prompt where

the Oracle server or an Oracle client is installed
– Enables y you to control and monitor a Data Guard
configuration from the prompt or in scripts
• Oracle Enterprise Manager Cloud Control:
– Provides wizards to simplify creating and managing standby
databases s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BE binterface
The DGMGRL command-line l e includes:
L I Z era
I A E nand
• Configuration
a sf setup tasks
T
• IC
R o n -tr and control of the configuration
Management
n
PA • Commands to check the status and health of the configuration
• Commands to execute role changes
Oracle Enterprise Manager (EM) Cloud Control includes the following Data Guard features:
• Wizard-driven creation of standby databases
• Wizard-driven creation of a broker configuration based on an existing databases
• Complete monitoring and proactive event reporting through email or pagers
• Simplified control of the databases through their potential states. For example, with
Enterprise Manager you can start or stop the redo transport services, start or stop the
log apply services, and place a standby database in read-only mode.
• “Pushbutton” switchover and failover. EM enables you to execute a switchover or
failover between a primary and a standby database by simply clicking a button.

Broker Controlled Database Initialization

Parameters
The broker controls the following parameters:
• LOG_ARCHIVE_DEST_n • PRESERVE_COMMIT_ORDER
• LOG_ARCHIVE_DEST_STATE_n • RECORD_APPLIES_DDL
• ARCHIVE_LAG_TARGET • RECORD_SKIP_DDL
• DB_FILE_NAME_CONVERT • RECORD_SKIP_ERRORS
• LOG_ARCHIVE_FORMAT
• LOG_ARCHIVE_MAX_PROCESSES
• LOG_ARCHIVE_MIN_SUCCEED_DEST
s a
) ha
• LOG_ARCHIVE_TRACE
• LOG FILE NAME CONVERT
LOG_FILE_NAME_CONVERT
l ฺ c om
• STANDBY_FILE_MANAGEMENT
m ai ฺ
• MAX_EVENTS_RECORDED 9 @ g
u ide
• i z 9 nt G
MAX_SERVERS u
pr tude
• (
ON his S
MAX_SGA
R
B AR use t
U
Oracle
R
H icen s
T
E le l
The Data Guard broker A Bdirectly
b controls the database initialization parameters listed in the
L I Z r a
slide. After defining
A E na sData fe Guard broker configuration, you should use DGMGRL or
I C I
Enterprise Manager
- t r a Cloud Control to manage your configuration. You should not use SQL
A TR notonmanage the databases, because you could cause a conflict with the broker.
commands
P The broker also uses configurable property settings to manage how redo apply and SQL
apply are started. Therefore, the following SQL statements are managed automatically by the
broker:
• ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
• ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE

Using the Command-Line Interface

of the Data Guard Broker
DGMGRL> connect sysdg/password
Connected.
DGMGRL> show configuration
Configuration - DRSolution
Protection Mode: MaxPerformance
Databases:
boston - Primary database
bostonFS - Far Sync
london - Physical standby database a
s
) ha
london2 - Logical standby database
londonFS - Far Sync (inactive)
l ฺ c om
m ai ฺ
Fast-Start Failover: DISABLED
9 @ g
u ide
i z 9 nt G
Configuration Status: u
pr tude
(
ON his S
SUCCESS
R
B AR use t
U
Oracle
R
H icen s
T
DGMGRL Commands A BE ble l
LIZ sfeare
The followingEcommands
ra available in DGMGRL (the Data Guard CLI). Many of these
C
commands
I IA have
- t r an
additional arguments that are not described here. See Oracle Data Guard
T R fornodetailed
Broker n information.
PA • ADD DATABASE: Adds a new standby database to the existing broker configuration
• ADD FAR_SYNC: Adds an existing Far Sync instance to an Oracle Data Guard broker
configuration
• CONNECT: Connects to the specified database using the specified username
• CONVERT DATABASE:
CO S CoConvertse ts tthe
e spec
specified
ed database to e
either
t e a ssnapshot
aps ot sta
standby
dby
database or a physical standby database
• CREATE CONFIGURATION: Creates a broker configuration and adds a primary
database to that configuration
• DISABLE CONFIGURATION: Disables broker management of a configuration so that
the configuration and all of its databases are no longer managed by the broker
• DISABLE DATABASE: Disables broker management of the named standby database

• DISABLE FAR_SYNC: Disables broker management of a Far Sync instance
• DISABLE FAST_START FAILOVER: Disables fast-start failover
• DISABLE FAST_START FAILOVER CONDITION: Allows a user to remove conditions
for which a fast
fast-start
start failover should be performed
• EDIT CONFIGURATION (Property): Changes the value of a property for the broker
configuration
• EDIT CONFIGURATION (Protection Mode): Changes the current protection mode

setting for the broker configuration
• EDIT CONFIGURATION (RENAME): Changes the configuration name
• EDIT CONFIGURATION RESET (Property): Resets the specified configuration property
to its default value
• EDIT DATABASE (Property): Changes the value of a property for the named database
• EDIT DATABASE (Rename): Changes the name used by the broker to refer to the
specified database
• EDIT DATABASE (State): Changes the state of the specified database s a
• EDIT DATABASE RESET (Property): Resets the specified property for the named ) ha
database to its default value l ฺ c om
• m ai ฺ
EDIT FAR_SYNC: Changes the name, state, or properties of a Far Sync instance
• 9 @ g
u ide
EDIT FAR_SYNC RESET (Property): Resets the specified property for the named Far
i z 9 nt G
u
pr tude
Sync instance to its default value
(
•
the specified instance R ON his S
EDIT INSTANCE (AUTO PFILE): Sets the name of the initialization parameter file for
• B AR use t
EDIT INSTANCE (Property): Changes the value of a property for the specified instance
• U IZ e to
EDIT INSTANCE RESET (Property): Resets an instance-specific property for the
H R icens
specified instance(s) to its default value
T
• A BE ble l
ENABLE CONFIGURATION: Enables broker management of the broker configuration
LIZ sfera
and all of its databases
E
•
I C IA -tran
ENABLE DATABASE: Enables broker management of the specified database
T•R nonENABLE FAR_SYNC: Enables broker management of the specified Far Sync instance
PA • ENABLE FAST_START FAILOVER: Enables the broker to automatically fail over from
the primary database to a target standby database
• ENABLE FAST_START FAILOVER CONDITION: Allows a user to add conditions for
which a fast-start failover should be performed
• EXIT: Exits the Data Guard command-line interface
• FAILOVER: Performs a database failover operation in which the standby database to
which DGMGRL is currently connected fails over to the role of primary database
• HELP: Displays online help for the Data Guard command-line interface
• QUIT: Quits the Data Guard command-line interface
• REINSTATE DATABASE: Reinstates the database after a failover
• REMOVE CONFIGURATION: Removes the broker configurationg and ends broker
management of its members

• REMOVE DATABASE: Removes the specified standby database from the broker
configuration
• REMOVE FAR_SYNC: Removes a Far Sync instance from an Oracle Data Guard broker
configuration
g
• REMOVE INSTANCE: Removes an instance from the broker configuration
• SHOW CONFIGURATION: Displays information about the broker configuration
• SHOW DATABASE: Displays information about the specified database

• SHOW FAR_SYNC: Shows information about a Far Sync instance
• SHOW FAST_START FAILOVER: Displays all fast-start failover–related information
• SHOW INSTANCE: Displays information about the specified instance
• SHUTDOWN: Shuts down a currently running Oracle database
• SQL: Allows you to enter SQL statements from the Data Guard command-line interface
(DGMGRL)
• START OBSERVER: Starts the observer a
s
•
) ha
STARTUP: Starts an Oracle instance with the same options as SQL*Plus, including
mounting and opening a database
l ฺ c om
• STOP OBSERVER: Stops the observer
m ai ฺ
•
9 @ g
u ide
SWITCHOVER: Performs a switchover operation in which the current primary database
i z 9 nt G
becomes a standby database, and the specified standby database becomes the primary
database u
pr tude
(
•
R ON his S
VALIDATE DATABASE: Performs a comprehensive set of database checks prior to a
role change
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Using Oracle Enterprise Manager Cloud Control

s a
) ha
l ฺ c om
m ai ฺ
Select “Data Guard Administration”
to access the Data Guard 9 @ g
u
pages.
ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BE features l e
To access the Data
L I Z erab in Enterprise Manager Cloud Control:
Guard
I A E Targets
1. Click the
a n sftab to go to the Targets page.
T
2 IC
2.
R Click -tr to go to the Databases page
Databases
o n page, where you can see a list of all discovered
PA n
databases, including the primary database.
3. Click the primary database to go to the primary database home page.
4. Click Availability.
5. Click “Data Guard Administration” to open the Data Guard Overview page.

Data Guard Overview Page

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
On the Data Guard A BE bpage,
Overview l e you can:
L I Z era
I A a n sf mode and access the page to edit the protection mode
E protection
• View the
T
• IC
R received
o n -tr showing the amount of data that the standby database has not
View a summary
PA n
• View information about the primary database
• View or access pages to change information for the standby databases:
- Add a standby database to the broker configuration
- Change the state or properties
- Discontinue
Discontin e Data G Guard
ard broker control
- Switch the role from standby to primary
- Transition the standby database to the role of the primary database
• Access pages to view performance information for the configuration and status of online
redo log files for each standby database
• Perform a verification process on the Data Guard configuration

Benefits of Using Enterprise Manager
• Enables you to manage your configuration by using a

familiar interface and event-management system

• Automates and simplifies the complex operations of
creating
g and managing
g g standbyy databases through g the use
of wizards
• Performs all Oracle Net Services configuration changes
that are necessary to support redo transport services and
log apply services a
• Provides a verify operation to ensure that redo transportom)
has
services and log apply services are configured and ailฺc
functioning properly @ gm ideฺ
99 fromG u
• i
Enables you to select a new primary database
r z t
u den a set
p
of viable standby databases N ( Stu
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
l e l
BE configuration
Managing your Data
I Z AGuard
r a b with Oracle Enterprise Manager Cloud Control
provides theE L fe
following benefits:
s
• IC I A
ab es you
Enables n
trato manage
a age youyour co
configuration
gu at o us using g tthe
e familiar
a a Enterprisete p se Manager
a age
R n -
no and event-management system
T interface
PA • Provides a wizard that automates the complex tasks involved in creating a broker
configuration
• Provides the Add Standby Database Wizard to guide you through the process of adding
more databases
• Performs all Oracle Net Services configuration changes that are necessary to support
redo transport services and log apply services across the configuration
• Provides a verify operation to ensure that redo transport services and log apply services
are configured and functioning properly
• Enables you to select a new primary database from a set of viable standby databases
when you need to initiate a role change for a switchover or failover operation

Quiz
Which tools are used to interface with the Data Guard Broker?
a. DGMGRL
b. SRVCTL
c Enterprise Manager
c.
d. CRSCTL
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: a, c
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Quiz
It is necessary to manage standby databases with the Data

Guard Broker framework.

a. True
b False
b.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: b
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Summary

• The Data Guard broker architecture

• Data Guard broker components
• Benefits of the Data Guard broker
• Data Guard broker configurations
• How to use Enterprise Manager to manage your Data
Guard configuration a
• How to invoke DGMGRL to manage your Data Guard ) has
om
configuration ilฺc
g ma deฺ
9 9 @ Gui
r u iz ent
N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
A BE ble l
E LIZ sfera
I C IA -tran
A TR non
P

s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
C
Creating
ti a Data
D t GGuard
d Broker
B k C Configuration
fi ti
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA
Objectives
After completing this lesson, you should be able to use

DGMGRL commands to:

• Manage the Data Guard broker configuration
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Data Guard Broker: Requirements
• Oracle Database Enterprise Edition

• Single-instance or multi-instance environment

• COMPATIBLE parameter: Set to 12.1 or later for primary
and standby databases to take advantage of new 12 12.11
features (Optional).
• Oracle Net Services network files: Must be configured for
the primary database and any existing standby databases
a
or Far Sync instances. Enterprise Manager Cloud Control
configures files for new standby databases
databases. ) has
o m
• GLOBAL_DBNAME attribute: Set to a concatenation of
a ilฺc
m ฺ
db_unique_name_DGMGRL.db_domain 9@g uide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A Bbroker,
L I Z erab you must comply with the following requirements:
To use the Data Guard
• Use theEEnterprise
I A a n sf Edition of Oracle Database.
T
• IC
R o n -tr
Use a single-instance or multi-instance environment
environment.
PA • Setnthe COMPATIBLE initialization parameter to 12.1 to take advantage of new Oracle

Database 12c Release 1 (12.1) features.
• Enterprise Manager automatically configures the Oracle Net Services network files
when it creates a standby database. If you configure an existing standby database in the
broker configuration, you must configure the network files. You must use TCP/IP.
• To enable the Data Guard broker to restart instances during g the course of broker
operations, a service with a specific name must be statically registered with the local
listener of each instance. The value of the GLOBAL_DBNAME attribute must be set to a
concatenation of db_unique_name_DGMGRL.db_domain.

Data Guard Broker: Requirements
• DG_BROKER_START initialization parameter: Set to TRUE

• Primary database: ARCHIVELOG mode

• All databases: MOUNT or OPEN mode
• DG BROKER CONFIG FILEn: Configured for shared
DG_BROKER_CONFIG_FILEn:
access for any RAC databases
• LOG_ARCHIVE_DEST_n parameters: Must be cleared on
any instance when using SERVICE attribute before
s a
creating a broker configuration
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
A BE ble initialization
• Set the DG_BROKER_START parameter to TRUE. This starts the DMON
L I Z r a
E nsfe
process.
A
IC I
Note: When
- t rayou use Enterprise Manager to create your configuration, this parameter is
R no n
T automatically set to TRUE.
PA • The primary database must be in ARCHIVELOG mode.
• Any database that is managed by the broker (including, for a RAC database, all
instances of the database) must be mounted or open. The broker cannot start an
instance.
• If any database in your configuration is a RAC database, you must configure the
DG_BROKER_CONFIG_FILEn initialization parameters for that database so that they
point to the same shared files for all instances of that database. You cannot use the
default values for these parameters.
Note: The shared files could be files on a cluster file system or on raw devices, or the
files could be stored using Automatic Storage Management (ASM).
• As of Oracle Database 12c Release 1 (12.1), for all databases to be added to a broker
configuration any LOG_ARCHIVE_DEST_n
configuration, LOG ARCHIVE DEST n parameters that have the SERVICE attribute
set, but not the NOREGISTER attribute, must be cleared.

Data Guard Broker and the SPFILE
• You must use a server parameter file (SPFILE) for

initialization parameters.
• Using the SPFILE enables the Data Guard broker to keep
its configuration
g file and the database SPFILE consistent.
• If you use the broker, use Enterprise Manager Cloud
Control or DGMGRL to update database parameter
values.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T
A
To ensure that theZbrokerBEcanbupdatel e l the values of parameters in both the database instance
LI sfile,
and the configuration f a must use the persistent server parameter file (SPFILE) to
eryou
E n initialization parameters. Use of the SPFILE gives the broker a
I C IA and
control static
- t r adynamic
R nothat
mechanism
T n enables it to reconcile property values that you have selected when using the
A
P broker with any related initialization parameter values that are recorded in the SPFILE. In
addition, the SPFILE permits persistent Data Guard settings so that Data Guard continues to
work even after the broker is disabled.
When you set definitions or values for database properties in the broker configuration, the
broker records the changes in the configuration file and also propagates the changes to the
related initialization parameters in the server parameter file in the Data Guard configuration
configuration.
When the configuration is enabled, the broker keeps the database property values in the Data
Guard configuration file consistent with the values of the database initialization parameters in
the SPFILE.
Even when the configuration is disabled, you can update database property values through
the broker. The broker retains the property settings (without validating the values) and
updates the database initialization parameters in the SPFILE and the in-memory y settings
g the
next time you enable the broker configuration.

For dynamic initialization parameters, the broker keeps the value of the database parameter
consistent in the System Global Area (SGA) for the instance, in the Data Guard configuration
files, and in the SPFILE. For static initialization parameters, the value in the SGA may differ
from what is in the configuration files and in the SPFILE. Typically, the broker reconciles the
differences by updating all parameter and property values the next time the database instance
is stopped and restarted.
Note: When using the broker (with Enterprise Manager or DGMGRL), do not attempt to
manually set the parameters that the broker controls. If you set them manually, either you
render your configuration inoperable or the broker simply takes the next opportunity to reset
the parameter to the recorded setting. If you want to change a parameter value, you must
change it by using one of the broker interfaces.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U IZ e to
T H R icens
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

Data Guard Monitor: Configuration File
• The broker configuration file is:

– Automatically created and named using a default path name

and file name when the broker is started
– Managed automatically by the DMON process
• The configuration file and a copy are created at each
managed site with default names:
– dr1<db_unique_name>.dat
– dr2<db_unique_name>.dat a
s
• Configuration file default locations are operating system–
m ) ha
specific: li ฺco a
gm ideฺ
– Default location for UNIX and Linux: ORACLE_HOME/dbs
@ u
z99 t G
– Default location for Windows: ORACLE_HOME\database
r udethe default ui n
• Use DG_BROKER_CONFIG_FILEn to ( poverride
path name and file name. O N is St
R h
B AR use t
U
Oracle
H icenR s
T l
A BE bpersistent
The DMON process maintains l e configuration data about all the databases in the
L I Z r a
E ninsfaebroker configuration file. Every database that is part of the Data
broker configuration
A
I C I
Guard broker
- t r a
configuration has two broker configuration files that are maintained and
R nonfor each database in the broker configuration. One of the files is in use and the
synchronized
T
A
P other acts as a backup. The configuration files are binary files and cannot be edited.
When the broker is started for the first time, the configuration files are created and named
automatically by using a default name. You can override this default name by setting the
DG_BROKER_CONFIG_FILEn initialization parameters. You can also change the
configuration file names dynamically by issuing the ALTER SYSTEM SQL statement. You must
disable the broker configuration and stop the DMON process before changing the names.names
The configuration files contain entries that describe the state and properties of the databases
in the configuration. For example, the files record the databases that are part of the
configuration, the roles and properties of each of the databases, and the state of each of the
databases in the configuration. Two files are maintained so that there is always a record of
the last-known valid state of the configuration. The broker uses the data in the configuration
file to configure and start the databases, control each database’s behavior, and provide
i f
information
ti tto DGMGRL and d Enterprise
E t i M Manager.
Note: The broker configuration files can reside on disks having any sector size up to 4 KB.

Data Guard Broker: Log Files
• The broker log files contain information recorded by the

DMON process.
• There is one file for each instance in the broker
configuration.
• Broker log files are created in the same directory as the
alert log and are named drc<$ORACLE_SID>.log.
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A BE operational
The DMON process records b l e and status information in the broker log file for each
L I Z r a
instance in the
A fe broker configuration.
E DatanGuard
s
I
IC n-tra
T R no
PA

Creating a Broker Configuration
1. Clear existing LOG_ARCHIVE_DEST_n entries on every

instance that references network locations.

2. Invoke DGMGRL and connect to the primary database.
3 Define the configuration,
3. configuration including a profile for the primary
database.
4. Add standby databases to the configuration.
5. Add Far Sync instances to the configuration.
a
6. Enable the configuration, including the databases. ) has
om
7. Define routing rules for the configuration. ilฺc
g ma deฺ
9 9 @ Gui
r u iz ent
N (p Stud
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BE a brokerl e l
Detailed steps forZ A
I ferab configuration will be shown in the following slides.
creating
L
E ns
I A
R IC n-tra
PA
T no

Clear Redo Transport Network Locations on

Primary
• Clear existing LOG_ARCHIVE_DEST_n entries on each
instance that references network locations.

SQL> select name,value from v$parameter where value like
'%SERVICE%';
%SERVICE% ;
NAME VALUE
------------------- --------------------------------
log_archive_dest_2 SERVICE=bostonFS SYNC REOPEN=15
valid_for=(ONLINE_LOGFILES,
a
has
PRIMARY_ROLE) db_unique_name =
bostonFS
m )
o
ilฺc
log_archive_dest_3 SERVICE=london2 SYNC REOPEN=15
a
gm= ideฺ
valid_for=(ONLINE_LOGFILES,
PRIMARY_ROLE) db_unique_name @
99 nt Gu
london2 i z
( pruscope=both;
SQL> alter system log_archive_dest_2=''
t u de
ON s S
SQL> alter system log_archive_dest_3='' scope=both;
R h i
R
A use t
Z B
I and/or
UOracle
Copyright © 2014,
H icen s
T
E le l
As of Oracle Database A B12c b
Release 1 (12.1), no database can be added to the Data Guard
L I Z r a
A Eattribute.
n s fe database instance has a LOG_ARCHIVE_DEST_n parameter using
if the
I C I
the SERVICE
- t r a For an existing Data Guard environment created with SQL, this
R ntheonprimary database, physical standby databases, logical standby databases, and
includes
T
A
P Far Sync instances.
You must clear any remote redo transport destinations on the primary database that do not
have the NOREGISTER attribute, before a configuration can be created. Otherwise, the
following error message is returned when you attempt to create the configuration:
ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added
Failed.
i

Connecting to the Primary Database with

DGMGRL
• Connecting to the primary database on the local system
DGMGRL> connect sysdg/password
• Connecting to the primary database remotely using the

password file
DGMGRL> connect sysdg/password@boston

s a
• Adding a database user to the password file ) ha
l ฺ c om
SQL> grant sysdg to dguser; m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
Similar to SQL*Plus, A BE blecanl connect using operating system authentication (not
DGMGRL
shown in theE LIZ slide),
above f e a user authentication, and remote user authentication using the
rlocal
password
C I Afile. The
t r a ns syntax is as follows:
generic
T RI DGMGRL>
n o n- CONNECT username/password[@connect-identifier]
PA The username and password must be valid for the configuration member to which you are
trying to connect. The username you specify must have the SYSDG or SYSDBA privilege. Do
not include AS SYSDG or AS SYSDBA on the CONNECT command. DGMGRL first attempts an
AS SYSDG connection. If that fails, it will then attempt an AS SYSDBA connection. Additional
database account users can be added to the password file by granting them the SYSDG
privilege The following query can show who has the SYSDG privilege:
privilege.
SQL> select * from v$pwfile_users;
USERNAME SYSDB SYSOP SYSAS SYSBA SYSDG SYSKM CON_ID
------------------ ----- ----- ----- ----- ----- ----- ----------
SYS TRUE TRUE FALSE FALSE FALSE FALSE 0
SYSDG FALSE FALSE FALSE FALSE TRUE FALSE 1
SYSBACKUP FALSE FALSE FALSE TRUE FALSE FALSE 1
SYSKM FALSE FALSE FALSE FALSE FALSE TRUE 1

Defining the Broker Configuration and

the Primary Database Profile
DGMGRL> CREATE CONFIGURATION 'DRSolution' AS PRIMARY
DATABASE IS 'boston' CONNECT IDENTIFIER IS

boston;
Configuration "DRSolution" created with primary database
"boston"


s a
Databases: ) ha
b
boston - Primary
i d
database
b
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
pr tude
(
ON his S
DISABLED
R
B AR use t
U
Oracle
R
H icen s
T
Execute the CREATE A BE ble l command to define the broker creation and create a
LIZ sdatabase.
CONFIGURATION
profile for theEprimary f era The following parameters must be specified:
• C
I IA g -tran
configuration-name: User-specified
p name for the configuration g
R o n
T• database-name: Used by the broker to reference the primary database. You must use
PA thenvalue of the DB_UNIQUE_NAME initialization parameter for the database name.
• connect-identifier: The value you specify for the connect identifier is a fully
specified connect descriptor or a name to be resolved by an Oracle Net Services
naming method. The broker uses this value to communicate with the other databases
defined in the configuration. The DGConnectIdentifier database property is set to
th connectt identifier
the id tifi value.
l

Adding a Standby Database to the Configuration
DGMGRL> add database 'london' as connect identifier is

london;
Database "london" added


Databases:
s a
) ha
om
london - Physical
y standby
y database
l ฺ c
m ai ฺ
ide
@ g
9
9 nt G u
Configuration Status: u i z
DISABLED ( pr tude
R ON his S
B AR use t
U
Oracle
H icenR s
T l
Use the ADD DATABASE A BEDGMGRL l e
b command to define the standby database and create a
L I Z r a
A E nprofile.
s fe The database name specified must be the same as the value of
I C I
the DB_UNIQUE_NAME
- t r a initialization parameter. The connect identifier is used by Oracle Net
A TR ntooaccess
Services n the database from all other databases in the configuration.
P The AS CONNECT IDENTIFIER clause is optional. If you do not specify this clause, the
broker will search the LOG_ARCHIVE_DEST_n initialization parameters on the primary
database for an entry that corresponds to the database being added.
The broker uses the specified connect-identifier to communicate with the specified
database from other databases. Therefore, you must ensure that the connect-identifier
can be
b used d tto address
dd th
the specified
ifi d d
database
t b ffrom allll d
databases
t b iin your configuration.
fi ti F
For
example, if TNS is used as the naming method, you must ensure that the tnsnames.ora file
on every database and instance that is part of the configuration contains an entry for the
connect identifier. The connect identifier must resolve to the same connect descriptor.
Note: The broker will determine the standby type whenever you add an existing standby. In
older versions of the Oracle database, such as version 10.2, you had to specify
"MAINTAINED AS [ PHYSICAL | LOGICAL ]" when you added an existing standby.

Adding a Far Sync to the Configuration
DGMGRL> add far_sync 'bostonFS' as connect identifier is

bostonFS;
far sync instance "bostonFS" added


Databases:
s a
bostonFS - Far Sync (inactive) ) ha
l d
london - Physical
h i l standby
db ddatabase
b
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
pr tude
(
ON his S
DISABLED
R
B AR use t
U
Oracle
H icenR s
T l
Use the ADD FAR_SYNC A BEDGMGRL l e
b command to define the Far Sync and create a broker
L I Z r a
configurationEprofile. The
A n s feFar Sync name specified must be the same as the value of the
I C I
DB_UNIQUE_NAME
- t r a initialization parameter. The connect identifier is used by Oracle Net
A TR ntooaccess
Services n the database from all other databases in the configuration.
P

Enabling the Configuration
DGMGRL> ENABLE CONFIGURATION;

Enabled.
DGMGRL> SHOW CONFIGURATION


Databases:
bostonFS - Far Sync (inactive)
s a
london - Physical standby database ) ha
l d 2
london2 - Logical
i l standby
db database
d b
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
pr tude
(
ON his S
SUCCESS
R
B AR use t
U
Oracle
R
H icen s
T
After defining the Z A BE inblthe
databases e lconfiguration, you enable the configuration and its
databases by E LI sfetheraENABLE CONFIGURATION DGMGRL command.
executing
I C IA -tran
A TR non
P

Broker Support for Complex Redo Routing
By default, a primary database sends its redo to every possible

redo transport destination in a broker configuration.

• The RedoRoutes broker property allows more complex
routing
g to be defined.
– Supports cascaded configurations
– Supports Far Sync configurations
– Supports real-time cascading and without real-time
cascading a
– Supports rules dependent on which database is the currentm)
has
primary i l ฺ co
– Supports the new Fast Sync configuration g ma deฺ
@ i
i z 99 nt Gu
( pru tude
R ON his S
B AR use t
U
Oracle
R
H icen s
T l
By default, a primary A BE blsends
database e the redo that it generates to every other redo transport
L I Z r a
A n s fe
destination inEthe configuration. You can use the RedoRoutes property with Oracle Data
Guard 12c
I C I to create
- t r a a more complex redo transport topology, such as one in which a physical
R ndatabase
standby
T o n or a Far Sync forwards redo received from the primary database to one or
A
P more destinations, or one in which the redo transport mode used for a given destination
depends on which database is in the primary role.

Defining RedoRoutes by Using DGMGRL
• The RedoRoutes property is set to a character string that

contains one or more redo routing rules.

DGMGRL> EDIT DATABASE database-name
SET PROPERTY 'RedoRoutes' = '(redo routing rule 1)(redo routing rule n)';
• Each rule contains one or more redo sources and one or

more redo destinations, separated by a colon.
• The redo source field must contain the LOCAL keyword or
a
a comma-separated list of DB_UNIQUE_NAME values.
) has
• Th redo
The d d destination
ti ti fifield
ld mustt contain
t i th
the kkeywordd ALL o m
or
a i lฺc
a comma-separated list of database names, each g mof which eฺ
@ i d
can be followed by an optional redo transport Gu
99 attribute. iz ent
r u
N
(redo source : redo destination, redo destination ATTRIBUTE)
(p Stud
(redo source : redo destination) (LOCAL : redo destination ATTRIBUTE)
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BE isbset l e l
A
The RedoRoutes property
IZ feone to a character string that contains one or more redo routing
ra or more redo sources and one or more redo destinations. A
rules. Each rule
E Lcontains
I
redo routing
C a ns active when one of the redo sources in the rule is in the primary
A ruletrbecomes
RIThisnresults
role.
T o n- in redo from the primary database being sent to every redo destination in
PAthat rule. A redo routing rule contains a redo source field and a redo destination field,
separated by a colon:
(redo source : redo destination)
The redo source field must contain the LOCAL keyword or a comma-separated list of
DB_UNIQUE_NAME values:
{
{LOCAL | db_unique_name_1,[,db_unique_name_n]}
i [ i ]}
You cannot set the RedoRoutes property on a logical or snapshot standby database.

RedoRoutes Usage Guidelines
• The RedoRoutes property has a default value of NULL,

which is treated as (LOCAL : ALL).

• A redo routing rule is active if its redo source field specifies
the current p primaryy database.
• If a rule is active, primary database redo is sent by the
database at which the rule is defined to each destination
specified in the redo destination field of that rule.
• The ASYNC redo transport attribute must be explicitly a
real time om)
specified for a cascaded destination to enable real-time
has
cascading to that destination. a ilฺc
• The RedoRoutes property cannot be set on9@ gm idoreฺ
a logical
snapshot standby database. i z 9 nt Gu
ru e (p Stud
N
R RO this
B A use
Z
I and/or
UOracle
R s e
T H icen
BE has l e l
The RedoRoutes property
I Z A r a b a default value of NULL, which is treated as (LOCAL : ALL). A
redo routing E L
rule is active
s feif its redo source field specifies the current primary database. If a
C I A
rule is active, primary
t r a n database redo is sent by the database at which the rule is defined to
I
R destination
each -
n specified in the redo destination field of that rule. The ASYNC redo transport
A T n o
P attribute must be explicitly specified for a cascaded destination to enable real-time cascading
to that destination. The RedoRoutes property cannot be set on a logical or snapshot standby
database.

How to Read Redo Routing Rules

If Berlin is the current primary database, the rule is active
DGMGRL> EDIT DATABASE Paris SET PROPERTY 'RedoRoutes' = '(Berlin : Madrid ASYNC)';
Which causes Paris to ship redo to Madrid s a

) ha
l ฺ c om
m ai ฺ
Enables real-time 9 @ g
u ide
cascading
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
The diagram in the A BEprovides
slide b l e an example of interpreting a redo routing rule. The
L I Z r a
command syntax
A E specifies
n s fe Paris as the database unique name for which the RedoRoutes
propertyIis a
beingrset, Berlin as the redo source, and Madrid as the redo destination. The
I C
R attribute - t
n is explicitly specified. If Berlin (redo source) is the current primary database,
A T
ASYNC
n o
P the rule is active. An active rule would cause Paris (database unique name) to ship redo to
Madrid (redo destination). The redo transport attribute can be set to SYNC, FASTSYNC, or
ASYNC. The AYSNC setting used in the example is required to enable real-time cascading.
The SYNC and FASTSYNC keywords are only applicable when the database that is doing the
shipping is a primary database.

Far Sync Example with RedoRoutes
An example Far Sync configuration for a Maximum Availability

broker configuration:
• Primary database in Boston, MA.
• Far Sync in Cambridge,
Cambridge MA.
MA
• Physical standby in Chicago, IL.
• Far Sync in Shaumburg, IL. (for role reversal)
s a
) ha
DGMGRL> EDIT DATABASE Boston SET PROPERTY 'RedoRoutes' = '(LOCAL : Cambridge
SYNC)';
DGMGRL> EDIT FAR
FAR_SYNC
SYNC Cambridge SET PROPERTY 'RedoRoutes'
RedoRoutes = '(Boston
(Boston : Chicago
l ฺ c om
ai ฺ
ASYNC)';
DGMGRL> EDIT
DATABASE Chicago SET PROPERTY 'RedoRoutes' = '(Local : Shaumburg
m
SYNC)';
DGMGRL> EDIT
FAR_SYNC Shaumburg SET PROPERTY 'RedoRoutes' = '(Chicago
9 @ u ide
g : Boston
ASYNC)';
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T
After Data Guard Z A BEhas bbeen
broker l e lconfigured for a primary database, Far Sync, physical
I
standby, andEaLsecond fFar
e raSync for role reversal, the configuration will appear as follows:
C I A trans
RI nSHOW
DGMGRL>
T o n- CONFIGURATION;
PAConfiguration - The SUPER cluster
Protection Mode: MaxAvailability
Databases:
Boston - Primary database
Cambridge - Far Sync
Chi
Chicago - Physical
Ph i l standby
db database
d b
Shaumburg – Far Sync (Inactive)
Configuration Status:
SUCCESS
Notice that in the output of the show configuration command, indentation is used to show that
a database or Far Sync instance is receiving redo from a source location.
location The use of
RedoRoutes overrides the LogXptMode Data Guard property.

Changing Database Properties and States
• To alter the state of only the primary database:

DGMGRL> EDIT DATABASE boston SET STATE='TRANSPORT-OFF';
• To alter the state of a physical or logical standby database:

DGMGRL> EDIT DATABASE boston SET STATE='APPLY-OFF';
• To alter a configurable database property: s a

) ha
DGMGRL> EDIT DATABASE boston SET PROPERTY
l ฺ c om
LogXptMode='SYNC';
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T
E le can l
Configurable database A Bproperties
b be viewed and dynamically updated by using the EDIT
L I Z r a
DATABASE SET
A E PROPERTYn s fe DGMGRL command. Use the SHOW DATABASE VERBOSE
command
I C I to obtain
- t r a a complete list of database properties.
A TREDITnoDATABASE
The n SET STATE DGMGRL command is used to change the state of the
P primary database and standby databases. When the broker configuration is enabled, the
databases are in one of four states:
• TRANSPORT-ON (applicable only to the primary database): Redo transport services
transmit redo data to the standby databases when the primary database is open in
read/write mode.
• TRANSPORT-OFF (applicable
( li bl only
l tto th
the primary
i d
database):
t b ) R
Redo
d ttransportt services
i are
stopped on the primary database.
• APPLY-ON (applicable only to a physical or logical standby database): Redo Apply is
started on the physical standby database when it is mounted or in open read-only mode.
SQL Apply is started on a logical standby database when it is opened and the logical
standby database guard is on.
• APPLY OFF (applicable only to a physical or logical standby database): Redo Apply is
APPLY-OFF
stopped on a physical standby database. SQL Apply is not running on a logical standby
database.

Managing Redo Transport Services

by Using DGMGRL
Specify database properties to manage redo transport services:
Property Purpose
AlternateLocation Specifies an alternate disk location to store the archived redo log files in
the standby when the location specified by the
StandbyArchiveLocation configurable property fails
ApplyLagThreshold Generates a warning status for a logical or physical standby when the
member's apply lag exceeds the value specified by the property
ArchiveLagTarget Limits the amount of data that can be lost and, effectively, increases the
s a
) ha
availability of the standby database or Far Sync instance by forcing a log
switch after the amount of time you specify (in seconds) elapses
l ฺ c om
Binding Specifies whether the redo destination is MANDATORY or OPTIONAL
m ai ฺ
@ g
making uid
e
DGConnectIdentifier Specifies the connection identifier the broker uses when
z 9
9 nt G
connections to a configuration member
u i
( pr tude
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
The properties that A BData
the b broker uses can be categorized into configuration
Guard
L I Z r a
properties that
A E control n s fe behavior of the broker configuration, monitorable (read-only)
the
I C I
properties
- t r a
for information, and configurable properties. The properties listed in the slide are
A TR nonproperties related to redo transport services specifically.

configurable
P For a complete list and detailed explanation of each broker property, see the documentation
titled Oracle Data Guard Broker.


by Using DGMGRL
Property Purpose
LogArchiveFormat Specifies the format for filenames of archived redo log files using a
database ID (%d)
(%d), thread (%t)
(%t), sequence number (%s)
(%s), and
resetlogs ID (%r)
LogArchiveMaxProcesses Specifies the initial number of archiver processes (ARCn) that are
invoked
LogArchiveMinSucceedDest Controls when online redo log files are available for reuse
s a
) ha
provided archiving has succeeded to a minimum number of
destinations
l ฺ c om
LogShipping Specifies the ENABLE and DEFER values for the
LOG_ARCHIVE_DEST_STATE_n initialization parameter of the m ai ฺ
database or Far Sync instance that is sending redo data
9 @ g
u ide
i z n G
9 configuration
t
LogXptMode Specifies the redo transport services u
pr tude on each
member to SYNC, ASYNC, or FASTSYNC (
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
Guard
L I Z r a
properties that
the
I C I
properties
- t r a

configurable
titled Oracle Data Guard Broker


by Using DGMGRL
Configurable Purpose
Property
MaxConnections Specifies how many ARCn processes will be used in parallel to transmit
redo data from a single archived redo log on the database or Far Sync
instance to the archived redo log at the remote site
MaxFailure Specifies the maximum number of contiguous archiving failures before the
redo transport services stop trying to transport archived redo log files to the
standby database
s a
NetTimeout Specifies
p the number of seconds the LGWR waits for Oracle Net Services to ) ha
respond to a LGWR request and is used to bypass the long connection
l ฺ c om
timeout in TCP/IP
m ai ฺ
RedoCompression Specifies whether redo data is transmitted to a standby 9 @ g
u
database or de
iFar
Sync instance in compressed or uncompressediform z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
Guard
L I Z r a
properties that
the
I C I
properties
- t r a

configurable
titled Oracle Data Guard Broker.


by Using DGMGRL
Configurable Property Purpose

ReopenSecs Specifies the minimum number of seconds before the
archiver process (ARCn
(ARCn, foreground
foreground, or log writer process)
should try again to access a previously failed destination
StandbyArchiveLocation Specifies the location of archived redo log files arriving from
a redo source
TransportDisconnectedThreshold Used to generate a warning status for a logical, physical, or

s a
) ha
snapshot standby, or a Far Sync instance when the last
communication from the primary database exceeds the
value specified
f in seconds
l ฺ c om
TransportLagThreshold Used to generate a warning status for a logical, m ai orฺ
physical,
snapshot standby, or a Far Sync instance @ g the ide
when
member's transport lag exceeds the
i z 9
9value n t Guin
specified
seconds
( pru tude
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
Guard
L I Z r a
properties that
the
I C I
properties
- t r a

configurable
titled Oracle Data Guard Broker

Managing the Redo Transport Service

by Using the LogXptMode Property
• The redo transport service must be set up for the chosen
data protection mode.

• Use the LogXptMode property to set the redo transport
services:
– ASYNC: Sets the ASYNC and NOAFFIRM attributes of
LOG_ARCHIVE_DEST_n
– SYNC: Sets the SYNC and AFFIRM attributes of
LOG_ARCHIVE_DEST_n a
– FASTSYNC: Sets the SYNC and NOAFFIRM attributes of ) has
om
LOG_ARCHIVE_DEST_n lฺc ai ฺ
m
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
BE LogXptMode
Use the Data GuardAbroker l e
L I Z erab property to set redo transport services.
• ASYNC:EConfigures
A n s f redo transport services by setting the ASYNC and NOAFFIRM
IC I
attributes tofra
- the LOG_ARCHIVE_DEST_n initialization p parameter
R n
noConfigures redo transport services by setting the SYNC and AFFIRM attributes of
T• SYNC:
PA the LOG_ARCHIVE_DEST_n initialization parameter
• FASTSYNC: Configures redo transport services by setting the SYNC and NOAFFIRM
attributes of the LOG_ARCHIVE_DEST_n initialization parameter
Definitions of LOG_ARCHIVE_DEST_n Attributes
S C Redo
• ASYNC: edo data that
t at iss generated
ge e ated by a transaction
t a sact o need
eed not
ot have
a e bee
been received
ece ed at a
destination that has this attribute before the transaction can commit.
• SYNC: Redo data that is generated by a transaction must have been received by every
enabled destination that has this attribute before the transaction can commit.
• AFFIRM and NOAFFIRM: Control whether redo transport services use synchronous or
asynchronous disk I/O to write redo data to the archived redo log files
- AFFIRM: Specifies that a redo transport destination acknowledges received redo
data after writing it to the standby redo log
- NOAFFIRM: Specifies that a redo transport destination acknowledges received
redo data before writing it to the standby redo log

Setting LogXptMode to ASYNC

MRP or Standby
Primary database LSP
TTnn RFS
Redo
buffer
Standby ack (Real-time
LGWR apply)
Standby
acle Net
redo logs
s a
Online ) ha
om
Ora
redo
d
ARC0 l ฺ c
logs
m ai ฺ
9 @ g
u i de
Sets the ASYNC and NOAFFIRM
i z 9 nt G
attributes of u
( u
ON his S logs
LOG_ARCHIVE_DEST_n
R
B AR use t
U
Oracle
R
H icen s
T l
A
When you set the LogXptModeBE bleproperty to ASYNC, the broker configures redo transport
L I Z r a
services for this
A E standby n s fedatabase by using the ASYNC and NOAFFIRM attributes of the
I C I
LOG_ARCHIVE_DEST_n
- t r a initialization parameter. ASYNC mode enables a moderate level of
A TR protection
data
n on for the primary database with a lower performance impact than SYNC mode.
P Standby redo log files are required for ASYNC mode.
In the diagram in the slide, the solid line represents a synchronous operation (writing locally to
the primary database online redo log files). The broken lines represent asynchronous
operations with respect to the transaction commit on the primary database.

Setting LogXptMode to SYNC
Primary database MRP or Standby

transactions LSP
database
NSSn RFS
Redo
buffer
LGWR apply)
Standby
acle Net
redo logs
s a
Online ) ha
om
Ora
redo
d
ARC0 l ฺ c
logs
m ai ฺ
9 @ g
u i de
Sets the SYNC and AFFIRM
i z 9 nt G
attributes of u
( u
ON his S logs
LOG_ARCHIVE_DEST_n
R
B AR use t
U
Oracle
R
H icen s
T l
A BE bledatabase
When you set the LogXptMode property to SYNC, the broker configures redo
L I Z r a
transport services
A E fornsthis festandby database by using the SYNC and AFFIRM attributes of the
I C I
LOG_ARCHIVE_DEST_n
- t r a initialization parameter. This mode enables the highest level of data
A TR notonthe primary database but also incurs the highest performance overhead.
protection
P Standby redo log files are required for SYNC mode.

Setting LogXptMode to FASTSYNC

(New in Oracle Database 12c)
Primary database MRP or Standby
transactions LSP
database
NSSn RFS
Redo
buffer
LGWR apply)
Standby
acle Net
redo logs
s a
Online ) ha
om
Ora
redo
d
ARC0 l ฺ c
logs
m ai ฺ
9 @ g
u i de
Sets the SYNC and NOAFFIRM
i z 9 nt G
attributes of u
( u
ON his S logs
LOG_ARCHIVE_DEST_n
R
B AR use t
U
Oracle
R
H icen s
T l
A
When you set the LogXptModeBE bledatabase property to FASTSYNC, the broker configures redo
L I Z r a
transport services
A E fornsthis festandby database by using the SYNC and NOAFFIRM attributes of
I C I
the LOG_ARCHIVE_DEST_n
- t r a initialization parameter. This mode is new for Oracle Database
A TR non
12c.
P Standby redo log files are required for FASTSYNC mode.

Disabling Broker Management of the

Configuration or Standby Database
• Disable broker management of the configuration:
DGMGRL> DISABLE CONFIGURATION;
• Disable broker management of a standby database:

DGMGRL> DISABLE DATABASE 'london';
• Disable broker management of a Far Sync: s a

) ha
DGMGRL> DISABLE FAR_SYNC 'londonFS';
l d
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
You can disable brokerA Bmanagement
b of a configuration or a specific standby database. You
L I Z r a
may want toE
A n s fe management to perform maintenance or to temporarily prevent
disable broker
I
IC n-tra
automated actions for testing.
T R
Disabling o management does not affect the underlying Data Guard configuration.
broker
PARather, itnremoves the ability for you to manage the configuration by using DGMGRL or
Enterprise Manager Cloud Control.
Use the DISABLE CONFIGURATION DGMGRL command to disable broker management of
the configuration. Use the DISABLE DATABASE DGMGRL command to disable broker
management of the named standby database.
Note: You must use the DISABLE CONFIGURATION command to disable broker
management of a primary database.

Removing the Configuration or Standby Database
• Remove a standby database from the configuration:

DGMGRL> REMOVE DATABASE 'london2' [PRESERVE

DESTINATIONS];
• Remove a Far Sync from the configuration

DGMGRL> REMOVE FAR_SYNC 'londonFS';
• Remove the configuration: a

s
) ha
DGMGRL> REMOVE CONFIGURATION [PRESERVE DESTINATIONS];
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
H icenR s
T l
A
Use the REMOVE DATABASE BE command
b l e to delete the named standby database from the broker
L I Z r a
E nsfe
configuration.
A
I
C REMOVE
Use Ithe
- a
trCONFIGURATION command to delete the configuration. When you execute
R
T REMOVE
the n
noremoved,
CONFIGURATION command, the broker configuration is removed, all database
PAprofiles are the Data Guard broker configuration files is removed, and broker
management of all databases in the configuration is terminated. Execution of this command
does not affect the underlying databases. You cannot remove the configuration when fast-
start failover is enabled.
The PRESERVE DESTINATIONS syntax is available for both the REMOVE DATABASE and
REMOVE CONFIGURATIONS commands.commands By default
default, broker settings for
LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_CONFIG initialization parameters are removed
when the REMOVE commands are issued, but PRESERVE DESTINATIONS maintains these
initialization parameters. A common usage for this is to allow the Data Guard broker to
perform all of the setup for the LOG_ARCHIVE_DEST_n initialization parameters and then
remove the broker when it has finished.

Quiz
How many Data Guard broker configuration files are created for
each database unique name?

a. One
b Two
b.
c. Three
d. Four
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
E le l
A B
Answer: b
L IZ ferab
A E ns
I
IC n-tra
T R no
PA

Summary
In this lesson, you should have learned how to use

DGMGRL commands to:

• Manage the Data Guard broker configuration
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA


• Setting the DG_BROKER_START initialization parameter

• Creating the broker configuration
• Enabling the broker configuration
s a
) ha
l ฺ c om
m ai ฺ
9 @ g
u ide
i z 9 nt G
u
pr tude
(
R ON his S
B AR use t
U
Oracle
R
H icen s
T
A BE ble l
E LIZ sfera
I C IA -tran
TR non
PA

D79232GC10 sg1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D79232GC10 sg1

Uploaded by

Copyright:

Available Formats

Edutronic Global Services EฺIฺRฺL

Student Guide – Volume I

Learn more from Oracle University at education.oracle.com

Author Copyright © 2014, Oracle and/or it affiliates. All rights reserved.

Mark Fuller Disclaimer

This document contains proprietary information and is protected by copyright and

1 Introduction to Oracle Data Guard

Creating a Physical Standby Database Job Task Details 2-15

Editing Primary Database Properties: General Properties 2-20

Specifying Role-Based Destinations 4-15

Specifying Values for LOG_FILE_NAME_CONVERT 4-21

Setting STANDBY_MAX_DATA_DELAY by Using an AFTER LOGON Trigger 5-13

Active Data Guard: DML on Temporary Tables 5-17

7 Creating a Logical Standby Database

Preparing to Create a Logical Standby Database 7-7

8 Oracle Data Guard Broker: Overview

Data Guard Broker: Management Model 8-6

10 Monitoring a Data Guard Broker Configuration

11 Configuring Data Protection Modes

Maximum Performance Mode 11-7

12 Performing Role Transitions

13 Using Flashback Database in a Data Guard Configuration

Configuring Flashback Database by Using Enterprise Manager 13-6

Using Flashback Database After Failover 13-13

14 Enabling Fast-Start Failover

Performing Manual Role Changes 14-39

Using Enterprise Manager to Suspend Fast-Start Failover 14-49

15 Backup and Recovery Considerations in an Oracle Data Guard Configuration

16 Enhanced Client Connectivity in a Data Guard Environment

Managing Services 16-6

Performing a Rolling Upgrade by Using an Existing Logical Standby

DBMS_ROLLING: Concepts 17-29

19 Oracle Database Exadata Cloud Service Overview

Data Security 19-11

Simple Web-Based Management 19-18

After completing this lesson, you should be able to:

• Describe the basic components of Oracle Data Guard

Oracle Database 12c: Data Guard Administration 1 - 2

What Is Oracle Data Guard?

database Redo transport database

Oracle Database 12c: Data Guard Administration 1 - 3

Types of Standby Databases

• Physical standby database:

– Is identical to the primary database on a block-for-block

Oracle Database 12c: Data Guard Administration 1 - 4

Types of Standby Databases

• Snapshot standby database:

– Is a fully updatable standby database

Oracle Database 12c: Data Guard Administration 1 - 5

Types of Data Guard Services

Data Guard provides three types of services:

• Redo transport services

Oracle Database 12c: Data Guard Administration 1 - 6

Role Transitions: Switchover and Failover

Oracle Data Guard supports two role-transition operations:

Oracle Database 12c: Data Guard Administration 1 - 7

Oracle Database 12c: Data Guard Administration 1 - 8

Oracle Data Guard Broker Framework

Oracle Database 12c: Data Guard Administration 1 - 9

Choosing an Interface for Administering

– DGMGRL command-line interface

Oracle Database 12c: Data Guard Administration 1 - 10

Oracle Data Guard: Architecture