Logical Standby Unleashed

An Oracle White Paper

September 2005
NOTE:
The following is intended to outline our general product
direction. It is intended for information purposes only, and
may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality,
and should not be relied upon in making purchasing
decisions. The development, release, and timing of any
features or functionality described for Oracle’s products
remains at the sole discretion of Oracle.
 Logical Standby Unleashed

Note:.................................................................................................................... 1
Executive Overview.......................................................................................... 3
Introduction To Data Guard........................................................................... 3
Customer Requirements................................................................................... 4
Best Practices for Meeting Requirements...................................................... 5
A User Example............................................................................................ 5
Meeting the Recovery Point Objective...................................................... 7
Configuring Maximum Availability Protection Mode ............................................... 7
Creating the Data Guard Configuration .............................................................. 10
Meeting the Server Recovery Time Objective........................................ 10
Real Application Clusters ................................................................................. 10
Meeting the Site Recovery Time Objective............................................. 11
Configuring Real-Time Apply ........................................................................... 11
Large Object Performance Enhancements ........................................................... 12
Other Performance Enhancements .................................................................... 13
New Metrics to Monitor your RPO and RTO ...................................................... 13
Fast-start Failover ........................................................................................... 14
Meeting the High Availability Objective ................................................. 17
Zero Downtime Instantiation ........................................................................... 17
Rolling Oracle Upgrades .................................................................................. 20
Conclusion........................................................................................................ 22
Additional References..................................................................................... 22

Logical Standby Unleashed Page 2

 Logical Standby Unleashed

EXECUTIVE OVERVIEW
This paper provides an in-depth review of Data Guard SQL Apply (Logical standby
database) utilizing significant new features in Oracle Database 10g. This paper
presents a strategy where SQL Apply is a significant element of a Business
Continuity strategy. This session will share best practices and user experience
deploying SQL Apply. Oracle Data Guard 10g Release 1 capabilities discussed
include: Zero Downtime standby instantiation, Zero Data Loss, Real Time Apply
and SQL Apply performance enhancements and improved LOB handling. This
paper also covers new Oracle Data Guard 10g Release 2 SQL Apply enhancements
that include new metrics to visibly verify that the service level agreements are being
met, automatic failover and reinstatement of the original primary, rolling upgrades
for database patch sets and major releases and improved manageability.

INTRODUCTION TO DATA GUARD

Oracle Data Guard is Oracle’s disaster recovery solution for data protection and
business continuity in the event of unplanned outages of any kind. In addition,
Data Guard provides significant capabilities for minimizing outages incurred during
planned downtime events for system maintenance or database upgrades.
There are two types of standby databases. A Physical Standby database maintains a
physical replica of the primary database. The Oracle technology utilized leverages
capabilities that are time-tested and Physical Standby databases are the
overwhelming favorite within the user community for disaster recovery protection
for Oracle databases.
A Logical Standby database, also referred to as SQL Apply, maintains a logical
replica of the primary database instead of an identical, block level replica. It does,
however, offer unique capabilities as a Disaster Recovery solution where the
standby database can be open for read access while updates received from the
primary database are being applied. This capability enables Logical Standby
databases to address both high availability and disaster recovery requirements, with
a high degree of asset utilization. This paper focuses on the use of Logical Standby
for such a purpose.

Logical Standby Unleashed Page 3

CUSTOMER REQUIREMENTS
While there are many requirements that the Data Guard user must meet to enable
them to meet their Service Level Agreements, there are several possible levels of
protection for each requirement depending on the application to be protected. The
following are Business Continuity requirements that are typical for the SQL Apply
customers with mission critical applications:
• Recovery Point Objective (RPO) is zero. RPO measures the maximum
allowable data loss following a failure. This means zero data loss must be the
result from any failure caused by data corruptions or storage failure, complete
site failure, or any other event that makes the primary site unavailable.
• Server Recovery Time Objective (RTO). In the event of server or database
instance crash RTO is zero. RTO measures the maximum time allowed
before access to data is restored following a failure.
• Site Recovery Time Objective (RTO). In the event of complete site failure or
database failure, RTO depends upon the type of user activity.
o For users requiring read access, RTO is zero. This means read
access to the standby database must be enabled while it is in
standby role. Upon any failure of the primary site, online clients
must be able to automatically reattach and continuously query an
up-to-date replica of the primary databases.
o For users requiring read/write access to the production database,
RTO is a maximum of 5 minutes to effect the complete transition
of the standby database to the primary role. It is understood that
the decision to execute a complete role transition trumps the
previous RTO for read access. The implication here is that in the
event of site failure, users can continue to have read access to up-
to-date data while the administrative staff determine if it is more
desirable to correct the failure and bring the primary system back
online, or execute a complete transition of the standby database
to the primary role.
• High Availability Objective (HAO) The database at the standby site must be
current with transactions occurring at the primary location and continuously
open for read access. This allows for the standby resource to be available for
query and reporting at all times.1 In addition to the Server and Site RTO in
case of a failure, the database must also be minimally affected by any kind of
update to the system and/or database.

1 Maximum latency between a transaction on the production database and the result of

that transaction appearing in the standby database must not exceed 5 seconds.

Logical Standby Unleashed Page 4

BEST PRACTICES FOR MEETING REQUIREMENTS
Oracle’s Maximum Availability Architecture (MAA) [1], the Oracle blueprint for
implementing highly available computing environments, addresses a broad range of
requirements including those described above.
Case studies detailing customer implementations using Oracle high availability
technologies are available on the Oracle Technology Network [4].
Before going into an in-depth review of the technologies and approach used to
satisfy the requirements listed in the previous section, it is helpful to understand
how one particular customer, Thomson Legal and Regulatory, has actually put these
Oracle capabilities into practice.

A User Example
Thomson Legal & Regulatory is a subsidiary of The Thomson Corporation and a
global provider of integrated information solutions to legal, tax, accounting,
intellectual property, compliance, and business and government professionals.
Thomson Legal & Regulatory serves more than 1 million customers world wide
including all of the top 100 global law firms and all “Big 4”accounting firms. More
than 120,000 daily online users access over 53 million web site page views each
month. Headquartered in Eagan, MN, Thomson Legal and Regulatory maintains
two world-class data centers with over 200,000 square feet, 700 TB of enterprise
class storage, and eight diesel generators with 16MW of power backup.
In addition to sharing many of the same business continuity requirements discussed
above, their database technology challenges also include:
• Making solutions incrementally scalable
• Insuring a scaling strategy transparent to applications and developers
• Not sacrificing performance
• Improving workload management capabilities
• Making the environment easy to setup and administer
• Making it cheaper.

Logical Standby Unleashed Page 5

 Thomson Legal & Regulatory has implemented MAA using Oracle Database 10g
SYSTEM & NETWORK
CONFIGURATION Release 1 for a large and dynamic repository of legal documents accessed by online
subscribers. Oracle Real Application Clusters (RAC) [2] and Oracle Data Guard
4-node RAC Primary, IBM E325 Servers
(each with 2 CPUs and 12GB RAM) SQL Apply [3] are used to protect against outages caused by data corruptions or
human error, as well as server, site, or network failures.
4-node RAC Standby, IBM E325 Servers
(each with 2 CPUs and 12GB RAM)
Online Users
SUSE9 64bit (United Linux 1.0)

NetApp Storage Site A Site B

Primary Location Standby Location
Gigabit network connecting primary and
standby locations located within 25 miles of
each other.

Oracle Database10g Release 1 SQL Apply

Zero Data Loss - Maximum Availability

(LGWR SYNC AFFIRM)

Real Time Apply

500GB database growing to 3TB

LGWR SYNC
Data Guard
2.8MB/sec peak redo generation
Primary Database Standby Database
Read Write Read
LOB intensive workload. Average LOB size 4-
RAC SQL/Apply & RAC
8k, but 5% of workload is comprised of LOBs
greater than 1MB in size

Figure 1: Two Site Architecture

The solution chosen by Thomson Legal & Regulatory is a GRID architecture

utilizing RAC and Data Guard SQL Apply, all running on inexpensive commodity
hardware (Figure 1). The remainder of this paper discusses the various elements of
this kind of architecture in greater depth.

Logical Standby Unleashed Page 6

Meeting the Recovery Point Objective
Data Guard provides several different protection modes so that user can adjust the
level of data protection to address different Service Level Agreements (SLA) and
widely varying system and network environments. Configuring Data Guard in
Maximum Availability Mode enables a zero data loss protection without
compromising the availability of the primary database – meeting the requirements
articulated in the introduction to this paper.
In the Maximum Availability protection mode, Data Guard transport services
synchronously ship all redo generated by the primary database to the standby
location. A primary database transaction will not commit until the redo needed to
recover the transaction is written on disk at the standby server guaranteeing that the
data is protected.
Several significant details of a Data Guard SQL Apply configuration are described
below. For a complete understanding of how to set up Data Guard SQL Apply,
please refer to the Oracle Data Guard Concepts and Administration [6] manual and
additional best practice recommendations provided in the Oracle Database 10g
Best Practices: Data Guard SQL Apply [7] paper.
Note that in the configuration shown in Figure 1, the standby system is comprised
of a 4-node RAC cluster that is identical to the primary production system.
Although this is considered a Best Practice, Data Guard does not require the
standby configuration to be identical to the primary. Many users allocate fewer
resources to the standby server, accepting less performance for the duration of
switchover or failover. The network between the primary and standby site must be
sufficient to accommodate the redo generated by the primary database. Reference
the Data Guard Primary Site And Network Best Practices [5] paper for more
information.

Configuring Maximum Availability Protection Mode

The Data Guard Maximum Availability protection mode enables zero data loss by
transmitting redo data in a synchronous fashion to remote destinations as it is being
written to online redo log files on the primary production server.
Figure 2 describes the Data Guard Maximum Availability process architecture. It
begins with a transaction on the primary database where the LGWR process writes
the resulting redo to an online redo logs on the primary server. A Data Guard
process named Logwriter Network Server (LNS), synchronously ships the redo to
the standby server. A second Data Guard process running on the standby, the
Remote File Server (RFS) process, receives the redo data, writes it to a standby redo
log, and sends an acknowledgement back to the primary that it has been received
and written to disk. When the primary database receives this acknowledgement, it
acknowledges the commit to the client application and processes the next
transaction. .

Logical Standby Unleashed Page 7

 Transactions

SQL
LGWR LNS RFS Apply

Standby
Online Redo Logs
Redo
Primary Logs Standby
Database Database

ARCH ARCH

Archived
Archived
Redo Logs
Redo Logs

Oracle Net Services

Figure 2 – Data Guard Maximum Availability Process Architecture

The Maximum Availability protection mode requires that one standby be defined
and enabled using synchronous redo transport. The following
LOG_ARCHIVE_DEST attributes enable Maximum Availability protection mode:

LGWR SYNC AFFIRM REOPEN=10 NET_TIMEOUT=30

• The SYNC attribute tells Data Guard to perform all network I/O
synchronously for this standby, in conjunction with each write operation
to the local online redo log file.
• The AFFIRM attribute insures that transactions are not acknowledged as
committed by the primary database until the redo data necessary to
recover the transactions has been written to the standby redo log at the
remote destination.
• The REOPEN=10 attribute specifies that the LGWR should not try to
reconnect to a standby that was previously disconnected (due to a network
failure, standby node failure, etc.) at the next log switch if that log switch
occurs in less than 10 seconds. If not specified, the default wait for
reopen is 300 seconds.
• The NET_TIMEOUT=30 attribute specifies the number of seconds (30
seconds in this case), that the LGWR process on the primary system will
wait for a reply from the standby server before terminating the network
connection and continuing processing on the primary server.

Logical Standby Unleashed Page 8

 Following any loss of connection to the standby server, Data Guard
continually monitors the status of the standby server and automatically
resynchronizes the standby database with the primary database once it
becomes available. The default value for NET_TIMEOUT is 180 seconds;
the minimum value that can be set is 1 second.
In order to prepare for an eventual switchover the transport parameters are
modified to take advantage of the VALID_FOR and DB_UNIQUE_NAME
capabilities, new with Oracle Database 10g Release 1.
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=wlp01a
The VALID_FOR attribute enables the configuration of destination attributes for
both the primary and standby database roles so that the Data Guard configuration
will operate properly after a role transition. This simplifies switchovers and
failovers because it is no longer necessary to enable and disable role-specific
archiving destinations after performing a database role transition.
The complete redo services parameter is defined as follows on both the Primary
database and the Logical standby database with the only difference being the TNS
service name.
log_archive_dest_2='SERVICE=WLP01A LGWR SYNC
AFFIRM REOPEN=10 NET_TIMEOUT=30
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=wlp01a'

To complete the configuration and enable a handshake between the two databases
the LOG_ARCHIVE_CONFIG parameter is added to both databases.
log_archive_config='DG_CONFIG=(wlp01a,wlp01z)'

Standby Redo Log Files (SRL), required for zero data loss protection, can be added
once the appropriate redo transport attributes have been set. The Standby Redo
Log files are only used by a standby database, but are configured on both primary
and standby databases in preparation for future role transitions.
The following statement is an example of adding a group of standby redo log files
to a standby database:
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2
2 ('/oradata/log1a.rdo') SIZE 500M;
The THREAD clause is required only to add one or more standby redo log file
groups to a specific primary database thread. If the THREAD clause is not used,
and the standby configuration uses Real Application Clusters (RAC), Data Guard
automatically assigns standby redo log file groups to threads at runtime, as they are

Logical Standby Unleashed Page 9


MANAGEMENT OPTIONS
SQL*Plus: Management of individual
systems in a Data Guard configuration
DGMGRL: A command line interface,
centrally managing all systems in a Data
Guard configuration.
EM GRID Control: Powerful browser-based
interface for centrally managing one or more
Data Guard configurations. Easiest to use.
Mouse driven, automated configuration
creation, management & control.
needed by the various primary RAC instances. It is best practice to always assign
the standby redo logs to specific threads
Finally, with the databases ready to support the Zero Data Loss mode of Maximum
Availability, set Maximum Availability protection mode with the following simple
command on the primary database in the mount state:
SQL> ALTER DATABASE SET STANDBY DATABASE
2 TO MAXIMIZE AVAILABILITY;
Creating the Data Guard Configuration
Data Guard users have a choice of three interfaces for creating and managing a
Data Guard configuration:
• SQL*Plus.
• Data Guard Broker (DGMGRL command line interface). The Broker enables
single commands, each of which executes the equivalent work of multiple
SQL*Plus statements, simplifying the management of a Data Guard
configuration. The Broker also provides centralized management of all
resources within a Data Guard configuration.
• Oracle Enterprise Manager (EM) 10g Grid Control enables centralized
management of all resources in one or more Data Guard configurations.
Enterprise Manager also includes a standby creation wizard that completely
automates the creation of a Data Guard configuration. Enterprise Manager
further enhances ease of use by providing a powerful browser based interface
with mouse-click management, monitoring, and control.
Meeting the Server Recovery Time Objective
In a Mission Critical environment it is necessary to ensure that a single server
failure will not completely stop production. Clusters of various sorts have been
used to meet this requirement and, as you can see above, Oracle’s Real Application
Cluster technology was used to meet challenge.
Real Application Clusters
In a RAC environment Oracle runs on two or more systems in a cluster while
concurrently accessing a single shared database. This provides a single database
system that spans multiple hardware systems, yet appears to the application as a
single unified database system. This transparently extends availability and scalability
benefits to all applications:
• Fault tolerance to server failures within the cluster.
• Flexibility and cost effectiveness in capacity planning, so that a system can
scale to any desired capacity simply by adding additional servers to the
Logical Standby Unleashed Page 10
 cluster. Computing resources within the cluster can also be dynamically
reallocated from one application to the next as priorities and business
needs change.

Meeting the Site Recovery Time Objective

The significant advantage of Data Guard SQL Apply is that the standby database is
open for read access by online users at the same time it is being updated by new
transactions coming from the primary database. However since all write
transactions execute against the primary database and Data Guard SQL Apply is
used to maintain a transaction consistent standby database at the remote location, it
is important to apply those transactions to the Logical Standby database as quickly
as possible. SQL Apply transforms redo back into SQL at the standby, and applies
it to the standby database as quickly as it is received using Real Time Apply, a Data
Guard 10g feature described below.

Configuring Real-Time Apply

Real-time apply enables the standby database to apply redo data as it is received,
without waiting for standby redo log files to be archived (instead SQL Apply will
read directly from the SRL). Combined with SQL Apply, this makes it possible to
meet service level agreements for an up-to-date standby database that is open for
read access by online users. The Real Time Apply process architecture is described
in Figure 3. The LSP ‘process’ is actually a series processes described in Figure 4.

An up-to-date
Logical
Standby
Database
RFS LSP

Standby
Redo
Logs

Real Time
Apply
ARCH

Archived
Redo Logs

Figure 3 – Real Time Apply Process Architecture

Logical Standby Unleashed Page 11

Real-time Apply provides for faster switchover and failover times for all Data
Guard configurations because all of the redo received by the standby database has
already been applied when failover or switchover begins. Real-time Apply is
enabled for a SQL Apply standby database using the following statement:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY
2 IMMEDIATE;

Reading from the standby redo log is only part of the work SQL Apply has to do to
actually transform the redo back into transactions that can be applied to the Logical
Standby database. The SQL Apply process architecture and redo flow is outlined
in Figure 4, below.

Standby
Redo Log
Threads

T1 Logical Change Records not

grouped into transactions

T2 Redo LCR
Records LCR
Reader Preparer : Builder
T3
Shared Pool

T4
Log Mining

Apply Processing Transaction

groups

Applier Coordinator Analyzer

Transactions to Transactions sorted in
be applied dependency order

Standby
Database Figure 4 – SQL Apply Process Architecture

Large Object Performance Enhancements

When SQL Apply was first introduced in Oracle9i Release 2, Large Object (LOB)
datatypes were fully supported in a Logical standby database. The method in which
SQL Apply processed them was governed by the order in which the data appeared
in the redo stream.
Replicating modifications done to a table require us to identify the row being
modified. In the redo stream prior to Oracle Database10g Release 1, for out-of-line
large objects however, the modifications done to the LOB blocks show up before

Logical Standby Unleashed Page 12

the identifying information for the base table row is logged. Since the mining
engine essentially does a single pass through the redo stream, this means that it
needs to stage all the LOB modifications in memory until it has encountered the
base table row to which the modified LOB column(s) belongs.2 Thus while
processing a LOB update that modifies a single LOB column of size 100 LOB
blocks (each of size 4K say), the mining component had to stage 400K of redo data
in memory, before it can process and propagate the information identifying the row
being modified. In databases where large numbers of LOBs are modified
concurrently this necessitates allocation of large shared pool memory to be set aside
for the LCR cache, without which the number of page outs would increase and
thus slow down the mining engine and in turn slow down SQL Apply.
In Oracle Database10g Release 1 (with compatibility set to 10.1.0.0 or higher), the
information identifying the row in the base table being modified is logged before
the modifications done to the LOB blocks. The mining engine can thus identify
the row being modified before it has seen the modified LOB blocks. Subsequent
modifications done to the LOB blocks seen in the redo stream can then be
streamed to the apply component, and applied as soon as they are processed,
without having to stage them in the LCR cache.

Other Performance Enhancements

SQL Apply has also been enhanced to provide the following additional
performance improvements
• Redo records associated with tables that are not maintained by SQL Apply
are filtered out early3, and thus stay in the LCR cache for a short duration
and do not have to be examined by the apply component. Earlier,
uninteresting LCRs stayed in the LCR Cache until the apply component
had a chance to determine whether or not they should be filtered out.
• The internal cache keeping track of meta-data corresponding to all tables
maintained by the SQL Apply has been improved to occupy less space.
• SQL Apply will batch inserts together whenever possible to improve
performance.
All these improvements enable SQL Apply to execute the transactions on the
Logical standby database as fast as possible.

New Metrics to Monitor your RPO and RTO

Several new metrics have been added to the Oracle database in Oracle Database10g
Release 2 to assist the DBA in monitoring the current state of the Recovery Point
and Time Objectives. This allows them to take proactive action if the need arises.

2 Note that without the information identifying the row being modified, the apply

component cannot apply the LOB changes.

3 Filtering is done by the builder process

Logical Standby Unleashed Page 13

These metrics are in two views in the database as defined in the following list as
well as one extra metric calculated and displayed in Grid Control.
• V$DATAGUARD_STATS
o Estimated Failover Time (seconds)
o Apply Lag (seconds)
o Transport Lag (seconds)
• V$STANDBY_APPLY_SNAPSHOT
o Redo Apply Rate (KB/second)
• Additional metric in Grid Control
o Redo Generation Rate (KB/second)

Fast-start Failover
Data Guard 10g Release 2 includes a new automatic failover feature, Fast-Start
Failover. Fast-start Failover continuously monitors the status of both the primary
and standby databases and automatically executes database failover and client
notification should it detect an outage at the primary database - no manual
intervention is required. By eliminating the requirement for manual intervention,
site failover can execute very fast. Oracle tests have shown that it is possible to
execute failover to a remote site in less than 15 seconds.
After a fast-start failover occurs, the old primary database is automatically
reconfigured as a new standby database upon reconnection to the configuration.
This enables Data Guard to restore disaster protection in the configuration easily,
without complex manual steps, improving the robustness of the disaster-recovery
features of Data Guard, as well as improving Data Guard manageability.
These new capabilities allow you to maintain uptime and increase the availability, as
well the robustness of disaster recovery. Plus, there is less need for manual
intervention, thereby reducing management costs.
A fast-start failover configuration is monitored by a separate Data Guard
“Observer” process. The Observer is a lightweight process integrated in the
DGMGRL client-side component and is installed on the Observer system using the
Oracle Client Administrator or the full Oracle Database kit. It runs on a different
computer from the primary or standby databases and the operating system on the
observer computer can be different from the operating system running on the
primary computer or target standby database computer. However, the operating
system for the primary database computer and all associated standby database
computers must be the same.
As shown in Figure 5, the Observer continuously monitors the fast-start failover
configuration to ensure the primary database is available. Once the observer is
enabled, no further user interaction is required.

Logical Standby Unleashed Page 14

 Primary Site Standby Site

Observer

Redo

Figure 5 – Fast Start Failover Configuration

If both the Observer and the standby database lose connectivity to the primary
database, the Observer waits for a configurable amount of time and then initiates a
fast-start failover without any human intervention.
In Figure 6, Disaster strikes the primary database and its network connections to
both the observer and the target standby database are lost. Upon detecting the
break in communication, the observer attempts to reestablish a connection with the
primary database for the amount of time defined by the Data Guard Broker
FastStartFailoverThreshold property before initiating a fast-start
failover.

Primary Site Standby Site

Observer

Figure 6 – Disaster Strikes!

Logical Standby Unleashed Page 15

If the observer is unable to regain a connection to the primary database within the
specified time, and the target standby database is ready for fast-start failover, then
fast-start failover ensues (See Figure 7).

Primary Site

Observer

Figure 7 – Failover Ensues

Moreover, after the failover completes, once the Primary database is available again
it is automatically reinstated as a standby database in the new broker configuration
and redo transmission begins automatically (See Figure 8). To return to the original
configuration a switchover can be performed.

Standby Site Primary Site

Observer

Figure 8 – Re-Instatement of the Original Primary

Fast-start failover is a Data Guard 10g Release 2 feature. Fast-start failover can be
used only in a Data Guard Broker configuration and can be configured only

Logical Standby Unleashed Page 16

through DGMGRL or Enterprise Manager. Fast-Start Failover also requires that
the Data Guard configuration use the Maximum Availability Protection mode.

Meeting the High Availability Objective

The first requirement to meet the High Availability Requirement was to use a Real
Application Cluster at the Primary site so that server failures would not interrupt a
user’s access to the data they require. In the case where the cluster is fine but the
network to the Primary site is lost the requirement is to enable the user to gain
access to the data without the need to failover to the standby. This is possible
because a Logical Standby database is always open. Using the technologies
described in the preceding sections, SQL Apply provides;
• An Up-to-date Readable Standby
o Read access to Production system data
o No change of database role required
o Real-Time Apply keeps the data current
o Read Write Access to additional data
Additional High Availability challenges arise during the creation of a Logical
Standby database and upgrading the Oracle software. These are addressed with
Zero Downtime Instantiation and Rolling Upgrades.

Zero Downtime Instantiation

One of the challenges creating a Logical standby database in Oracle9i is that either
a cold backup of the primary database has to be used or the database users
quiesce’d to obtain a period where there are no in-flight transactions before you can
use a hot backup. The latter will still stall the updaters and, since it requires that the
Resource Manager be running, requires at least one bounce of the primary if it was
not already started at instance startup time.
Data Guard 10g enables the creation of a logical standby database without having

Recovery

1 5
3
On-Line
Backup

2 Restore

Primary Physical Standby

Database Database

Create and Copy

Logical Standby
Control File 4

Transport Service

Figure 9 – Oracle Database10g Logical Standby Creation

Logical Standby Unleashed Page 17

to shut down or quiesce the primary database. The process is simple. An online
backup is taken to create a physical standby database. A logical standby control file
is then created at the primary database, which is subsequently used to convert the
physical standby into a logical standby database. The first set of steps is shown in
Figure 9.
The backup taken in Step 1 is combined with the control file taken in Step 2 and
restored at the standby site to create a Physical standby database that has enough
information in the control file to continue the process of creating a Logical standby
database. Step two in Figure 9 does the real work to prepare for the Logical
standby database. Not only does it create the Logical standby control file but it also
performs the dictionary build for the mining of the redo and it determines the
transaction boundary where the dictionary build begins and where all in-flight
transactions end. Once this ‘Pseudo’ Physical standby database is mounted and
redo transport enabled (Step 4), Redo Apply is started to bring the database up to
the point where the in-flight transactions end and the dictionary build begins.
When this point is reached the Redo Apply process (MRP) will stop at the
appropriate SCN in the redo stream.
At this point activating the standby database, changing its name and identification
using the NID utility and starting the SQL Apply as shown in Figure 10 complete
the process.

Physical Standby 6
Database! Activation

Change DBNAME and DBID

Logical Standby
Database!

Start SQL Apply Services

Figure 10 – Oracle Database10g Logical Standby Creation

Once Step 7 is complete and the Logical Standby database is restarted, redo
transport from the Primary to the standby database resumes. All redo that was
generated at the Primary database during the time it took to complete steps 3

Logical Standby Unleashed Page 18

through 7 will be automatically shipped to the Logical Standby database using the
existing gap fetch mechanism in the redo transport layer. When SQL Apply is
started in step 8 it will know where to start in the redo stream based on information
if gets from the Logical standby control file and will automatically skip any of the
in-flight transactions that were completed by Redo Apply during step 5.
Oracle Database10g Release 2 simplifies this procedure by removing any extra file
copying, duplicate open resetlogs and running the NID utility on the standby
database during the creation process. In addition, by merely stopping the Redo
Apply process of a Physical standby database before executing steps 2 through 4 of
Figure 11 you can transform any Physical standby database into a Logical standby
database in 3 easy steps.4

1 Create a Physical
Standby

2 3
Physical Standby
Database!
Primary Perform Dictionary Recover to
Database Build on Primary Logical
database Standby

4 Logical Standby
Database!
Start SQL Apply Services

Figure 11 – Oracle Database10g Release 2

Logical Standby Creation

The Dictionary build performed in step 2 on the primary database performs the
same functions as the Logical standby control file step in the previous Oracle
Database10g Release 1 method without requiring copying the standby control file
for a second time. The dictionary build also turns on supplemental logging
automatically, which was a manual step in previous releases.
Since Redo transport is already enabled and functioning (from the creation of the
Physical standby database) the redo generated by step 2 is sent to the Physical
standby but not yet applied.
By executing ALTER DATABASE RECOVER TO LOGICAL STANDBY <new dbname>; on
the Physical standby database in Step 3, the standby database is converted to a
Logical standby database and the steps to change the database name and
identification are performed automatically, leaving the standby database in an un-

4 Before executing step 2 you must stop the Redo Apply process on the Physical
standby database.

Logical Standby Unleashed Page 19

 mounted state. After performing an open resetlogs and starting SQL Apply in Step
4, the standby database is a fully functioning Logical Standby database5.

Rolling Oracle Upgrades

Starting with Oracle Database 10g Release 1, Data Guard provides the foundation
“Data Guard's rolling upgrade capability is
amazing. Airbus tested upgrading from Oracle
for performing rolling upgrades of the Oracle database software from the first with
Database 10g Release 1 to Oracle Database minimal interruption of service. This is accomplished with the use of a Logical
10g Release 2. The elapsed time for the Standby database and switching over between the Primary database and the Logical
database upgrade was about 3 hours. But standby. Figure 12 shows the basic steps for performing this RDBMS rolling
applications were available for all but less than
upgrade.
2 minutes while a Data Guard switchover was
executed, quickly transitioning production from
Release 1 over to Release 2. Oracle Data
Guard has made great strides in helping us
achieve our 100% availability goal.”
Upgrade

Werner Kawollek Redo

Clients
Application Management Operations A B Logs A B
Queue
Airbus Deutschland GmbH

Version X Version X X X+1

1 Initial SQL Apply Config 2 Upgrade node B to X+1

Redo Redo
Upgrade A B A B

X+1 X+1 X X+1

4 Switchover to B, upgrade A 3 Run in mixed mode to test

Figure 12 – Rolling Upgrade

• Step 1 - Initial Configuration

o The configuration consists of the Production database where the
users are currently attached and a Logical standby, which can be
remote or local. Both these databases are running the initial
version, which we will call Version X.
• Step 2 - Upgrade the Logical Standby
o The first step is to stop shipping redo to the Logical standby and
upgrade the Oracle software and database at the Logical standby
site to Version X+1.

5Note that the creation of the logical standby control file in Oracle Database10g
Release 1 and the Dictionary build in Oracle Database10g Release 2 will wait for all
active transactions to commit before the operation can complete.

Logical Standby Unleashed Page 20

 o The redo is retained at the Primary waiting for the Logical
standby to return. This has no impact on the performance of the
Primary database since it is a controlled action.
o Once the Logical standby database is upgraded, normal testing
can be performed to ensure that it functions correctly. The
testing would be Read-only on the objects being maintained by
SQL Apply but could be Read-Write on any other objects.
• Step 3 - Run in a Mixed Environment
o Re-enable the redo shipping from the Primary database to the
Logical standby (running in Version X+1) and the archive logs
that were not sent yet will be automatically shipped to the standby
and applied. Run in this mixed version environment for as long
as necessary until confident that everything works as expected.
• Step 4 - Switch over to the Logical Standby
o When ready, perform a switch over and move the users (and
applications) from the current Primary database to the newly
upgraded Logical standby database. This requires a short period
where the users cannot update either database.
o Transactions will now be running on the new Primary database,
which is running in Version X+1. The original primary database
is now a Logical standby but cannot receive redo until it too is
upgraded to Version X+1.
• Step 5 - Upgrade Original Primary
o With the users and transaction executing on the new Primary,
upgrade the original Primary, which is now a Logical standby.
This is done by shutting down the database, upgrading the Oracle
software and performing the upgrade of the original Primary
database (now a Logical standby database).
• Step 6 - Resynchronize The Original Primary
o Re-enable the destination on the new Primary and all of the redo
that has been created since the switchover will be sent to the
Logical standby and applied, bringing it up to date with the
current Primary. Run in this mode or switch back to the original
configuration by performing a switchover (in the reverse
direction).
At this point all of the databases have been upgraded to Version X+1 with
minimal interruption of service.

Logical Standby Unleashed Page 21

CONCLUSION
Data Guard 10g SQL Apply provides users with the best of both worlds: a
reporting solution that also serves as a highly functional DR solution for their
Oracle databases. Advantages of Data Guard 10g include:
Faster Failover: The standby database applies directly from the standby redo log
as redo is received. There is no delay at failover time while the standby database
applies redo from the last archive log.
Enhanced Performance: Faster LOB apply, faster overall apply processing
Better data protection & reporting: Zero Data Loss protection using SQL
Apply. No latency for updates to the standby database.
Cheaper: Greater asset utilization by using DR system as production reporting
server. This effectively reduces the cost of maintaining a DR system.
Easier to manage: Elimination of role-specific configurations with powerful
browser-based creation, management & control of Data Guard configurations.
In addition, with 10g Release 2, Database Administrators can take advantage of the
automatic archived log deletion feature at the logical standby database that deletes
archived logs received from the primary database, as soon as their contents are
applied

ADDITIONAL REFERENCES
1. Oracle Maximum Availability Architecture
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
2. Oracle Real Application Clusters
http://www.oracle.com/technology/products/database/clustering/index.html
3. Oracle Data Guard Overview
http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardOverview.html
4. High Availability Customer Case Studies
http://www.oracle.com/technology/deploy/availability/htdocs/HA_CaseStudies.html
5. Data Guard Primary Site and Network Configuration Best Practices
http://www.oracle.com/technology/deploy/availability/pdf/MAA_DG_NetBestPrac.pdf
6. Oracle Data Guard Concepts and Administration
http://download-west.oracle.com/docs/cd/B13789_01/server.101/b10823/toc.htm
7. Oracle Database 10g Best Practices: Data Guard SQL Apply
http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gSQLApplyBestPrac
tices.pdf

Logical Standby Unleashed Page 22

Logical Stadby Unleashed
September 2005
Author: Joseph Meeks, Larry M. Carpenter
Contributing Authors: Eric Nielson, Dan Dressel, Dave Baar, Joydip Kundu

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com

Copyright © 2005, Oracle. All rights reserved.

This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, PeopleSoft, and Retek are registered trademarks of
Oracle Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.