Database Replication
Database Replication
Release 8.1.5
A67781-01 Library Product Contents Index
34
Database Replication
Lady, you are the cruel'st she alive, If you will lead these graces to the grave And leave the
world no copy.
Shakespeare: Twelfth-Night
This chapter explains the basic concepts and terminology for the Oracle replication
features.
What Is Replication?
Multimaster Replication
Snapshot Replication
Replication Conflicts
Additional Information:
What Is Replication?
Replication is the process of copying and maintaining database objects in multiple databases
that make up a distributed database system. Changes applied at one site are captured and
stored locally before being forwarded and applied at each of the remote locations.
Replication provides user with fast, local access to shared data, and protects availability of
applications because alternate data access options exist. Even if one site becomes
unavailable, users can continue to query or even update the remaining locations.
Replication Objects
Replication Groups
Note:
This chapter uses the term snapshot instead of materialized view to refer
to materialized views that are used for basic or advanced replication. The
term "snapshot" is obsolete and will be replaced by "materialized view"
in future releases of the documentation. In SQL statements, the keywords
SNAPSHOT and MATERIALIZED VIEW are interchangeable.
In a multimaster replication environment, the replication groups are called master groups.
Corresponding master groups at different sites must contain the same set of replication
objects (see "Replication Objects"). Figure 34-1 illustrates that master group "SCOTT_MG"
contains an exact replica of the replicated objects at each master site.
Figure 34-1 Master Group SCOTT_MG contains same replication objects at all sites.
At a snapshot site, organization is maintained using a snapshot group. A snapshot group
maintains a partial or complete copy of the objects at the target master group. Figure 34-2
illustrates that snapshot group "Group A" at the snapshot site maintains only a partial
replica of master group "Group A" at the master site, while the "Group B" snapshot and
master groups maintain a complete replica.
Additionally, Figure 34-2 illustrates that each site may contain multiple replication groups.
Replication Sites
A replication group can exist at multiple replication sites. Replication environments support
two basic types of sites: master sites and snapshot sites.
A master site maintains a complete copy of all objects in a replication group. All master
sites in a multimaster replication environment communicate directly with one another
to propagate data and schema changes in the replication group. A replication group at
a master site is more specifically referred to as a master group. Additionally, every
master group has one and only one master definition site (for example, ORC1.WORLD
in Figure 34-3 might be the master definition site). A replication group's master
definition site is a master site serving as the control point for managing the replication
group and objects in the group.
A snapshot site supports read-only and updateable snapshots of the table data at an
associated master site. A snapshot site's table snapshots can contain all or a subset of
the table data within a replication group. However, these must be simple snapshots
with a one-to-one correspondence to tables at the master site. For example, a snapshot
site may contain snapshots for only selected tables in a replication group. And a
particular snapshot might be just a selected portion of a certain replicated table. A
replication group at a snapshot site is more specifically referred to as a snapshot
group. A snapshot group can also contain other replication objects.
Multimaster Replication
Oracle's multimaster replication allows multiple sites, acting as equal peers, to manage
groups of replicated database objects. Applications can update any replicated table at any
site in a multimaster configuration. Figure 34-4 illustrates a multimaster replication system.
Multimaster replication is useful for many types of application systems with special
requirements. The following scenarios describe some of the uses for multimaster
replication:
Failover Site
Read-Only Snapshots
In a basic configuration, snapshots may provide read-only access to the table data that
originates from a primary or "master" site. Applications can query data from local data
replicas to avoid network access regardless of network availability. However, applications
throughout the system must access data at the primary site when updates are necessary.
Figure 34-6 illustrates basic, read-only replication.
Can support complex snapshots (snapshot may be based on one or more tables and
may contain aggregates, joins, set operations, or a CONNECT BY clause).
In a more advanced configuration, you can create an updateable snapshot that allows users
to insert, update, and delete rows of the target master table. An updateable snapshot may
also contain only a subset of the target master table's data set. Figure 34-7 illustrates a
replication environment using updateable snapshots.
Updateable snapshots are based on tables at a master site that has been setup to support
multimaster replication. In fact, updateable snapshots must be part of a snapshot group that
is based on a master group at a master site.
Oracle propagates the changes made through an updateable snapshot to the snapshot's
remote master table. If necessary, the updates then cascade to all other master sites.
Allowing users to query and update a local replicated data set even when disconnected
from the master site.
Increased data security achieved by replicating only a selected subset of the target
master table's data set.
Snapshot replication is useful for several types of applications. The following sections
describe some of the typical uses for snapshot replication.
Information Off-Loading
Information Distribution
Read-only snapshot replication is useful for information distribution. For example, consider
the operations of a large consumer department store chain. In this case, it is critical to
ensure that product price information is always available and relatively current and
consistent at retail outlets. To achieve these goals, each retail store can have its own copy of
product price data that it refreshes nightly from a primary price table.
Disconnected Environments
To help deploy a snapshot environment to, for example, a sales force, deployment templates
allow the database administrator to pre-create a snapshot environment at the master site
for an easy, custom, and secure distribution and installation of a snapshot environment.
Deployment templates allow the DBA to create a snapshot environment once and deploy as
often as necessary to the target snapshot sites.
For example, as shown in Figure 34-10, n-way (or multimaster) replication between two
masters can support full-table replication between the databases that support two
geographic regions. Snapshots can be defined on the masters to replicate full tables or table
subsets to sites within each region.
Replicated masters must contain data for the full table being replicated, whereas
snapshots can replicate subsets of master table data.
Multimaster replication allows you to replicate changes for each transaction as the
changes occur. Snapshot refreshes are set oriented, propagating changes from
multiple transactions in a more efficient, batch-oriented operation, but at less frequent
intervals.
If conflicts occur from changes made to multiple copies of the same data, master sites
detect and resolve the conflicts.
Replication Catalog
Every master and snapshot site in a replication environment has a replication catalog. A
site's replication catalog is a distinct set of data dictionary tables and views that maintain
administrative information about replication objects and replication groups at the site.
Every server participating in a replication environment can automate the replication of
objects in replication groups using the information in its replication catalog.
To configure and manage a replication environment, each participating server uses Oracle's
replication application programming interface (API). A server's replication management API
is a set of PL/SQL packages encapsulating procedures and functions administrators can use
to configure Oracle's replication features. Oracle Replication Manager also uses the
procedures and functions of each site's replication management API to perform work.
Replication Conflicts
Asynchronous multimaster and updateable snapshot replication environments must
address the possibility of replication conflicts that may occur when, for example, two
transactions originating from different sites update the same row at nearly the same time.
When data conflicts do occur, you need a mechanism to ensure that the conflict will be
resolved in accordance with your business rules and that the data converges correctly at all
sites.
In addition to logging any conflicts that may occur in your replicated environment, Oracle
replication offers a variety of conflict resolution methods that will allow you to define a
conflict resolution system for your database that will resolve conflicts in accordance with
your business rules. If you have a unique situation that Oracle's pre-built conflict resolution
methods cannot resolve, you have the option of building and using your own conflict
routines.
Additional Information:
Procedural Replication
Procedural Replication
Batch processing applications can change large amounts of data within a single transaction.
In such cases, typical row-level replication could load a network with a large quantity of
data changes. To avoid such problems, a batch processing application operating in a
replication environment can use Oracle's procedural replication to replicate simple stored
procedure calls to converge data replicas. Procedural replication replicates only the call to a
stored procedure that an application uses to update a table. Procedural replication does not
replicate data modifications.
To use procedural replication, you must replicate the packages that modify data in the
system to all sites. After replicating a package, you must generate a wrapper for this package
at each site. When an application calls a packaged procedure at the local site to modify data,
the wrapper ensures that the call is ultimately made to the same packaged procedure at all
other sites in the replicated environment. Procedural replication can occur asynchronously
or synchronously.
When a replication system replicates data using procedural replication, the procedures that
replicate data are responsible for ensuring the integrity of the replicated data. That is, you
must design such procedures either to avoid or to detect replication conflicts and resolve
them appropriately. Consequently, procedural replication is most typically used when
databases are available only for the processing of large batch operations. In such situations,
replication conflicts are unlikely because numerous transactions are not contending for the
same data.
You can create a replicated environment with some sites propagating changes
synchronously while others use asynchronous propagation (deferred transactions).
Note: