Data Guard 11g

<Course title here>
Preface
1-1
<Course title here>
Preface
1-2
<Course title here>
Preface
1-3
<Course title here>
Preface
1-4
<Course title here>
Preface
1-5
<Course title here>
Preface
1-6
Oracle Database 11g: Data Guard Administration 1 - 2
What Is Oracle Data Guard?
Oracle Data Guard is a central component of an integrated Oracle Database High Availability (HA)
solution set that helps organizations ensure business continuity by minimizing the various kinds of
planned and unplanned down time that can affect their businesses.
Oracle Data Guard is a management, monitoring, and automation software infrastructure that 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. Using a backup copy of the
primary database, you can create from one to 30 standby databases. The standby databases, together
with the primary database, make up a Data Guard configuration.
All Data Guard standby databases can enable up-to-date read access to the standby 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
A physical standby database is physically identical to the primary database, with on-disk
database structures that are identical to the primary database on a block-for-block basis. The
physical standby database is updated by performing recovery using redo data that is received
from the primary database. Oracle Database 11g 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, see Oracle Database Utilities in the Oracle
Database 11g documentation.
Types of Standby Databases (continued)
Snapshot Standby Database
A snapshot standby database is a database that is created by converting a physical standby
database into a snapshot standby database. The snapshot standby database receives redo
from the primary database, but does not apply the redo data until it is converted back into a
physical 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
The following types of services are available with Data Guard:
Redo transport services: Control the automated transmittal of redo information from
the primary database to one or more standby databases or archival destinations.
Apply services: Control when and how data is applied to the standby database.
- 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
Data Guard enables you to change the role of a database dynamically by issuing SQL
statements or by using either of the Data Guard brokers interfaces. Data Guard supports two
role-transition operations:
Switchover: The switchover feature enables you to switch the role of the primary
database to one 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, 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.
Oracle Data Guard Broker
The Oracle Data Guard broker is a distributed management framework that automates and
centralizes the creation, maintenance, and monitoring of Data Guard configurations. After
creating the Data Guard configuration, the broker monitors the activity, health, and availability
of all systems in the configuration.
Choosing an Interface for Administering a Data Guard Configuration
You can use Oracle Enterprise Manager Grid Control or the Data Guard brokers own
specialized command-line interface (DGMGRL) to take advantage of the brokers
management capabilities.
Enterprise Manager Grid Control provides a Web-based interface that combines with the
brokers centralized 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 (Overview)
Oracle Data Guard leverages the existing database redo-generation architecture to keep the
standby databases in the configuration synchronized with the primary database. By using the
existing architecture, Oracle Data Guard minimizes its impact on the primary database.
Oracle Data Guard uses several processes to achieve the automation that is necessary for
disaster recovery and high availability. Some of these processes existed before the
introduction of Data Guard; others were created specifically to support Oracle Data Guard.
These processes are discussed in more detail on the next few pages.
Primary Database Processes
On the primary database, Data Guard uses the following processes:
Log writer (LGWR): LGWR collects transaction redo information and updates the online
redo logs. For each synchronous (SYNC) standby database, LGWR passes the redo to
an LNS (Log Writer Network Server) process, which ships the redo directly to the remote
file server (RFS) process on the standby database. LGWR waits for confirmation from
the LNS process before acknowledging the commit. For asynchronous (ASYNC)
standby databases, independent LNS processes 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 LNS 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. For Oracle Database 11g Release 2 (11.2),
there can now be 30 archiver processes. The default value is four.
Standby Database Processes
On the standby database, Data Guard uses the following processes:
Remote file server (RFS): RFS receives redo information from the primary database
and can write the redo into standby redo logs or directly to archived redo logs. Each
LNSn and ARCn process from the primary database has its own RFS process.
Note: The 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 the managed recovery
with the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE SQL statement,
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 information to the logical standby database.
Physical Standby Database: Redo Apply Architecture
The Data Guard physical standby Redo Apply architecture consists of:
A production (primary) database, which is linked to one or more standby databases (up
to 30) that are identical copies of the production database. The limit of 30 standby
databases is imposed by the LOG_ARCHIVE_DEST_n parameter. For Oracle Database
11g Release 2 (11.2), the maximum number of destinations is 31. One is used as the
local archive destination, leaving the other 30 for uses such as the standby database.
Note: You can use the Cascaded Redo Log Destinations feature to incorporate more
than 30 standby databases in your configuration.
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.
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
In a logical standby database configuration, Data Guard SQL Apply uses redo information
shipped from the primary system. However, instead of using media recovery to apply changes
(as in the physical standby database configuration), the redo data is transformed into
equivalent SQL statements by using LogMiner technology. These SQL 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. 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.
Automatic Gap Detection and Resolution
If connectivity is lost between the primary database and one or more standby databases, redo
data that is being generated on the primary database cannot be sent to those standby
databases. When a connection is reestablished, Data Guard automatically detects that there
are missing archived redo log files (referred to as a gap), and then automatically transmits the
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
Data Guard provides three high-level modes of data protection that you can configure to
balance cost, availability, performance, and transaction protection. You can configure the
Data Guard environment to maximize data protection, availability, or performance.
Maximum Protection
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
prevents it from writing its redo stream to at least one remote standby redo log.
Hardware and Operating System Requirements
These are the requirements for Data Guard:
The hardware for the primary and standby database systems can be different. For
example, the number of CPUs, the memory size, and the storage configuration can
differ.
The operating systems for both databases and operating system binaries can be
different such as Linux and Windows.
If the primary and standby databases are both on the same server, you must ensure that the
operating system enables you to mount two databases with the same name on the same
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.
Refer to My Oracle Support notes 413484.1, 395982.1, and 414043.1 for additional
information.
Data Guard Operational Requirements: Oracle Database Software
You must install the same release of Oracle Database Enterprise Edition for the primary
database and all standby databases in your Data Guard configuration. Oracle Data
Guard is available only as a feature of Oracle Database Enterprise Edition; it is not
available with Oracle Database Standard Edition.
Note: See the course 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
the primary and standby database. If any database in your Data Guard configuration
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
Continuous service: With the use of switchover and failover between systems, your
business does not need to halt because of a disaster at one location.
Complete data protection: Data Guard guarantees that there is no data loss and
provides a safeguard against data corruption and user errors. Redo data is validated
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
needs by using the protection modes and several tunable parameters.
Centralized management: You can use Enterprise Manager Grid Control to manage all
configurations in your enterprise.
Answer: a, c, d
Answer: c
Steps to Create a Physical Standby Database
You perform the steps listed in the slide to use SQL and RMAN commands to create a
physical standby database. Detailed information about each step is provided in the remaining
slides of the lesson.
Note: See Oracle Data Guard Concepts and Administration for detailed information about
creating a physical standby database by using only SQL commands.
Preparing the Primary Database
The FORCE LOGGING mode determines whether the Oracle database server logs all changes in the
database (except for changes to temporary tablespaces and temporary segments).
Note: Additional information about enabling FORCE LOGGING follows in this lesson.
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 Administrators Guide.
A standby redo log is used to store redo received from another Oracle database.
Note: 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.
Note: The Data Guard broker requires the use of a server parameter 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
Administrators Guide for additional information about archiving.
FORCE LOGGING Mode
FORCE LOGGING mode determines whether the Oracle database server logs all changes in
the database (except for changes to temporary tablespaces and temporary segments). The
[NO]FORCE LOGGING clause of the ALTER DATABASE command contains the following
settings:
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.
The FORCE_LOGGING column in V$DATABASE contains a value of YES if the database is in
FORCE LOGGING mode.
Configuring Standby Redo Logs
A standby redo log is used only when the database is in the standby role to store redo data
received from the primary database. Standby redo logs form a separate pool of log file
groups.
Configuring standby redo log files is highly recommended for all databases in a Data Guard
configuration to aid in role reversal.
A standby redo log is required to implement:
Synchronous transport mode
Real-time apply
Cascaded redo log destinations
Note: By configuring the standby redo log on the primary database, the standby redo log is
created automatically on the standby database when you execute the DUPLICATE TARGET
DATABASE FOR STANDBY FROM ACTIVE DATABASE RMAN command.
Creating Standby Redo Logs
You must create at least one more standby redo log group than you have online redo log
groups as 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.
The RFS process writes to an archive redo log file 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.
Using SQL to Create Standby Redo Logs
You can create standby redo logs by using the ADD STANDBY LOGFILE clause of the ALTER
DATABASE statement. Although standby redo logs are used only when the database is
operating in the standby role, you should create standby redo logs on the primary database
so that switching roles does not require additional DBA intervention.
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
To verify that standby redo logs were created, query V$STANDBY_LOG or V$LOGFILE. An
example output using Automatic Storage Management (ASM) is shown below:
SQL> SELECT group#, type, member FROM v$logfile WHERE type =
'STANDBY;
GROUP# TYPE MEMBER
---------- ------- ------------------------------------------------
4 STANDBY +SBDAT/pc01sby1/onlinelog/group_4.266.711624939
4 STANDBY +SBFRA/pc01sby1/onlinelog/group_4.259.711624941
8 rows selected.
Setting Initialization Parameters on the Primary Database
On the primary database, you define initialization parameters that control redo transport
services while the database is in the primary role. These parameters are described in more
detail in the following slides.
Setting LOG_ARCHIVE_CONFIG
Specify the DG_CONFIG attribute of the LOG_ARCHIVE_CONFIG parameter to list the
DB_UNIQUE_NAME of the primary and standby databases in the Data Guard configuration. By
default, the LOG_ARCHIVE_CONFIG parameter enables the database to send and receive
redo. The LOG_ARCHIVE_CONFIG parameter can be used to disable the sending of redo logs
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
keyword of the LOG_ARCHIVE_CONFIG initialization parameter.
Setting LOG_ARCHIVE_DEST_n
By using the various LOG_ARCHIVE_DEST_n attributes, you define most of the settings for
the Data Guard configuration. The Redo Transport Service is directly controlled by these
settings. There are a number of different attributes that can be set for each
LOG_ARCHIVE_DEST_n parameter. Most have defaults that are adequate for most
configurations. See Oracle Data 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 the
Oracle Database, LOG_ARCHIVE_DEST_10 was set to USE_DB_RECOVERY_FILE_DEST
when the fast recovery area was being used. For Oracle Database 11g Release 2, this will
now have to be manually set. Query the 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
The VALID_FOR attribute of the LOG_ARCHIVE_DEST_n initialization parameter enables you
to identify exactly when the archive destination is to be used, as well as which type of log file it
is used for. The attribute uses a keyword pair to identify the redo log type as well as the
database role. Using this attribute enables you to set up parameters in anticipation of
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 attribute: redo_log_type and database_role.
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
log files.
Combinations for VALID_FOR
In the table in the slide, Valid indicates that the archive log destination is used in a database
that is in the role defined by the column heading. Ignored means that the archive log
destination is not appropriate and that a destination of this type is ignored. An ignored
destination does not generate an error.
There 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
The following attributes of the LOG_ARCHIVE_DEST_n initialization parameter define the redo
transport mode that is used by the primary database to send redo to the standby database.
SYNC: Specifies that redo data generated by a transaction must have been received at a
destination that has this attribute before the transaction can commit; otherwise, the
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 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
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 with the SYNC attribute is deprecated and will not be
supported in future releases.
The parameters listed in the slide are required if the disk configuration is not the same for the
primary and standby databases. The parameters are also applicable when the primary
database is transitioned to a standby database.
Specifying Values for DB_FILE_NAME_CONVERT
When files are added to the standby database, the DB_FILE_NAME_CONVERT parameter is
used to convert the data file name on the primary database to a data file name on the standby
database. The file must exist and be writable on the physical standby database; if it is not, the
recovery process halts with an error.
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. Parentheses are 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
The LOG_FILE_NAME_CONVERT parameter is used to convert the name of a redo log file on
the primary database to the name of a redo log file on the standby database. Adding a redo
log file to the primary database requires adding a corresponding file to the standby database.
When the standby database is updated, this parameter is used to convert the log file name
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 and 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 is a 255-character limit on this parameter.
Specifying a Value for STANDBY_FILE_MANAGEMENT
When STANDBY_FILE_MANAGEMENT is set to AUTO, you cannot execute the following
commands on the standby database:
ALTER DATABASE RENAME
ALTER DATABASE 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.
In the example in the slide, assume that the primary database is named pc01prmy and the
standby is named pc01sby1. For each, there is an Oracle Net Services name defined.
There are additional parameters 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:
DB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/pc01sby1/',
'/u01/app/oracle/oradata/pc01prmy/'
LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/pc01sby1/',
'/u01/app/oracle/oradata/pc01prmy/'
STANDBY_FILE_MANAGEMENT=AUTO
Specifying these initialization parameters configures the primary database to resolve gaps,
converts new data file and log file path names from a new primary database, and archives the
incoming redo data when this database is in the standby role.
Note: The convert parameters can also be used to change ASM disk groups, for example:
DB_FILE_NAME_CONVERT=('+DATA','+SBDAT')
Creating an Oracle Net Service Name for Your Physical Standby Database
Use Oracle Net Manager to define a network service name for your physical standby
database.
The slide shows the entry in the tnsnames.ora file that was generated by Oracle Net
Manager.
Note: This entry is used to connect to the standby database when invoking RMAN and
executing the 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 an Entry for Your Standby Database for the Listener
Use Oracle Net Manager to configure a new listener (if necessary) or to update the
listener.ora file with an entry for your physical standby database. The slide shows the
entry in the listener.ora file that was generated by Oracle Net Manager.
Note: This entry is needed because you start the instance in NOMOUNT mode. The labs for
this course use ASM, which runs from the /u01/app/oracle/product/11.2.0/grid
software home location. This location is different from the database software home location
defined as /u01/app/oracle/product/11.2.0/dbhome_1. Both software home
locations contain network configuration files. The ASM software home runs the listener on
port 1521 by the default installation. A second listener on port 12001 is created using the
network configuration files found in the database software home location.
Copying Your Primary Database Password File to the Physical Standby Database
Host
You must create a password file for your physical standby database by copying the primary
database password file to the physical standby database host and renaming it.
Creating an Initialization Parameter File for the Physical Standby Database
Create a text initialization parameter file containing only the DB_NAME initialization parameter.
This initialization parameter file is used to start the physical standby database in NOMOUNT
mode prior to the execution of the DUPLICATE TARGET DATABASE FOR STANDBY FROM
ACTIVE DATABASE 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 a directory for the physical standby database in the $ORACLE_BASE/admin directory.
Create the audit trail directory named adump under the database directory in
$ORACLE_BASE/admin.
Create a directory for the physical standby database data files in the
$ORACLE_BASE/oradata directory.
Starting the Physical Standby Database
Set the ORACLE_SID environment variable to your physical standby database. Start the
physical standby database in NOMOUNT mode by using the text initialization parameter file.
With ASM installed, there will be multiple software home locations on each machine. This will
require that the ORACLE_HOME and PATH location change accordingly. Oracle recommends
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. For example:
[oracle@EDBVR6P2-+ASM ~]$ . oraenv
ORACLE_SID = [+ASM] ? pc01sby1
The Oracle base for
ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid is
/u01/app/oracle
Note: Since the initialization parameter file contains an entry only for DB_NAME, 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.
Setting FAL_CLIENT and FAL_SERVER Initialization Parameters
On physical standby databases, fetch archive log (FAL) provides a client/server mechanism
for resolving gaps detected in the range of archived redo logs that are generated at the
primary database and received at the standby database. The FAL process is started only
when needed, and shuts down as soon as it is finished. It is very likely you will not see this
process running.
The FAL_CLIENT initialization parameter specifies the FAL client name (Oracle Net service
name) that is used by the FAL service, configured through the FAL_SERVER parameter, to
refer to the FAL client. This parameter is no longer required for Oracle Database 11g Release
2 (11.2). If it is not set, the fetch archive log (FAL) server will obtain the clients network
address from the LOG_ARCHIVE_DEST_n parameter that corresponds to the clients
DB_UNIQUE_NAME.
The FAL_SERVER initialization parameter specifies the FAL server (Oracle Net service name)
for a standby database.
Creating an RMAN Script to Create the Physical Standby Database
Create an RMAN script containing the DUPLICATE TARGET DATABASE FOR STANDBY FROM
ACTIVE DATABASE command.
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 (continued)
In the RMAN script, specify the settings for the physical standby initialization parameters.
Creating the Physical Standby Database
Connect to the primary database instance (target) and physical standby database instance
(auxiliary). Execute the script that you created.
Enabling Real-Time Apply
When you enable the optional real-time apply feature, log apply services apply the redo data
from standby redo log files in real time (at the same time the log files are being written to) as
opposed to recovering redo from archived redo log files when a log switch occurs. If for some
reason the apply service is unable to keep up (for example, if you have a physical standby in
read-only mode 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-only, up-to-date reporting from a logical standby 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.
Starting Redo Apply
On the standby database, issue the ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE USING CURRENT LOGFILE SQL command to start Redo Apply. This statement
automatically mounts the database. In addition, include the DISCONNECT FROM SESSION
option so that Redo Apply runs in a background session.
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;
Special Note: Standby Database on the Same System
If you have a standby database on the same system as the primary database, you must use the
following guidelines:
The data files must be renamed. The actual file names can be the same, but at least the directory
path must be different. This means that you must use the DB_FILE_NAME_CONVERT 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 than the primary
database. Otherwise, the standby database may overwrite the primary 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.
Preventing Primary Database Data Corruption from Affecting the Standby
Database
Data Guard uses Oracle processes to validate redo data before it is applied to the standby
database.
Corruption-detection checks occur at the following key interfaces:
On the 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 as part of archive log gap handling.
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 lost writes can be detected.
Answer: b
Answer: b
Oracle Data Guard Broker: Features
The following are some of the operations that the broker automates and simplifies:
Automated creation of Data Guard configurations incorporating a primary database, a
new or existing standby database, redo transport services, and log apply services
Note: Any of the databases in the configuration can be a Real Application Clusters
(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, testing, and performance tools
Data Guard Broker: Components
The Oracle Data Guard broker consists of both client-side and server-side components.
On the client, you can use the following Data Guard components to define and manage a
configuration:
Oracle Enterprise Manager
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,
modify their behavior at run time, monitor the overall health of the configuration, and provide
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 databases behavior. The properties are recorded in the
configuration file as a part of the databases object profile that is stored there. Many database
properties are used to control database initialization parameters related to the Data Guard
environment.
Data Guard Broker: Configurations
A Data Guard configuration consists of one primary database and up to 30 standby
databases. The databases in a Data Guard configuration are typically dispersed
geographically and are connected by Oracle Net.
A Data Guard broker configuration is a logical grouping of the primary and standby databases
in a Data Guard configuration. The brokers 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
The Data Guard broker performs operations on the following logical objects:
Configuration of databases
Single database
A broker configuration 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.
Data Guard Broker: Architecture
The Data Guard broker helps you create, control, and monitor a Data Guard configuration.
This configuration consists of a primary database that is protected by one or more standby
databases. After the broker has created the Data Guard configuration, the broker monitors the
activity, health, and availability of all systems in that configuration.
The Data Guard monitor process (DMON) is an Oracle background process that runs on every
instance that is managed by the broker. 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. 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 instance.
Data Guard Monitor: DMON Process
The Data Guard monitor comprises two components: the DMON process and the configuration
file.
The DMON process is an Oracle background process that is part of each database instance
managed by the broker. When you start the Data Guard broker, a portion of the SGA is
allocated and 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
By automating the tasks required to configure and monitor a Data Guard configuration, the
broker enhances the high-availability, data protection, and disaster protection capabilities that
are inherent in Oracle Data Guard. If the primary database fails, the broker streamlines the
process for any one of the standby databases to replace the primary database and take over
production processing.
The broker enables easy configuration of additional standby databases. After creating a Data
Guard configuration consisting of two databasesa primary and standbyyou 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
The table in the slide provides an overview of configuration management with and without the
Data Guard broker (source: Table 1-1, Configuration Management With and Without the
Broker, in Oracle Data Guard Broker).
Data Guard Broker Interfaces
The DGMGRL command-line interface includes:
Configuration and setup tasks
Management and control of the configuration
Commands to check the status and health of the configuration
Commands to execute role changes
Oracle Enterprise Manager Grid 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. Grid Control enables you to execute a switchover
or failover between a primary and a standby database by simply clicking a button.
Note: After defining a Data Guard broker configuration, you should use DGMGRL or
Enterprise Manager Grid Control to manage your configuration. You should not use SQL
commands to manage the databases because you could cause a conflict with the broker.
DGMGRL Commands
The following commands are available in DGMGRL (the Data Guard CLI). Many of these
commands have additional arguments that are not described here. See Oracle Data Guard
Broker for detailed information.
ADD: Adds a standby database to the broker configuration
CONNECT: Connects a given username to the specified instance
CREATE: Enables you to create broker configurations
DISABLE: Enables you to disable broker control of a configuration or database so that
the object is no longer managed by the broker
EDIT: Used to edit a configuration, database, or instance
ENABLE: Enables you to enable broker control of a configuration or database
EXIT/QUIT: Exits DGMGRL
FAILOVER: Performs a database failover operation in which one of the standby
databases changes to the role of primary database (This is an unplanned transition that
may result in the loss of application data.)
Using Oracle Enterprise Manager 10g Grid Control
To access the Data Guard features in Grid Control:
1. Click the Targets tab to go to the Targets page.
2. Click Databases to go to the Databases page, where you can see a list of all discovered
databases, including the primary database.
3. Click the primary database to go to the primary database home page.
4. Click Availability.
5. Click Setup and Manage in the Data Guard section of the Availability page to open the
Data Guard Overview page.
Data Guard Overview Page
On the Data Guard Overview page, you can:
View the protection mode and access the page to edit the protection mode
View a summary showing the amount of data that the standby database has not
received
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 Data Guard 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
Note: You access the Data Guard Overview page by clicking Setup and Manage in the Data
Guard section of the database Availability page.
Benefits of Using Enterprise Manager
Managing your Data Guard configuration with Oracle Enterprise Manager Grid Control
provides the following benefits:
Enables you to manage your configuration using the familiar Enterprise Manager
interface and event-management system
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
Answer: a, c
Answer: b
Data Guard Broker: Requirements
To use the Data Guard broker, you must comply with the following requirements:
Use the Enterprise Edition of Oracle Database.
Use a single-instance or multi-instance environment.
Set the COMPATIBLE initialization parameter to 11.2.0 to take advantage of new
Oracle Database 11g Release 2 (11.2) features.
Enterprise Manager automatically configures the Oracle Net 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 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 (continued)
Set the DG_BROKER_START initialization parameter to TRUE. This starts the DMON
process.
Note: When you use Enterprise Manager to create your configuration, this parameter is
automatically set to TRUE.
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). For details, see the
section titled Managing Broker Configuration Files in an Oracle RAC Environment in
Oracle Data Guard Broker.
Data Guard Broker and the SPFILE
To ensure that the broker can update the values of parameters in both the database instance
and the configuration file, you must use the persistent server parameter file (SPFILE) to
control static and dynamic initialization parameters. Use of the SPFILE gives the broker a
mechanism that enables it to reconcile property values that you have selected when using the
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.
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 settings the
next time you enable the broker configuration.
Data Guard Monitor: Configuration File
The DMON process maintains persistent configuration data about all the databases in the broker
configuration in a broker configuration file. Every database that is part of the Data Guard broker
configuration has two broker configuration files that are maintained and synchronized for each database
in the broker configuration. One of the files is in use and the 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.
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 databases behavior, and provide information to DGMGRL and Enterprise Manager.
Note: For Oracle Database 11g Release 2, the broker config files can reside on disks having any sector
size up to 4KB.
Data Guard Broker Log Files
The DMON process records operational and status information in the broker log file for each
instance in the Data Guard broker configuration.
Creating a Broker Configuration
To create a broker configuration by using DGMGRL, you first define the configuration, and
then add each database to the configuration and enable the configuration. Each step is
discussed in detail in the following slides.
Note: The databases must exist before you add them to the configuration 9
Defining the Broker Configuration and the Primary Database Profile
Execute the CREATE CONFIGURATION command to define the broker creation and create a
profile for the primary database. The following parameters must be specified:
configuration-name: User-specified name for the configuration.
database-name: Used by the broker to reference the primary database. You must use
the value 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
the connect identifier value.
Adding a Standby Database to the Configuration
Use the ADD DATABASE DGMGRL command to define the standby database and create a
broker configuration profile. The database name specified must be the same as the value of
the DB_UNIQUE_NAME initialization parameter. The connect identifier is used by Oracle Net
Services to access the database from all other databases in the configuration.
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 used to address the specified database from all databases in your configuration. 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
Oracle database version 10.2, you had to specify "MAINTAINED AS [ PHYSICAL |
LOGICAL ]" when you added an existing standby.
Enabling the Configuration
After defining the databases in the configuration, you enable the configuration and its
databases by executing the ENABLE CONFIGURATION DGMGRL command.
Changing Database Properties and States
Configurable database properties can be viewed and dynamically updated by using the EDIT
DATABASE SET PROPERTY DGMGRL command. Use the SHOW DATABASE VERBOSE
command to obtain a complete list of database properties.
The EDIT DATABASE SET STATE DGMGRL command is used to change the state of the
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 only to the primary database): Redo transport services 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
stopped on a physical standby database. SQL Apply is not running on a logical standby
database.
Managing Redo Transport Services by Using DGMGRL
Use the DGConnectIdentifier, LogXptMode, and LogShipping configurable database
properties to manage redo transport services. Details about each database property are
provided in the next few slides.
Note: See Oracle Data Guard Broker for information about additional properties that are used
to manage redo transport services.
Specifying the Connection Identifier by Using the DGConnectIdentifier
Property
The DGConnectIdentifier property is set when a database is added to the broker
configuration. Its initial value is the connect identifier that is specified in the CONNECT
IDENTIFIER IS clause of the ADD DATABASE command. If the optional CONNECT
IDENTIFIER IS clause is not specified, the initial value of the DGConnectIdentifier
property is obtained from the SERVICE attribute of the LOG_ARCHIVE_DEST_n initialization
parameter for the database specified in the ADD DATABASE command. If the
DGConnectIdentifier property is changed, the SERVICE attribute of the
LOG_ARCHIVE_DEST_n initialization parameter for that database is also changed.
The DGConnectIdentifier property value is also used to set the FAL_SERVER and
FAL_CLIENT initialization parameters. If the DGConnectIdentifier property is changed,
the FAL_SERVER and FAL_CLIENT initialization parameters are also updated.
Managing the Redo Transport Service by Using the LogXptMode Property
Use the Data Guard broker LogXptMode property to set redo transport services.
ASYNC: Configures redo transport services by setting the ASYNC and NOAFFIRM
attributes of the LOG_ARCHIVE_DEST_n initialization parameter.
SYNC: Configures redo transport services by setting the SYNC and AFFIRM attributes of
the LOG_ARCHIVE_DEST_n initialization parameter.
Definitions of LOG_ARCHIVE_DEST_n Attributes
ASYNC: Redo data that is generated by a transaction need not have been received 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
When you set the LogXptMode property to ASYNC, the broker configures redo transport
services for this standby database by using the ASYNC and NOAFFIRM attributes of the
LOG_ARCHIVE_DEST_n initialization parameter. ASYNC mode enables a moderate level of
data protection for the primary database with a lower performance impact than SYNC mode.
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
When you set the LogXptMode database property to SYNC, the broker configures redo
transport services for this standby database by using the SYNC and AFFIRM attributes of the
LOG_ARCHIVE_DEST_n initialization parameter. SYNC mode is required for maximum
protection and maximum availability data protection modes. This mode enables the highest
level of data protection to the primary database but also incurs the highest performance
overhead.
Standby redo log files are required for SYNC 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.
Controlling the Shipping of Redo Data by Using the LogShipping Property
Use the LogShipping configurable database property to specify whether redo transport
services can send redo data to a particular standby database. The value specified for the
LogShipping property is applicable only when the primary database is in the TRANSPORT-
ON state. If the value of the LogShipping property is ON, redo transport services are enabled
for that standby database. If the LogShipping property is set to OFF, redo transport services
are disabled for that standby database.
Disabling Broker Management of the Configuration or Standby Database
You can disable broker management of a configuration or a specific standby database. You
may want to disable broker management to perform maintenance or to temporarily prevent
automated actions for testing.
Disabling broker management does not affect the underlying Data Guard configuration.
Rather, it removes the ability for you to manage the configuration by using DGMGRL or
Enterprise Manager Grid 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
Use the REMOVE DATABASE command to delete the named standby database from the broker
configuration.
Use the REMOVE CONFIGURATION command to delete the configuration. When you execute
the REMOVE CONFIGURATION command, the broker configuration is removed, all database
profiles are removed, 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. By 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.
Answer: b
Answer: d
Using Enterprise Manager to Create a Broker Configuration
Oracle Enterprise Manager (Enterprise Manager) automates the process of creating a
standby database. The Add Standby Database Wizard is used to create a new broker
configuration (including standby databases) and to add databases to an existing
configuration.
Before you invoke the Add Standby Database Wizard, verify that the primary database
instance was started with a server parameter file (SPFILE). If the instance was not started
with an SPFILE, the wizard notifies you.
Creating a Configuration
You can access the Data Guard features in Enterprise Manager Grid Control by clicking
Setup and Manage in the Data Guard section on the Availability page.
Click the Add Standby Database link to invoke the Add Standby Database Wizard.
Creating a New Configuration
Using the Add Standby Database Wizard, perform the following steps:
1. Specify the backup type to use for the standby database creation.
2. Specify the backup options.
3. Select the Oracle home in which to create the standby database.
4. Specify the location for standby database files.
5. Specify standby database configuration parameters.
6. Review the configuration information.
During the standby creation process, the following operations are performed (for online
backup types):
RMAN automatically copies the server parameter file to the standby host
The auxiliary instance is started with the parameter file
A backup control file is restored
All necessary database files and archive redo logs are copied over the network to the
standby host
RMAN recovers the standby database, but does not place it in manual or managed
recovery mode
Adding a Standby Database to an Existing Configuration
Click the Add Standby Database button to invoke the Add Standby Database Wizard.
Using the Add Standby Database Wizard
With the Add Standby Database Wizard, you first select the type of standby database that you
want to create. You can create a physical or logical standby database, or you can add an
existing database, including a RAC database, to the configuration to serve as a standby
database.
Note: You must be connected to the primary database with SYSDBA credentials to invoke the
Add Standby Database Wizard.
If you choose to create a new standby database, the following conditions are verified when
you click Continue:
All databases in the configuration are using an SPFILE.
The primary database is in ARCHIVELOG mode.
If any of these conditions are not met, the wizard returns a message indicating that you must
cancel the wizard and perform the appropriate action to meet the condition.
In addition, the wizard verifies that the primary database is in FORCE LOGGING mode. If it is
not, a warning message appears. You can then cancel the configuration and enable FORCE
LOGGING.
The following slides describe the wizard steps in detail.
Step 1: Specify the Backup Type
You can use the Backup Type page of the wizard to select the type of backup for the creation
of the standby database. There are two options:
Perform an online backup of the primary database: Creates a backup using the
Recovery Manager utility (RMAN)
Use a backup from a previous standby database creation: Uses an existing backup
of the primary database that was created by Data Guard during a previous creation of a
standby database
Step 2: Specify the Backup Options (RMAN Direct Copy)
If you selected the Perform a live backup of the primary database option on the Backup
Type page with the option to Use Recovery Manager (RMAN) to copy database files, then
staging areas are not required. RMAN will copy files directly to destination locations.
In the Primary Host Credentials section, specify the operating system credentials of the user
who owns the primary database Oracle server installation. The credentials are preset to the
host-preferred credentials that are stored with the primary database-preferred credentials by
default.
Step 2: Specify the Backup Options (Staging Areas Example)
If you selected the Perform an online backup of the primary database option on the Backup
Type page with the option to Copy database files via staging areas, you can specify a location
on the primary database host to store the backup files. A default location is specified in the
Backup Files Directory Location field, or you can provide your own location. A unique
subdirectory to store the backup files is created in the specified directory.
If you intend to create additional standby databases, you can save the backup by selecting
the Retain directory for a future standby database creation option. Otherwise, you should
select the Delete directory after standby database creation option. If you choose to retain the
backup, additional space is required (as indicated on the Backup Options page).
If you selected the Use a backup from a previous standby database creation option on the
Backup Type page, specify the location of the backup in the Backup Files Directory Location
field. This backup must have been taken by Data Guard during creation of a previous standby
database and must be of the same type that you are creating.
In the Primary Host Credentials section, specify the operating-system credentials of the user
who owns the primary database Oracle server installation. The credentials are preset to the
host-preferred credentials that are stored with the primary database-preferred credentials by
default.
Step 3: Select the Standby Database Location Instance Name
In the Instance Name field, specify the instance name for your new standby database, or use
the default instance name that is provided. The instance name must conform to Oracle
naming guidelines.
Note: For a physical standby, the database name is the same as the primary because a
physical standby is an exact, block-by-block copy of the primary. You can make the instance
name the same as the primary. However, you must make the instance name different from the
primary if the standby is on the same machine as the primary.
In the Standby Database Location section, specify the host machine name and Oracle Home
location for the database software. There may be more than one Oracle Home on the same
machine.
In the Standby Host Credentials section, specify the operating system credentials of the user
who owns the Oracle installation in the selected Oracle Home on the standby host.
Step 3: Select the Standby Database Location Oracle Home
The Standby Database Location section lists all available Oracle Homes that match the
primary database version and host operating system. From this list, select the host and
Oracle Home for your new standby database.
Note: The standby database home location should not be a Grid Infrastructure home.
Step 4: Specify the Standby Database File Locations (Staging Method)
The Standby Host Backup File Access section appears only when you are creating a standby
database on a host other than the primary database. You must select a method to be used to
make the primary backup files accessible to the standby host. This is screenshot is valid when
staging areas have been selected as the backup method.
Transfer files: If you choose to transfer files from the primary host working directory to a
standby host directory, you must specify a temporary location on the standby host to
store the backup files copied from the primary host. In addition, you must select the file-
transfer method: FTP or HTTP server. FTP is the faster of the two methods. Select the
HTTP server option if you know that the primary or standby host does not support FTP.
Directly access the files: If you select this method, you must supply the network path
name for the standby host. This method is appropriate when the primary host working
directory location is directly accessible from the standby host via NFS, a network share,
or some other network method. This option saves time and disk space because there is
no file transfer to the standby host and because no temporary location is needed.
Step 4: Specify the Standby Database File Locations
By default, all standby database files are placed in an Oracle Optimal Flexible Architecture
(OFA) directory structure when your primary and standby databases are on the same host.
When your primary and standby databases are on different hosts, you can specify that you
want to convert the standby files to an OFA structure or keep the file names and locations the
same as the primary database. As an option, you can change the locations of individual
standby database files by clicking the Customize button to display the File Locations
Customize page of the wizard.
The Flash Recovery Area (now known as Fast Recovery Area) allows you to enable the
feature, define a location for the Fast Recovery Area, and set the Fast Recovery Area size.
Data Guard automatically adds configuration information for the new standby database to the
listener.ora and tnsnames.ora files in the directory that is specified in the
Configuration File Location field in the Network Configuration File Location section. The
default location is the network administration directory for the standby databases Oracle
home. The default location is correct for most configurations. You can specify a different
directory if you want the new standby database to be serviced by a listener that is running in a
different Oracle home on the standby host.
Step 5: Specify Standby Database Configuration Parameters
On the Standby Configuration page, you can specify configuration parameters for the standby
database. The parameters that must be specified depend on whether you are adding an
existing standby database, creating a physical standby database, or creating a logical
standby database. The configuration parameters include the instance name, service provider
name, target name, and standby archive location. The default values are based on
corresponding primary database settings.
When you create a physical database, you must configure the following parameters:
Database Unique Name: Specify a value for the database DB_UNIQUE_NAME
parameter. This name must be unique in the Data Guard configuration.
Note: This field appears only if you are creating a physical standby database.
Target Name: Specify a name for Enterprise Manager to use for the new standby
database. This name will appear in the list of database targets maintained by Enterprise
Manager. This name should be the same as the database unique name.
In the Standby Database Monitoring Credentials, you can choose between a non-SYSDBA
user such as DBSNMP to monitor the database or choose to use the SYSDBA monitoring
credentials.
Step 6: Review the Configuration Information
The Review page displays a summary of your selections and lists the parameters to be used
to create the standby database.
The standby database is created in the background by an Oracle Enterprise Manager job.
The name of the job that is submitted is provided at the top of the page.
When you click Finish, the Processing page appears. This page tracks each step through the
submission of the standby creation job. After the job submission is complete, you see the
Data Guard Overview page, where you can monitor the progress of the standby creation job.
Standby Database Creation: Processing
On the Processing page, you can view the progress of the Add Standby Database process.
On completion of the process, Oracle Enterprise Manager displays the Data Guard Overview
page.
The display on the Processing page differs based on whether you are adding an existing
standby database or creating a standby database. An arrow indicates which step is being
processed. When the process is completed, a check icon appears next to the step.
The following steps appear on the Processing page:
Creating Data Guard Configuration or Updating Data Guard Configuration: The
Data Guard configuration (if it does not exist) is created during this step. If you are
adding an existing standby database, it is added to the configuration.
Preparing standby creation job: This step appears only if you are creating a standby
database. The standby database is actually created by an Enterprise Manager job;
preliminary setup steps to prepare for job submission are accomplished in this step. You
can cancel the Add Standby Database process at any point up to the completion of this
step.
Standby Database Creation: Progress
After the job is submitted, you return to the Data Guard Overview page. The Data Guard
Status column indicates that standby database creation is in progress. Click the Creation in
progress link to access the job page and monitor the progress.
After creation of the standby database, it appears on the Data Guard Overview page with a
status of Normal.
Verifying a Data Guard Configuration
After creating your configuration, you should use the Data Guard Verify operation to check the
configuration. (You can use the Verify operation at any other time to check your
configuration.) Invoke the Verify operation by clicking Verify Configuration in the Additional
Administration section of the Data Guard page. The Verify operation performs a series of
validation checks on the Data Guard configuration, including a health check of each database
and agent. The Verify operation:
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.
Performs a log switch on the primary database (for non-RAC databases) and verifies
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 operation (including errors).
Note: You can cancel the Verify operation at any time by clicking Cancel.
Reviewing Results of the Verify Operation
View the results of the Verify operation on the Detailed Results page. If errors occur during
the operation, detailed information appears on this page.
Performing Routine Maintenance
You can use Enterprise Manager Grid Control to maintain your broker configuration. Each
task is described in detail in the next few slides.
Editing Standby Database Properties
To access the Standby Database Properties page, select your standby database on the Data
Guard overview page and click Edit.
Managing Apply Services
You may need to temporarily stop Redo Apply for routine maintenance tasks. You can stop
apply services by selecting Log Apply Off on the Edit Standby Database Properties page and
then clicking Apply.
When you specify Log Apply Off, Redo Apply is stopped and redo data is not applied to the
standby database. However, the standby database continues to receive data from the primary
database.
Changing the Basic Properties of a Database
To use Enterprise Manager to view or change properties:
1. In the Primary Database section on the Data Guard Overview page (or in the Standby
Databases section, as appropriate), click Edit.
2. Click the Standby Role Properties tab or the Common Properties tab (depending on the
property that you want to change).
3. Make the appropriate change and click Apply.
When the process is completed, a message indicates success.
Changing the Advanced Properties of a Database
To use Enterprise Manager to view or change properties:
1. In the Primary Database section on the Data Guard Overview page (or in the Standby
Databases section, as appropriate), click Edit.
2. Click the Standby Role Properties tab or the Common Properties tab (depending on the
property that you want to change).
3. Expand the Show Advanced Properties link. The advanced properties will be different
depending on the type of standby database.
4. Make the appropriate change and click Apply.
When the process is completed, a message indicates success.
Setting the Redo Transport Mode by Using Enterprise Manager
On the Standby Role Properties page, select the redo transport mode from the following
values in the Log Transport Mode list:
ASYNC: Configures redo transport services for your standby database by using the
LGWR, ASYNC, and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization
parameter. This mode, along with standby redo log files, provides a moderate level of
protection to the primary database and incurs a moderate performance impact.
SYNC: Configures redo transport services for your standby database by using the LGWR,
SYNC, and AFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter.
This mode, along with standby redo log files, is required for the maximum-protection or
maximum-availability protection modes. This redo transport mode provides the highest
level of data protection to the primary database, but it also incurs the highest
performance impact.
Answer: b
Answer: b
Benefits of Implementing a Logical Standby Database
A logical standby database provides benefits in disaster recovery, high availability, and data
protection that are similar to those of a physical standby database. It also provides the
following specialized benefits:
Efficient utilization of system resources: A logical standby database is an open,
independent, 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 11g includes 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 Logical Standby Database (continued)
Data protection: A logical standby database provides a safeguard against data
corruption and user errors. Primary-side physical corruptions do not propagate through
the redo data that are transported to the logical standby database. Similarly, user errors
that may cause the primary database to be permanently damaged can be resolved
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 Upgrading Databases in a Data Guard Configuration for
additional information about using a logical standby database to perform upgrades.
Logical Standby Database: SQL Apply Architecture
In a logical standby database configuration, Data Guard SQL Apply uses redo information
shipped from the primary system. However, instead of using media recovery to apply changes
(as in the physical standby database configuration), archived redo log information is
transformed into equivalent SQL statements by using LogMiner technology. These SQL
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
SQL Apply uses a collection of parallel execution servers and background processes that
apply changes from the primary database to the logical standby database as follows:
The reader process reads redo records from the archived redo log files.
The preparer processes convert the block changes into table changes or logical change
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 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 Logical Standby Database
When creating a logical standby database, you must take several actions before you begin.
The following slides cover these steps in detail.
Unsupported Objects
If the primary database contains unsupported tables, log apply services automatically exclude
these tables when applying redo data to the logical standby database.
Unsupported Data Types
Ensure that your logical standby database can support the data types of the database objects
that are defined in your primary database.
Note: See Oracle Data Guard Concepts and Administration for additional information about
unsupported data types and objects. SecureFile LOB's are supported if the database
compatibility level is set to 11.2 or higher.
Checking for Unsupported Tables
You can query DBA_LOGSTDBY_UNSUPPORTED_TABLE to determine which tables in the
primary database are not supported by log apply services.
Checking for Tables with Unsupported Data Types
You can query the DBA_LOGSTDBY_UNSUPPORTED data dictionary view to see all tables that
contain data types that are not supported by logical standby databases. These tables are not
maintained (that is, they do not have DML applied) in the logical standby database. Changes
made to unsupported data types, tables, sequences, or views on the primary database are
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
Not all data SQL commands that are executed on the primary database are applied to the
logical standby database. If you execute any of the commands (shown in the slide) on the
primary database, they are not executed on any logical standby database in your
configuration. You must execute them on the logical standby database if needed to maintain
consistency between the primary database and the logical standby database.
Unsupported PL/SQL Supplied Packages
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.
Oracle PL/SQL supplied packages that do not modify system metadata but may modify user
data are supported as long as the modified data belongs to the supported data types.
Example of such packages are DBMS_LOB, DBMS_SQL, and DBMS_TRANSACTION. Specific
support for DBMS_JOB has been provided. Jobs created on the primary database are
replicated on the standby database, but will not run as long as the standby maintains its
standby role. Specific support for DBMS_SCHEDULER has been provided to allow jobs to run
on the standby database with the database_role attribute of jobs.
Note: See Oracle Data Guard Concepts and Administration for additional information about
unsupported data types and objects.
Ensuring Unique Row Identifiers
Because the row IDs on a logical standby database might not be the same as the row IDs on
the primary database, a different mechanism must be used to match the updated row on the
primary database to its corresponding row on the logical standby database. Primary keys and
unique indexes can be used to match the corresponding rows. It is recommended 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 logical
standby database.
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);
Adding a Disabled Primary Key RELY Constraint
If your application ensures that the rows in a table are unique, you can create a disabled
primary key RELY constraint on the table without incurring the overhead of maintaining a
primary key on the primary database.
The RELY constraint tells the system to log the named columns (in this example,
EMPLOYEE_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
identify the row on the logical standby database. Failure to do so results in full table 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
The remainder of this lesson covers each of these steps in detail.
Step 1: Create a Physical Standby Database
You create a logical standby database by first creating a physical standby database. Then
you convert the physical standby database into a logical standby database.
To create the physical standby database:
a. Create a physical standby database as described in the lesson titled Creating a
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
To stop Redo Apply, issue one of the following commands:
If the configuration is not managed by the broker
SQL > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
If the configuration is managed by the broker
DGMGRL > EDIT DATABASE '<database name>' set state='apply-off';
Step 3: Prepare the Primary Database to Support a Logical Standby Database
a. To transition the primary database to the logical standby role, you must modify the
initialization parameters on the primary database so that no parameters need to change
after a role transition. To do this, include the LOG_ARCHIVE_DEST_2 destination on the
primary database. This parameter takes effect only when the primary database is
transitioned to the standby database role.
b. Set the UNDO_RETENTION initialization parameter to 3600. The UNDO_RETENTION
parameter specifies (in seconds) the amount of committed undo information to retain in
the database. The value of 3600 is recommended for best results when building a
LogMiner dictionary for the logical standby database to prevent ora-1555 errors when
there are a number of active transactions.
Step 4: Build a LogMiner Dictionary in the Redo Data
SQL Apply requires a LogMiner dictionary in the redo data so that it can properly interpret
changes in the redo. When you execute the DBMS_LOGSTDBY.BUILD procedure, the
LogMiner dictionary is built and supplemental logging is automatically enabled for logging
primary key and unique key columns. Supplemental logging ensures that each update
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
To prepare the physical standby database to transition to a logical standby database:
a. Issue the ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name command to
continue applying redo data to the physical standby database until it is ready to convert
to a logical standby database. Specify a database name (db_name) to identify the new
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 the LOG_ARCHIVE_DEST_n parameters to specify separate local destinations
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
To open the logical standby database and start SQL Apply:
a. On the logical standby database, issue the ALTER DATABASE OPEN RESETLOGS
command to open the database.
b. On the logical standby database, issue the following command to start SQL Apply:
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
Adding a Logical Standby Database to a Data Guard Broker Configuration
Use the ADD DATABASE DGMGRL command to define the standby database and create a
broker configuration profile. The database name that is specified must be the same as the
value of the DB_UNIQUE_NAME initialization parameter. The connect identifier is used by
Oracle Net Services to access the database from all other databases in the configuration.
Note: If the existing Data Guard broker configuration has not been enabled, you will need to
enable it to allow the broker to manage the new logical standby database.
Step 7: Verify That the Logical Standby Database Is Performing Properly
After creating your logical standby database and setting up redo transport services and log
apply services, you should verify that redo data is being transmitted from the primary
database and applied to the standby database.
To verify that the logical standby database is functioning properly:
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,
2 DICT_BEGIN,DICT_END
3 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
(continued)
d. On the logical standby database, query the V$LOGSTDBY_STATS view to verify that
redo data is being applied correctly:
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
2 WHERE NAME = 'coordinator state';
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
2 FROM V$LOGSTDBY_PROGRESS;
Creating a Logical Standby Database by Using Enterprise Manager
To create a logical standby database by using Enterprise Manager:
1. Click Add Standby Database on the Data Guard overview page to invoke the Add
Standby Database Wizard.
Note: If the logical standby database is the first database to be created in your
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
On the Add Standby Database: Backup Type page, you determine if you have tables or
columns that are not supported by SQL Apply. In the SQL Apply Unsupported Tables section,
select Table Columns and Data Types in the drop-down list and click Go to see the
unsupported tables.
Using the Add Standby Database Wizard (continued)
On the Add Standby Database: Configuration page, specify the values for the DB_NAME and
DB_UNIQUE_NAME parameters for your logical standby database. In addition, specify the
target name to be used by Enterprise Manager Grid Control.
In the Standby Database Monitoring Credentials section, you can choose between a non-
SYSDBA user such as DBSNMP to monitor the database or choose to use the SYSDBA
monitoring credentials.
Using the Add Standby Database Wizard (continued)
After completing all pages in the wizard, you see the Add Standby Database Review page.
Review the information on this page and click Finish to submit a job to create your logical
standby database.
Securing Your Logical Standby Database
The database guard controls user access to tables in a logical standby database. Use the
ALTER DATABASE GUARD command to configure the database guard.
By default, it is not possible for a nonprivileged user to modify data on a Data Guard SQL
Apply database, because the database guard is automatically set to ALL. With this level of
security, only 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
Archived redo logs on the logical standby database are automatically deleted by SQL Apply
after they are applied. This feature reduces the amount of space consumed on the logical
standby database and eliminates the manual step of deleting the archived redo log files.
You can enable and disable the auto-delete feature for archived redo logs by using the
DBMS_LOGSTDBY.APPLY_SET procedure. By default, the auto-delete feature is enabled.
Note: If you are using a flash recovery area, auto deletion is based on the flash recovery
areas space pressure.
Managing Remote Archived Log File Retention
By default, SQL Apply deletes an archived redo log file after applying the contents. This
behavior is controlled by the LOG_AUTO_DELETE parameter. During a flashback operation or
point-in-time recovery of the logical standby database, SQL Apply must stop and re-fetch all
remote archived redo log files.
In Oracle Database 11g, 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.
Managing SQL Apply Filtering
You can use SQL Apply filters to control what to apply and what not to apply. To define a SQL
Apply filter, use the following configurable database properties:
LsbyASkipCfgPr: Provides a way to indicate to SQL Apply that it should ignore (skip)
SQL statements that you do not want to apply to the logical standby database. Valid
values for this property are a valid set of arguments to the DBMS_LOGSTDBY.SKIP
procedure.
LsbyASkipErrorCfgPr: Provides criteria to determine if an error should cause SQL
Apply to stop. All errors to be skipped are stored in system tables that describe how
exceptions should be handled. Valid values for this property are a valid set of arguments
to the DBMS_LOGSTDBY.SKIP_ERROR procedure. The string must contain comma
separators between the arguments.
LsbyASkipTxnCfgPr: Enables you to specify the transaction ID (XIDSQN NUMBER) of
a problematic transaction that you want SQL Apply to ignore. Valid values for this
property are a valid set of arguments to the DBMS_LOGSTDBY.SKIP_TRANSACTION
procedure.
See the Oracle Database PL/SQL Packages and Types Reference for detailed information
about the DBMS_LOGSTDBY package and its procedures.
Managing SQL Apply Filtering (continued)
Use the following configurable database properties to delete a previously defined SQL Apply
filter:
LsbyDSkipCfgPr: Deletes an existing SQL Apply skip specification. Valid values are a
valid set of arguments to the DBMS_LOGSTDBY.UNSKIP procedure
LsbyDSkipErrorCfgPr: Deletes an existing SQL Apply skip error specification. Valid
values are a valid set of arguments to the DBMS_LOGSTDBY.UNSKIP_ERROR
procedure.
LsbyDSkipTxnCfgPr: Reverses or removes the actions of the LsbyASkipTxnCfgPr
property. Valid values are a valid set of arguments to the
DBMS_LOGSTDBY.UNSKIP_TRANSACTION procedure.
about the DBMS_LOGSTDBY package and its procedures.
Viewing SQL Apply Filtering Settings
You can query the DBA_LOGSTDBY_SKIP view on the logical standby database to determine
the SQL Apply filtering settings. The view contains the following columns:
ERROR: Indicates whether the statement should be skipped or should return an error for
the statement
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.
Managing SQL Apply Filtering by Using Enterprise Manager
You can use Enterprise Manager to implement SQL Apply filtering by navigating to the Edit
Standby Database Properties page. On the Standby Role Properties tabbed page, expand
Advanced Properties to access the Skip Table Entries section.
Use the Add Skip Table Entry page to specify the following skip criteria:
Identify SQL statements that are not applied to the standby database by specifying the
schema and database object to be skipped.
Specify criteria to be used to determine if an error should cause log apply services to
stop. All errors to be skipped are stored in system tables that describe how exceptions
should be handled.
Specify additional processing that should be done (such as execution of a stored
procedure).
Using DBMS_SCHEDULER to Create Jobs on a Logical Standby Database
Use the DBMS_SCHEDULER package to create Scheduler jobs so that they are executed when
intended. Scheduler jobs can be created on a standby database.
When a Scheduler job is created, it defaults to the local role. If the job is created on the
standby database, it defaults to the role of a logical standby. The Scheduler executes jobs
that 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. If you want a job to run for all database roles on a particular host, you must create
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.
about using the DBMS_SCHEDULER package.
Answer: b
Answer: a
Snapshot Standby Databases: Overview
A snapshot standby database is a fully updatable standby database that is created by
converting a physical standby database to a snapshot standby database. A snapshot standby
database receives and archivesbut does not applyredo data from a primary database.
Redo data received from the primary database is applied when a snapshot standby database
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 restore point is created and Flashback Database is enabled. After performing
operations on the snapshot standby database, you can convert it back to a physical standby
database.
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
After a physical standby database is converted to a snapshot standby database, Redo Apply
no longer applies the redo data. The redo data continues to be received using the defined
transport method (SYNC or ASYNC), but it is not applied until the snapshot standby database is
converted back to a physical standby database.
Converting a Physical Standby Database to a Snapshot Standby Database
Use the CONVERT DATABASE DGMGRL command to convert a physical standby database to
a snapshot standby database, as in the following example:
DGMGRL> convert database pdb1 to snapshot standby;
Converting database "pdb1" to a Snapshot Standby database,
please wait...
Database "pdb1" converted successfully
Activating a Snapshot Standby Database: Issues and Cautions
Keep the following in mind when activating a snapshot standby database:
Potential data loss when there is a corrupted log file: The snapshot standby
database accepts redo log files but does not apply them. If there is a corrupted redo log
file at the snapshot standby database, it is not discovered until the database is
converted back to 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, 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
When you convert the physical standby database to a snapshot standby database, it cannot
be the only standby database in the configuration if your configuration is in maximum
protection mode. In addition, you cannot make changes to the configuration after converting
to a snapshot standby database that would create this situation.
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
The DATABASE_ROLE column of the V$DATABASE view indicates that the database is a
snapshot standby database.
Using DGMGRL to View Snapshot Standby Database Information
Use the SHOW CONFIGURATION and SHOW CONFIGURATION VERBOSE DGMGRL commands
to display information about the snapshot standby database.
Using DGMGRL to View Snapshot Standby Database Information (continued)
When you execute the SHOW DATABASE and SHOW DATABASE VERBOSE commands for a
snapshot standby database, SNAPSHOT STANDBY is displayed in the role field.
Converting a Snapshot Standby Database to a Physical Standby Database
Use the CONVERT DATABASE command to convert the database back to a physical standby
database.
Answer: b
Oracle Active Data Guard
Oracle Active Data Guard is a separately licensed database option for Oracle Database 11g
Enterprise Edition. It includes the Real-time Query feature, which enables a physical standby
database to be open read-only while Redo Apply is active. With this feature, users who are
connected to a physical standby database can query and report against data that is up-to-
date with the primary database.
Oracle Active Data Guard also enables you to configure RMAN block change tracking for a
physical standby database. With RMAN block change tracking, you can offload fast
incremental backups from the production database to the physical standby database.
Using Real-Time Query
With Oracle Active Data Guard, you can use a physical standby database for queries while
redo is applied to the physical standby database. This feature enables you to use a physical
standby database for disaster recovery and to offload work from the primary database during
normal operation.
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 when configured as follows:
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
With Oracle Database 11g Release 2 (11.2), it is no longer necessary to stop redo apply on a
physical standby database when opening the database to enable real-time query mode if and
only if the physical standby is managed by the Data Guard broker. The Data Guard broker
automatically stops redo apply when an open is attempted. After the instance is opened, the
Data Guard broker automatically restarts redo apply according to the settings recorded in the
broker configuration file.
DGMGRL> show database pc01sby1
Database - pc01sby1
Enterprise Manager Name: pc01sby1.us.oracle.com
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
Real Time Query: OFF
Instance(s):
pc01sby1
Disabling Real-Time Query
To disable Real-time Query, you must shut down the standby database instance and restart it
in MOUNT mode.
Checking the Standbys Open Mode
You can use the OPEN_MODE column of V$DATABASE to check the open mode of a physical
standby database. If the physical standby database stops redo apply in order to open the
database in read-only mode, then the OPEN_MODE column will indicate 'READ ONLY'.
After the database has been opened read-only, Redo Apply can be restarted to enable Active
Data Guard real-time query mode with the following command:
SQL> alter database recover managed standby database using
current logfile 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
Active Data Guard can improve performance by off-loading a read-only workload to a physical
standby database. However, due to hardware and network issues, the data on a standby
database may lag behind the data on the primary database. The standby database may not
always be current with the primary database if it does not have the capacity to apply redo as
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 11g Release 2 (11.2) 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 lag. Query results are returned to the application if the lag is within the acceptable
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 has been redefined in Oracle Database 11g Release 2 (11.2). Apply lag is a
measure of the degree to which a standby database lags behind the primary database, due to
delays in propagating and applying redo to the standby database.
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. If the difference is larger than this, the apply lag
metric may not be accurate. This metric is computed to the nearest second.
Monitoring Apply Lag: V$STANDBY_EVENT_HISTOGRAM
V$STANDBY_EVENT_HISTOGRAM is a new view that is available on the standby database.
This view displays the histogram of the apply lag on the physical standby database.
Use the histogram to focus on periods of time when the apply lag exceeds desired levels.
Determine the cause of the lag during those time periods and take steps to resolve the
excessive lag.
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.
Setting a Predetermined Service Level for Currency of Standby Queries
You can configure a limit through the use of the STANDBY_MAX_DATA_DELAY session
parameter. Use this session parameter to specify a limit for the amount of time (in seconds)
allowed to elapse between when changes are committed on the primary database and when
those same changes can be queried on the active standby database.
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
You can ensure that your application querying data on the standby database sees all data
that has been committed on the primary database by setting STANDBY_MAX_DATA_DELAY to
0.
A query does not execute until the query SCN on the standby database has advanced to a
value equal to 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.
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
You can create an AFTER LOGON trigger that sets the STANDBY_MAX_DATA_DELAY session
parameter when the database is a physical standby database that is operating in real-time
query mode.
In Oracle Database 11g Release 2 (11.2), the DATABASE_ROLE attribute of the USERENV
context 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
The slide presents an example of an AFTER LOGON trigger that is used to set the value of
STANDBY_MAX_DATA_DELAY based on the database role.
Forcing Redo Apply Synchronization
You can execute the ALTER SESSION SYNC WITH PRIMARY command to ensure that the
standby database is completely synchronized with the primary database at the time of
execution. The use of this command is particularly applicable in a reporting environment.
ALTER SESSION SYNC WITH PRIMARY performs a blocking wait on the standby database
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
This type of trigger is useful when you are using the standby database for reporting and want
to be sure that the reports have the most current data. The standby-only AFTER LOGON trigger
executes the ALTER SESSION SYNC WITH PRIMARY command to force a wait for
synchronization between the primary database and the standby database. A standby-only
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.
Supporting Read-Mostly Applications
Reporting applications that are predominantly read-only, but require limited read-write
database access are referred to as read-mostly applications. Active Data Guard enables a
standby database to support the read-only portion of read-mostly applications if writes are
redirected to the primary database or a local database.
Example: Transparently Redirecting Writes to the Primary Database
Consider an application as described in the slide. The application executes as user U, reading
the U.R table and writing to the U.W table. The application connects as user U when
executing on the primary database.
User S accesses U.R with the S.R synonym and U.W with the S.W synonym.
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
With the Oracle Active Data Guard option, you can enable block change tracking on a
physical standby database. When you back up the physical standby database, RMAN uses
the block change tracking file to quickly identify the blocks that have changed since the last
incremental backup. RMAN reads only the changed blocks rather than the entire data file.
Creating Fast Incremental Backups
The goal of an incremental backup is to back up only those data blocks that have changed
since a previous backup. You can use RMAN to create incremental backups of data files,
tablespaces, or the entire database. During media recovery, RMAN examines the restored
files to determine whether it can recover them from an incremental backup. RMAN always
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 file. 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
You enable block change tracking from the database home page. Click the Policy tab on the
Backup Settings page. You do not need to set the change tracking file destination if the
DB_CREATE_FILE_DEST initialization parameter is set, because the file is created as an
Oracle Managed File (OMF) file in the DB_CREATE_FILE_DEST location. You can, however,
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. 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
The output of the V$BLOCK_CHANGE_TRACKING view shows where the change tracking file
is located, the status of block change tracking (ENABLED/DISABLED), and the size (in bytes)
of the file.
Querying the V$BACKUP_DATAFILE view shows the effectiveness of block change tracking in
minimizing 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
Answer: b
Data Protection Modes and Redo Transport Modes
When you define a redo transport mode, you are configuring the shipment of log files from the
primary database to the standby database (physical or logical). You must set your redo
transport mode to support the protection mode that you want for your configuration. However,
configuring the redo transport mode alone does not set up the protection mode.
After setting up the redo transport mode, you can put the configuration into a data protection
mode. The data protection mode setting causes internal rules to be implemented, ensuring
that your configuration is protected at the necessary level.
Data Protection Modes
Oracle Data Guard offers maximum protection, maximum availability, and maximum
performance modes to help enterprises balance data availability against system performance
requirements.
In some situations, a business cannot afford to lose data. In other situations, the availability of
the database may be more important than the loss of data. Some applications require
maximum database performance and can tolerate the potential loss of data.
Maximum Protection Mode
This protection mode ensures that no data loss occurs if the primary database fails. To
provide 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 on at least one standby
database before the transaction commits. To ensure that data loss cannot occur, the primary
database shuts down if a fault prevents it from writing its redo stream to at least one remote
standby redo log. For multiple-instance RAC databases, Data Guard shuts down the primary
database if it is unable to write the redo records to at least one properly configured database
instance.
Maximum protection mode requirements:
Configure standby redo log files on at least one standby database.
Set the SYNC and AFFIRM attributes of the LOG_ARCHIVE_DEST_n parameter for at
least one standby database destination.
Note: Oracle recommends a minimum of two standby databases for maximum protection
mode.
Maximum Availability Mode
This protection mode provides the highest possible level of data protection without
compromising the availability of the primary database. A transaction does not commit until the
redo that is needed to recover that transaction is written to the local online redo log and to at
least one remote standby redo log. 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 gaps in redo
log files are resolved. When all gaps are resolved and the standby database is synchronized,
the primary database automatically resumes operating in maximum availability mode.
This mode guarantees that no data loss occurs if the primary database failsbut 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 availability mode requirements:
Configure standby redo log files on at least one standby database.
Set the SYNC and AFFIRM attributes of the LOG_ARCHIVE_DEST_n parameter for at
least one standby database.
Maximum Performance Mode
Maximum performance is the default protection mode and provides the highest possible level
of data protection without affecting the performance of the primary database. This is
accomplished by allowing a transaction to commit as soon as the redo data needed to recover
that transaction is written to the local online redo log. The primary databases redo data is
also written to at least one standby database, but that redo data is written asynchronously
with respect to the commitment of the transactions that create the redo data.
When network links with sufficient bandwidth are used, this mode provides a level of data
protection that approaches that of maximum availability mode with minimal impact on primary
database performance.
Maximum performance mode requirement: Set the ASYNC and NOAFFIRM redo transport
attributes of the LOG_ARCHIVE_DEST_n parameter on at least one standby database.
Comparing Data Protection Modes
Consider the characteristics of each protection mode. You must balance cost, availability,
performance, and transaction protection when choosing the protection mode.
Note: If you plan to enable fast-start failover, you must set the protection mode to maximum
availability or maximum performance. See the lesson titled Enabling Fast-Start Failover for
additional information.
Setting the Data Protection Mode by Using DGMGRL
1. You must configure standby redo log files for the primary database or another standby
database in the configuration to ensure that it can support the chosen protection mode
after a switchover.
2. Use the EDIT DATABASE SET PROPERTY command to set the redo transport mode for
the standby database. For example, if you are changing the data protection mode to
maximum availability, use the EDIT DATABASE command to specify SYNC for redo
transport services:
DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY
'LogXptMode'='SYNC';
You must also set the redo transport services for the primary database or another
standby database in the configuration to ensure that it can support the chosen protection
mode after a switchover.
3. Use the EDIT CONFIGURATION SET PROTECTION MODE AS command to set the overall
configuration protection mode. To set the protection mode to maximum availability, use
the following command:
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS
MAXAVAILABILITY;
Setting the Data Protection Mode
If the data protection mode that you need requires a standby database to use the SYNC or
ASYNC redo transport mode, Enterprise Manager automatically sets the redo transport mode
for the primary database and the selected standby databases.
Enterprise Manager automatically determines the correct number and size of standby redo log
files that are needed for all databases in the configuration and adds those log files using the
directory locations that you specify.
To set the data protection mode with Enterprise Manager:
1. Navigate to the Data Guard page.
2. Click the link in the Protection Mode field to access the Change Protection Mode: Select
Mode page.
Setting the Data Protection Mode (continued)
3. Select Maximum Protection, Maximum Availability, or Maximum Performance, and click
Continue.
4. If prompted, enter the username and password of a user with SYSDBA privileges. Click
Login.
5. Select one or more standby databases to support the protection mode that you selected.
(If standby redo log files are needed, verify the names of the log files.) Click OK.
6. On the Confirmation page, click Yes.
Answer: a, b, d
Role Management Services
You can use role management services to change the primary and standby roles dynamically
as a planned transition called a switchover operation, or as a result of a database failure
through a failover operation.
For example, you might perform a switchover operation to transition the primary database to
the standby role and transition a standby database to the primary role to perform routine
maintenance tasks.
Role Transitions: Switchover and Failover
Switchover
You can use the switchover feature to switch the role of the primary database to one of the
available standby databases. The chosen standby database becomes the primary database,
and the original primary database then becomes a standby database. There is no need to
re-create any of the databases involved in the switchover operation. There is no data
divergence between the original and new primary databases after successful completion of
the switchover.
Failover
You invoke a failover operation when a failure occurs on the primary database and there is no
possibility of recovering the primary database in a timely manner. During a failover operation,
the 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.
Note: You can enable fast-start failover to fail over automatically when the primary database
becomes unavailable. When fast-start failover is enabled, the broker determines if a failover is
necessary and initiates the failover to the specified target standby database automatically,
with no need for DBA intervention and with no loss of data. For details, see the lesson titled
Enabling Fast-Start Failover.
Switchover
A switchover operation transitions the primary database to the standby role and transitions the
standby database to the primary role, without resetting the online redo logs of the new primary
database.
The primary database at the start of a switchover operation will need to be shutdown and
restarted. The physical standby database is not shutdown and restarted during a switchover.
If the physical standby database is in the Active Data Guard mode, it is closed for the
transition then opened again after the switchover completes, but it is never totally shutdown to
require a restart.
If the switchover operation involves a logical standby database, there is no need to shut down
and restart either the primary database or any of the standby databases. Logical standby
databases do not need to be shut down and restarted.
Note: When necessary, the broker automatically starts and stops all but one instance in a
Real Application Clusters (RAC) environment for the primary database. If the broker is not
used, this must be done manually. Starting with Oracle Database 11g Release 2 (11.2), the
secondary RAC instances of a physical standby database no longer need to be shutdown
during the switchover. They can stay in the mounted or Active Data Guard state. The primary
still requires only one instance be running during a switchover.
Switchover: Before
As an example, suppose that the primary database is located in San Francisco and the
physical standby database is located in Boston. Switchovers are started only on the primary
database and completed on the target standby database. You can be connected to any
database in the configuration through DGMGRL to execute the SWITCHOVER command.
Switchover: After
After the switchover is completed, each database has the role opposite to the one that it had
before the switchover. In this example, Boston is now the primary database and San
Francisco is the standby database.
Because Data Guard does not automatically switch over sessions from one database to the
other, active sessions for each system need to reconnect. See the lesson titled Managing
Client Connectivity for information about configuring automatic methods to reconnect
sessions.
Preparing for a Switchover
Before you execute the SWITCHOVER command, verify the following:
Each location in the Data Guard configuration has connectivity through Oracle Net to the
primary database and to all associated standby databases.
The state of the primary is set to TRANSPORT-ON and the state of the standby
databases is APPLY-ON.
There are no errors or warning for any of the participating databases.
The standby LogXptMode, DbFileNameConvert, LogFileNameConvert,
StandbyArchiveLocation, and LogArchiveFormat database properties are set
on the primary database, so that the primary database can function correctly when
transitioned to a standby database.
The LogXptMode configurable database property is set to SYNC on the current primary
database if the configuration is set to in either maximum availability mode or maximum
protection mode.
Standby redo log files are configured on the primary database. Standby redo log
configuration should be identical on the primary database and on any physical standby
databases. Even though the standby redo logs are not used when the database is in the
primary role, configuring the standby redo logs on the primary database is
recommended in preparation for an eventual switchover operation.
Performing a Switchover by Using DGMGRL
After verifying the conditions required for executing a switchover, execute the SWITCHOVER
command to perform the switchover operation. The Data Guard broker performs the following
operations:
1. Verifies that the primary database and target standby database are in the correct states
2. Shuts down any instances as necessary
3. Switches roles between the primary and standby databases
4. Updates the broker configuration file with the new role information
5. Restarts the new standby database
6. Opens the new primary database in read/write mode and starts redo transport services
Note: For detailed information about each step, see Oracle Data Guard Broker.
Performing a Switchover by Using Enterprise Manager
When it is used for the switchover, Enterprise Manager:
a. Checks to ensure that the primary database and standby database are not currently in
an error status condition and that broker management of the primary database is
enabled and online
b. Automatically closes any active sessions connected to the primary database during the
switchover
c. First changes the primary database to the standby role, and then changes the standby
database to the primary role
d. Opens the target database if it is a mounted physical standby database and restarts the
former primary database
To initiate a switchover by using Enterprise Manager:
1. On the Data Guard page, select the standby database that you want to become the
primary database.
2. Click Switchover.
The Data Guard Switchover Confirmation page is displayed.
Performing a Switchover by Using Enterprise Manager (continued)
3. Click the Browse Primary Database Sessions link to view active sessions.
4. Click Yes to continue with the switchover, or click No to cancel.
You cannot cancel the switchover operation after it begins.
Performing a Switchover by Using Enterprise Manager (continued)
The Data Guard Switchover Processing page displays the progress of the switchover
operation as it:
Switches roles between the primary and standby databases (If the switchover target is a
physical standby database and mounted, it is opened without restarting. The former
primary database is restarted.)
Waits for the Data Guard broker to complete the initialization tasks required to switch the
database roles.
You can view the database alert log of the primary and standby databases by clicking the
respective View alert log links. A new browser window opens with the content of the alert
log.
After the switchover operation is complete, you are returned to the Data Guard page.
Considerations When Performing a Switchover to a Logical Standby Database
Unlike a switchover to a physical standby database, a switchover to a logical standby
database does not require a shutdown of the primary database.
If you are switching over to a logical standby database, you do not need to terminate
applications that are connected to the current primary database or to the logical standby
database, because neither database is shut down during the switchover operation.
However, because sessions on the old primary database may fail after the switchover
operation is completed and the database guard is turned on, you should terminate such
open sessions now. The database guard prevents users from making changes in the
logical standby database.
If you switch over to a logical standby database, be aware that you may not have all of
the data that was in your primary database if the logical standby database is only a
subset of the primary database.
A switchover to a logical standby database invalidates and disables all physical and
snapshot standby databases in the configuration. You must re-create the physical
standby databases from a backup of the new primary database before you can reenable
them.
Situations That Prevent a Switchover
You cannot perform a switchover if:
Archived redo log files are unavailable: If there is a gap in the archived redo log files
on the standby database, you cannot switch over to that standby database.
Point-in-time recovery is required: When you perform a switchover to a standby
database, you always switch over to the current state of the primary database. You
cannot switch over to a time in the past.
The production database is not open and cannot be opened: A switchover is
initiated on the primary database while it is in the open state. If you cannot open the
primary database, a switchover is not possible.
Failover
You invoke a failover operation when a failure occurs on the primary database and there is no
possibility of recovering the primary database in a timely manner. During a failover operation,
the primary database is disabled from the Data Guard environment and a standby database
assumes the primary database role. Failing over to a standby database is a one-way
operation. You cannot "fallback" and return the database to its former role as a standby
database. Because of this, you should invoke a failover operation only in an emergency.
It is not always necessary to fail over to the standby database. In some cases, recovery of the
primary database may be faster. Most failures can be resolved at a primary database in a
reasonable amount of time.
In a failover operation:
The original primary database is presumed to be lost. (If you want, you can reinstate or
re-create the original primary database as a new standby database. You may then
initiate a switchover operation compared to a failover operation to return the databases
to their original roles.)
Standby databases that are online at the time of the failover operation, but are not
involved in the role transition, do not need to be shut down and restarted unless they
were ahead of the failover target due to differences in apply lag situations. In that case,
they may need to be flashed back to the point the standby became a primary or re-
created.
Types of Failovers
A manual failover is invoked through DGMGRL or Enterprise Manager. There are two types of
manual failover:
Complete: The maximum amount of redo data for the protection mode is recovered. In
this type of failover, the broker avoids disabling any standby databases that are not the
failover target. Complete failover is the default and recommended type of failover.
Immediate: No additional redo data is applied to the standby database after the failover
is invoked. This is the fastest type of failover. After an immediate failover, you must re-
create or reinstate the original primary database and all standby databases that were
not a target of the failover.
Note: You should always try to perform a complete failover. Perform an immediate failover
only when a complete failover is unsuccessful. Depending on the destination attributes of
redo transport services, a complete failover can take place without incurring any data loss,
while an immediate failover usually results in the loss of data.
You can configure fast-start failover so that the broker automatically fails over to a chosen
standby database in the event of the loss of the primary database. For details, see the lesson
titled Enabling Fast-Start Failover.
Failover Considerations
During a failover operation, a standby database transitions to the primary role and the old
primary database is rendered unable to participate in the configuration. Depending on the
protection mode under which the old primary database was operating before the failover,
there may be some or no data loss during a failover.
A failover is typically used only when a primary database becomes incapacitated and there is
no possibility of performing a switchover or successfully repairing the primary database in a
reasonable amount of time.
The specific actions that are performed during a failover vary, depending on:
Whether a logical or physical standby database is involved in the failover operation
The state of the configuration at the time of the failover
The specific SQL commands that are used to initiate the failover
Performing a Failover by Using DGMGRL
After determining that the primary database cannot be recovered in a timely manner, execute
the FAILOVER command to perform the failover operation.
If you specify the IMMEDIATE option, no attempt is made to apply any unapplied redo that
has been received.
The Data Guard broker performs the following operations for a complete failover:
a. Verifies that the target standby database is enabled
b. Stops Redo Apply after all unapplied redo data is applied to the target standby database
c. Transitions the target standby database to the primary database role by:
- Opening the new primary database in read/write mode
- Determining if any standby databases need to be reinstated or recreated
- Starting redo transport services
For an immediate failover, the broker does not wait for all available redo data to be applied
(as described in step b). For details about each step, see Oracle Data Guard Broker.
Reenabling Disabled Databases by Using DGMGRL
After a failover, you may need to reinstate or re-create databases in your configuration.
If a database can be reinstated, the database has the following status after a complete
failover:
ORA-16661: the standby database needs to be reinstated
Note: To reinstate a database, Flashback Database must have been enabled on the
database prior to the failover and flashback logs must be available.
To reinstate the database:
1. Start the database instance and mount the database.
2. Invoke DGMGRL and connect to the new primary database.
3. Use the REINSTATE DATABASE DGMGRL command to reinstate the database.
If a database must be re-created, it has the following status after the failover:
ORA-16795: the standby database needs to be re-created
You must re-create the standby database from a copy of the primary database and then
reenable it by using the ENABLE DATABASE DGMGRL command.
Performing a Failover by Using Enterprise Manager
Perform a failover only in the event of a software or system failure that results in the loss of
the primary database. The failed primary database is disabled by the broker and must be re-
created. The standby database then assumes the primary database role.
To initiate a failover by using Enterprise Manager:
1. On the Data Guard page, select the standby database that you want to become the
primary database.
2. Click Failover.
Performing a Failover with Enterprise Manager (continued)
3. On the Data Guard Failover Confirmation page, specify the type of failover that you want
to perform:
- Complete: All available redo is applied on the standby database. Oracle
Corporation recommends that you specify this type of failover.
- Immediate: No additional data is applied on the standby database, resulting in a
data-loss failover. An immediate failover should be used only when a complete
failover is not possible.
4. Select the failover option, and click Yes to confirm the failover operation.
.
Performing a Failover with Enterprise Manager (continued)
After you click Yes, the Failover Processing page displays the progress of the failover
operation.
You cannot cancel this operation after it begins.
Performing a Failover to a Physical Standby Database
During the failover operation, the selected standby database transitions into the primary role.
The failover target (a physical standby database) is restarted. When the operation finishes,
the Data Guard Overview page reflects the updated configuration.
After a complete or immediate failover, the primary database and some standby databases
may need to be reinstated or re-created. To reinstate the database, click the Database must
be reinstated link. Then click Reinstate on the General Properties page. Enterprise Manager
reinstates the database as a standby database to the new primary database.
Note: Flashback Database must have been enabled on the database prior to the failover, and
the required flashback logs must be available on that database for reinstatement to succeed.
In addition, the database to be reinstated and the new primary database must have network
connectivity.
Performing a Failover to a Logical Standby Database
When you perform a failover to a logical standby database, any physical standby databases in
the configuration are permanently disabled after the failover and are no longer usable. These
databases must be re-created from the new primary database.
Answer: a
Answer: b
Using Flashback Database in a Data Guard Configuration
Flashback Database provides the following advantages in a Data Guard configuration:
Provides an alternative to delaying the application of redo to protect against user errors
or logical corruptions. By using Flashback Database in this context, standby databases
are more closely synchronized with the primary database, thereby reducing failover and
switchover times.
Eliminates the need to completely re-create the original primary database after a
failover. The failed primary database can be flashed back to a point in time before the
failover and converted to be a standby database for the new primary database.
Flashback Database is used in a Data Guard configuration for the following features:
Fast-start failover: You must enable Flashback Database and set up a fast recovery
area on the primary database and the target standby database before enabling fast-start
failover. (See the lesson entitled Enabling Fast-Start Failover for additional
information.)
Snapshot standby: To convert a physical standby database to a snapshot standby
database, you must configure the Fast Recovery Area and size. If Flashback Database
is not enabled, it will be enabled when the primary database is converted to a snapshot
standby database. (See the lesson titled Creating and Managing a Snapshot Standby
Database for additional information.)
Overview of Flashback Database
With Flashback Database, you can quickly bring your database to an earlier point in time by
undoing all changes that took place since that time. This operation is fast because you do not
need to restore backups. You can use this feature to undo changes that resulted in logical
data corruptions.
When you use Flashback Database, Oracle Database uses past block images to back out
changes to the database. During normal database operation, Oracle Database occasionally
logs these block images in flashback logs, which are written sequentially and are not
archived. Oracle Database automatically creates, deletes, and resizes flashback logs in the
fast recovery area. You need to be aware of flashback logs only for monitoring performance
and deciding how much disk space to allocate to the fast recovery area for flashback logs.
The time it takes to rewind a database with Flashback Database is proportional to how far
back in time you need to go and the amount of database activity after the target time. The
time it would take to restore and recover the whole database could be much longer. The
before images in the flashback logs are used only to restore the database to a point in the
past, and forward recovery is used to bring the database to a consistent state at some time in
the past. Oracle Database returns data files to the previous point in timebut not auxiliary
files such as initialization parameter files.
Flashback Database can also be used to complement Data Guard and Recovery Advisor and
to synchronize clone databases.
Configuring Flashback Database
As of Oracle Database 11g Release 2 (11.2), the database can be open when you enable
flashback. In prior versions, the database had to be mounted after a clean shutdown prior to
enabling flashback.
1. Configure the fast recovery area.
2. Set the retention target with the DB_FLASHBACK_RETENTION_TARGET initialization
parameter.
You can specify an upper limit, in minutes, on how far back you want to be able to flash
back the database. The example uses 2,880 minutes, which is equivalent to two days.
This parameter is only a target and does not provide any guarantee. Your flashback time
interval depends on how much flashback data was kept in the fast recovery area.
3. Enable Flashback Database with the following command:
ALTER DATABASE FLASHBACK ON;
Before you can issue the command to enable Flashback Database, the database must
be configured for archiving.
Determine whether Flashback Database is enabled with the following query:
SELECT flashback_on FROM v$database;
Disable Flashback Database with the ALTER DATABASE FLASHBACK OFF command. As a
result, all existing Flashback Database logs are deleted automatically.
Configuring Flashback Database by Using Enterprise Manager
1. On the Availability page, select Recovery Settings in the Backup/Recovery region.
2. Ensure that your database is in ARCHIVELOG mode. If not, select ARCHIVELOG Mode.
Configuring Flashback Database by Using Enterprise Manager (continued)
3. Review the flash recovery area location.
The flash recovery area is a unified storage location for all recovery-related files and
activities in an Oracle database. All files that are needed to completely recover a
database from a media failure are part of the flash recovery area. The recovery-related
files that can be created in the flash recovery area include archived redo log files, control
files, backups created by Recovery Manager (RMAN), flashback logs, and the change
tracking file. By allocating a storage location and unifying recovery-related files in a
specific area, the Oracle database server relieves the database administrator from
having to manage the disk files created by these components. If you want it in a different
location, specify the location in the Flash Recovery Area Location field.
4. Set the flash recovery size in the Flash Recovery Area Size field.
5. Select Enable Flashback Database. You can also set the flashback retention time, and
you can view important information regarding your flashback database window.
6. Scroll down to the bottom of the Recovery Settings page, and click Apply.
Note: Flash recovery area has been renamed fast recovery area in Oracle 11g Release 2
(11.2). Enterprise Manager is still at version 10.2.0.5.2 as of the writing of this course and
uses the old name.
Using Flashback Database Instead of Apply Delay
As an alternative to the Apply Delay configuration option, you can use Flashback Database to
protect against the application of corrupted or erroneous data to the standby database.
Flashback Database can quickly and easily flash back a standby database to an arbitrary time
in the past. You can configure one standby database with Flashback Database to achieve the
same benefit as multiple standby databases with different delays.
Note: Apply delay will be discussed in the lesson titled "Optimizing a Data Guard
Configuration".
Using Flashback Database and Real-Time Apply
The Oracle Data Guard real-time apply feature reduces failover time. Flashback Database
protects a physical standby database from logical data corruption and user error.
The Data Guard broker automatically enables real-time apply.
Using Flashback Database After RESETLOGS
Physical Standby Configuration
For a physical standby database, it is possible that the Redo Apply service might not halt
when it encounters the OPEN RESETLOGS command in the redo information. If the physical
standby databases SCN (system change number) is far enough behind the primary
databases SCN, then the Redo Apply service can interpret the OPEN RESETLOGS command
without stopping.
Note: Recall that the recovery through RESETLOGS feature was implemented in Oracle
Database 10g.
Use the following procedure to avoid re-creating a standby database after you issue an OPEN
RESETLOGS command on the primary database and the managed recovery process is halted
on the physical standby database:
1. On the primary database, determine an SCN that is at least two SCNs prior to the SCN
when the OPEN RESETLOGS command was issued. This is necessary to enable the
standby to recover properly through OPEN RESETLOGS. Use the following query to find
the before RESETLOGS SCN:
SELECT TO_CHAR(resetlogs_change# - 2) FROM v$database;
1 2
Flashback Through Standby Database Role Transitions
Use Flashback Database to revert a database to a point in time before a physical standby
database switchover or failover. The database role does not change when flashing back
through a physical standby switchover, failover, or activation.
In a logical standby database, the FLASHBACK DATABASE command reverts the database to
a system change number (SCN) or time stamp before a switchover or failover. For a logical
standby database, the database reverts to its original role at the time of the flashback SCN or
flashback time.
You can also use Flashback Database to undo a physical standby activation.
Note: For detailed information about switchover and failover, see the lesson titled Performing
Role Transitions.
Using Flashback Database After Failover
You invoke a failover operation when a catastrophic failure occurs on the primary database
and there is no possibility of recovering the primary database in a timely manner. After a
failover operation, the old standby database becomes the new primary database, and the old
primary database is placed in the needs reinstatement state.
Note: Detail on reinstating the database is provided in the lesson titled Performing Role
Transitions.
Use the Flashback Database feature to convert the old primary database into a new standby
database without re-creating the database. You can flash back the old primary database so
that it contains only those changes that are already applied to the old standby database. This
enables you to convert the old primary database into a new standby database without
restoring the old primary database.
The STANDBY_BECAME_PRIMARY_SCN column in V$DATABASE can provide the SCN
number corresponding to the failover. The old primary database should use the "FLASHBACK
DATABASE TO SCN .." command to rewind to this point. It can then be converted into a
standby database with the SQL command "ALTER DATABASE CONVERT TO PHYSICAL
STANDBY".
Note: You must enable the Flashback Database feature on the old primary database prior to
the failover.
1
2
Answer: b
Fast-Start Failover: Overview
Fast-start failover enables Data Guard to rapidly and automatically fail over to a previously
chosen standby database without requiring manual intervention. This feature increases the
availability of your database in the event of a disaster by reducing the need for you to perform
a failover operation manually.
The observer is an Oracle Call Interface (OCI) client-side component that typically runs on a
separate computer and monitors the availability of the primary database.
When Does Fast-Start Failover Occur?
Fast-start failover occurs when any of the following conditions are met:
Loss of connectivity between both the primary database and the observerand
between the primary database and the fast-start failover target standby database
exceeds the fast-start failover threshold.
The database health-check mechanism determines any of the following (as optionally
configured):
- A data file is offline because of a write error.
- Dictionary corruption of a critical database object occurs.
- Control file is permanently damaged because of a disk failure.
- LGWR is unable to write to any member of the log group because of an I/O error.
- Archiver is unable to archive a redo log because the device is full or unavailable.
An instance crash occurs for a single-instance database.
All instances of a Real Application Clusters (RAC) primary database crash.
Shutdown abort of the primary database occurs.
An application initiates a fast-start failover by calling the
DBMS_DG.INITIATE_FS_FAILOVER function.
Installing the Observer Software
To use fast-start failover, you should install the DGMGRL program (which contains the
observer software) on a computer system that is separate from the primary database and
standby database systems.
To install DGMGRL on the observer computer, use one of the following methods:
Install the complete Oracle Client Administrator by choosing the Administrator option in
the Oracle Universal Installer. This installation includes DGMGRL but it does not include
the Oracle Enterprise Manager agent. This type of installation enables you to manage
the observer by using DGMGRL commands but not Oracle Enterprise Manager.
Install the full Oracle Database software kit. This installation includes DGMGRL.
Note: To manage the observer from Oracle Enterprise Manager (EM) Grid Control, the EM
Grid Control agent will need to be installed on the observer machine in addition to DGMGRL.
The observer host should be located on the client network or the location that contains the
most client activity or highest priority activity. This method could introduce a false failover,
that is a fast-start failover occurs even though the primary is running and accessible locally,
but if the clients can't get to the primary it may as well be down.
Fast-Start Failover Prerequisites
The broker configuration must be operating in maximum availability or maximum
performance mode.
The primary database must be configured with standby redo log files.
The standby database that is the target of fast-start failover must have its LogXptMode
property set to SYNC to enable fast-start failover in maximum availability mode or to
ASYNC to enable fast-start failover in maximum performance mode.
Flashback Database must be enabled on the primary database and target standby
database.
The primary database and target standby database must have connectivity.
Configure the tnsnames.ora file on the observer system so that the observer is able to
connect to the primary database and the preselected target standby database.
Create a static service name so that the observer can automatically restart a database
as part of reinstatement.
Configuring Fast-Start Failover
The manual steps to configure fast-start failover are described in detail on the next few pages.
Configuring fast-start failover by using Enterprise Manager Grid Control is described later in
the lesson.
Step 1: Specify the Target Standby Database
In a Data Guard configuration with multiple standby databases, you must set the
FastStartFailoverTarget database property on the primary database and your chosen
target standby database before enabling fast-start failover.
On the primary database, set the FastStartFailoverTarget property to the fast-start
failover target standby database. Execute the command when connected to the primary
database or to any standby database in the configuration that has connectivity to the primary
database. The command syntax is:
EDIT DATABASE database-name
SET PROPERTY FastStartFailoverTarget = FSFO-database-name;
You need not set the FastStartFailoverTarget property in a configuration with only one
standby database: The Data Guard broker automatically sets it appropriately for the primary
database and the standby database when fast-start failover is enabled.
Step 2: Set the Protection Mode
You can enable fast-start failover when the configuration is in maximum availability mode or
maximum performance mode. For details about each mode, see the lesson titled Configuring
Data Protection Modes.
In maximum performance mode, set the FastStartFailoverLagLimit configuration
property to an acceptable limit (in seconds) by which the standby database is permitted to fall
behind the primary database in terms of redo applied. If the standby database is further
behind than this value, fast-start failover is not allowed.
Step 3: Set the Fast-Start Failover Threshold
The fast-start failover threshold specifies how long the observer and target standby database
should simultaneously wait to hear from the primary database before initiating a fast-start
failover. The threshold value is specified as a positive, nonzero number of seconds. The
default value for the FastStartFailoverThreshold property is 30 seconds. When
choosing a value for this property, you must balance the increased risk of an unnecessary
failover (for example, if the network connection was temporarily broken for a few seconds)
against the benefits of faster failover and less down time during a critical outage.
Recommended settings for the FastStartFailoverThreshold property:
Single-instance primary, low-latency reliable network = 1015 seconds
Single-instance primary, high-latency network over WAN = 3045 seconds
RAC primary = (CSS misscount + reconfiguration time) + (2440 seconds)
Execute the EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold =
threshold-val command when connected to the primary database or to any standby
database in the Data Guard broker configuration with connectivity to the primary database.
Note: You can modify this property whether fast-start failover is enabled or disabled.
Step 4: Set Additional Fast-Start Failover Properties
You can set additional properties to control fast-start failover operation.
The FastStartFailoverPmyShutdown property enables users to decide whether the
primary database shuts down if redo generation has stalled and the primary database has lost
connectivity with the observer and target standby database for longer than the value specified
in FastStartFailoverThreshold. Redo generation stalls because the primary database
has lost connectivity to both the observer and the target standby database concurrently. This
property cannot be used to prevent the primary database from shutting down if a fast-start
failover occurred because a user-configurable condition was detected or was requested by an
application calling the DBMS_DG.INITIATE_FS_FAILOVER function.
The FastStartFailoverAutoReinstate property enables users to decide whether the
old primary database should be automatically reinstated if a fast-start failover was initiated
because it lost connectivity with the observer and target standby database for longer than the
value specified in FastStartFailoverThreshold. This property cannot be used to cause
automatic reinstatement if a fast-start failover occurred because a user-configurable condition
was detected or was requested by an application calling the
DBMS_DG.INITIATE_FS_FAILOVER function.
Note: Each of these three properties is discussed in more detail on the following pages.
Setting the Lag-Time Limit
You can configure fast-start failover for configurations operating in maximum performance
protection mode. Use the FastStartFailoverLagLimit property to specify an acceptable
lag-time limit in seconds. If the standby databases applied redo point is within the specified
number of seconds of the primary databases redo generation point, a fast-start failover is
allowed. If the standby databases applied point lags beyond this limit, a fast-start failover is
not allowed. The lag limit is ignored for SYNC destinations. This is applicable only to
configurations when fast-start failover is enabled in maximum performance modes.
Real-time apply must be enabled on the target standby database to ensure a valid calculation
of the lag time.
Configure the FastStartFailoverLagLimit property as follows:
EDIT CONFIGURATION
SET PROPERTY FastStartFailoverLagLimit = {n};
The minimum value for n is 10. The default value is 30.
You can perform a manual failover to a maximum performance fast-start failover target. The
maximum performance failover target must be within the specified lag limit of the primary
database for the failover to be allowed. If the failover target is more than the specified lag limit
behind the primary database, an error is returned.
Configuring the Primary Database to Shut Down Automatically
If you do not want the old primary database to shut down automatically after a fast-start
failover is triggered due to the primary redo generation being stalled and the primary database
loosing connectivity with the observer and target standby database for longer than the number
of seconds specified by the FastStartFailoverThreshold configuration property , set
the FastStartFailoverPmyShutdown property to FALSE. When the property is set to
FALSE, the old primary database stalls awaiting diagnosis of the condition that caused the
fast-start failover.
DGMGRL> edit configuration set property
> FastStartFailoverPmyShutdown = false;
Property "faststartfailoverpmyshutdown" updated
A value of TRUE causes the primary database to shut down with the ABORT option after the
elapse of the number of seconds specified in the FastStartFailoverThreshold property
and the primary database has no contact from its fast-start failover partners. TRUE is the
default.
Note: The primary database is always shut down if a user configurable fast-start failover
condition is detected or if an application initiated a fast-start failover by calling the
DBMS_DG.INITIATE_FS_FAILOVER function even if FastStartFailoverPmyShutdown
is set to FALSE.
Automatic Reinstatement After Fast-Start Failover
Reinstatement of the original primary database is critical for reestablishing high availability
after a fast-start failover. The original primary database can act as the fast-start failover target
standby database for the new primary database after being reinstated as a standby database.
Unless you reconfigure the fast-start failover environment, you cannot perform a subsequent
fast-start failover until the original primary database is reinstated.
Automatic reinstatement of the original primary database is triggered when all of the following
conditions are met:
FastStartFailoverAutoReinstate is set to TRUE.
The original primary database and the new primary database comprise the same fast-
start failover configuration before the failover occurs and after the original primary
database restarts.
In a multi-standby database configuration, you have not performed a subsequent
failover or switchover before the original primary database restarting.
The observer can connect to the original primary database.
The original primary database must be able to connect to the new primary database to
complete the reinstatement operation.
Configuring Automatic Reinstatement of the Primary Database
The FastStartFailoverAutoReinstate property enables you to determine whether the
observer should automatically reinstate the old primary database after a fast-start failover. In
some fast-start failover situations, you may want to diagnose the cause of the fast-start
failover before reinstating the primary database; you should set the property to FALSE. The
default value is TRUE.
DGMGRL> edit configuration set property
> FastStartFailoverAutoReinstate = false;
Property "faststartfailoverautoreinstate" updated
DGMGRL> show fast_start failover
Fast-Start Failover: ENABLED
Threshold: 90 seconds
Target: pc01sby1
Observer: EDBVR6P2
Lag Limit: 60 seconds
Shutdown Primary: TRUE
Auto-reinstate: FALSE
Setting a Connect Identifier for the Observer
Use the ObserverConnectIdentifier configurable database property to specify how the
observer should connect to and monitor the primary and standby database. Set this property
for the primary and target standby database if you want the observer to use a different
connect identifier than the one that is used to ship redo data (that is, the connect identifier
specified by the DGConnectIdentifier property).
Step 5: Configure Additional Fast-Start Failover Conditions
Use the ENABLE/DISABLE FAST_START FAILOVER broker commands to specify the
conditions under which a fast-start failover should occur. The Oracle Database server detects
when a specified condition occurs and informs the observer. The observer initiates a fast-start
failover without waiting for FastStartFailoverThreshold to expire (if the standby is in a
valid fast-start failover state to accept a failover).
Use the SHOW FAST_START FAILOVER command to obtain a list of valid conditions and
confirm your changes. They include the following:
Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES
Oracle Error Conditions
(none)
Configuring Fast-Start Failover Conditions
Additional database health conditions for a fast-start failover are displayed in the table.
The conditions Datafile Offline, Corrupted Controlfile, and Corrupted
Dictionary are enabled by default. An error is returned if the value you specify is not
recognized.
If the condition was already set, no error is displayed.
Example: Enable a database health condition for a fast-start failover:
DGMGRL> enable fast_start failover condition "Inaccessible
Logfile"
DGMGRL> show fast_start failover
Configurable Failover Conditions

Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile YES
Stuck Archiver NO
Datafile Offline YES
Step 6: Enable Fast-Start Failover
You can enable fast-start failover by using DGMGRL. When you issue the ENABLE
FAST_START FAILOVER command, the observer is able to observe the primary database
and the standby database and can initiate a fast-start failover when necessary.
In addition to enabling fast-start failover, you must start the observer (as described on the next
page).
Step 7: Start the Observer
Execute the START OBSERVER command, which directs the broker to begin observing the
Data Guard configuration to which DGMGRL is connected. You must execute this command
on the computer where the observer will reside.
When you execute the START OBSERVER command, the observer retrieves the primary
database and the fast-start failover target standby database connect identifiers and begins
observation. It provides the name of its host computer to the Data Guard broker.
The primary database must be available for the START OBSERVER command to succeed.
There can be only one observer for a Data Guard configuration at any one time. If you attempt
to start a second observer for the configuration, you receive an error message.
If you disable fast-start failover while the observer is observing the configuration, the observer
idles while waiting for fast-start failover to become enabled.
Step 8: Verify the Configuration
You can also use the SHOW FAST_START FAILOVER command to display all fast-start
failover information.
Initiating Fast-Start Failover from an Application
In Oracle Database 11g, an application can initiate a fast-start failover by invoking the
DBMS_DG.INITIATE_FS_FAILOVER function. The function is used to alert the primary
database server that the application wants a fast-start failover to occur immediately. The
primary database server notifies the observer of this request, and the observer immediately
initiates a fast-start failover. The standby database must be in a valid fast-start failover state
observed and synchronized or within the lag limit of the primary databaseto accept a
failover.
Initiating Fast-Start Failover from an Application (continued)
The DBMS_DG PL/SQL package contains the INITIATE_FS_FAILOVER function, which
enables an application to request a fast-start failover.
The application-initiated failover is an invocation of the FAILOVER command and requires the
SYSDBA privilege. The DBMS_DG package is defined as an invokers rights package to
address privilege concerns. The DBMS_DG.INITIATE_FS_FAILOVER function calls
DBMS_DRS.INITIATE_FS_FAILOVER. This implementation restricts access to the definers
right procedure, DBMS_DRS.INITIATE_FS_FAILOVER, while allowing you to grant the
EXECUTE privilege for the DBMS_DG.INITIATE_FS_FAILOVER procedure.
If the configuration is not in a valid fast-start failover state, the INITIATE_FS_FAILOVER
function returns an ORA error, informing the caller that a fast-start failover operation cannot be
performed.
Viewing Fast-Start Failover Information
V$DATABASE contains the following columns that provide detailed information about fast-start
failover. They include:
FS_FAILOVER_STATUS:
- BYSTANDER: Fast-start failover is enabled, but this standby database is not the
target of the fast-start failover.
- DISABLED: Fast-start failover is disabled.
- LOADING DICTIONARY: This status appears only on a logical standby database
that has not completed loading a copy of the primary database data dictionary.
- PRIMARY UNOBSERVED: This status occurs only on the target standby database
when it is synchronized with or is TARGET UNDER LAG LIMIT of the primary
database and has connectivity with the observer, but the primary database does
not have a connection to the observer.
- REINSTATE FAILED: Reinstatement of the failed primary database as a new
standby database failed. See the Data Guard broker drc* log files for additional
information.
Determining the Reason for a Fast-Start Failover
You can query the V$FS_FAILOVER_STATS view on the primary database to learn why a
fast-start failover operation took place. The view shows the time of the last fast-start failover
and the reason for the operation.
Prohibited Operations After Enabling Fast-Start Failover
After enabling fast-start failover, you cannot perform any of the following operations (which
undermine the fast-start failover environment):
Change the configuration protection mode.
Change the LogXptMode property for the primary database or target standby database.
Perform a failover or switchover to a standby database that is not the fast-start failover
target.
Disable the Data Guard broker configuration.
Delete the Data Guard broker configuration.
Disable the standby database that is the target of fast-start failover.
Remove the standby database that is the target of fast-start failover.
Alter the FastStartFailoverTarget database-level property of either the primary
database or the standby database.
Fail over to an unsynchronized fast-start failover target.
Disabling Fast-Start Failover
You can disable fast-start failover to prevent the observer from initiating a failover to the target
standby database.
When you execute the DISABLE FAST_START FAILOVER command, the Data Guard broker
disables fast-start failover on the target standby database and then disables fast-start failover
on the primary database. The Data Guard broker records this change persistently in the Data
Guard broker metadata and propagates the change to all standby databases in the Data
Guard broker configuration.
If the primary database and the fast-start failover target standby database do not have
connectivity with each other, you can use the FORCE option to disable fast-start failover. If this
command is executed on the primary database or on a bystander (non-fast-start failover
target) standby database that has connectivity with the primary database, the Data Guard
broker disables fast-start failover locally. The Data Guard broker then records this change
persistently in the Data Guard broker metadata and propagates the change to all databases in
the Data Guard broker configuration to which the primary database has connectivity.
Disabling Fast-Start Failover Conditions
Use the DISABLE FAST_START FAILOVER CONDITION command to disable fast-start
failover for specified conditions. (You specify conditions as described earlier in the lesson.)
Using the FORCE Option
Use the FORCE option when:
You want to disable fast-start failover when the environment is synchronized and the
primary database has lost connectivity with the observer and the target standby
database. The FORCE option enables you to disable fast-start failover without requiring
connectivity with the target standby database or the observer.
You want to prevent a fast-start failover from occurring on the target standby database
because you know that the primary database will resume service before the fast-start
failover threshold expires.
You want to conduct a manual failover to either the target standby database or a
bystander standby database when the fast-start failover environment is unsynchronized.
In this case, you must be willing to accept a data-loss failover.
Stopping the Observer
If you no longer want to use fast-start failover, or if you want to move the observer to a
different host computer, use the STOP OBSERVER command to stop the observer.
Note: The STOP OBSERVER command does not disable fast-start failover. You can issue this
command whether or not fast-start failover is enabled.
You must issue this command on the primary database or on a standby database in the
configuration that has connectivity to the primary database. If you execute this command
when fast-start failover is enabled, the fast-start failover target standby database must have
connectivity to the primary database.
The observer does not immediately stop when you execute the STOP OBSERVER command.
The broker informs the observer the next time it is contacted by the observer. After you
execute the STOP OBSERVER command, the Data Guard broker can accept a new observer
whether or not the stopped observer is terminated.
Performing Manual Role Changes
You can perform manual role changes in a fast-start failover configuration if the role change is
directed to the fast-start failover target standby database and if the configuration is
synchronized.
The following conditions must be met:
If the configuration is operating in maximum availability mode, the target standby
database must be synchronized with the primary database.
If the configuration is operating in maximum performance mode, the target standby
database must be within the specified lag limit of the primary database.
For manual failover, the observer must be started and must be communicating with the
target standby database.
Manually Reinstating the Database
Use the REINSTATE DATABASE command to reinstate the database. If the conditions for
reinstatement are not satisfied, the request fails and the specified database remains disabled.
If the database name specified is the original primary database and fast-start failover is
enabled, the original primary database is reinstated as a standby database to the new primary
database. The fast-start failover configuration is updated to reflect the availability of the new
standby database. It accepts archived redo log files from the new primary database and
serves as the fast-start failover target if the new primary database fails.
Issue this command while connected to either the primary database or to a standby database
in the configuration that has connectivity to the primary database other than the original
primary database to be reinstated.
Note: The REINSTATE DATABASE command does not require fast-start failover to be
enabled. It can also be used to reinstate an original primary database after a conventional no-
data-loss failover.
Using Enterprise Manager to Enable Fast-Start Failover
On the Data Guard page, click the Disabled link (next to Fast-Start Failover) to invoke the
fast-start failover wizard.
Using Enterprise Manager to Enable Fast-Start Failover (continued)
Select the fast-start failover target database and (optional) the observer host. If the observer
was not started, click the Configure Observer button.
Specify the observer host and observer Oracle home to indicate where the observer will be
started.
You can also specify an alternate observer host and alternate observer Oracle home.
Enterprise Manager will provide high availability for the observer with this setup. If the original
observer or observer node dies, Enterprise Manager will automatically start the observer on
the alternate node.
Note: Enterprise Manager ensures that each observer has uniquely named data and
DGMGRL log files. As a result, there is no problem if observers for different Data Guard
configurations are started in the same Oracle Home.
The observer data files, named afoXXXXX.dat, are stored in the $ORACLE_HOME/dbs
directory. The DGMGRL log file, named dgmgrlXXXXX.log, is stored in the
$ORACLE_HOME/rdbms/log directory.
XXXXX is a unique number generated by Enterprise Manager and is the same for the observer
data file and the DGMGRL log file for a given primary standby database configuration. XXXXX
changes each time an observer is restarted.
Flashback logging must be enabled on both the primary database and the standby database
to enable fast-start failover. If either database does not have flashback logging enabled, the
Enable Flashback Logging page is displayed. Specify the flash recovery area location, flash
recovery area size, and flashback retention time for each database.
On the Confirmation: Enable Fast-Start Failover page, confirm that you want to enable fast-
start failover to the named database.
After you confirm that you want to enable fast-start failover to a specific database, the fast-
start enabling process begins. After the processing steps are complete, you are returned to
the Data Guard page.
On the Data Guard Fast-Start Failover Processing page, you can observe the progress of the
fast-start failover enabling operation as the following actions are performed:
Standby redo log files are created on the primary and standby databases.
The protection mode is upgraded to Maximum Availability (if required).
The primary database and standby database are restarted (if required).
Fast-start failover is enabled.
The observer process is started.
Changing the Protection Mode and Disabling Fast-Start Failover
If you change the protection mode to a mode that does not support fast-start failover, you
implicitly disable fast-start failover.
Note: Enterprise Manager Grid Control 10g does not support maximum performance mode
with fast-start failover.
Using Enterprise Manager to Disable Fast-Start Failover
Click the Enabled link to access the Fast-Start Failover: Change Mode page, where you
select the Disable option and the Stop observer check box to disable fast-start failover.
Using Enterprise Manager to Suspend Fast-Start Failover
To suspend fast-start failover, select Disable on the Fast-Start Failover: Change Mode page.
Do not select the Stop observer check box.
Moving the Observer to a New Host
If the observer host machine fails, you may need to move the observer to a new host.
To stop the original observer and start the observer on a new host:
1. Execute the STOP OBSERVER command to sever the link between the original observer
and the broker configuration:
DGMGRL> STOP OBSERVER;
2. Execute the SHOW CONFIGURATION VERBOSE and SHOW DATABASE commands to
verify that the observer is stopped and the configuration is no longer being observed.
3. Invoke DGMGRL, connect to a database in your configuration, and start the observer on
your new host.
Answer: b
Answer: a
Understanding Client Connectivity in a Data Guard Configuration
Consider the issues listed in the slide when managing client connectivity in a Data Guard
configuration.
Understanding Client Connectivity: Using Local Naming
The diagram illustrates client connectivity using local naming.
The tnsnames.ora file would look similar to the following:
PROD = (DESCRIPTION =
(ADDRESS=(PROTOCOL = TCP)
(HOST = EDBVR6P1)(PORT = 1521))
(ADDRESS=(PROTOCOL = TCP)
(HOST = EDBVR6P2)(PORT = 1521))
(CONNECT_DATA = (SERVICE_NAME = DG_PROD)))
Preventing Clients from Connecting to the Wrong Database
Clients who send connection requests to the wrong host might be connected to the wrong
database instance, or they might receive an error message such as the following:
ORA-01033: ORACLE initialization or shutdown in progress
You can prevent clients from connecting to the wrong database by using database services.
Managing Services
Database services are implemented with the DBMS_SERVICE package. This package
provides for the creation, deletion, starting, and stopping of services for a single database
instance.
Note: For Oracle Real Application Clusters (RAC) and single-instance databases managed
by Oracle Restart or Oracle Clusterware (which includes ASM), the DBMS_SERVICE
procedure is deprecated in Oracle Database 11g Release 2 (11.2) and srvctl should be
used instead to create services.
Understanding Client Connectivity: Using a Database Service
The diagram in the slide illustrates client connectivity when using a database service.
Creating Services for the Data Guard Configuration Databases
By using the DBMS_SERVICE.CREATE_SERVICE procedure, you define a service to
represent each role or state in which the databases in your Data Guard configuration can
operate. A service created with DBMS_SERVICE.CREATE_SERVICE is not aware of the
actual database role. This functionality is only available with the SRVCTL interface for both
Real Application Clusters and Oracle Restart. In the examples above, the service name is
being used to imply the database role, which could be inaccurate after role transitions. The
CREATE_SERVICE procedure creates a service name in the data dictionary.
You should create services for the physical standby database when it is opened in read-only
mode (using Real-time Query) and when it is converted into a snapshot standby database.
The DBMS_SERVICE.CREATE_SERVICE will fail to execute on a physical standby database
even if it is open read-only. The service must be created on the primary and allowed to
propagate to the physical standby. In addition, create a service for logical standby databases
in your configuration.
Note: Database service names in the slide are examples.
Configuring Role-Based Services
You can configure database services with a database role on an Oracle RAC database or a
single-instance database registered with Oracle Restart. The Data Guard broker interacts with
Oracle Clusterware or Oracle Restart to ensure that the correct database services are active
after a role change. This is available on Oracle Database 11g Release 2 (11.2) only if the Data
Guard configuration is broker managed.
The SRVCTL ADD SERVICE and MODIFY SERVICE commands support the following new
attributes:
-l: ROLE attribute with values of PRIMARY, PHYSICAL_STANDBY, LOGICAL_STANDBY,
and SNAPSHOT_STANDBY. Default is PRIMARY. This attribute is used to specify the
database role for which a given database service should be active.
-y: MANAGEMENT POLICY attribute with values of AUTOMATIC and MANUAL. Default is
AUTOMATIC.
When the database instance starts, the service is started automatically if the MANAGEMENT
POLICY attribute is set to AUTOMATIC and the value of the ROLE attribute matches the
database role. Users can also start a service manually if the database instance is started.
Note: If the service is created on a database instance that has already been started, then it will
be necessary to manually start the service the first time. The following syntax illustrates using
SRVTL to manually start a service:
srvctl start service d pc01sby1 s pc01prod
Adding Standby Databases to Oracle Restart Configuration
When Enterprise Manager Grid Control 10g is used to create standby databases with the
wizard-driven approach, the newly created standby databases are not automatically
registered with the Oracle Restart configuration. Use SRVCTL to create the database object
in the Oracle Restart Configuration before database services can be associated with the
standby databases. The syntax for SRVCTL is displayed in the slide to create a new
database object. The values for start_options include open, mount, or nomount. The
values for stop_options include normal, transactional, immediate, or abort.
Example: Configuring Role-Based Services
The example in the slide shows the configuration of two role-specific services:
PAYROLL is a read-write service that always runs on the database with the primary role.
ORDERSTATUS is a read-only service that always runs on an Active Data Guard standby
database, which is currently defined as the Dallas database while it is in the
PHYSICAL_STANDBY role. A role transition can stop this service.
Note: Database services are linked to a specific DB_UNIQUE_NAME in the Oracle Restart
Configuration. For the PAYROLL service to be associated with both the primary database and
standby database, it will have to be registered to each database individually. The role is set to
PRIMARY, so it will start only on one of the two databases.
Connecting Clients to the Correct Database
Ensure that clients connect to the database instance that is in the correct state and role in the
Data Guard configuration by using a database event trigger. The AFTER STARTUP trigger
starts the appropriate service on the database.
Note: Database service names in the slide are shown as an example. It is not necessary to
employ an AFTER STARTUP trigger if the services are managed by Oracle Clusterware.
Creating the AFTER STARTUP Trigger
The AFTER STARTUP trigger is invoked when the database is opened. The trigger checks the
database role and the open mode of the database and, based on the values, invokes the
DBMS_SERVICE.START_SERVICE procedure to start the appropriate service. The CREATE
TRIGGER SQL command needs to be run only in the primary database. It will be replicated to
all standby databases.
Note: The trigger shown in the slide is an example using the service names defined earlier in
the lesson. Additional trigger functionality may be necessary based on your circumstances. It
is not necessary to employ an AFTER STARTUP trigger if the services are managed by Oracle
Clusterware.
Configuring Service Names in the tnsnames.ora File
To ensure that clients connect to a database in the correct state and role for a particular
service, configure a Net service name for each service in the tnsnames.ora file.
Note: The example in the slide corresponds to the service names and trigger defined earlier
in the lesson.
Automatic Failover of Applications to a New Primary Database
In previous Oracle Database releases, user-written database triggers were required to
implement automatic failover as follows:
A startup trigger was used to start database services on the new primary database.
A role-change trigger was used to publish a FAN ONS event to break JDBC clients still
connected to the original primary database out of a TCP timeout.
In Oracle Database 11g Release 2 (11.2), you can automate fast failover of applications to a
new primary database without the need for user-written triggers. You must use the Data
Guard broker to use this feature.
Automatic fast failover of application clients to a new primary database following failover
requires:
1. Fast database failover
2. Restarting database services on the new primary database
3. Notifying clients that a failure has occurred in order to break them out of TCP timeout
and redirect them to the new primary database
Data Guard Broker and Fast Application Notification (FAN)
When a failover operation is complete, the Data Guard broker publishes a Fast Application Notification
(FAN) event to notify applications that the old primary database is down, and that services on the old
primary database are down. This enables applications to transparently fail over to the new primary
database.
FAN notification is sent after failover for databases configured with Cluster Ready Services (CRS) and
for single-instance databases registered with Oracle Restart.
Applications using the following Oracle integrated database clients can be configured for Fast Connection
Failover (FCF) to automatically connect to a new primary database after a failover:
Oracle Database JDBC
Oracle Database Oracle Call Interface (OCI)
Oracle Database ODP.NET.
These clients can use FAN without programmatic changes.
Applications can use FAN programmatically by using the Oracle Notification Service (ONS) Application
Programming Interface to subscribe to FAN events and to execute event-handling actions upon the
receipt of an event.
Refer to Oracle Real Application Clusters Administration and Deployment Guide 11g Release 2 for detailed
information about configuring FAN, FCF, and ONS in an Oracle RAC environment.
Enabling FAN Events in an Oracle Restart Environment
To enable Oracle Restart to publish Fast Application Notification (FAN) events, you must
create an Oracle Notification Services (ONS) network that includes the Oracle Restart servers
and the integrated clients. These clients can include Oracle Connection Manager (CMAN),
Java Database Connectivity (JDBC), and Universal Connection Pool (UCP) clients. If you are
using Oracle Call Interface or ODP.NET clients, you must enable Oracle Advanced Queuing
(AQ) HA notifications for your services. In addition, ONS and eONS must be running on the
server.
To enable FAN events in an Oracle Restart environment:
1. Prepare to run SRVCTL from the Oracle Grid Infrastructure environment. SRVCTL can
also be found in the ORACLE_HOME database, but it should not be used from there.
2. Add the database to the Oracle Restart configuration if it is not already managed by
Oracle Restart. Oracle Enterprise Manager 10g wizards do not automatically add newly
created standby databases to the Oracle Restart configuration.
3. Add ONS and eONS to the configuration.
4. Start ONS and eONS.
5. Add the service to the Oracle Restart configuration.
6. Enable each client for fast connection failover.
Automating Client Failover in a Data Guard Configuration
Automating client failover in a Data Guard configuration includes:
Relocating database services to the new primary database as part of a Data Guard
failover
Notifying clients that the failure occurred in order to break them out of TCP timeout
Redirecting clients to the primary database that is established during the failover
operation
Client Failover: Components
Connect time failover: Redirects failed connection requests to a secondary listener.
Transparent Application Failover (TAF): Enables Oracle Call Interface (OCI) client
applications to automatically reconnect to a database if the original connection fails. TAF
fails over only the session and SELECT statements. SELECT statements are
automatically restarted in the new session when TAF is configured for SELECT failover.
INSERT, UPDATE, and DELETE statements must be rolled back by the application. In
addition, any session customizations (for example, ALTER SESSION statements) must
be reexecuted by the application. Process state variables (such as PL/SQL session
level variables) are not reestablished but can be reestablished by using a TAF callback.
Fast Application Notification (FAN): Provides quick notification when a resource
(such as an instance, service, node, or database) fails. FAN is available to all
applications by using either Fast Connection Failover with a FAN-integrated Oracle
client (clients using JDBC, OCI, or OLE DB) or by using the FAN API to read FAN
events directly.
Fast Connection Failover: Provides fast failover of database connections by enabling
you to configure FAN-integrated JDBC clients to automatically subscribe to FAN high-
availability events and react to service, instance, and database UP and DOWN events.
DB_ROLE_CHANGE system event: Is fired when any database is first opened after a
Data Guard role transition occurs. Using this system event, you can write a trigger to
perform post-role change actions.
Client Failover: Best Practices
Additional information about each type of client follows in this lesson. For detailed examples,
see the white paper titled Client Failover Best Practices for Highly Available Oracle
Databases: Oracle Database 10g Release 2.
Automating Failover for OCI Clients
To automate failover for OCI clients, perform the following steps to configure your database:
1. Ensure that your configuration is managed by the Data Guard broker.
2. Execute the DBMS_SERVICE.CREATE_SERVICE procedure to create the database
service, enable high-availability notification, and configure server-side TAF settings.
3. Create a trigger that fires on the system startup event.
This trigger relocates the database to the service (created in step 2) to a Data Guard
standby database after a role transition.
To automate failover for OCI clients, perform the following steps to configure your OCI clients
to receive notification of FAN high-availability events and avoid reconnecting to a failed
instance:
1. Create an Oracle Net service name that includes an ADDRESS entry for the primary
database host and all standby databases hosts.
2. Use the OCI_EVENTS parameter to initialize the environment so that OCI clients receive
FAN notifications:
OCIEnvCreate(...OCI_EVENTS...)
Note: See the Oracle Call Interface Programmers Guide for additional information.
3. Link the OCI client application to the libthread or libpthread thread library.
Automating Failover for OLE DB Clients
To automate failover for OLE DB clients, perform the following steps to configure your
database:
1. Ensure that your configuration is managed by the Data Guard broker.
2. Execute the DBMS_SERVICE.CREATE_SERVICE procedure or SRVCTL to create the
database service, enable high-availability notification, and configure server-side TAF
settings.
3. Create a trigger that fires on the system startup event if needed.
This trigger relocates the database after a role transition to the service that was created
in step 2.
Configuring OLE DB Clients for Failover
To configure OLE DB clients to receive notification of FAN high-availability events:
1. Set the following OraOLEDB connection string attributes:
a. DBNotifications = true
b. DBNotificationPort = [unsigned integer]
Setting the DBNotificationPort attribute allows the port to be specified. If this
attribute is not set, the port is randomly selected.
2. Set the SQLNET.OUTBOUND_CONNECT_TIMEOUT parameter in the sqlnet.ora file to
a value of 3 seconds.
This parameter enables clients to quickly traverse an address list if a failure occurs.
If a client attempts to connect to a host that is unavailable, the connection attempt is
bounded to the time specified by the SQLNET.OUTBOUND_CONNECT_TIMEOUT
parameter, after which the client attempts to connect to the next host in the address list.
This behavior continues for each host in the address list until a successful connection is
made.
Automating Failover for JDBC Clients
To automate failover for JDBC clients, perform the following steps to configure your database:
1. Execute the DBMS_SERVICE.CREATE_SERVICE procedure or SRVCTL to create the
database service for JDBC clients.
Because JDBC clients use FCF rather than TAF, database services for JDBC clients are
not configured for AQ HA events. Instead, a trigger is required to notify JDBC clients
when a Data Guard failover occurs.
2. Configure and start ONS daemons on all hosts that may contain a primary database.
Configure ONS in the $ORACLE_HOME/opmn/conf directory (similar to the example in
the slide). See the Oracle Database JDBC Developers Guide and Reference for details.
3. Start the ONS daemon.
4. Create a trigger on the system startup event to relocate the database service after a role
transition if needed. The trigger is not needed when using Oracle Restart.
5. Create a trigger enabled for the DB_ROLE_CHANGE system event that calls a C program
named the FAN ONS Publisher.
This trigger is required because the primary host where the ONS daemons reside are no
longer available. By calling the FAN ONS Publisher program based on a trigger enabled
on the DB_ROLE_CHANGE system event, JDBC clients are notified of the primary site
failure and instructed to reconnect to the new primary database. See the white paper
titled Client Failover Best Practices for Highly Available Oracle Databases: Oracle
Database 10g Release 2 for information about the FAN ONS Publisher.
Configuring JDBC Clients for Failover
To configure JDBC clients for failover:
1. Set the FastConnectionFailoverEnabled DataSource property to True
so that the client application uses implicit JDBC connection cache on its data source.
2. Set the oracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STR property to a value of
3 seconds on the data source.
This property enables the JDBC client to quickly traverse an address list in the event of
a failure. If the client attempts to connect to a host that is unavailable, the connection
attempt is bounded to the time specified by the SQLnetDef.TCP_CONNTIMEOUT_STR
property, after which the client attempts to connect to the next host in the address list.
The behavior continues for each host in the address list until a successful connection is
made.
3. Create an Oracle Net service name that includes an ADDRESS entry for the primary
database host and all standby database hosts.
4. Configure a remote ONS subscription on the JDBC client so that an ONS daemon is not
required on the client. The remote ONS subscription should contain all hosts that have
the potential to become a primary database.
5. Enable SSL for communications.
SSL should be used for all ONS communications.
Answer: a
Answer: a
Using RMAN to Back Up and Restore Files in a Data Guard Configuration
Recovery Manager (RMAN) can be used to back up and recover a standby database.
Backups that you make on a physical standby database are usable at a primary database or
another standby database.
A recovery catalog is required when you use RMAN in a Data Guard configuration containing
physical standby databases. Metadata for the primary database and all standby databases is
stored in the recovery catalog.
Oracle Maximum Availability Architecture (MAA) best practices recommend that backups be
taken at both the primary and the standby databases to:
Reduce mean time to recover (MTTR)
Handle outages at multiple sites
Avoid introducing new site practices during switchover and failover
Offloading Backups to a Physical Standby
RMAN can back up the standby database and its associated archived redo logs. Standby
backups of data files and archived redo logs are fully interchangeable with primary database
backups. You can execute the RESTORE command to restore a backup of a standby data file
to the primary database, and you can restore a backup of a primary data file to the standby
database. The standby control file and primary control file, however, are not interchangeable.
Both the primary database and standby database must use the same recovery catalog. Note
that you do not need to register the standby database in the catalog if the primary is already
registered; simply connect to the standby database and execute the BACKUP command.
Restrictions and Usage Notes
If physical standby database backups are to be usable for restore jobs at the primary site, you
must be connected to the recovery catalog when backing up the standby database or you
must resynchronize the physical standby database shortly after the backup. This step is
necessary because there is no way for the primary database to know about the standby
backups unless the backup records are stored in the recovery catalog.
Furthermore, you cannot make an image copy or non-RMAN backup of the standby control
file and then use it to restore the primary database.
When you back up the standby database, you must connect to the standby database with the
TARGET keyword (not the AUXILIARY keyword). The standby database essentially
substitutes for the primary database during the backup.
Backup and Recovery of a Logical Standby Database
You can back up your logical standby database by using the same method that you use for
your primary database. The backup files are not interchangeable with the primary database.
Remember that this is a different database.
You can use the same recovery techniques as you use with any other database for loss of
data files or online log files. You must use the backups of the logical (not the primary)
database.
If the entire logical standby database is lost, you must re-create the logical standby.
If you lose all copies of your control file, you must use a binary copy of the control file when
performing the recovery. (Using a trace file or the CREATE CONTROLFILE command for
control file recovery does not create a logical standby control file.) Make a binary copy of the
control file by doing either of the following:
Shut down the logical standby and copy the control file to a backup.
Issue the following command while the logical standby database is open:
ALTER DATABASE BACKUP CONTROLFILE TO '<filename>';
This command creates a binary copy of the control file with the name that you supply.
Using the RMAN Recovery Catalog in a Data Guard Configuration
In a Data Guard configuration, you should use an RMAN recovery catalog. This permits
backups taken on one database server to be restored to another database server. If you use
only the control file as the RMAN repository, the primary database will have no knowledge of
backups taken on the standby database.
Creating the Recovery Catalog
1. Configure the database in which you want to store the recovery catalog.
a. Determine the database in which you will install the recovery catalog schema. Be
sure to consider your backup and recovery procedures for this database.
b. Create a tablespace for the recovery catalog, which becomes the default
tablespace for the recovery catalog owner. The amount of space required by the
recovery catalog schema depends on the number of databases monitored by the
catalog. The typical space requirement is 15 MB for each database registered in
the recovery catalog.
SQL> CREATE TABLESPACE rc_ts DATAFILE SIZE 30M;
2. Create a user to serve as the recovery catalog owner. Set the default tablespace for this
user to the tablespace that you created for the recovery catalog. Be sure to provide
UNLIMITED quota on this tablespace for the user. After creating the user, grant the
RECOVERY_CATALOG_OWNER role to the user.
SQL> CREATE USER rcowner IDENTIFIED BY rcpass
2 TEMPORARY TABLESPACE temp
3 DEFAULT TABLESPACE rc_ts
4 QUOTA UNLIMITED ON rc_ts;
SQL> GRANT recovery_catalog_owner TO rcowner;
Registering a Database in the Recovery Catalog
After creating the recovery catalog, you must register the target databases in the recovery
catalog. Only the primary database must be explicitly registered by using the REGISTER
DATABASE command. A standby database is automatically registered in the recovery catalog
when you connect to it or when the CONFIGURE DB_UNIQUE_NAME command is executed to
specify the net service name for the physical standby database.
To register your primary database:
1. Invoke RMAN and connect to the recovery catalog database and to the target database,
as shown in the following example:
% rman TARGET / CATALOG rcowner/rcpass@reccatdb
2. Ensure that the target database is mounted or open.
3. Issue the REGISTER command to register the target database in the recovery catalog:
RMAN> REGISTER DATABASE;
Setting Persistent Configuration Settings
Use the CONFIGURE RMAN command to register and configure settings for databases in your
Data Guard configuration.
RMAN uses the DB_UNIQUE_NAME initialization parameter to distinguish the databases in the
Data Guard configuration. You can use the CONFIGURE command with the FOR
DB_UNIQUE_NAME clause to create a persistent configuration for a database in a Data Guard
configuration without connecting to the database as TARGET. Use the SET DBID command to
set the DBID in the RMAN session so that you can configure a standby database when
RMAN is not connected as TARGET to a database in the Data Guard environment. You can
also use this technique to create a configuration for a standby database that is not yet
created.
RMAN must be connected to a recovery catalog when you create or alter a configuration for a
database in the Data Guard environment.
Setting RMAN Persistent Configuration Parameters on the Primary Database
Configure the retention policy to determine the backups that need to be kept to recover
to the specified point in time. This setting specifies that necessary backups should be
kept to perform database recovery to any point in time within the specified number of
days.
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF <n> DAYS;
Execute the DELETE OBSOLETE command to delete any backups that are not required
by the retention policy.
Use the CONFIGURE ARCHIVELOG DELETION POLICY command to specify when
archived logs can be deleted.
- To delete logs after ensuring that they shipped to all destinations:
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL
STANDBY;
- To delete logs after ensuring that they were applied on all standby destinations:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL
STANDBY;
Setting RMAN Persistent Configuration Parameters on the Physical Standby
Database
On the physical standby database that you will be using for backups, set RMAN persistent
configuration parameters as follows:
Enable automatic backup of the control file and the server parameter file.
CONFIGURE CONTROLFILE AUTOBACKUP ON;
Set backup optimization to ON so that RMAN does not back up data files for which there
is valid backup with the same checkpoint.
CONFIGURE BACKUP OPTIMIZATION ON;
Specify the archived log file deletion policy to indicate when archived redo log files are
deleted.
CONFIGURE ARCHIVELOG DELETION POLICY TO
BACKED UP 1 TIMES TO DEVICE TYPE DISK;
When backing up to tape, configure tape channels as required by the media management
software. For details about backups to tape and the use of media management software, see
Oracle Data Guard Concepts and Administration.
Setting RMAN Persistent Configuration Parameters on the Other Standby
Databases
You specify the archived log file deletion policy to indicate that archived logs are deleted after
they are applied at the standby database.
Configuring Daily Incremental Backups
Oracle Corporation recommends that you implement a daily incremental backup strategy. In
this backup strategy, data file image copies are rolled forward with the latest incremental
backups. The resulting up-to-date data file image copy is used by RMAN for media recovery.
Perform a full database backup on the first day, followed by an incremental backup on day
two. Archived redo logs can be used to recover the database to any point during either day.
Beginning on day three, the previous days incremental backup is merged with the data file
copy and a current incremental backup is taken, allowing fast recovery to any point within the
last day. Redo logs can be used to recover the database to any point during the current day.
You can create an RMAN script to take all of the backups (as shown in the slide):
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL: Resynchronizes the information from
all database sites (primary and other standby databases) in the Data Guard
configuration that are known to the recovery catalog.
RECOVER COPY OF DATABASE WITH TAG 'dgbkup': Rolls forward the level 0 copy of
the database by applying the level 1 incremental backup taken the day before.
- On day 1, there is no roll forward because there is no incremental level 1 backup.
- On day 2, there is no roll forward because there is only a level 0 incremental
backup at this time.
Recovering from Loss of a Data File on the Primary Database
These two methods are covered on the following pages.
Using a Backup to Recover a Data File on the Primary Database
Invoke RMAN and connect to the primary database and the recovery catalog.
Execute the RESTORE DATAFILE command to restore the data file.
Execute the RECOVER DATAFILE command to recover the data file.
For detailed information about the RESTORE and RECOVER commands, see the Oracle
Database Backup and Recovery Reference.
Using a Physical Standby Database Data File to Recover a Data File on the
Primary Database
To use a current data file from the physical standby database to recover a data file on the
primary database:
1. Connect to the standby database as the target database:
CONNECT TARGET sys/oracle@pc01sby1
Connect to the primary database as the auxiliary database:
CONNECT AUXILIARY sys/oracle@pc01prmy
2. Back up the data file on the standby host across the network to a location on the
primary host, as in the following example:
BACKUP AS COPY DATAFILE 5
AUXILIARY FORMAT '/u02/oracle/restore/df5copy.dbf';
Using a Physical Standby Database Data File to Recover a Data File on the
Primary Database (continued)
3. Exit the RMAN session. Invoke RMAN again and connect to the primary database as
the target database and connect to the recovery catalog, as in this example:
CONNECT TARGET sys/oracle@pc01prmy
CATALOG rcowner/rcpass@pc01db11;
4. Use the CATALOG DATAFILECOPY command to catalog this data file copy so that
RMAN can use it.
CATALOG DATAFILECOPY '/u02/oracle/restore/df5copy.dbf';
5. Use the SWITCH DATAFILE command to switch the data file copy so that the cataloged
file becomes the current data file.
RUN {
SET NEWNAME FOR DATAFILE 5 TO
'/u02/oracle/restore/df5copy.dbf';
SWITCH DATAFILE 5;
}
Recovering a Data File on the Standby Database
Using a Backup to Recover a Data File on the Standby Database
To recover a data file on the standby database, you must restore the lost file to the standby
database from the backup by using the RESTORE DATAFILE RMAN command. If all archived
redo log files that are required for recovery of the file are accessible on disk by the standby
database, you only need to restart Redo Apply.
If the archived redo log files that are required for recovery are not accessible on disk, use
RMAN to recover the restored data files to an SCN or log sequence that is greater than the
last log applied to the standby database. Next, restart Redo Apply to continue the application
of redo data.
Using a Data File From the Primary Database
You can use a current data file from the primary database to recover a file on the standby
database.
Enhancements to Block Media Recovery
In past releases of Oracle Database, if a block was corrupted you had to identify the corrupt
block and manually perform block media recovery by executing the RECOVER BLOCK
command.
The Automatic Block Repair feature in Oracle Database 11g Release 2 (11.2) enables block media
recovery to use blocks from a physical standby database to perform the recovery without manual
intervention. The physical standby database must have real-time query enabled to take advantage
of this feature.
When a query is executed on a physical standby database configured with real-time query
and a corrupted block is detected, a valid block is retrieved from the primary database.
When a corrupted block is detected during a recovery operation on the standby database, the
recovery process will retrieve a valid block from the primary database.
This feature reduces the amount of time that production data cannot be accessed due to
block corruption by automatically repairing the corruption as soon as it is detected. Block
recovery time is reduced because up-to-date good blocks from a real-time, synchronized
physical standby database are used rather than blocks from disk or tape backups, or
flashback logs.
Note: Automatic Block Repair is applicable only for physical block corruption (when the
checksum is invalid, the block contains all zeros, or the block header is fractured).
Enhancements to Block Media Recovery (continued)
Automatic Block Repair also enables the automatic repair of corrupt blocks on the physical
standby database. Block media recovery is performed by using blocks retrieved from the
primary database. Real-time query must be enabled on the physical standby database to take
advantage of this feature.
Executing the RECOVER BLOCK Command
In past releases of Oracle Database, when you executed the RECOVER BLOCK command
to perform block media recovery, RMAN searched the flashback logs for good copies of the
blocks, and then searched in full or level 0 incremental backups. In Oracle Database 11g
Release 2 (11.2), RMAN first attempts to restore blocks from a physical standby database that
is configured with real-time query. If RMAN does not find a valid block in the physical standby
database, the flashback logs are searched. Finally, the full or level 0 incremental backups are
searched.
Excluding the Standby Database
By default, the RECOVER BLOCK command tries to retrieve a good block from a physical
standby database. You can disable the search on the physical standby database by
specifying the EXCLUDE STANDBY clause with the command. You may use the EXCLUDE
STANDBY clause when you know there is a network issue or other reason that the standby
database is not available.
Answer: b
Answer: b
Objectives
The methods outlined in this lesson are applicable for a patch, a critical patch update (CPU),
a patch set, or a major release.
Upgrading an Oracle Data Guard Broker Configuration
To upgrade the databases in your Data Guard configuration:
1. Disable broker management of the databases in the Data Guard configuration by
executing the following DGMGRL command:
DGMGRL> DISABLE CONFIGURATION;
2. Execute the following SQL*Plus statement to stop the broker:
SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;
After completing the upgrade:
1. Start the Data Guard broker by executing the following command in SQL*Plus:
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;
2. Enable broker management of the configuration by executing the following DGMGLR
command:
DGMGRL> ENABLE CONFIGURATION
Note: The first time the release 11.2 broker starts, it detects the existence of release 10.n
broker configuration files and automatically upgrades them to include new properties
introduced in release 11.2.
Upgrading Oracle Database in a Data Guard Configuration with a Physical
Standby Database
Perform the steps in the slide to upgrade to Oracle Database 11g Release 2 (11.2) when your
Data Guard configuration contains one or more physical standby databases.
Note: For detailed information about these steps, see the Oracle Database Upgrade Guide
(including the Preparing to Upgrade chapter).
Upgrading Oracle Database in a Data Guard Configuration with a Physical
Standby Database (continued)
Data Guard configuration contains one or more physical standby databases.
Note: For detailed information about these steps, see the Oracle Database Upgrade Guide
(including the Preparing to Upgrade chapter).
Upgrading Oracle Database in a Data Guard Configuration with a Logical Standby
Database
Data Guard configuration contains a logical standby database.
Note: For detailed information about the steps for upgrading to Oracle Database 11g
Release 2 (11.2) when your Data Guard configuration contains a physical standby database,
see the Oracle Database Upgrade Guide (including the Preparing to Upgrade chapter).
Using SQL Apply to Upgrade the Oracle Database
You can use a logical standby database to perform a rolling upgrade of Oracle Database 10g
software. During a rolling upgrade, different releases of Oracle Database can be on the
primary database and logical standby databases while you upgrade them one at a time,
incurring minimal down time on the primary database.
Using Data Guard SQL Apply, you can perform a rolling upgrade of the Oracle Database
software from patch set release n to any higher-versioned patch set or major version release.
Note: The minimum supported release is 10.1.0.3.
Requirements for Using SQL Apply to Perform a Rolling Upgrade
Prior to performing the rolling upgrade, complete the following requirements:
Remove the databases from the Data Guard broker configuration.
Set the Data Guard protection mode to either maximum availability or maximum
performance.
The LOG_ARCHIVE_DEST_n initialization parameter for the logical standby destination
must not be set to MANDATORY.
Set the COMPATIBLE initialization parameter so that it matches the software release
prior to the upgrade. A rolling upgrade from release x to release y requires that the
COMPATIBLE initialization parameter be set to release x on the primary database and
the standby database.
Performing a Rolling Upgrade by Using SQL Apply
You can use SQL Apply to perform a rolling upgrade in several different configurations. Each
of the configurations is outlined in detail in this lesson.
Identifying Unsupported Data Types
You identify data types and storage attributes on the primary database that are not supported
in a logical standby database by querying the DBA_LOGSTDBY_UNSUPPORTED and
DBA_LOGSTDBY_SKIP views on the primary database. If your primary database contains
unsupported objects, you may be able to perform the upgrade by temporarily suspending
changes to the unsupported tables for the period of time it takes to perform the upgrade
procedure.
If you cannot prevent changes to unsupported tables during the upgrade, you may be able to
use Oracle Data Pump or the Import utility to import the changed tables to the upgraded
databases. Unsupported transactions that occur are recorded in the
DBA_LOGSTDBY_EVENTS table on the logical standby database.
Performing a Rolling Upgrade by Using an Existing Logical Standby Database
To perform a rolling upgrade by using a logical standby database in your Data Guard
configuration:
1. Prepare for the rolling upgrade as follows:
a. Stop SQL Apply by issuing the following statement on the logical standby
database:
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
b. Set the COMPATIBLE initialization parameter to the highest value. Ensure that the
COMPATIBLE initialization parameter specifies the release number for the Oracle
Database software running on the primary database prior to the upgrade.
2. Upgrade the Oracle Database software on the logical standby database to release y.
While the logical standby database is being upgraded, it does not accept redo data from
the primary database. See the Oracle Database Upgrade Guide for detailed information.
(continued)
3. Restart SQL Apply by executing the following statement on the standby database:
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
The redo data that was accumulating on the primary database system is automatically
transmitted and applied on the logical standby database. To monitor how quickly the
logical standby database is catching up to the primary database, query the
V$LOGSTDBY_PROGRESS view on the logical standby database. For example:
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY
HH24:MI:SS';
Session altered.
SQL> SELECT SYSDATE, APPLIED_TIME FROM V$LOGSTDBY_PROGRESS;
SYSDATE APPLIED_TIME
------------------ ------------------
27-FEB-10 17:07:06 27-FEB-10 17:06:50
(continued)
4. Query DBA_LOGSTDBY_EVENTS to determine whether there are any DDL and DML
statements that were not applied on the logical standby database:
SELECT EVENT_TIMESTAMP, EVENT, STATUS
FROM DBA_LOGSTDBY_EVENTS
ORDER BY EVENT_TIMESTAMP;
5. Begin a switchover to the upgraded logical standby database by executing the following
statement on the primary database:
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
This statement waits for existing transactions to complete. To minimize the time it takes
to complete the switchover, users connected to the primary database should log off
immediately and reconnect to the standby database.
(continued)
6. Import any tables that were modified during the upgrade from the primary database that
were unsupported in the logical standby database.
7. Complete the switchover by executing the following statement on the logical standby
database:
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL PRIMARY;
After the switchover, you cannot send redo data from the new primary database (using
the new Oracle Database software release) to the new standby database (using the
older Oracle Database software release).
(continued)
8. Upgrade the Oracle Database software on the original primary database to release y.
See the Oracle Database Upgrade Guide for detailed information.
9. Start SQL Apply on the original primary database. You may also need to create a
database link to the new primary database:
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
NEW PRIMARY db_link;
(continued)
10. Monitor events on the new logical standby database by querying the
DBA_LOGSTDBY_EVENTS view.
11. Optional: Perform a switchover to return to the original configuration.
12. Optional: Raise the compatibility level on both databases by setting the COMPATIBLE
initialization parameter on the standby database before you set it on the primary
database.
Performing a Rolling Upgrade by Creating a New Logical Standby Database
1. Identify data types and storage attributes on the primary database that are not supported
in a logical standby database (as described earlier in this lesson).
2. Create a logical standby database (as described in the lesson titled Creating a Logical
Standby Database).
3. Perform a rolling upgrade (as described earlier in this lesson).
Performing a Rolling Upgrade by Using a Physical Standby Database
Note: Use the following technique only when you are upgrading an Oracle Database 11g
database to a later release.
To perform a rolling upgrade when your configuration contains a physical standby database:
1. Prepare the primary database for a rolling upgrade:
a. Enable Flashback Database.
b. Create a guaranteed restore point:
CREATE RESTORE POINT pre_upgrade GUARANTEE FLASHBACK
DATABASE;
Performing a Rolling Upgrade by Using a Physical Standby Database (continued)
2. Convert the physical standby database to a logical standby database. This is only
temporarily done for the duration of the rolling upgrade.
a. Create a logical standby database and execute the following command:
ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;
Note: A logical standby database created with the KEEP IDENTITY clause retains the
same DB_NAME and DBID as those of its primary database.
b. Disable automatic deletion of foreign archived logs at the logical standby database:
execute DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE',
'FALSE');
c. Start SQL Apply:
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
After completing these steps, your original primary database will be the logical standby
database and your original physical standby database will be your primary database with an
upgraded version of the Oracle Database software.
4. Flash back the original primary database to the guaranteed restore point that you
created in step 1.
5. Mount the original primary database using the new version of the software. You will not
run the upgrade scripts because this database will be turned into a physical standby,
and will be upgraded automatically as it applies redo data generated from the new
primary database.
6. Convert the original primary database to a physical standby database:
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SHUTDOWN IMMEDIATE;
7. Start the managed recovery process on the original primary database:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE DISCONNECT FROM SESSION;
8. To perform a switchover to return to your original configuration, execute the following
commands on the new primary database:
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY
WITH SESSION SHUTDOWN;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
On the original primary database, execute the following commands:
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SHUTDOWN IMMEDIATE;
STARTUP
9. Clean up the guaranteed restore point created in step 1.
DROP RESTORE POINT PRE_UPGRADE;
Answer: b
Answer: b
Monitoring the Data Guard Configuration by Using Enterprise Manager Grid
Control
Enterprise Manager Grid Control provides a graphical user interface for monitoring the Data
Guard configuration. The following pages in this lesson describe the information that you can
view on the Data Guard Overview page and its related pages.
Viewing the Data Guard Configuration Status
On the Data Guard Overview page, you can view the status of the primary database and the
standby databases in a configuration. In the Standby Progress Summary section, you can
view information about transport and apply lags.
The apply lag shows the approximate number of seconds that the standby database is behind
the primary database. A large apply lag may indicate that Redo Apply needs to be tuned or
that there is a gap.
The transport lag shows the approximate number of seconds of redo not yet available on the
standby database and provides an indication of potential data loss in the event of a disaster.
A significant transport lag may be caused by:
A gap in the redo
Network bandwidth constraints
An overloaded log writer network server (LNS) process on the primary database
Redo generation that is faster than the LNS and network can handle
I/O issues on the remote file server (RFS) process side
An overloaded RFS process
An inadequate number of standby redo log files causing the RFS process to stall or to
use archived log files
Viewing Data Guard Performance
Click Performance Overview in the Performance section of the Data Guard Overview page to
access the Performance Overview page.
The Performance Overview page displays detailed performance-related statistics for the Data
Guard configuration. The performance charts provide a graphical summary of all redo log
activity in the configuration. You can set the collection interval (which causes the charts to be
refreshed) to determine the rate of sampling of the primary database in the View Data field.
The following charts display performance information for all databases in the configuration:
Redo Generation Rate: Redo generation rate (in KB per second).
Lag Times: Approximate amount of potential data loss. Lag Times -- Shows the
Transport Lag (the approximate number seconds of redo not yet available on the
standby database) and Apply Lag (The approximate number of seconds the standby is
behind the primary database).
Apply Rate: Data applied on each standby database in the configuration. Each point on
the chart represents the amount of redo data that has been applied since the last time it
was refreshed.
Click any of the charts to obtain historical information.
Viewing Log File Details
The Log File Details page displays information about the log files that were generated on the
primary database and received by the standby database. The information is presented in a
tabular format for each standby database in the configuration. The table contains the following
columns:
Log: Contains the log file sequence number
Status: Partially Applied, Not Applied, Not Received
ResetLogs ID: Identifier that changes after a terminal recovery and an open with
RESETLOGS
First Change # (SCN): First system change number (SCN) in the log file
Last Change # (SCN): Last SCN in the log file
Size (KB): Size of the log file
Time Generated: Time at which the log file was generated
Time Completed: Time at which the log file completed
Enterprise Manager Metrics and Alerts
Metrics are units of measurement that are used to assess the health of your system. Each
target comes with a predefined set of metrics.
Metric thresholds are boundary values against which monitored metric values are compared.
Some thresholds are predefined by Oracle; others are not.
When a threshold is reached, an alert is generated to indicate that a particular condition was
encountered. An alert is triggered when one of the following conditions is true:
A threshold is reached.
An alert was cleared.
The availability of a monitored service changes.
A specific condition occurs. (Example: An alert is triggered when an error message is
written to a database alert log file.)
Alerts are detected through a polling-based mechanism by checking for the monitored
condition from a separate process at regular, predefined intervals.
You can associate an alert with a notification, with the automatic execution of a job, and so
on.
Data Guard Metrics
You can use Enterprise Manager to monitor status and log file activity. In addition, Enterprise
Manager automatically monitors the status and archived redo log file activity on the primary
and standby databases and provides the following metrics:
Data Guard Fast-Start Failover: When fast-start failover is enabled, this metric
generates a critical alert on the new primary database if a fast-start failover occurs.
Data Guard Fast-Start Failover Observer: This metric displays the current status of
the fast-start failover observer. A down status triggers an alert. The observer is a
separate OCI client-side component that monitors the availability of the primary
database in a fast-start failover configuration. Fast-start failover is discussed in the
lesson titled Enabling Fast-Start Failover.
Data Guard Performance: This metric provides alerts for performance that is related to
redo log activity in the configuration.
Data Guard Status: This metric checks the status of each database in the broker
configuration and triggers a warning or critical alert if necessary.
You can set up Email Services to send you a message if a metric is triggered. See Oracle
Data Guard Broker for detailed information.
Note: These metrics are seen on the primary database only.
Managing Data Guard Metrics
You can specify that an email notification be sent to you when a Data Guard metric is
triggered. To configure the notification:
1. Configure notification methods in Enterprise Manager.
a. Click Setup at the top of the Database Home page.
b. Click Notification Methods on the Setup page.
c. Enter the appropriate information in the Mail Server section and click Apply. Next,
click Test Mail Servers to verify your configuration.
2. View the All Metrics page by clicking All Metrics in the Related Links section on the
Database Home page. Next, view the Oracle Enterprise Manager metrics, including the
metrics for Data Guard.
3. Set or change Data Guard metric thresholds by clicking Metric and Policy Settings in
the Related Links section on the All Metrics page to access the Metric and Policy
Settings page. On this page, you can set and change the Data Guard Status metric on
the Metrics Thresholds tab.
If a metric condition is triggered or a threshold value is exceeded, an alert is issued. Click
Data Guard Status on the All Metrics page to view triggered metrics. Click the metric, and
then click a particular database to see details.
Viewing Metric Value History
When an alert is triggered, you can view detailed information by clicking the link in the
Message field.
Viewing Data Guard Diagnostic Information
The Data Guard broker records activity information in the Oracle database alert log file and in
the Data Guard broker log files. The broker log files are named drc<$ORACLE_SID>.log
and are located in the same directory as the alert log file.
You can obtain information about the health of the database (referred to as the database
status) by issuing the SHOW DATABASE DGMGRL command.
The following monitorable database properties can be used to query the database status:
StatusReport: Lists all problems detected by the broker during a database health
check
LogXptStatus: Lists all log transport errors detected on all instances of the primary
database
InconsistentProperties: Lists all properties that have inconsistent values between
the broker configuration file and the database settings
InconsistentLogXptProps: Lists all redo transportrelated properties of standby
databases that have inconsistent values between the broker configuration file and the
redo transport settings
Using Monitorable Database Properties to Identify a Failure
You can use the SHOW CONFIGURATION and SHOW DATABASE commands and the
monitorable database properties to identify and determine an appropriate resolution for a
failure in your Database Guard configuration.
1. Use the SHOW CONFIGURATION command to check the status of the configuration.
The status is an aggregated status of all databases and instances in the broker
configuration. If everything is working properly in the configuration, the output of this
command with respect to status is "SUCCESS." If there is a problem in the configuration,
you receive an error message and it will indicate which databases are in warning or
error states.
2. If you receive an error message when you execute the SHOW CONFIGURATION
command, execute the SHOW DATABASE command for each database to view a partial
list of the warnings and errors for the database. For Oracle Database 11g Release 2
(11.2), the SHOW DATABASE command now includes the output from the previous
'SHOW DATABASE <name> StatusReport' command.
3. After viewing the StatusReport output, you can view the other monitorable database
properties: InconsistentProperties, LogXptStatus,
InconsistentLogXptProps.
Using the SHOW CONFIGURATION DGMGRL Command to Monitor the
Configuration
The SHOW CONFIGURATION DGMGRL command provides a brief description of the
configuration, including the state of the configuration, the protection mode, and the state of
fast-start failover. The display also lists the databases that are part of the configuration.
In addition, the current status of the configuration is provided; if there is a problem with the
configuration, a warning message appears. You can investigate the problem as described on
the following slides.
Using the SHOW DATABASE DGMGRL Command to Monitor the Configuration
Use the SHOW DATABASE VERBOSE DGMGRL command to view a brief summary of the
specified database in the broker configuration.
Using the SHOW DATABASE VERBOSE DGMGRL Command to Monitor the
Configuration
Use the SHOW DATABASE VERBOSE DGMGRL command to view a brief summary and the
properties of the specified database.
Viewing Standby Redo Log Information in V$LOGFILE
Obtain information about the standby redo log by querying V$LOGFILE. The STATUS column
contains the following possible values:
INVALID: The file is inaccessible.
STALE: The file contents are incomplete.
DELETED: The file is no longer used.
Null: The file is in use.
Viewing Standby Redo Log Information in V$STANDBY_LOG
Query V$STANDBY_LOG to obtain information about the standby redo log. Columns of interest
include:
GROUP#: Log group number.
DBID: Database ID of the primary database to which the standby redo log file is
assigned. If the standby redo log file is unassigned, the value UNASSIGNED is displayed.
ARCHIVED: Contains a value of YES or NO. See STATUS for additional information.
STATUS: Contains a value of UNASSIGNED or ACTIVE.
- UNASSIGNED: If the value of ARCHIVED is NO, the standby redo log was archived
and is again available. If the value of ARCHIVED is YES, the standby redo log was
never used and is available.
- ACTIVE: If the value of ARCHIVED is NO, the standby redo log is complete and
waiting to be archived. If the value of ARCHIVED is YES, the standby redo log is
currently being written to and is not ready to be archived.
Identifying Destination Settings
The VALID_NOW column in V$ARCHIVE_DEST indicates whether the archive log destination
is used. The column contains the following values:
YES: The archive log destination is appropriately defined for the current database role.
WRONG VALID_TYPE: The archive log destination is appropriately defined for the current
database role but cannot be used. For example, LOG_ARCHIVE_DEST_2 is set to
(STANDBY_LOGFILES,STANDBY_ROLE), but WRONG VALID_TYPE is returned because
this standby destination does not have an implemented standby redo log.
WRONG VALID_ROLE: The archive log destination is not appropriately defined for the
current database role. For example, LOG_ARCHIVE_DEST_3 is set to
(ONLINE_LOGFILES,STANDBY_ROLE), but WRONG VALID_ROLE is returned because
this destination is currently running in the primary database role.
UNKNOWN: The archive log destination is not defined.
The VALID_TYPE and VALID_ROLE columns are the values from the VALID_FOR attribute
that is specified for each archive log destination.
Setting the LOG_ARCHIVE_TRACE Initialization Parameter
Set this parameter to trace the transmission of redo data to the standby system.
To enable, disable, or modify the LOG_ARCHIVE_TRACE parameter in a primary database,
issue the ALTER SYSTEM SET LOG_ARCHIVE_TRACE=trace_level statement while the
database is open or mounted. If you change the value of this parameter dynamically with an
ALTER SYSTEM statement, the changes take effect at the start of the next archive operation.
See Oracle Data Guard Concepts and Administration for additional information.
Monitoring Redo Apply by Querying V$MANAGED_STANDBY
Query V$MANAGED_STANDBY to view information about Redo Apply and redo transport status
on a physical standby database. See the Oracle Database Reference for detailed information
about the values in each column.
Evaluating Redo Data by Querying V$DATAGUARD_STATS
Query V$DATAGUARD_STATS to evaluate each standby database in terms of the currency of
the data in the standby database and the time it takes to perform a role transition if all
available redo data is applied to the standby database.
V$DATAGUARD_STATS displays the amount of redo data generated by the primary database
that is not yet available on the standby database. This information enables you to determine
how much redo data would be lost if the primary database were to crash when you queried
this view.
See the Oracle Database Reference for detailed information about column values.
Viewing Data Guard Status Information by Querying V$DATAGUARD_STATUS
Query V$DATAGUARD_STATUS to view messages that were recently written to the alert log or
server process trace files that concern physical standby databases or redo transport services
for all standby database types.
See the Oracle Database Reference for detailed information about column values.
Viewing V$LOGSTDBY_TRANSACTION
Query V$LOGSTDBY_TRANSACTION to view information about the transactions that are
actively being processed by SQL Apply. The transaction identifiers shown in this view
correspond to transaction identifiers assigned at the primary database and do not correspond
to the transactions that are active at the logical standby database. Query the
V$TRANSACTION view on the logical standby database for information about transactions that
are active in the logical standby database, including those that were created as part of SQL
Apply.
Answer: a
Answer: b
Monitoring Configuration Performance by Using Enterprise Manager Grid Control
Graphical charts on the Performance Overview page:
Redo Generation Rate: Shows the redo generation rate (in KB per second) on the
primary database.
Apply Rate: Shows the apply rate (in KB per second) on the standby database. The
Apply Rate When Active statistic indicates the actual apply rate averaged over the last
three log files.
Lag Time: Shows the transport lag and apply lag. Transport lag is the approximate
amount of redo (in seconds) that is not yet available on the standby database. Apply lag
is the approximate number of seconds by which the standby database is behind the
primary database.
On the Performance Overview page, you can invoke a test application to generate a workload
on the primary database. This provides a way to view performance metrics when the primary
database is operating under a load.
Optimizing Redo Transport Services
Information about these techniques is provided in the following slides.
Setting the ReopenSecs Database Property
When you specify a value for the ReopenSecs database property, it is propagated to the
REOPEN attribute of the LOG_ARCHIVE_DEST_n initialization parameter for your primary
database. The REOPEN attribute of the LOG_ARCHIVE_DEST_n parameter specifies the
minimum number of seconds before the process that is shipping the redo should try again to
access a previously failed destination.
REOPEN applies to all errors and not only connection failures. These errors include (but are
not limited to) network failures, disk errors, and quota exceptions.
Setting the NetTimeout Database Property
When you specify a value for the NetTimeout database property, it is propagated to the
NET_TIMEOUT attribute of the LOG_ARCHIVE_DEST_n initialization parameter for your
primary database. The NET_TIMEOUT attribute enables you to bypass the default network
timeout interval that was established for the system on which the primary database resides.
Without the NET_TIMEOUT attribute, the primary database can potentially stall for the default
network timeout period. By specifying a smaller, nonzero value for NET_TIMEOUT, you can
enable the primary database to mark a destination as failed after the user-specified timeout
interval expires.
Note: Remember to specify a reasonable value when running in maximum protection mode.
False network failure detection may cause the primary instance to shut down if there are no
other standby databases in the correct mode that can be contacted by the primary database
instance.
Optimizing Redo Transmission by Setting MaxConnections
The redo transport mechanism uses all available bandwidth by allowing a single large redo
log file to be transferred in parallel by multiple archiver processes. This behavior is controlled
by the MaxConnections database property.
This architecture increases the redo transfer rate and enables faster redo transmission to
standby databases for bulk batch updates on the primary database. As a result of the
improvement in transfer rates, there is an increased availability of data at the standby
database site.
Setting the MaxConnections Database Property
When you specify a value for the MaxConnections database property, it is propagated to
the MAX_CONNECTIONS attribute of the LOG_ARCHIVE_DEST_n initialization parameter for
your primary database. The MAX_CONNECTIONS attribute of LOG_ARCHIVE_DEST_n is used
to set the number of parallel connections that are used for transmitting archived redo log files
to a remote destination. The MAX_CONNECTIONS attribute defaults to 1, indicating that a
single connection is established for the communication and transfer of data. The maximum
value for MAX_CONNECTIONS is 5.
Note: You must set the LOG_ARCHIVE_MAX_PROCESSES initialization parameter to be
greater than or equal to the value of MAX_CONNECTIONS to achieve the desired number of
parallel connections. If the value of the MAX_CONNECTIONS attribute exceeds the value of
LOG_ARCHIVE_MAX_PROCESSES, Data Guard uses the available archiver processes.
Compressing Redo Data
When the communication network to remote databases is a high-latency, low-bandwidth WAN
link and the redo data that is transferred to standby databases is substantial, you want to
make the most effective use of network bandwidth. Redo transport compression can be
enabled on any remote destination for all redo transport methods to reduce network
bandwidth usage.
Redo compression can be enabled or disabled by setting the Oracle Data Guard brokers
RedoCompression property. The setting is propagated to the COMPRESSION attribute of the
LOG_ARCHIVE_DEST_n initialization parameter. Redo compression is disabled by default. All
databases in a Data Guard configuration must use Oracle Database 11g to enable redo
transport compression.
When you add a database to the Data Guard configuration, the Data Guard broker
automatically detects whether network compression is enabled or disabled for the standby
database being added. The property is set accordingly.
Note: Use of this feature requires the Oracle Advanced Compression option.
Delaying the Application of Redo
You can delay the application of changes to standby databases, thereby providing protection
from user errors and corruptions. You can protect against the application of corrupted or
erroneous data to the standby database. The apply process also revalidates the log records
to prevent application of log corruptions.
For example, if a critical table is accidentally dropped from the primary database, you can
prevent this action from affecting the standby database by delaying the application of the
change in the standby database.
When operating in maximum protection or maximum availability mode, Data Guard ensures
zero data loss even with the delayed apply in effect.
If you define a delay for a destination that has real-time apply enabled, the delay is ignored.
Note: You can use Flashback Database as an alternative to the Apply Delay configuration
option. Flashback database is an Oracle best practice. See the lesson titled Using Flashback
Database in a Data Guard Configuration for additional information.
Setting the DelayMins Database Property to Delay the Application of Redo
Use the DelayMins configurable database property to specify the number of minutes that log
apply services must wait before applying redo data to the standby database. This setting is
propagated to the DELAY attribute of the LOG_ARCHIVE_DEST_n initialization parameter.
Using Enterprise Manager to Delay the Application of Redo
1. On the Data Guard page, select your standby database and click Edit.
2. On the Edit Standby Database Properties page, click Standby Role Properties.
3. In the Apply Delay field, enter the delay value (in minutes).
4. Click Apply.
Optimizing SQL Apply
The MAX_SERVERS, APPLY_SERVERS, and PREPARE_SERVERS parameters can be modified
to control the number of processes that are allocated to SQL Apply. Because SQL Apply
allocates one process for the READER, BUILDER, and ANALYZER roles, the following
relationship between the three parameters is required:
APPLY_SERVERS + PREPARE_SERVERS = MAX_SERVERS 3
Use the DBMS_LOGSTDBY.APPLY_SET procedure to change the APPLY_SERVERS,
MAX_SERVERS, and PREPARE_SERVERS parameters.
Query DBA_LOGSTDBY_PARAMETERS to view the SQL Apply parameter settings.
Note: See the Oracle Database PL/SQL Packages and Types Reference for detailed
information about the DBMS_LOGSTDBY.APPLY_SET procedure. Also consult the "SQL Apply
Best Practices: Oracle Data Guard 11g Release 1" whitepaper found at:
http://www.oracle.com/technology/deploy/availability/pdf/maa_wp_11gr1_sqlapplybestpractices.pdf
Adjusting the Number of APPLIER Processes
Before changing the number of APPLIER processes, perform the following steps to determine
whether adjusting the number of APPLIER processes will help you achieve greater
throughput:
1. Determine if APPLIER processes are busy by issuing the following query:
SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS
WHERE TYPE = 'APPLIER' and status_code = 16166;
2. After ensuring that there are no idle APPLIER processes, determine if there is enough
work available for additional APPLIER processes by issuing the following query:
SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME LIKE 'transactions%';
The second query returns two statistics that provide a cumulative total: the number of
transactions that are ready to be applied by the APPLIER processes and the number of
transactions that have already been applied. If the difference between "transactions mined"
and "transactions applied" is higher than twice the number of available APPLIER processes,
an improvement in throughput is possible if you increase the number of APPLIER processes.
Before you increase the number of APPLIER processes, consider the following requirement:
Adjusting the Number of PREPARER Processes
On rare occasions, you may need to adjust the number of PREPARER processes. Before
increasing the number of PREPARER processes, verify that the following conditions are true:
All PREPARER processes are busy.
The number of transactions ready to be applied is less than the number of available
APPLIER processes.
There are idle APPLIER processes.
Perform the following queries to verify the preceding conditions:
1. Determine if all PREPARER processes are busy:
SELECT COUNT(*) AS IDLE_PREPARER
FROM V$LOGSTDBY_PROCESS
WHERE TYPE = 'PREPARER' and status_code = 16166;
2. Determine if the number of transactions ready to be applied is less than the number of
APPLIER processes:
SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME LIKE 'transactions%';
SELECT COUNT(*) AS APPLIER_COUNT
FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER';
Adjusting the Number of PREPARER Processes (continued)
3. Determine if there are idle APPLIER processes:
SELECT COUNT(*) AS IDLE_APPLIER
FROM V$LOGSTDBY_PROCESS
WHERE TYPE = 'APPLIER' and status_code = 16166;
Before you increase the number of PREPARER processes, consider the requirement:
You may need to increase the value of MAX_SERVERS before increasing the value of
PREPARE_SERVERS.
Use the DBMS_LOGSTDBY.APPLY_SET procedure to increase the values of MAX_SERVERS
and PREPARE_SERVERS, as shown in the following example:
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS', 26);
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS', 3);
Answer: a
Answer: b

Data Guard 11g

Uploaded by

Document Information

Original Description:

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

Data Guard 11g

Uploaded by

Copyright:

Available Formats

<Course title here>

Configurable Failover Conditions

You might also like