Architecture and Infrastructure
Reviewed by Oracle Certified Master Korea Community
( http://www.ocmkorea.com http://cafe.daum.net/oraclemanager )
HIGH-AVAILABILITY OPTIONS IN ORACLE9IR2
HIGH AVAILABILITY OVERVIEW
The term “high availability” means different things to different people. It can legitimately encompass concepts such as
performance scalability, mean time to repair (MTTR), and rolling upgrades. When considering how to make an Oracle
database server highly available, a system architect can consider solutions such as node failover or storage array failover that do
not involve any advanced Oracle capabilities at all. In this paper, though, we’re interested in Oracle features and options that
provide some type of redundancy, with the goal of providing more or less continuous use of a database by avoiding a single
point of failure. We’ll consider the high availability (HA) features provided by Oracle9iR2, focusing on their requirements,
strengths, limitations, administration considerations, and ways in which they can be combined.
Some of the terms we’ll be using are:
• Failover—the ability of database clients to connect to one of two or more Oracle instances at login time (connect-time
failover), or the ability of applications to detect an instance or database failure and transparent connect to a redundant
instance (Transparent Application Failover).
• Instance failure—the failure of a running Oracle server instance, due to Oracle-specific problems, host computer hardware
or software problems, or network problems.
• Database failure—the unavailability of a database due to problems with the database itself; these might be caused by the
corruption of a database file, a disk subsystem failure, or any number of other problems in which the instance continues to
run but the database becomes inaccessible for all practical purposes.
We’ll start by discussing two types of redundancy: instance and database.
INSTANCE REDUNDANCY
An Oracle instance is the non-persistent set of background processes and a System Global Area (SGA) that provides access to
the Oracle database resident on disk; it can be more clearly called an Oracle server instance. An instance that has opened a
database is a prerequisite for use of the information stored in that database. High availability requires that there is more than
one instance available for client connections in case of the failure of another instance or database. Instance redundancy is
required for failover, whether it be connect-time failover or Transparent Application failover; even in HA configurations such
as Data Guard physical standby that do not support immediate failover, a redundant instance is available. Given the wide use
of storage redundancy such as RAID and other technologies, instance redundancy can suffice for some HA environments.
DATABASE REDUNDANCY
Database redundancy refers to the existence of a second copy of at least part of the data in a database. All of the HA facilities
discussed here, except Real Application Clusters, provide this capability. Database redundancy, of course, provides a higher
level of availability than instance redundancy alone—in the event of a complete server failure (e.g., a catastrophic storage
subsystem failure that renders the server and its data unavailable), a second copy of the database allows applications to
Paper # 211
Architecture and Infrastructure
continue working after a brief delay. However, with database redundancy comes additional administrative responsibility—
namely, keeping multiple copies of data in sync.
HIGH AVAILABILITY OPTIONS
Now let’s identify the HA alternatives provided by Oracle in 9iR2.
REAL APPLICATION CLUSTERS
Real Application Clusters is a multiple-server technology that provides instance redundancy but not database redundancy. It
offers scalability in addition to high availability, and can be used in conjunction with other HA technologies.
DATA GUARD
Data Guard encompasses physical standby and (new for Oracle9iR2) logical standby databases. A physical standby database is
an exact copy of the primary, kept up-to-date by the application of redo information, but not used unless transitioned to the
primary role. A logical standby database converts redo information from the primary into SQL and executes it; it can be used
for other purposes as well at the same time.
ADVANCED REPLICATION
Oracle Advanced Replication comprises materialized view (snapshot) replication and multi-master replication. In the former, a
single master site supplies data to one or more materialized view sites, which synchronize periodically with the master. In
multi-master replication, as the name implies, each participating database is a master; each masters propagates its changes to
every other master.
ORACLE STREAMS
Oracle Streams is another new feature of Oracle9iR2. It provides the ability to capture, queue, and apply DML and DDL
statements (obtained from the redo logs) and user events at one or more databases. The Data Guard logical standby database
facility is built on Streams technology; Streams itself offers is considerably more flexibility and capability for environments that
require them.
ORACLE NET FAILOVER
Oracle Net failover is not a high-availability solution in itself, but it works in concert with the server features. By failover we
mean the ability of Oracle Net to direct either a database connection attempt, or a running application, to a different database
instance in the event that a primary database becomes unavailable. Thus, applications can connect to whichever database
instance is available without manual intervention.
Let’s continue with examinations of each of these options in greater depth.
REAL APPLICATION CLUSTERS
CONCEPTS
While Oracle Parallel Server and its predecessors have been around since Oracle version 5, Oracle Corporation made such
major improvements in the technology for Oracle9i that the product was re-christened as Real Application Clusters (RAC).
And in truth, RAC is the first release of this clustered database server technology that does not carry heavy application-
partitioning requirements, in a case of the database tail wagging the application dog, so to speak.
Briefly, RAC and its predecessors require the deployment of operating-system cluster technology, in which two or more
computing nodes share storage devices. The first and still most successful implementation of this architecture was Digital
Equipment Corporation’s (later Compaq’s, and now HP’s) VMS clustering. Each machine in the cluster runs an Oracle server
instance, and each instance mounts and opens a common database on the shared storage.
Earlier releases, called Oracle Parallel Server, had not adequately solved the cache management problem: multiple servers
shared a single database on disk, but each had its own buffer cache. When one instance requested a database block that
resided in the cache of another instance, the block had to be written to disk before the requesting instance could load it into
cache; in effect, the shared disk became a communication mechanism. The speed of this mechanism left much to be desired.
Paper # 211
Architecture and Infrastructure
Because this so-called “block pinging” was inherently not scalable, Oracle recommended that applications be assigned to
different database instances, and that no two applications ever have the potential of requesting write access to the same block.
Parallel Server thus had very limited appeal and deployment.
With RAC, however, Oracle introduced Cache Fusion, which allowed the transfer of database blocks from one instance to
another over the cluster’s high-speed interconnect, which is orders of magnitude faster than disk devices. The application
partitioning requirements are now, if not completely eliminated, greatly reduced, making RAC an option for many more
systems.
CAPABILITIES
RAC provides both high availability and scalability. Scalability is enhanced by the ability to address greater application loads by
adding more nodes to the cluster. High availability is provided by the presence of multiple instances with which to access a
single database. Oracle Net’s load-balancing and failover features (discussed later in this paper) provide the appearance of a
single database service provided redundantly by each machine in the cluster. Note, however, that RAC does not provide
database redundancy: storage failure, corruption, or human error that makes one or more database files inaccessible still
constitutes a single point of failure. RAC can, however, be used with other HA features, such as Advanced Replication, Data
Guard, or Streams, to provide a robust HA solution that offers great scalability as well.
Oracle also offers the Real Application Clusters Guard option, which combines RAC with platform-specific cluster manager
software. Applications always connect to a RAC node designated as the primary; in the event of failure, however, RAC
components work with cluster management software to provide a graceful and transparent transition to the secondary node.
RAC Guard is a combination of RAC and operating-system failover technologies.
PREREQUISITES
A basic requirement of clustering (and hence RAC) is that each node be hosted on identical or nearly identical hardware,
running the same version of the same operating system, and using the operating-system vendor’s clustering technology. The
clustering software usually must be licensed separately, as must RAC, so this is one of the more expensive HA solutions. In
addition, RAC can be difficult to set up and maintain, so it must be chosen and deployed with adequate care and planning.
When properly installed and maintained, it is a very powerful HA option.
DATA GUARD
Oracle’s Data Guard technology was introduced in Oracle7 as Standby Database and was limited to the physical standby
option. Logical standby was introduced in Oracle9iR2, building on another Oracle feature, LogMiner.
PHYSICAL STANDBY DATABASE
CONCEPTS
A Data Guard physical standby database begins as an exact backup copy of a source database, which must be run in
ARCHIVELOG mode. The database is copied to another machine and mounted by a new instance, which is placed in a
perpetual recovery mode. As redo logs are filled and archived on the primary machine, copies of the archived logs are copied
to the standby and their redo information is applied: the process is similar to that of restoring a backup and applying archived
logs to it to roll forward. During this period, no users can connect to the database, as it is not open. The reason that the
standby must be an exact copy is clear: redo information consists of low-level block change vectors consisting of block
addresses, offsets, and data values; the files to which these changes are applied must be identical to the originals, or complete
gibberish will be produced!
It is possible to open a physical standby database in read-only mode, to allow queries to be executed against it. Although redo
information may still be received from the primary while the database is open, the changes are not applied. Eventually the
database must be closed, mounted as a standby, and automatic recovery restarted.
HISTORY
In early implementations of physical standby, Oracle did not provide any mechanisms to transfer the logs from the primary to
the standby, or to detect and resolve gaps in the log sequence; thus, a significant amount of programming was required to
automate these processes.
Paper # 211
Architecture and Infrastructure
With each subsequent RDBMS release, however, Oracle added more management tools, and in Oracle9i log transport and
other features make it possible to set up a physical standby that is automatically kept up to date. In addition, Oracle now
provides three distinct protection modes, known as Maximum Protection, Maximum Availability, and Maximum Performance.
These modes either use the Log Writer (LGWR) background process to send redo information to the standby as it is generated
by the primary, or use the Archiver (ARCH) process to transmit a copy of each just-filled redo log to the standby (as a second
log archive destination, the first being the primary’s local log archive directory).
CONFIGURATION
In Maximum Protection and Maximum Availability modes, redo information is transmitted to the standby by the Log Writer
(LGWR) background process as it is generated; i.e., there is no wait for a log to be filled and archived. In Maximum
Protection mode, a transaction on the primary database will not commit until the redo data needed to recover that transaction
is written to at least one standby database. If the primary is unable to perform such a write, it will shut down to prevent the
generation of unprotected data. Of course, the other side of the coin here is that the impact on performance and availability of
the primary is the highest of the three modes.
In Maximum Availability mode, which also uses LGWR to transmit redo information to the standby, a primary database
transaction will similarly not commit until redo information is written to a standby. However, if the write cannot be performed,
the primary will not shut down; instead, it will transition temporarily to Maximum Performance mode until the fault is
corrected and the standby catches up with the primary. There can be no data loss in this mode unless the primary fails while in
Maximum Performance mode.
In Maximum Availability mode, which can use either LGWR (as above) or archiver (ARCH) redo transmission, there is no
wait to commit. Instead, the redo information is transmitted asynchronously. Data can be lost if the primary fails and some
redo information required to recover it has not been written to a standby.
In any of these modes, a process known as Remote File Server (RFS) runs on the standby, to receive and apply redo
information received from the primary.
Note that it is critical to have sufficient network capacity in the link between the primary and standby. The log writer cannot
begin writing to a redo group if it has not been successfully archived to at least one standby; this will cause the suspension of
all writes on the primary database until archiving is complete. Adequate network bandwidth is a function of the maximum rate
of redo generation, which should be measured during times of most-intense insert/update/delete activity.
Each database requires certain initialization parameters to support its possible roles as a standby or primary. They may be
combined in a common init.ora file, or two init.ora files may be maintained, one to support each role.
Finally, to protect against missing redo information due to operations performed with the NOLOGGING option, the primary
database should be placed in FORCE LOGGING mode via an ALTER DATABASE command, which forces redo
information to be written regardless of whether NOLOGGING is specified.
ROLE TRANSITION
There are two types of role transition: switchover and failover. A switchover is a planned, managed transition where the
standby becomes the primary and the primary becomes the standby. This is accomplished with a series of commands on both
databases; first the primary is converted to standby, then the old standby is converted to primary. The process can then be
repeated in the other direction. Switchover is frequently used for scheduled maintenance purposes.
In failover, a loss of the primary database motivates an irreversible transition of the standby to the primary role. Once a
failover is performed, a new standby must be created from the new primary.
PLATFORM REQUIREMENTS
Standby databases must reside on servers of the same operating system and architecture (e.g., 32-bit Intel Linux, 64- bit AIX);
the operating system versions do not have to be identical. Directory structures may differ. The Oracle server software must
be Enterprise Edition, and the versions must be identical on each database.
LOGICAL STANDBY DATABASE
Logical standby, a new feature of Oracle9iR2, differs significantly from physical standby:
• A logical standby database need not be an identical physical copy of a primary.
Paper # 211
Architecture and Infrastructure
• A logical standby may contain different schemas and objects from the primary.
• A logical standby can remain open for use while redo information is applied.
• A logical standby allows selective application of redo.
PLATFORM REQUIREMENTS
The platform requirements for logical standby are the same as for physical standby.
CONCEPTS
Oracle frequently builds on existing features to create new ones (we’ll see another example of this later, in the discussion of
multi-master replication). In this case, Oracle has used both LogMiner and Streams to make Logical Standby possible.
Logical standby requires that redo information be transmitted from primary to standby, as it is in physical standby, but what
happens to the redo once it reaches the standby is very different. Logical standby Log Apply Services use LogMiner to
construct SQL statements from the redo log information, and execute that SQL on the standby. That’s why a logical standby
database can be open (indeed, must be open) while redo is being applied: it’s being applied not as low-level block changes,
but as SQL very similar to what created the redo information on the primary.
Because of this approach, logical standby allows (and sometimes requires) more setup than physical standby does. For
example, a table that is to participate in a logical standby database must have a primary key or unique key, and it cannot contain
certain data types, or be an index-organized table (there are other restrictions; see the Oracle9i Data Guard Concepts and
Administration manual for details)
CONFIGURATION
The same types of log transport options pertain to logical standby and physical standby.
Additional logical standby preparation on the primary includes determining data type and object type support, ensuring rows
can be uniquely identified, and enabling supplemental logging. The latter adds primary or unique key information to the redo
stream, to guarantee that the row being modified can be uniquely identified (ordinarily, redo information comprises only the
columns that are modified, and these may not suffice to identify a row).
Because the logical standby is not a physical copy of the primary, and is kept up-to-date via SQL, it is possible to filter the flow
of changes from primary to standby; for example, all operations on a specific table can be skipped, or certain classes of DDL
(such as CREATE or DROP TABLE, INDEX, VIEW). The DBMS_LOGSTDBY.SKIP procedure provides this capability.
Certain SQL statements are never applied to a logical standby; these include
ALTER DATABASE
ALTER SESSION
ALTER SNAPSHOT
ALTER SNAPSHOT LOG
ALTER SYSTEM SWITCH LOG
CREATE CONTROL FILE
CREATE DATABASE
CREATE DATABASE LINK
CREATE PFILE FROM SPFILE
CREATE SCHEMA AUTHORIZATION
CREATE SNAPSHOT
CREATE SNAPSHOT LOG
CREATE SPFILE FROM PFILE
CREATE TABLE AS SELECT FROM A CLUSTER TABLE
DROP DATABASE LINK
DROP SNAPSHOT
DROP SNAPSHOT LOG
EXPLAIN
LOCK TABLE
RENAME
SET CONSTRAINTS
SET ROLE
SET TRANSACTION
Paper # 211
Architecture and Infrastructure
Because LogMiner transforms redo data into SQL, sufficient resources (such as space for the LogMiner dictionary, preferably
in a tablespace other than SYSTEM) are required on the standby to ensure its smooth operation.
ADVANCED REPLICATION
MATERIALIZED VIEW REPLICATION
The first type of replication builds upon the snapshot capability that was introduced in Oracle7.
CONCEPTS
A materialized view (MV) is an instantiation of a query, and is updated via a process known as “refresh”. A refresh can either
be complete, in which the MV’s defining query is re-executed and the results replace the current contents of the MV, or fast, in
which only the changes to the master are applied to the MV. In materialized view replication environments, one database
holds the master, and other databases contain the MVs. There are three types of MVs:
• Read-only
• Updatable
• Writeable
Read-only MVs are useful for the distribution of reference data, or for providing data copies to be used for reporting. There is
no possibility of data conflicts with the master site when using read-only MVs. Updatable MVs allow user DML; these
changes are then pushed back to the master during refresh. Writeable MVs, which are rarely used, allow writes, but the
changes to the MV are lost on refresh.
REQUIREMENTS
In general, MVs require that master table rows be uniquely identifiable. In addition, to enable fast refresh, an object called a
materialized view log must be created on the master table; the log comprises a trigger and a table. When DML against the
master table changes data, the trigger captures the changes and stores them in the log table. The fast refresh process reads the
table, applies the changes to the MVs, and purges the log table of contents that have been applied to all MVs defined against
the master.
FEATURES
Materialized views can be advantageous in situations that do not require constant update of each copy of master data; refresh
can be scheduled as necessary. Note, however, that refresh is initiated from the MV site, not the master site, so it is more
difficult to determine when to refresh based on master site transaction volume. Materialized views can also contain just a
subset of master data. In addition, materialized view replication supports multitier materialized views, in which an MV may be
based on another MV (which is called a master MV).
LIMITATIONS
The content of materialized views typically lags that of their masters, because of the nature of the refresh process, which is to
communicate periodically with longer intervals between bulk data transfers. They may communicate with only one master site
or one master materialized view site.
MULTI-MASTER REPLICATION
Multi-master replication was introduced as Symmetric Replication in Oracle7.
REQUIREMENTS
As with materialized view replication, multi-master replication requires that table rows be uniquely identifiable In addition, all
replication environments require that the initialization parameter GLOBAL_NAMES be set to TRUE; this requires that a
database link must have the same name as the database to which it connects.
Every replication environment requires a database user to act as the replication administrator. This user acts as an agent for
the owners of replicated objects. It is responsible for propagation and receipt of DML changes, and for administrative tasks
such as queue purges and building objects required for replication support. Generally, a replication administrator schema acts
Paper # 211
Architecture and Infrastructure
as both propagator and receiver of changes that are transmitted from one master database to each of the others, although it is
possible to separate the propagation and reception functions.
One major advantage of multi-master replication is that Advanced Replication can replicate data between Oracle databases
running on different hardware and operating systems.
CONCEPTS
The concept of deferred transactions underlies multi-master replication. In some types of distributed computing environments,
transactions complete at all sites immediately, using a protocol known as two-phase commit. Multi-master replication uses an
asynchronous approach; deferred transactions at remote sites queue for execution at a later time. Deferred transactions use an
interprocess communication mechanism known as message queuing. A transaction queue stores information about operations
to be performed at a remote site. Triggers on the master site place transaction information on the queue. A queue processing
task runs periodically to service the queue; i.e., to remove messages and forward them to remote sites for processing.
Concurrent multi-master transactions present the possibility of simultaneous changes to the same row. While application
design can reduce the possibility of such conflicts, it may not be able to eliminate them completely. Oracle provides several
built-in conflict resolution methods. If these are insufficient, Oracle allows use of custom (user-written) routines.
DDL applied directly to replicated objects is not replicated. When modifications are to be made to replicated objects, each
copy of the object must undergo the same changes to ensure that replication can continue to operate properly. Oracle
provides procedures in the DBMS_REPCAT package to apply DDL and replicate it to all copies of a replicated object. The
replication group containing the object must be quiesced during this operation.
When replication is enabled, certain operations are prohibited. A replication group can be quiesced (using
DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY) to allow maintenance activities to take place. When a group is quiesced,
DML operations are not allowed against any of the objects in the group. DBMS_REPCAT.RESUME_MASTER_ACTIVITY
takes a replication group out of the quiesced state.
Oracle uses internal triggers to capture and store any data changes made to tables that have been defined as replicated. It stores
the data changes as remote procedure calls (RPCs) in deferred transaction queue tables for propagation at a predefined time
and interval.
FEATURES
Multi-master replication is built on Oracle’s Advanced Queuing facility. The implementation of multi-master replication is
thus quite robust, and includes a number of useful management features.
• Oracle ensures that transactions are propagated to each master database in a replication group, and that they are applied
only once.
• Error queues hold remote transactions that failed to execute successfully on the local database; they can be retried or
deleted.
• Deferred transactions may be inspected and their constituent operations (SQL statements) identified.
• Successfully propagated transactions can automatically be purged from the deferred transaction queues.
• The ability to compare and/or reconcile the contents of replicated objects.
The supplied packages DBMS_REPCAT, DBMS_DEFER_SYS, and DBMS_REPUTIL provide most of the operations
required for replication management. These may be called directly, or from scripts. In addition, Oracle provides a Replication
Manager graphical interface as part of Oracle Enterprise Manager. It generates and executes calls to the same packages.
For some implementations, Procedural Replication makes the most sense. In this case, DML is not replicated directly; instead,
calls to packaged procedures are replicated, and the DML that they perform is thus applied to each master site in the
replication group. Procedural Replication can help limit the size of deferred transaction queues and the amount of network
traffic between master database sites.
ORACLE STREAMS
Streams is a new and very promising offering from Oracle. It offers a rich set of features and capabilities. This discussion
focuses on the use of Streams for high availability; there are, however, many other potential applications for this technology.
Paper # 211
Architecture and Infrastructure
REQUIREMENTS
• Streams is available only in Oracle9iR2 and subsequent releases.
• Streams does not require an exact match between database platforms.
CONCEPTS
The basic components of Streams are:
• Event capture
• Event staging and propagation
• Event application
A Streams capture process (implemented as an Oracle background process) reads redo information from the online redo logs,
captures DML and DDL, formats them into objects called Logical Change Records (LCRs), and enqueues them. Row LCRs
capture changes made to data, and DDL LCRs capture information about changes to a database object. The Streams
administrator creates rules to specify which changes are captured. Streams tags can be specified for redo entries produced by a
particular session or by an apply process; because Streams LCRs may be applied at the same database from which they came,
tags can be used to identify the source of a change and keep LCRs from being sent back to the database in which they
originated.
After capture, events are staged by enqueuing them for propagation. Events are sent from one queue (the source queue) to
another (the destination queue). There can be one-to-many, many-to-one, or many-to-many relationships between source and
destination queues. In addition to LCRs, Streams queues may also contain user messages inserted directly into the queues by
an application, and events may be explicitly dequeued as well.
The apply process is also an Oracle background process. It dequeues events and either applies them directly to a database
object or passes them to a user-defined apply handler.
FEATURES
The main features that distinguish Streams from other replication offerings are:
• Ability to form directed networks
• Explicit event queuing and dequeuing
• Transformation rules
A directed network is a configuration in which streams may travel through many queues on many nodes, with processing of the
queued event taking place on zero or more of the nodes. In a distributed computing environment this capability allows an
event captured on one node to be applied and/or transformed at many different nodes depending on their roles and
requirements.
Explicit event queuing and dequeuing allow application access to Streams queues. Applications may queue events directly, and may
remove them from queues directly; this capability allows even more customization, as queues may consist of both LCRs and
user-defined events.
Transformation rules are code objects that execute based on certain conditions in a captured event; they fire during the Streams
apply process. They are somewhat analogous to triggers in that they are event-driven and contain conditional logic. They
would be used principally in the application of Streams to perform data integration.
STREAMS FOR HIGH AVAILABILITY
Streams is the mechanism used for Data Guard logical standby, which is a packaged solution and should be adequate for most
purposes. Streams can be used, however, to create a replica database if any of the following requirements exist.
• More than 10 copies of data. Data Guard provides only 10 LOG_ARCHIVE_DEST_n parameters; Streams is not
limited in the number of copies it can make.
• Writes (updates) at the replica database. Data Guard does not allow updates of the standby. Using Streams, writes are
allowed, and local applications can operate independently.
Paper # 211
Architecture and Infrastructure
• Different primary and standby platforms. Streams does not require homogeneous platforms.
• Different database character sets. Streams will automatically convert from the source to the destination character set
during the apply process.
Of course, creating a replica using Streams requires the development of many of the facilities and tools provided with Data
Guard; this means that additional training, planning, and testing must go into the implementation in order to assure a
production-ready system.
ORACLE NET
Oracle Net provides two features that complement high-availability database systems. One is available to almost any
application; the other, while offering much more functionality, is limited to clients written with a particular interface to Oracle.
CONNECT-TIME FAILOVER
An Oracle9i database instance can specify the name of one or more services that it provides; these services are specified in the
initialization parameter service_names. Connect-time failover involves creating an Oracle Net database service name that
specifies a database service name and the addresses of two or more listeners that can create connections to instances that
provide that service; for example:
PROD.MYCOMPANY.COM =
(DESCRIPTION =
(ADDRESS_LIST =
(LOAD_BALANCE=off)
(FAILOVER=ON)
(ADDRESS = (PROTOCOL = TCP)(HOST = oracle01.mycompany.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = oracle02.mycompany.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = prodappdb.mycompany.com)
)
)
Any client that attempts a connection using this Oracle Net service name will be directed first to the first listener in the address
list; if a connection cannot be made, an attempt will be made via the second listener, and so on. The parameter
LOAD_BALANCE=off means that connections will always be directed initially to the first address in the list rather than being
distributed among the addresses. Connect-time failover thus allows applications to transparent connect to a second database
instance if a primary database instance becomes unavailable.
TRANSPARENT APPLICATION FAILOVER
Transparent application failover (TAF) requires that client database access be made via the Oracle Call Interface (OCI). The
listeners and database instances that compose the failover pool may be specified the same way as they are for connect-time
failover, or an alternate Net service name may be supplied via the FAILOVER_MODE parameter. TAF allows a client
operation to detect database failure, and then transparently re-connect to a failover database.
TAF configuration in the Net service name allows specification of an alternate Net service name for failover connection; the
creation of preconnections on one or more failover machines, for faster failover; and the specification of either session failover
(which just fails over a lost connection) or select failover (which attempts to allow the resumption of fetches if a session fails
over during retrieval of rows). In addition, TAF provides the ability to specify a retry count and retry delay for failover
connection attempts.
On the client side, OCI provides failover callback. A user-written function may be registered in the server context. If a
connection is lost, the function will be executed a number of times during the failover process; each execution will report what
progress has been made and the function can take appropriate action.
CHOOSING A HA STRATEGY
With so many choices, how do you choose a high-availability configuration? Here are some things to consider.
Paper # 211
Architecture and Infrastructure
AVAILABLE PLATFORMS
• Most HA options are available on all platforms; Real Application Clusters is the exception. RAC requires specific
clustering hardware and software and thus usually involves the adoption of a platform specifically for building a RAC
system.
• Data Guard requires that the platforms hosting participating databases be of the same hardware architecture and operating
system.
• Both RAC and Data Guard require the Enterprise Edition of the Oracle server, and that the Oracle software be at the
same release and patch level.
• Advanced Replication and Streams are platform-independent. Streams is available only on 9iR2; Advance Replication may
operate between 8i and 9i instances.
COMPATIBILITY ISSUES
When using an object-based HA scheme, such as Data Guard logical standby, Streams, and Advanced Replication, consider
the fact that they may be incompatible with certain data types and object types. Physical standby, because it operates at a
block-change level, and RAC, because it does not replicate data, do not carry these restrictions. If your application uses types
unsupported by a particular HA scheme, you must either change the object types or develop a workaround.
PERFORMANCE CONSIDERATIONS
No HA solution comes without performance overhead.
RAC’s Cache Fusion, although orders of magnitude faster for inter-instance block transfers than Parallel Server, still transfers
data from memory to memory over an interconnect that is far slower than the speed of a system’s backplane. There is
additional overhead represented by distributed lock managers and other processes necessary to coordinate many-to-one
instance-to-database access.
Data Guard physical standby has minimal effect on the primary database as long as there is sufficient network capacity to keep
up with redo generation. As mentioned earlier, a deficiency in this area can have severe effects on the performance of the
primary database.
Data Guard logical standby is subject to the same network requirements as physical standby. The overhead of the LogMiner
processes on the standby can affect other processes using that database. In addition, transactions applied to the standby may
be many times slower than they were on the primary because of the nature of the SQL created from redo information.
Consider a SQL statement that deletes 10,000 rows. The redo information for this statement must consist of as many block
changes as are necessary (potentially more than 10,000, if each row is in a different block and there are indexes on the table).
When LogMiner extracts this information, it in effect creates 10,000 separate delete statements, which will almost always take
longer to run than a single delete.
Advanced Replication, especially multi-master replication, can cause a great deal of network traffic between replicated nodes.
There is also some impact on DML performance due to the overhead of internal triggers, but it should not be an issue for
well-designed applications and databases.
RECOVERY REQUIREMENTS
RAC, Advanced Replication, and Streams replicas can provide almost immediate recovery from failure when used in
conjunction with Oracle Net failover. Data Guard requires a role transition to convert a standby to a primary, and this can
take time that some applications may not be able to tolerate.
OTHER REQUIREMENTS
Advanced Replication and Streams may be deployed for individual database schema objects, and so offer maximum flexibility.
RAC and physical standby operate at the database level, so that all objects participate. Logical standby begins at the database
level, but with the introduction of filters into the apply process, any number of objects (such as tables) or operations (such as
tablespace creation) may be skipped by the standby apply process.
Paper # 211
Architecture and Infrastructure
You can mix and match HA options to satisfy almost any requirement.
• Combine multi-master replication with a physical standby to provide a transactional database, a reporting database, and a
remote copy for disaster recovery.
• Combine RAC with advanced replication to provide HA across different platforms and performance scalability.
• Use RAC with Data Guard to provide the database redundancy that RAC alone does not offer.
• Open a Data Guard physical standby in read-only mode outside of business hours and use it for batch reporting, or data
warehouse loading.
• Add logical standby to multimaster replication to send a filtered data stream to a third database.
Many other combinations are possible.
SUMMARY
This paper is only an overview of Oracle’s HA offerings. Each of the options makes available a rich set of possibilities for
customization; with Streams and its sibling, logical standby, Oracle has raised the ante considerably for high-availability
computing that can also perform data integration and distribution functions. If you are willing to become familiar with more
than one of the HA choices, you have the ability to create a database environment that is uniquely suited to your company,
your application, and your data.
Paper # 211