7
Planning Your Replication Environment

Before you begin to plan your replication environment, it is important to understand the replication concepts and architecture described in the previous chapters of this book. After you understand replication concepts and architecture, this chapter presents important considerations for planning a replication environment.

This chapter covers the following topics:

• Considerations for Replicated Tables

• Initialization Parameters

• Master Sites and Snapshot Sites

• Guidelines for Scheduled Links

• Guidelines for Scheduled Purges of a Deferred Transaction Queue

• Serial and Parallel Propagation

• Deployment Templates

• Conflict Resolution

• Security

Considerations for Replicated Tables

The following sections discuss considerations for tables you plan to use in a replication environment.

Primary Keys

If possible, each replicated table should have a primary key. Where a primary key is not possible, each replicated table must have a set of columns that can be used as a unique identifier for each row of the table. If any of the tables that you plan to use in your replication environment do not have a primary key or a set of unique columns, alter these tables accordingly. In addition, if you plan to create any primary key snapshots based on a master table, that master table must have a primary key.

Datatype Considerations

Multimaster replication supports the replication of tables with columns that use the following datatypes: NUMBER, DATE, VARCHAR2, CHAR, NVARCHAR2, NCHAR, RAW, ROWID.

Oracle also supports the replication of tables with columns that use the following large object types: binary LOBs (BLOBs), character LOBs (CLOBs), and national character LOBs (NCLOBs). The deferred and synchronous remote procedure call mechanism used for multiple master replication propagates only the piece-wise changes to the supported LOB datatypes when piece-wise updates and appends are applied to these LOB columns.

Oracle does not support the replication of columns that use the LONG and LONG RAW datatypes. Oracle simply omits columns containing these datatypes from replicated tables. You should convert LONG datatypes to LOBs in Oracle8i.

Oracle also does not support user-defined object types and external or file-based LOBs (BFILEs). Attempts to configure tables containing columns of these datatypes as master tables will return an error message.

Initialization Parameters

Several initialization parameters are important for the operation, reliability, and performance of a replication environment. Table 7-1 lists these parameters.

Table 7-1 Initialization Parameters Important for Replication (Page 1 of 5)

COMPATIBLE

Default: 8.0.0

Range: 8.0.0 to Current 
Release Number

ENQUEUE_RESOURCES

Default: Derived from 
SESSIONS parameter

Range: 10 to unlimited

GLOBAL_NAMES

Default: FALSE

Range: TRUE or FALSE

JAVA_POOL_SIZE

Default: 0

Range: 0 to 4 GB

JOB_QUEUE_INTERVAL

Default: 60 (seconds)

Range: 1 to 3600 (seconds)

JOB_QUEUE_PROCESSES

Default: 0

Range: 0 to 36

MAX_ENABLED_ROLES

Default: 20

Range: 0 to 148

MTS_DISPATCHERS

Default: None

Range: Not Applicable

MTS_DISPATCHERS = "(PROTOCOL=TCP)
  (PRE=oracle.aurora.server.SGiopServer)"

OPEN_CURSORS

Default: 50

Range: 1 to 4294967295 

(4 GB -1)

OPEN_LINKS

Default: 4

Range: 0 to 255

PARALLEL_MAX_SERVERS

PARALLEL_MIN_SERVERS

Default: 0

Range: 0 to Value of 
PARALLEL_MAX_SERVERS

PROCESSES

Default: Derived from 
PARALLEL_MAX_SERVERS

Range: 6 to operating system 
dependent limit

REPLICATION_DEPENDENCY_TRACKING

Default: TRUE

Range: TRUE or FALSE 

SHARED_POOL_SIZE

Default: 16 MB
(64 MB if 64 bit)

Range: 300 KB to Operating 
System Dependent Limit
 

Master Sites and Snapshot Sites

When you are planning your replication environment, you need to decide whether the sites participating in the replication environment will be master sites or snapshot sites. Consider the characteristics and advantages of both types of replication site when you are deciding whether a particular site in your replication environment should be a master site or a snapshot site. One replication environment can support both master sites and snapshot sites.

Table 7-2 Characteristics of Master Sites and Snapshot Sites

Advantages of Master Sites

Master sites have the following advantages:

• Support for highly available data access by remote sites

• Provide better support for frequent data manipulation language (DML) changes because changes are propagated automatically and, typically, at short intervals

• Allow simultaneous DML changes and data propagation without locking tables

• Can provide failover protection

To set up a master site, you can use either the Replication Manager Setup Wizard or the replication management API.

Advantages of Snapshot Sites

Snapshot sites have the following advantages:

• Support disconnected computing

• Can contain a subset of its master site's data

To set up a snapshot site, you can use either the Replication Manager Setup Wizard or the replication management API.

Guidelines for Scheduled Links

A scheduled link determines how a master site propagates its deferred transaction queue to another master site, or how a snapshot site propagates its deferred transaction queue to its master site. When you create a scheduled link, Oracle creates a job in the local job queue to push the deferred transaction queue to another site in the system. When Oracle propagates deferred transactions to a remote master site, it does so within the security context of the replication propagator.

You can configure a scheduled link to push information using serial or parallel propagation. In general, you should use parallel propagation, even if you set parallel propagation to 1.

Before creating the scheduled links for a replication system, carefully consider how you want replication to occur globally throughout the system. For example, you may choose to propagate deferred transactions at intervals, with time in between these intervals when the deferred transactions are not propagated. In this case, you must decide how often and when to schedule pushes. Alternatively, if you want to simulate real-time (or synchronous) replication, you might want to have each scheduled link constantly push a master site's deferred transaction queue to its destination.

Also, you might want to schedule links at a time of the day when connectivity is guaranteed or when communications costs are lowest, such as during evening hours. Furthermore, you might want to stagger the scheduling for links among all master sites to distribute the load that replication places on network resources.

Scheduling Periodic Pushes

You can schedule periodic intervals between pushes of a site's deferred transaction queue to a remote destination. Examples of periodic intervals are once an hour or once a day. To do so, when configuring a scheduled link in the Replication Manager Setup Wizard, the Create Scheduled Link property sheet, or the Edit Scheduled Link property sheet, set Delay Seconds on the Option page to the default value of 0. Then configure the interval to push the deferred transaction queue using the Next Date and Interval settings on the General page.

Scheduling Continuous Pushes

Even when using Oracle's asynchronous replication mechanisms, you can configure a scheduled link to simulate continuous, real-time replication. To do so, when configuring a scheduled link in the Replication Manager Setup Wizard, the Create Scheduled Link property sheet, or the Edit Scheduled Link property sheet, set Delay Seconds on the Option page to 1,200 and set Interval to a value less than the Delay Seconds setting. With this configuration, Oracle continues to push transactions that enter the deferred transaction queue for the duration of the entire interval. If the deferred transaction queue has no transactions to propagate for delay seconds, Oracle releases the resources used by the job and starts fresh when the next SNP process becomes available.

Guidelines for Scheduled Purges of a Deferred Transaction Queue

A scheduled purge determines how a master or snapshot site purges applied transactions from its deferred transaction queue. When you use the Replication Manager Setup Wizard to create a master or snapshot site, Oracle creates a job in each site's local job queue to purge the local deferred transaction queue on a regular basis. Carefully consider how you want purging to occur before configuring the sites in a replication environment. For example, consider the following options:

• You can synchronize the pushing (scheduled links) and purging of a site's deferred transaction queue. For example, you can configure continuous pushing and purging of the transaction queue. This type of configuration might offer performance advantages because it is likely that information about recently pushed transactions is already in the server's buffer cache for the corresponding purge operation.

• When a server is not CPU bound, you can schedule continuous purging of the deferred transaction queue to keep the size of the queue as small as possible.

• For servers that experience a high-volume of transaction throughput during normal business hours, you can schedule purges to occur during off-peak hours.

Scheduling Periodic Purges

You can schedule periodic purges of a site's deferred transaction queue. Examples of periodic purges are purges that occur once a day or once a week. When configuring a site's scheduled purge using the Replication Manager Setup Wizard, or the Purge Scheduling page of the Edit DB Connection property sheet, set Delay Seconds to the default value of 0. Then configure the interval to purge the deferred transaction queue using the Next Date and Interval settings.

Scheduling Continuous Purges

To configure continuous purging of a site's deferred transaction queue when using the Replication Manager Setup Wizard, or the Purge Scheduling page of the Edit DB Connection property sheet, set Delay Seconds to 500,000 and set Interval to a value less than the Delay Seconds setting.

Serial and Parallel Propagation

When you create the scheduled links for a replication environment, each link can asynchronously propagate changes to a destination using either serial or parallel propagation. Before you configure your replication environment, decide whether you want to use serial propagation or parallel propagation.

• With serial propagation, Oracle propagates replicated transactions one at a time in the same order that they are committed on the source system. To configure a schedule link with serial propagation, use the Create Scheduled Link or Edit Scheduled Link property sheet, and disable the Parallel Propagation setting of the Options page. Typically, you should use serial propagation only when the replicated environment includes Oracle7 sites.

• With parallel propagation, Oracle propagates replicated transactions using multiple parallel streams for higher throughput. When necessary, Oracle orders the execution of dependent transactions to preserve data integrity. To configure a scheduled link with parallel propagation, use the Create Scheduled Link or Edit Scheduled Link property sheet, and enable the Parallel Propagation setting of the Options page. Set Processes to the desired degree of parallelism (1 or greater).

  See Also: "Parallel Propagation".

Deployment Templates

If you plan to include snapshot sites in your replication environment, consider using deployment templates to create the replicated objects at the snapshot sites.

Preparing Snapshot Sites for Instantiation of Deployment Templates

If you decide to use deployment templates, you need to prepare your snapshot sites for instantiation. If a deployment template has been designed well, little preparation is necessary at the remote snapshot site. This section describes the most common preparations that must be performed at the remote snapshot site. Once any required preparations have been completed, you are ready to perform either an online or offline instantiation.

Use the following questions to assess which actions are necessary to prepare the remote snapshot site for instantiation:

• Does the remote snapshot site have network connectivity to the target master site?

• Does the snapshot site have an Oracle8i Enterprise Edition, Oracle8i Standard Edition, or Oracle8i Personal Edition release 8.1.5 or higher database? Or, does the snapshot site have an Oracle8i Lite release 4.0 or higher database?

• Has the remote snapshot site been set up to support snapshot replication?

• Do the schemas required by the deployment template exist at the snapshot site?

• If required database links are not part of the deployment template, do the required database links from the snapshot site to the master site exist?

• Will you use online instantiation or offline instantiation to instantiate the deployment template at the snapshot sites?

• Do the rollback segments required by the deployment template exist at the snapshot site and are they online?

The following sections provide guidance for the issues raised by each of these questions.

Network Connectivity

As with all replicated environments, network connectivity is a key component in Oracle replication. For Oracle8i Enterprise Edition, Oracle8i Standard Edition, and Oracle8i Personal Edition, verify that the remote snapshot site has a proper SQL*Net or Net8 connection to the target master site.

Oracle8i Lite snapshot sites using Java RepAPI must be able to use an Internet Inter-ORB Protocol (IIOP) connection to communicate with a master site.

Database Version

The snapshot site must have an Oracle8i release 8.1.5 or higher database to instantiate a deployment template. If your snapshot site is using Oracle8i Lite, release 4.0 or higher must be installed. If your snapshot site does not meet the database version requirements, you need to upgrade your database at the snapshot site before instantiating a deployment template.

Snapshot Site Setup

Each snapshot site needs several users that have special privileges to support a snapshot site. In addition to having the administrative privileges, these users also participate in the propagation and refreshing of data.

Snapshot site setup also includes scheduling several automated jobs to handle the automatic refreshing of the snapshot (optional) and the purging of the deferred transaction queue.

You can setup your snapshot site with:

• Replication Manager: You can connect to the remote snapshot site with Replication Manager and use the Setup Wizard.

  See Also: The Replication Manager online help for instructions on setting up your snapshot site with Replication Manager.

• Replication Management API: Using the replication management API to setup your snapshot site is an ideal solution when you are not able to connect to the remote snapshot site with Replication Manager. When you build a SQL script containing the API calls to setup your snapshot site, you can also add the DDL and API calls to complete the remaining preparation (such as creating necessary schema, database links, and rollback segments, as described in the following three sections). The script that you create should be distributed with the offline instantiation file and executed before the offline instantiation file.

  See Also: "Set Up Snapshot Sites" in Chapter 2 of Oracle8i Replication Management API Reference for instructions on setting up your snapshot site with the replication management API.

Create Necessary Schema

If the deployment template that you are instantiating will create objects in multiple schemas, make sure that all of the necessary schemas have been created. Additionally, the user instantiating the deployment template must have the appropriate CREATE privileges on that schema. For example, if the deployment template will create a procedure in schema MARY and the user SCOTT is instantiating the template, SCOTT must have the CREATE ANY PROCEDURE privilege on schema MARY.

Create Database Links

While it is advantageous to include the DDL to create all necessary database links for a remote snapshot site in the deployment template, it is not required. If the database link DDL is not in the deployment template, manually create the database links to the target master site prior to instantiating the deployment template. The database links are required to populate the snapshot base tables during an online instantiation and are required for the proper maintenance of the snapshot environment.

Online or Offline Instantiation

You have the option of performing online or offline instantiation of deployment templates at snapshot sites. With online instantiation, the data in your snapshots is pulled from the master site during instantiation. With offline instantiation, the data in your snapshots is packaged in the template itself and is applied locally when you instantiate the template. In general, if your snapshots will contain a large amount of data, offline instantiation is preferred to minimize utilization of your network resources.

Create Necessary Rollback Segment

If the deployment template that you are instantiating will use specific rollback segments that do not currently exist at the remote snapshot site, create the necessary rollback segments. To see if your template objects use the default rollback segment or a specific rollback segment, query the DBA_REPCAT_TEMPLATE_OBJECTS view.

Conflict Resolution

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. If possible, plan your replication environment to avoid the possibility of conflicts. If data conflicts may occur in your replication environment, you need a mechanism to ensure that the conflict is resolved in accordance with your business rules and to ensure that the data converges correctly at all sites.

Security

Security may be a concern in both multimaster and snapshot replication environments. You should plan your security strategy before you configure your replication environment.