Oracle8i Replication
Release 2 (8.1.6)

Part Number A76959-01

Library

Product

Contents

Index

Go to previous page Go to next page

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

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.


Note:

Oracle8i does not support replication of LOB datatypes in replication environments where some sites are running Oracle7 release 7.3. 


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.

See Also:

Oracle8i Reference for more information about these initialization parameters. 

Table 7-1 Initialization Parameters Important for Replication (Page 1 of 5)
Parameter  Values  Description 
COMPATIBLE
 
Default: 8.0.0

Range: 8.0.0 to Current 
Release Number
 

COMPATIBLE lets you use a new release, while at the same time guaranteeing backward compatibility with an earlier release. This ability is helpful in case it becomes necessary to revert to the earlier release.

This parameter specifies the release with which the Oracle server must maintain compatibility.

When a snapshot site COMPATIBLE setting is less than 8.1.0, a snapshot view is created for each snapshot to maintain compatibility with releases prior to release 8.1.0. If COMPATIBLE is set to 8.1.0 or higher at a snapshot site, no view is created for snapshots. 

ENQUEUE_RESOURCES
 
Default: Derived from 
SESSIONS parameter

Range: 10 to unlimited

 

ENQUEUE_RESOURCES sets the number of resources that can be concurrently locked by the lock manager. An enqueue is a sophisticated locking mechanism that permits several concurrent processes to share known resources to varying degrees. Any object that can be used concurrently can be protected with enqueues. For example, Oracle allows varying levels of sharing on tables: two processes can lock a table in share mode or in share update mode.

ENQUEUE_RESOURCES must be set to at least 1000 if the Oracle server supports Java RepAPI. 

GLOBAL_NAMES
 
Default: FALSE

Range: TRUE or FALSE
 

GLOBAL_NAMES specifies whether a database link is required to have the same name as the database to which it connects. GLOBAL_NAMES must be set to TRUE to use Oracle replication. 

JAVA_POOL_SIZE
 
Default: 0

Range: 0 to 4 GB
 

JAVA_POOL_SIZE specifies the size in bytes of the Java pool, from which the Java memory manager allocates most Java state during runtime execution. This memory includes the shared in-memory representation of Java method and class definitions, as well as the Java objects that are migrated to the Java session space at end-of-call.

JAVA_POOL_SIZE must be set to at least 50000000 if the Oracle server supports Java RepAPI. 

JOB_QUEUE_INTERVAL
 
Default: 60 (seconds)

Range: 1 to 3600 (seconds)
 

JOB_QUEUE_INTERVAL specifies in seconds how frequently each SNPn background process of the instance wakes up. The setting for this parameter should be at least as frequent as the most frequent scheduled job. 

JOB_QUEUE_PROCESSES
 
Default: 0

Range: 0 to 36
 

JOB_QUEUE_PROCESSES specifies the number of SNPn job queue processes per instance (SNP0, ... SNP9, SNPA, ... SNPZ). Job queue processes process requests created by DBMS_JOB.

This parameter should be set to at least 1, and should be set to the same value as the maximum number of jobs that can run simultaneously.

When JOB_QUEUE_PROCESSES is set to 0 at a site, you must apply administration requests manually for all groups at the site, and you must manually push and purge the deferred transaction queue. 

MAX_ENABLED_ROLES
 
Default: 20

Range: 0 to 148
 

MAX_ENABLED_ROLES specifies the maximum number of database roles that users can enable, including roles contained within other roles.

The actual number of roles user can enable is 2 plus the value of MAX_ENABLED_ROLES, because each user has two additional roles, PUBLIC and the user's own role. For example, if MAX_ENABLED_ROLES is set to 5, user SCOTT can have seven roles enabled: the five enabled by MAX_ENABLED_ROLES plus PUBLIC and SCOTT.

MAX_ENABLED_ROLES must be set to at least 30 if the Oracle server supports Java RepAPI. 

MTS_DISPATCHERS
 
Default: None

Range: Not Applicable

 

MAX_DISPATCHERS configures dispatcher processes in the multi-threaded server (MTS) architecture. The parsing software supports a name-value syntax to enable the specification of attributes in a position-independent case-insensitive manner.

MAX_DISPATCHERS must be set to the following if the Oracle server supports Java RepAPI:

MTS_DISPATCHERS = "(PROTOCOL=TCP)
  (PRE=oracle.aurora.server.SGiopServer)"
 
OPEN_CURSORS
 
Default: 50

Range: 1 to 4294967295 
(4 GB -1)
 

OPEN_CURSORS specifies the maximum number of open cursors (handles to private SQL areas) a session can have at once. You can use this parameter to prevent a session from opening an excessive number of cursors. This parameter also constrains the size of the PL/SQL cursor cache, which PL/SQL uses to avoid having to reparse as statements are re-executed by a user.

It is important to set the value of OPEN_CURSORS high enough to prevent your application from running out of open cursors. The number will vary from one application to another. Assuming that a session does not open the number of cursors specified by OPEN_CURSORS, there is no added overhead to setting this value higher than actually needed.

OPEN_CURSORS must be set to at least 100 if the Oracle server supports Java RepAPI. 

OPEN_LINKS
 
Default: 4

Range: 0 to 255
 

OPEN_LINKS specifies the maximum number of concurrent open connections to remote databases in one session. These connections include the schema objects called database links, as well as external procedures and cartridges, each of which uses a separate process.

OPEN_LINKS must be set to at least 10 if the Oracle server supports Java RepAPI. 

PARALLEL_MAX_SERVERS
 

Default: Derived from the values of the following parameters:

CPU_COUNT

PARALLEL_AUTOMATIC_TUNING

PARALLEL_ADAPTIVE_MULTI_USER

Range: 0 to 3599 

PARALLEL_MAX_SERVERS specifies the maximum number of parallel execution processes and parallel recovery processes for an instance. As demand increases, Oracle will increase the number of processes from the number created at instance startup up to this value.

If you use parallel propagation, make sure the value of this parameter is set high enough to support it. 

PARALLEL_MIN_SERVERS
 
Default: 0

Range: 0 to Value of 
PARALLEL_MAX_SERVERS
 

PARALLEL_MIN_SERVERS specifies the minimum number of parallel execution processes for the instance. This value is the number of parallel execution processes Oracle creates when the instance is started.

If you use parallel propagation, make sure you have at least one process for each stream. 

PROCESSES
 
Default: Derived from 
PARALLEL_MAX_SERVERS

Range: 6 to operating system 
dependent limit

 

PROCESSES specifies the maximum number of operating system user processes that can simultaneously connect to Oracle. Its value should allow for all background processes such as locks, job queue processes, and parallel execution processes. 

REPLICATION_DEPENDENCY_TRACKING
 
Default: TRUE

Range: TRUE or FALSE 
 

REPLICATION_DEPENDENCY_TRACKING enables or disables dependency tracking for read/write operations to the database. Dependency tracking is essential for propagating changes in a replicated environment in parallel.

TRUE: enables dependency tracking.

FALSE: allows read/write operations to the database to run faster, but does not produce dependency information for Oracle to perform parallel propagation. Do not specify FALSE unless you are sure that your application will perform no read/write operations to the replicated tables. 

SHARED_POOL_SIZE
 
Default: 16 MB
(64 MB if 64 bit)

Range: 300 KB to Operating 
System Dependent Limit
 
 

SHARED_POOL_SIZE specifies in bytes the size of the shared pool. The shared pool contains shared cursors, stored procedures, control structures, and other structures. Larger values improve performance in multi-user systems. Smaller values use less memory.

Typically, the shared pool should be larger for an Oracle server in a replication environment than in a non-replication environment.

You can monitor utilization of the shared pool by querying the view V$SGASTAT.

SHARED_POOL_SIZE must be set to at least 50000000 if the Oracle server supports Java RepAPI. 

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
Master Sites  Snapshot Sites 
  • Typically communicate with a small number of other master sites, and may communicate with a large number of snapshot sites

 
  • Communicate with one master site

 
  • Contain large amounts of data that are full copies of the other master sites' data

 
  • Contain small amounts of data that can be subsets of the master sites' data

 
  • Typically communicate continuously with short intervals between data propagation

 
  • Communicate periodically with longer intervals between bulk data transfers

 


Note:

Master sites require either Oracle8i Enterprise Edition or Oracle8i Standard Edition. Oracle8i Standard Edition supports only single master site configurations. Snapshot sites require one of the following: Oracle8i Enterprise Edition, Oracle8i Standard Edition, Oracle8i Personal Edition, or Oracle8i Lite. In addition, replication must be installed on all master sites and snapshot sites. 


Advantages of Master Sites

Master sites have the following advantages:

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

See Also:

  • The Replication Manager online help for instructions on using the Replication Manager Setup Wizard to set up a master site.

  • "Setup Master Sites" in Chapter 2 of Oracle8i Replication Management API Reference for instructions on using the replication management API to set up a master site.

  • "Designing for Survivability" for information about designing your replication environment for failover protection.

 

Advantages of Snapshot Sites

Snapshot sites have the following advantages:

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

See Also:

  • The Replication Manager online help for instructions on using the Replication Manager Setup Wizard to set up a snapshot site.

  • "Set Up Snapshot Sites" in Chapter 2 of Oracle8i Replication Management API Reference for instructions on using the replication management API to set up a snapshot site.

 

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.

See Also:

"Serial and Parallel Propagation" for more information about issues related to serial and parallel propagation. 

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.

See Also:

"Delay Seconds" for more information about setting delay seconds. 

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:

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.

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.

See Also:

Chapter 4, "Deployment Templates Concepts & Architecture" for information about deployment templates. 

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:

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.

See Also:

Net8 Administrator's Guide for information about setting up an Oracle network connection with SQL*Net or Net8. 

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.

See Also:

The Oracle8i Lite documentation for information about setting up snapshot clients with IIOP, and see Appendix C, "Configuring the Oracle8i Server for RepAPI" for information about setting up the server to accept these connections. 

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:

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.

See Also:

"Packaging and Instantiating Deployment Templates" for more information about online and offline instantiation. 

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.

See Also:

"Conflict Resolution Concepts & Architecture" for more information about avoiding conflicts and for information about the conflict resolution methods available to you if conflicts may occur. 

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.

See Also:

Appendix A, "Security Options" in the Oracle8i Replication Management API Reference for information about security options in a replication environment. 


Go to previous page Go to next page
Oracle
Copyright © 1996-2000, Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index