Contents

Introduction

Oracle Data Guard (known as Oracle Standby Database prior to Oracle9i),
forms an extension to the Oracle RDBMS and provides organizations with
high availability, data protection, and disaster recovery for enterprise
databases. Oracle Data Guard provides the DBA with services for creating,
maintaining, managing, and monitoring one or more standby databases. The
functionality included with Oracle Data Guard enables enterprise data systems
to survive both data corruption as well as major disasters.

Oracle9i Release 2 was greatly enhanced with new features and functionality
to not only enable better flexibility, but to also make it easier for the DBA to
build a stable and available infrastructure. One of those new features in
Oracle9i Release 2 is the ability for the DBA to place the database into
one of the following protection modes:

Maximum Protection

Maximum Availability

Maximum Performance

These three new modes replace the guaranteed, instance, rapid, and delayed modes of
data protection available in Oracle9i Release 1 (9.0.1).

Data Guard protection modes are simply a set of rules that the primary database must
adhere to when running in a Data Guard configuration. A protection mode is only set
on the primary database and defines the way Oracle Data Guard will maximize a Data Guard
configuration for performance, availability, or protection in order to achieve the maximum
amount of allowed data loss that can occur when the primary database or site fails.

A Data Guard configuration will always run in one of the three protection modes listed
above. Each of the three modes provide a high degree of data protection; however they differ
with regards to data availability and performance of the primary database.

When selecting a protection mode, always consider the one that best meets the needs of your
business. Carefully take into account the need to protect the data against any loss vs. availability
and performance expectations of the primary database. This article will explain the new
protection modes available
in Oracle9i Release 2, how Log Transport Services works to support them, and
finally the steps necessary to configure the standby database to the desired protection mode.

The SYNC attribute with the LGWR process specifies that network I/O is to be
performed synchronously for the destination. This means that once the I/O (redo data) is
initiated, the archiving process waits for the I/O to complete before continuing. When specifying
the SYNC attribute, all network I/O operations are performed synchronously, in conjunction
with each write operation to the online redo log. The transaction is not committed on the primary
database until the redo data necessary to recover that transaction is received by the destination.

It is highly recommended that a Data Guard configuration
operating in Maximum Protection mode contain at least two physical standby
databases that meet the requirements listed in the table above. That way,
the primary database can continue processing if one of the physical standby
databases cannot receive redo data from the primary database. If only one standby
database is configured with the minimum requirements listed above, the
primary database will shut down when the physical standby
databases cannot receive redo data from the primary database!

LGWR / ASYNC vs. ARCH

When configuring log transport services to use LGWR and remotely archive in ASYNC
mode, the LGWR process does not wait for each network I/O to complete before proceeding.
This behavior is made possible by the use of an intermediate process, known as a
Log Writer Network Server Process (LNS), which performs the actual network I/O and
waits for each network I/O to complete. Each LNS has a user configurable buffer that is
used to accept outbound redo data from the LGWR process. This is configured by specifying
the size (in 512 byte blocks) on the ASYNC attribute in the archivelog parameter for the standby destination service.
For example, ASYNC=2048 indicates a 1MB buffer. As long as the LNS process is able
to empty this buffer faster than the LGWR can fill it, the LGWR process will never
stall. If the LNS cannot keep up, then the buffer will become full and the LGWR
process will stall until either sufficient buffer space is freed up by a successful network
transmission or a timeout occurs.

When configuring log transport services to remotely archive using the ARCH
attribute, redo logs are transmitted to the destination only during an archival operation.
This means that the standby database does not receive any redo data until the primary database
fills its current online redo and archives it. The data received and applied to the standby
database is only as current as the last archived redo log sent from the primary database.
The background archiver processes (ARCn) or a foreground archival process operation
serves as the redo log transport service. Using ARCH to remotely archive redo data
does not impact the primary database throughput as long as enough redo log groups exist so
that the most recently used group can be archived before it must be reopened.

Take note of the following important points to understand when configuring the standby database:

The standby database that is used to satisfy the minimum requirements for a given
protection mode must be enabled and ready to receive redo data from the primary database
before you can switch to that mode.

When archiving to a physical standby destination using the LGWR process, changes
(transactions) being made and committed on the primary database are not instantly written
to the actual database files on the standby database. In Oracle9i Release 2 and higher,
when log transport services is configured for Maximum Availability mode or Maximum Protection
mode, the LGWR process on the primary database will send redo data to the
standby redo logs (located on the standby database) at the same time it is writing redo
data to the local (online) redo logs. Keep in mind that the LGWR process is actually
communicating with a Remote File Server (RFS) process on the standby database server.
This RFS process on the standby database is responsible for capturing and writing the redo
data it obtains from the primary database to the standby redo logs (LGWR) or the
standby archived redo logs (ARCn).

The Remote File Server process runs on the standby database and can receive redo data over
the network from both LGWR and ARCn. The RFS process will write the redo
data it receives to either a standby redo log or to a standby archived redo log.

When a log switch occurs on the primary database, a log switch is also triggered on the
standby database where the ARCH process then archives the standby redo logs to the
archive destination specified on the standby database. After the archival process has completed
on the standby database, the Managed Recovery Process (MRP) then writes the changes to the
actual database files from the archived redo log files.

Why is this important to point out?
It illustrates the fact that the actual changes (transactions) being made and committed on the
primary database do indeed make it over to the standby database, but get applied to the
standby redo logs. In Oracle9i, these changes are only made to the actual database files
on the standby database when a log switch occurs on the primary. In Oracle Database 10g,
a new feature called real-time apply can be enabled which tells log apply services to
apply redo data to the database files on the standby database as it is received, without waiting
for the current standby redo log file to be archived. This results in faster switchover and
failover times because the standby redo log files have been applied already to the standby
database by the time the failover or switchover begins.

To enable the real-time apply feature on the standby database, use the following
ALTER DATABASE statement:

When using standby redo logs, you must ensure the archiver process (ARCn) is enable
on the standby database. Prior to Oracle Database 10g, it was required to set the
log_archive_start initialization parameter to TRUE in order to enable
automatic archiving. This is no longer necessary as automatic archiving is enabled by
default when the database is placed into archivelog mode with Oracle Database 10g or higher.

Upgrading the Protection Mode

Use the following steps to upgrade the protection mode from the default of Maximum Performance.

Both of the higher protection modes (Maximum Availability and Maximum Protection)
require the use of standby redo logs on the destination standby database. If standby
redo logs do not exist for the standby database, create them now.

Ensure that the attributes for LOG_ARCHIVE_DEST_n are
configured on the primary instance to support the desired
protection mode. Also note that the destination standby database
should be enabled to support the target protection mode as
documented in this article.

For the mode of Maximum Protection,
the standby database must be up and mounted!

Set the LOG_ARCHIVE_DEST_n initialization parameter on the
primary database to support the required protection mode:

[Connect to the primary database]
SQL> connect sys/change_on_install@testdb_vmlinux3.idevelopment.info as sysdba[Configure log transport services to support the desired protection mode]
SQL> alter system set log_archive_dest_2='service=testdb_vmlinux4.idevelopment.info LGWR SYNC AFFIRM';
SQL> alter system set log_archive_dest_state_2=enable;

The primary database will need to be closed and then placed in the MOUNT stage.

SQL> shutdown immediate
SQL> startup mount

On the primary database, change the protection mode and open the database:

(Optional) Although the steps in this
section are optional, there are highly recommended so that the primary
database can easily and quickly switchover to a standby role without the need
for DBA intervention. For example, standby redo logs are only used on the
physical standby database; however, creating and having standby redo logs
ready to go on the physical primary database makes role transition much
easier if the primary would every have to become the standby:

Configure the attributes for LOG_ARCHIVE_DEST_n on the primary instance to
support the new desired protection mode:

[Connect to the primary database]
SQL> connect sys/change_on_install@testdb_vmlinux3.idevelopment.info as sysdba[Configure log transport services to support the desired protection mode]
SQL> alter system set log_archive_dest_2='service=testdb_vmlinux4.idevelopment.info ARCH';
SQL> alter system set log_archive_dest_state_2=enable;

Both of the higher protection modes (Maximum Availability and Maximum Protection)
require the use of standby redo logs on the destination standby database. It you were
to downgrade from Maximum Protection mode to Maximum Availability mode, you would
need to keep the standby redo logs that exist for the standby database. If
downgrading to Maximum Performance mode, you can drop the standby redo logs
from the standby unless you are going to be configuring log transport services
to use LGWR. For this example, I am going to be downgrading to maximum
performance mode and using ARCH for log transport services and can
therefore drop any standby redo logs from the standby database (and the primary if
they exist):

About the Author

Jeffrey Hunter is an Oracle Certified Professional, Java Development Certified Professional, Author,
and an Oracle ACE.
Jeff currently works as a Senior Database Administrator for
The DBA Zone, Inc. located in Pittsburgh, Pennsylvania.
His work includes advanced performance tuning, Java and PL/SQL programming, developing
high availability solutions, capacity
planning, database security, and physical / logical database design in a UNIX /
Linux server environment. Jeff's other interests include mathematical
encryption theory, tutoring advanced mathematics, programming language processors (compilers and interpreters)
in Java and C, LDAP, writing web-based database administration tools, and of
course Linux. He has been a Sr. Database Administrator and Software Engineer
for over 20 years and maintains his own website site at:
http://www.iDevelopment.info.
Jeff graduated from Stanislaus State University in Turlock,
California, with a Bachelor's degree in Computer Science and Mathematics.

Copyright (c) 1998-2017 Jeffrey M. Hunter. All rights reserved.

All articles, scripts and material located at the Internet address of http://www.idevelopment.info is the copyright of Jeffrey M. Hunter
and is protected under copyright laws of the United States. This document may not be hosted on any other site without my express,
prior, written permission. Application to host any of the material elsewhere can be made by contacting me at jhunter@idevelopment.info.

I have made every effort and taken great care in making sure that the material included on my web site is technically accurate,
but I disclaim any and all responsibility for any loss, damage or destruction of data or any other property which may arise from
relying on it. I will in no case be liable for any monetary damages arising from such loss, damage or destruction.