Release 8.1.5
A67791-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Replication Release 8.1.5 A67791-01 |
|
This chapter explains the basic concepts and terminology for the Oracle replication features.
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.
The following sections explain the basic components of a replication system, including replication sites, replication groups, and replication objects.
A replication object is a database object existing on multiple servers in a distributed database system. Oracle's replication facility enables you to replicate tables and supporting objects such as views, database triggers, packages, indexes, and synonyms. SCOTT.EMP and SCOTT.BONUS illustrated in Figure 1-1 are examples of replication objects.
In a replication environment, Oracle manages replication objects using replication groups. By organizing related database objects within a replication group, it is easier to administer many objects together. Typically, you create and use a replication group to organize the schema objects necessary to support a particular database application. That is not to say that replication groups and schemas must correspond with one another. Objects in a replication group can originate from several database schemas and a schema can contain objects that are members of different replication groups. The restriction is that a replication object can be a member of only one group.
|
Note: Read-only snapshots are not required to belong to a snapshot group, nor are they required to be based on a master table that is part of a master group. |
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 1-1 illustrates that master group "SCOTT_MG" contains an exact replica of the replicated objects at each master site.
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 1-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 1-2 illustrates that each site may contain multiple replication groups.
A replication group can exist at multiple replication sites. Replication environments support two basic types of sites: master sites and snapshot sites.
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 1-4 illustrates a multimaster replication system.
Oracle database servers operating as master sites in a multimaster environment automatically work to converge the data of all table replicas, and ensure global transaction consistency and data integrity.
Multimaster replication is useful for many types of application systems with special requirements. The following scenarios describe some of the uses for multimaster replication:
Multimaster replication can be useful to protect the availability of a mission critical database. For example, a multimaster replication environment can replicate all of the data in your database to establish a failover site should the primary site become unavailable due to system or network outages. In contrast with Oracle's standby database feature, such a failover site can also serve as a fully functional database to support application access when the primary site is concurrently operational.
Multimaster replication is useful for transaction processing applications that require multiple points of access to database information for the purposes of distributing a heavy application load, ensuring continuous availability, or providing more localized data access.
Applications that have application load distribution requirements commonly include customer service oriented applications. (Application load distribution can also be achieved by using updateable snapshots - see "Snapshot Replication" for more information.)
A snapshot contains a complete or partial replica of a target master table from a single point-in-time. A snapshot may be read-only or updateable.
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 1-6 illustrates basic, read-only replication.
The following is a list of benefits of read-only snapshots:
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 1-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 (see "Snapshot Groups" for more information).
Updateable snapshots have the following properties.
Updateable snapshots have the following benefits:
Snapshot replication is useful for several types of applications. The following sections describe some of the typical uses for snapshot replication:
Read-only snapshot replication is useful as a way to replicate entire databases or off-load information. For example, when the performance of high-volume transaction processing systems is critical, it can be advantageous to maintain a duplicate database to isolate the demanding queries of decision support applications.
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.
Read-only and updateable snapshot replication can be useful as an information transport mechanism. For example, read-only snapshot replication can periodically move data from a production transaction processing database to a data warehouse.
Updateable snapshot replication is useful for the deployment of transaction processing applications that operate using disconnected components. For example, consider the typical sales force automation system for a life insurance company. Each salesperson must visit customers regularly with a laptop computer and record orders in a personal database while disconnected from the corporate computer network and centralized database system. Upon returning to the office, each salesperson must forward all orders to a centralized, corporate database.
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.
Multimaster replication and snapshots can be combined in hybrid or "mixed" configurations to meet different application requirements. Mixed configurations can have any number of master sites and multiple snapshot sites for each master.
For example, as shown in Figure 1-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.
Key differences between snapshots and replicated masters include the following:
There are several tools that are available to help you administer and monitor your replication environment. Oracle's Replication Manager provides a powerful GUI interface to help you manage your environment, while the Replication Management API provides you with the familiar application programming interface (API) to build customized scripts for replication administration. Additionally, the replication catalog keeps you informed about your replicated environment.
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.
An administration request is a call to a procedure or function in Oracle's replication management API. For example, when you use Replication Manager to create a new master group, Replication Manager completes the task by making a call to the DBMS_REPCAT.CREATE_MASTER_REPGROUP procedure. Some administration requests generate additional replication management API calls to complete the request.
Replication environments supporting both a multimaster and snapshot replication environment can be challenging to configure and manage. To help administer these replication environments, Oracle provides a sophisticated management tool, Oracle Replication Manager. Other sections in this book include information and examples for using Replication Manager.
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.
Chapter 6, "Conflict Resolution" discusses how to design your database to avoid data conflicts and how to build conflict resolution routines that resolve such conflicts when they occur. Chapter 6, "Conflict Resolution" of the Oracle8i Replication API Reference describes how to build conflict resolution routines using the Replication Management API.
Some applications have special requirements of a replication system. The following sections explain the Oracle unique replication options, including:
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. See "Using Procedural Replication".
Asynchronous data propagation is the normal configuration for replication environments. However, Oracle also supports synchronous data propagation for applications with special requirements. Synchronous data propagation occurs when an application updates a local replica of a table, and within the same transaction, also updates all other replicas of the same table. Consequently, synchronous data replication is also called real-time data replication. Use synchronous replication only when applications require that replicated sites remain continuously synchronized.
You can create a replicated environment with some sites propagating changes synchronously while others use asynchronous propagation (deferred transactions).
When a shared ownership system replicates all changes synchronously (real-time replication), replication conflicts cannot occur. With real-time replication, applications use distributed transactions to update all replicas of a table at the same time. As is the case in nondistributed database environments, Oracle automatically locks rows on behalf of each distributed transaction to prevent all types of destructive interference among transactions. Real-time replication systems can prevent replication conflicts.
