Oracle7 Server Distributed Systems Volume II: Replicated Data
Overview
The Oracle Server provides a variety of methods to replicate your data. This chapter begins with a discussion of store-and-forward, or asynchronous, replication. For asynchronous replication you can select the method that best suits your needs, from basic primary site replication to advanced dynamic and shared ownership models. Real-time (synchronous) and procedural replication, which have specialized uses, are described later in this chapter. To help you understand these replication options, this chapter discusses supporting mechanisms.
Basic Replication
Basic replication uses read-only snapshots to enforce a form of a primary site replication. As shown in Figure 1 - 1, a read-only snapshot is a full copy of a table, or a subset of a table, that reflects a recent state of the master table. A snapshot is defined by a distributed query that references one or more master tables, views, or other snapshots. A database that contains a master table is referred to as the master database.
Each replica (or copy) of the master table is called a snapshot because the information captured at a moment in time can be periodically refreshed to reflect a more recent transaction-consistent state of the master table.
A simple snapshot is based on a single remote table and has none of the following: distinct or aggregate functions; GROUP BY or CONNECT BY clauses; subqueries; joins; or set operations. If a snapshot's defining query contains any of these clauses or operations, it is a complex snapshot.
Advantages of Read-Only Snapshots
Maintaining read-only snapshots of a master table among the
nodes of a distributed database is often a useful feature for the following reasons:
- Queries can be issued against a local snapshot. Therefore, associated query performance is fast because the requested data does not have to be shipped over a network.
- If the master site becomes unavailable, for example, because of a network failure, you can continue to query the read-only copies of this data.
Groups of snapshots can be refreshed to a single point in time, allowing you to maintain transactional consistency between copies of several related master tables.
Advanced Replication
The advanced replication option supports a symmetric, update-anywhere replication model; that is, all copies of data can potentially be updated, and ultimately all sites converge on the same data.
Replication Groups
A replicated object is a database object that is copied to multiple sites in a distributed system. Replication groups are
- the basic unit for controlling and managing advanced replication
- typically created by the replication administrator for all the replication objects that are
- associated with a particular application
- to be replicated to a set of sites
When you issue a data manipulation language (DML) or data-level statement against a replicated table, that update is ultimately propagated to every other replica of the table. Oracle applies DML changes to each replica in a transactionally consistent manner to ensure data consistency and referential integrity between tables.
Oracle also applies DDL (data definition language or schema-level) changes to each replica, such as adding a column to a table.
Oracle allows you to replicate
- objects that support those tables, such as
Supporting objects are replicated because their SQL Data Definition Language (DDL) statements are replicated. For example, supporting objects are created by propagating and executing the same CREATE statement at each site.
Oracle allows you to define, replicate, and manage groups of replicated objects (replication groups) as a unit. Please note the following:
- The members of a replication group can span multiple schemas.
- A schema can contain multiple replication groups.
- A replicated object can be a member of only one replication group.
Replication Sites
A replication group can be replicated (copied) to one or more replication sites. There are two basic kinds of replication sites: master sites and snapshot sites.
A master site must receive a full copy of all of the objects in the replication group. Each master site propagates, or pushes, its changes to every other master site for the replication group.
A snapshot site can receive a subset of the objects in the replication group. For example, you may choose to replicate only selected tables to a snapshot site, or even selected portions of a table. Table-level information is replicated at snapshot sites in the form of read-only or updatable snapshots.
Read-only snapshots can be used only for queries and only the master table can be updated (see the following table). Updatable snapshots provide a local, updatable copy of a remote master table and can be defined to contain a full copy of a master table or a defined subset of rows in the master table that satisfy value-based selection criteria.
| Read-Only Snapshots
| Updatable Snapshots
|
| for queries only
| for queries and updates
|
| can be simple or complex
(derived from a single master table or more than one master table)
| must be simple (derived from a single master table)
|
Snapshot sites must have an associated master site (although this master site can change if necessary), and unlike master sites, snapshot sites only push their changes to their associated master site. Snapshot sites can also pull down changes from their associated master site. The propagation mechanisms used by master and snapshot replication sites are explained in greater detail ![[*]](jump.gif)
.
A replicated environment consists of a replication group, the replicated objects in the group, and the snapshot and master sites containing replicas of the group. Every replication group must have one and only one master definition site. The master definition site is used as the control point for performing administrative activities. Although data-level changes can be made at any site participating in a replicated environment, schema-level changes must be performed at the master definition site. However, if you experience a network outage, the master definition site can be relocated to another master site from any master site in the system.
As shown in Figure 1 - 2, a replication site can participate in multiple replication groups. For example, Site A in Figure 1 - 2 is a snapshot site for schema 3, the master definition site for schema 2, and the master site for schema 1.
Replication Catalog
The symmetric replication facility uses a replication catalog to maintain information, such as which objects are being replicated, where they are being replicated, and how updates need to be propagated to these replicas. This replication catalog consists of a set of database tables that can be backed up and recovered (like any other tables).
Additionally, these tables are themselves replicated to each master replication site, ensuring that there is no single point of failure in your replicated environment.
Once you have configured your replicated environment, any data-level changes that you make will be propagated to all of the associated replication sites. No special commands or interfaces are required.
Schema-level changes, such as those used to configure and administer a replicated environment, must be made using a replication interface. Oracle provides a number of packaged procedures that you can call to administer your replicated environment. These procedures are described, as well as in other parts of this document.
Oracle Replication Manager
Oracle Replication Manager, which can be launched as an applet from Oracle Enterprise Manager or run as a stand-alone product, is a graphical tool that lets you configure, schedule, and administer your replicated environment from a single location. Replication Manager's point-and-click interface lets you create replication groups consisting of tables as well as their supporting objects, such as indexes, triggers, views, and conflict resolution procedures. You can drag and drop a group onto other databases to add new replication sites to your environment. If you add or remove objects from a replication group, the changes are automatically deployed at every site.
Replication Manager also helps you troubleshoot and resolve error conditions. You can view the deferred transaction queue at each location, and reschedule or force immediate execution of these transactions as needed. You can also view outstanding administrative requests for each location. Additionally, you can take advantage of Enterprise Manager's event management capabilities, which provide a proactive monitoring capability of replication status across multiple site.
Additional Information: To learn more about this tool and its graphical user-interface (GUI), consult the Oracle Replication Manager online help system.
Note: The rest of this manual refers to the procedural, rather than the Replication Manager GUI, interface for replication administration.