Oracle8(TM) Server Replication
Release 8.0

A54651-01

Library

Product

Contents

Index

Prev Next

3
Using Multimaster Replication

This chapter explains how to configure and manage an advanced replication system that uses multimaster replication. This chapter covers the following topics.

Note: This chapter explains how to manage a multimaster replication system that uses the default replication architecture-row-level replication using asynchronous propagation. For information about configuring procedural replication and synchronous data propagation, see Chapter 7, "Advanced Techniques". Also, examples appear throughout this chapter of how to use the Oracle Replication Manager tool to manage a multimaster replication system. Each section lists equivalent replication management API procedures for your reference. For complete information about Oracle's replication management API, see Chapter 10, "Replication Management API Reference".

Quick Start: Building a Multimaster Replication Environment

To create a multimaster advanced replication environment, you must complete the following steps at a minimum:

  1. Design the advanced replication environment. Decide what tables and supporting objects to replicate to multiple databases, and organize replication objects in suitable master groups.
  2. Use Replication Manager's setup wizard to configure a number of databases to support a multimaster replication environment. The Replication Manager setup wizard quickly configures all components necessary to support a multimaster replication system.
  3. Using the Replication Manager database connection to the master definition site, create one or more master groups to replicate tables and related objects to multiple master sites.
  4. Grant privileges necessary for application users to access data at each site.

For detailed information about each step and other optional configuration steps, see the later sections of this chapter.

A Simple Example

The following simple example demonstrates the steps necessary to build a multimaster replication environment.

Step 1: Design the Environment

The first step is to design the basic replication environment. This example demonstrates how to replicate the tables SCOTT.EMP and SCOTT.DEPT tables at the master sites DBS1 and DBS2. DBS1 is designated as the master definition site for the system.

Note: The primary key of SCOTT.EMP is the EMPNO column, and the primary key of SCOTT.DEPT is the DEPTNO column.

Step 2: Use the Replication Manager Setup Wizard

The Replication Manager setup wizard helps you configure the supporting accounts, links, schemas, and scheduling at all master sites in a multimaster replication system. For this example, use the setup wizard to:

Step 3: Create a Master Group

In a multimaster replication environment, Oracle replicates tables and related replication objects as part of a master group. Using the database connection to the master definition site DBS1, open Replication Manager's Create Master Group property sheet to create a new master group called EMPLOYEE. Use the property sheet's pages to identify the replication objects for the group, SCOTT.EMP and SCOTT.DEPT, as well as the other master site, DBS2. By default, Replication Manager generates replication support for all objects in the group and then resumes replication activity for the group.

Step 4: Grant Access to Replication Objects

After configuring a multimaster replication environment, grant access to the various replication objects so that users that connect to each site can use them.

GRANT SELECT ON scott.emp TO ... ;

Other Steps

This simple example does not mention several optional steps that might be necessary to configure certain multimaster replication systems. For example, when an advanced replication system uses a shared ownership data model, you'll want to configure conflict resolution for all replicated tables before resuming replication activity for a master group. Refer to the remainder of this chapter for more detailed information about configuring multimaster replication systems.

Preparing for Multimaster Replication

Before starting to build a multimaster advanced replication environment, you must prepare each participating database with the following:

The Replication Setup Wizard

Preparing all sites for a default multimaster replication configuration is a simple process using Replication Manager's replication setup wizard. At each master site that you specify, this wizard performs the following steps:

To start the Replication Manager setup wizard:

  1. Click File.
  2. Click Setup Wizard.

The following sections explain how to use the Replication Manager setup wizard to prepare the master sites in a multimaster replication system.

Create Master Sites

The initial page of the replication setup wizard prompts you to indicate what type of replication environment setup that you want to perform.

  1. Select Setup Master Sites.
  2. Click Next.

The next page of the wizard lets you create a list of the master sites in the new multimaster replication system. At this point, it is likely that you will not have any Replication Manager database connections available to use for the setup wizard. When this is the case, perform the following steps

  1. Click New.
  2. In the New Master Site dialog that appears, enter the global database name of a master site in the proposed system, as well as the password for the SYSTEM account at the site. (The setup wizard uses the SYSTEM account to perform subsequent configuration tasks.)
  3. When you finish, click Add to add the site to the list of master sites in the setup wizard.
  4. Repeat Step 2 for each master site. After you enter the final site's information, click OK to add the site and dismiss the dialog.
  5. After reviewing the list of master sites, click Next to continue.

Create Replication Administrator, Propagator, and Receiver Accounts

The next page of the wizard lets you specify information for the database accounts that will function as each master site's replication administrator, propagator, and receiver. The wizard creates accounts with the same name and password at all master sites in the system.

The setup wizard supports two different types of master site account setups.

Create Schemas to Organize Replication Objects

The next page of the setup wizard lets you indicate what schemas to create as schemas that will contain replication objects. The wizard creates schemas with the same name and password at all master sites in the system.

To add new schemas to the list

  1. Click New.
  2. In the New Replicated Object Schema dialog that appears, enter the name of a schema that you want to use to contain replication objects, as well as the password for the schema. When you finish, click Add to add the schema to the list of schemas in the setup wizard.
  3. Repeat Steps 1 and 2 for each schema. After you enter the final schema's information, click OK to add and dismiss the New Replicated Object Schema dialog.
  4. After reviewing the list of schemas, click Next to continue.

Create Scheduled Links

The next page of the setup wizard lets you indicate default propagation characteristics for all master sites in the system. The setup wizard uses this information to create corresponding scheduled links from each master site to all other master sites. For explanations of each setting in this page of the wizard, see "Creating a Scheduled Link" on page 3-9.

After reviewing the default scheduling settings, click Next to continue.

Specify Purge Scheduling

The next page of the setup wizard lets you configure the default purge schedule for the deferred transaction queue at each master site in the system. For explanations of each setting in this page of the wizard, see "Purging a Site's Deferred Transaction Queue" on page 3-13.

After reviewing the default purge settings, click Next to continue.

Customize Each Master Site

The next page of the setup wizard lets you customize settings for individual master sites in the system. If you choose not to customize master sites in the system, each site will have matching

To customize a master site's settings:

  1. Select the target master site to customize.
  2. Click Customize.

Next, use the pages of the Customize Master Site property sheet to customize the target master site's

After reviewing the customized settings for a master site, click OK. To customize another master site's settings, repeat the process above. When you are finished customizing all master sites, click Next to continue.

Reviewing and Building the Configuration

The next page of the setup wizard asks if you are ready to complete the configuration of the multimaster advanced replication system. When you are ready, click Finish to continue. Replication Manager then presents an informational dialog that lets you quickly review your settings.

After you click Finish, Replication Manager builds the multimaster replication environment.

Note: If you want to record a script of the API procedures that are executed during the setup process, click Record a script before building the system. Additionally, Replication Manager records the script Repsetup.log in the current working directory.

What's Next?

After using the Replication Manager setup wizard, you should continue configuration by completing the following steps.

  1. Create the master groups at the site that serves as each group's master definition site. See "Managing Master Groups" on page 3-16 for more information about creating and managing master groups.
  2. Create or identify the replication objects for each master group at its master definition site. See "Adding Objects to a Master Group" on page 3-20 for more information about creating and managing replicated objects.
  3. Configure conflict resolution for all replicated tables in each master group. See Chapter 5, "Conflict Resolution" for more information about configuring conflict resolution for replication objects.
  4. Resume replication activity for each master group. See "Resuming Replication Activity for a Master Group" on page 3-20 for more information about managing the replication activity for master groups.
  5. Monitor the multimaster environment to ensure that the system is operating properly. See "Monitoring a Multimaster Replication System" on page 3-42 for more information about monitoring the activity of master groups.

Starting SNP Background Processes

To simplify administration, most advanced replication environments configure data propagation to occur automatically. Accordingly, each master site in an advanced replication environment must start one or more SNP background processes. The following initialization parameters control the SNP background process setting for each server.

Managing Scheduled Links

Scheduled links are necessary to propagate replicated data from one replication site to another. In a multimaster replication environment, each master site requires a scheduled link to move data to every other master site. Additionally, a snapshot site with updatable snapshots requires a scheduled link to move data to its corresponding master site.

Among other things, Replication Manager's setup wizards prepare each multimaster or snapshot site environment with the necessary scheduled links. Replication Manager also has features that allow you to manage scheduled links. The following sections explain more about managing scheduled links.

Creating a Scheduled Link

To create a new scheduled link:

  1. Click anywhere in the open database connection that connects to the site where you want to create the link.
  2. Click the Create New toolbar button.
  3. Click New Scheduled Link.

Use the Create New Scheduled Link property sheet to create the new link. The following sections explain the settings that are available for the General and Options pages of this property sheet.

Database Link

The database link to use for the new scheduled link. Click Browse to display the Set Scheduled Link dialog and select a database link.

Next Date

The initial time to push changes to the new destination. Click Edit to display the Set Date dialog and set a time for the Next Date field.

Interval Expression

The automatic interval to push changes to the new destination. Click Edit to display the Set Interval dialog and set a time for the Interval field.

Enabled

Check to immediately enable the new scheduled link and push changes to the new destination.

Note: If the target destination is unavailable when creating the link, consider disabling the new scheduled link. This way, Oracle does not try to push changes to the unavailable destination.

Parallel Propagation

Whether to use parallel propagation (or serial propagation) for the scheduled link. When checked, you can set parallel propagation settings for the link. When unchecked, the new scheduled link uses serial propagation.

Processes

The number of background processes that the scheduled link uses for parallel propagation of information to the destination. The default value, 0, is an alternate way to indicate serial propagation for the link. A value n that is greater than 0 indicates parallel propagation with n background processes.

Delay Seconds

The amount of time to sleep after starting the push of the local deferred transaction queue, even if the queue is empty. See "Guidelines for Scheduled Links" on page 3-10 for more information about this setting.

Batch Size (Oracle7 Database Only)

It determines how often to commit transactions when pushing the local deferred transaction queue. The default, 0, indicates that you want to commit each transaction as it pushes to the remote destination. When using serial propagation for the scheduled link, setting Batch Size to a higher value can commit several deferred transactions in one operation and reduce the overhead from many transaction commits.

Stop on Error

How to react after an error occurs while pushing the local deferred transaction queue. The default, unchecked, indicates that propagation of the local deferred transaction queue should continue. When checked, Oracle stops execution of deferred transactions.

API Equivalents: DBMS_DEFER_SYS.SCHEDULE_PUSH, DBMS_DEFER_SYS.SCHEDULE_EXECUTION (Oracle7 Database Only)

Guidelines for Scheduled Links

A scheduled link determines how a master site propagates its deferred transaction queue to another master site (or from a snapshot site 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. Additionally, you can configure a scheduled link to push information using serial or parallel propagation. Before creating the scheduled links for an advanced replication system, carefully consider how you want replication to occur globally throughout the system.

For example, to simulate near real-time replication, you might want to have each scheduled link constantly push a master site's deferred transaction queue to its destination. Alternatively, when you choose to propagate deferred transactions at regular intervals, you must decide how often and when to schedule pushes. You might want 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 Continuous Pushes

Even when using Oracle's asynchronous replication mechanisms, you can configure a scheduled link to simulate continuous, real-time replication. 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 500,000.

Scheduling Periodic Pushes

Alternatively, you can schedule periodic pushes of a site's deferred transaction queue to a remote destination. 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, 0. Then configure the interval to push the deferred transaction queue using the Next Date and Interval settings on the General page.

Deciding between Serial and Parallel Propagation

A scheduled link can push a site's deferred transaction queue using either serial or parallel propagation. For more information about issues related to serial and parallel propagation, see "Planning for Parallel Propagation" on page 3-38.

Editing a Scheduled Link

To edit the refresh interval or propagation characteristics for a scheduled link, or disable a scheduled link

  1. Click on the target scheduled link.
  2. Click the Properties toolbar button.

Use the Edit Scheduled Link property sheet to modify the properties of the scheduled link and apply your changes. See "Creating a Scheduled Link" on page 3-9 for more information about the properties that you can adjust for a scheduled link.

API Equivalents: DBMS_DEFER_SYS.SCHEDULE_PUSH, DBMS_DEFER_SYS.SET_DISABLED, DBMS_DEFER_SYS.SCHEDULE_EXECUTION (Oracle7 only)

Viewing the Status of a Scheduled Link

To list the status of all scheduled links for a site, use Replication Manager.

  1. Click anywhere in the open database connection that connects to the site where you want to view links.
  2. Click the Scheduling folder.
  3. Click the Links folder.

The detail panel of Replication Manager displays a list of all scheduled links for the site, including the current status (enabled or disabled) of each link.

API Equivalent: DBMS_DEFER_SYS.DISABLED

Deleting a Scheduled Link

To delete a scheduled link

  1. Click on the target scheduled link.
  2. Click the Delete toolbar button.

API Equivalent: DBMS_DEFER_SYS.UNSCHEDULE_PUSH

Purging a Site's Deferred Transaction Queue

After successfully pushing a deferred transaction to its destination master site, the transaction does not have to remain in the site's deferred transaction queue. Regular purging of applied deferred transactions from a site's deferred transaction queue keeps the size of the queue manageable. When you use the Replication Manager setup wizard to configure an advanced replication system, the wizard configures purging for all master and snapshot sites in the system. The settings for a site's purge schedule include:

Next Date

The next time to purge applied transactions from the local deferred transaction queue. Click Edit to display the Set Date dialog and set a time for the Next Date field.

Interval Expression

The automatic interval to purge applied transactions from the local deferred transaction queue. Click Edit to display the Set Interval dialog and set a time for the Interval field.

Rollback Segment

The rollback segment to target when performing a purge of the local deferred transaction queue. Click Browse to display the Select a Rollback Segment dialog and pick a rollback segment in the database. A null value for this setting allows Oracle to pick the rollback segment when purging the deferred transaction queue.

Note: When you expect a purge of the local deferred transaction queue to generate a large amount of rollback data, target a sufficiently large rollback segment.

Delay Seconds

The amount of time to sleep after starting the purge of the local deferred transaction queue, even if the queue is empty. Useful for reducing overhead when scheduled purges happen frequently.

API Equivalents: DBMS_DEFER_SYS.SCHEDULE_PURGE, DBMS_DEFER_SYS.SCHEDULE_EXECUTION (Oracle7 only)

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 Replication Manager's setup wizards 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 an advanced replication system. For example:

Scheduling Continuous Purges

To configure continuous purging of a site's deferred transaction queue when using a Replication Manager setup wizard, or the Purge Scheduling page of the Edit DB Connection property sheet, set Delay Seconds to 500,000.

Scheduling Periodic Purges

Alternatively, you can schedule periodic purges of a site's deferred transaction queue. When configuring a site's scheduled purge using a Replication Manager setup wizard, or the Purge Scheduling page of the Edit DB Connection property sheet, set Delay Seconds to the default value, 0. Then configure the interval to purge the deferred transaction queue using the Next Date and Interval settings.

Specifying a Site's Purge Schedule

If you manually configured a master or snapshot site or want to modify a site's purge schedule, use the Edit DB Connection property sheet. To edit the purge schedule for a site:

  1. Click on a database connection to the site.
  2. Click the Properties toolbar button.

Use the Purge Scheduling page of the Edit DB Connection property sheet to modify the purge schedule for the site and apply your changes.

API Equivalents: DBMS_DEFER_SYS.SCHEDULE_PURGE, DBMS_DEFER_SYS.SCHEDULE_EXECUTION (Oracle7 only)

Manually Purging a Site's Deferred Transaction Queue

To manually purge a master or snapshot site's deferred transaction queue, use the Edit DB Connection property sheet. To edit the purge schedule for a site:

  1. Click on a database connection to the site.
  2. Click the Properties toolbar button.
  3. Click on the Purge Scheduling page.
  4. Click Purge Now.

API Equivalents: DBMS_DEFER_SYS.PURGE

Managing Master Groups

Each master site in an advanced replication system maintains a complete copy of all objects in a replication group. A replication group at a master site is more specifically referred to as a master group. Replication Manager has many features that let you create and manage master groups.

The following sections explain more about managing master groups.

Creating a Master Group

To create a new master group in an advanced replication environment, use the Create Master Group property sheet of Replication Manager. To create a new master group

  1. Click anywhere in the open database connection that connects to the new master group's master definition site. When selecting a master definition site for a new master group, choose the site that is most likely to be available at all times. You can change a group's master definition site later, if necessary.
  2. Click the Create New toolbar button.
  3. Click New Master Group.

The Create Master Group property sheet has three pages: General, Objects, and Destinations. The settings of the Objects and Destinations pages are optional; if used, they enable Replication Manager to complete more configuration steps when creating a master group.

Note: During the creation of a new master group, Replication Manager might prompt for supplemental information to create the group and the replication objects that you identify. For example, when you create a new master group along with a replicated table that does not have a primary key, Replication Manager displays the Set Alternate Key Columns dialog so that you can identify an alternate identity column or set of columns for the replicated table. Replication Manager also prompts whether or not to enable replication activity for the group after creation.

Warning: If you decide to add one or more tables to a master group during creation of the group, make sure not to resume replication activity. First consider the possibility of replication conflicts, and configure conflict resolution for the replicated tables in the group. See Chapter 5, "Conflict Resolution" for more information about configuring conflict resolution for master group objects.

API Equivalent: DBMS_REPCAT.CREATE_MASTER_REPGROUP

Using Connection Qualifiers for a Master Group

Connection qualifiers allow several database links pointing to the same remote database to establish connections using different paths. For example, a database can have two public database links DBS1 that connect to the remote database using different paths.

Additional Information: See Chapter 2 of Oracle8 Server Distributed Databases to learn about defining connection qualifiers for a database link.

When you create a new master group, you can indicate that you want to use a connection qualifier for all scheduled links that correspond to the group. However, when you use connection qualifiers for a master group, Oracle propagates information only after you have created database links with connection qualifiers at every master site.

For example, consider a multimaster configuration with two master sites, DBS1 and DBS2, and two master groups, MG1 and MG2. You want the group MG1 to use the connection qualifier ETHERNET and the group MG2 to use the connection qualifier MODEM. To accomplish this configuration:

Caution: To preserve transaction integrity in a multimaster environment that uses connection qualified links and multiple master groups, a transaction cannot manipulate replication objects in multiple groups.

Attention: If you plan to use connection qualifiers, you will probably need to increase the value of the initialization parameter OPEN_LINKS at all master sites. The default is four open links per process. You will need to estimate the required value based on your usage. See the Oracle8 Server Reference Manual for more information about the parameter OPEN_LINKS.

Deleting a Master Group

To remove a master group from all master sites in an advanced replication environment:

  1. Click on the target master group at its master definition site.
  2. Click the Delete toolbar button.

API Equivalent: DBMS_REPCAT.DROP_MASTER_REPGROUP

Suspending Replication Activity for a Master Group

Before completing most administrative operations for a master group or any of its replication objects, Oracle requires that you suspend replication activity for the master group at all master sites. Suspending replication activity is also called quiescing the master group.

Oracle requires that you suspend replication activity before completing the following administration tasks:

You may find it necessary to suspend replication activity for a group in other situations as well. For example, administrators may wish to suspend activity and perform queries and updates manually on master group table replicas to restore equivalence if an unexpected conflict is detected that was not resolved.

Warning: Before performing any administration task that requires you to suspend replication activity of a group, wait until the status of the group is "quiescing" at the master definition site. If the presence of a nonempty deferred transaction queue or replication trigger at a site could cause a problem, you should wait until this status of the group is "quiesced" before proceeding.

To suspend replication activity for a master group:

  1. Click the target master group in the database connection the connects to the group's master definition site.
  2. Click the Properties toolbar button.
  3. Click the Operations page of the Edit Master Group property sheet.
  4. Click Suspend Replication.

After suspending replication activity for a master group, monitor the status of the master group at all master sites before completing any administrative operation at the master definition site.

Note: When you request Oracle to suspend replication activity for a master group, Oracle first pushes the deferred transaction queue at all master sites before "quiescing" the group. During the process, Replication Manager displays the status of the group "Await Callback." Once the process completes at all sites, Replication Manager displays the status of the group "Quiesced."

API Equivalent: DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY

Resuming Replication Activity for a Master Group

After completing administrative operations for a master group or any of its replication objects, you can resume replication activity for the master group at all master sites.

Note: Before resuming replication activity for a master group, ensure that there are no unexpected errors by checking the status of the group's administration requests.

To resume replication activity for a master group:

  1. Click the target master group in the database connection the connects to the group's master definition site.
  2. Click the Properties toolbar button.
  3. Click the Operations page of the Edit Master Group property sheet.
  4. Click Resume Replication.

After resuming replication activity for a master group, monitor the status of the master group to ensure that replication activity resumes without errors.

API Equivalent: DBMS_REPCAT.RESUME_MASTER_ACTIVITY

Adding Objects to a Master Group

After suspending replication activity of a master group, you can identify new replication objects for the group. Oracle lets you replicate tables, views, synonyms, indexes, triggers, procedures, functions, and packages as part of a master group. To add one or more objects to a master group:

  1. Open the Database Objects folder at the master definition site.
  2. Drag and drop selected database objects into the target master group at the same master definition site.

You can also use the Add Objects to Group dialog and Edit Master Group property sheet to add objects to a master group.

Warnings: To avoid name conflicts for generated objects, the name of a replicated table should not exceed 27 bytes. Also, do not explicitly replicate indexes that correspond to PRIMARY KEY and UNIQUE constraints for replicated tables in a master groups. Oracle automatically replicates all table constraint definitions, which in turn replicates indexes that are necessary to enforce constraints.

When adding an object to a master group, you must also consider the following administrative operations:

API Equivalent: DBMS_REPCAT.CREATE_MASTER_REPOBJECT

Designating an Alternate Key for a Replicated Table

Oracle must be able to uniquely identify and match corresponding rows at different sites during data replication. Typically, Oracle's advanced replication facility uses the primary key of a table to uniquely identify rows in the table. When a table does not have a primary key, you must designate an alternate key-a column or set of columns that Oracle can use to identify rows in the table during data replication.

Warning: Applications should not be allowed to update the identity columns of a table to ensure that Oracle can identify rows and preserve the integrity of replicated data.

When you create a new master group along with a table that does not have a primary key, or attempt to add to a master group a table that does not have a primary key, Replication Manager automatically displays the Set Alternate Key Columns dialog so that you can identify an alternate identity column or set of columns for the replicated table.

API Equivalent: DBMS_REPCAT.SET_COLUMNS

Datatype Considerations for Replicated Tables

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: Oracle8 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.

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 masters will return an error message.

Replicating Object Definitions to Master Sites

When you add an object to a master group, Replication Manager prompts you whether to "use existing object if present."

Allowing Oracle to Create Objects

By default, when you add an object to a group at the master definition site, Oracle can use the definition of the object to create the same object at all master sites. This option requires less administrative work but creates network traffic due to initial object creation.

Manually Creating Objects

Before adding an object to a group at the master definition site, you can manually create an identical object definition at each master site. Later, when you add the object to the group, Oracle can use the existing objects and forego creating the object at each master site.

Manual creation of replication objects helps to minimize network traffic when you are configuring large replication environments. You might also have to consider this option when a master group contains tables with circular dependencies or a specific table contains a self-referential constraint.

When you choose to precreate replication objects, consider the following issues:

Replicating Table Data to Master Sites

When you add a table to a master group, Replication Manager prompts you whether to "copy row data."

Allowing Oracle to Replicate Table Data

By default, when you add a table to a group at the master definition site, Oracle can replicate the data of the master definition site table to the table at all master sites. This option requires less administrative work but creates network traffic due to initial object creation.

Manually Loading Table Data

Before adding an table to a group at the master definition site, you can precreate an identical table structure at each master site and then manually load identical data into each table replica. Later, when you add the object to the group at the master definition site, Oracle can use the existing table replicas and forego creating and replicating table data at each master site. This option is appropriate when you are configuring large tables and want to minimize the network traffic due to initial object creation and data replication.

When you choose to populate a replicated table at a master site yourself, you are responsible for the ensuring that the table data is consistent among all replicas in the system. For example, when manually populating replicated tables with data, do so before adding the table to its master group. Furthermore, prevent applications from accessing the replicated table until the table is added to a master group and replication activity is resumed; otherwise, the table might become inconsistent at the various master sites.

Offline Instantiation

If you are currently replicating a large amount of data and want add a new site to the system, you should consider offline instantiation. For complete information about offline instantiation, see "Snapshot Cloning and Offline Instantiation" on page 7-15.

Altering Objects in a Master Group

To alter the definition of a replication object in a master group, you should always use Replication Manager (or an equivalent API call). Use of Enterprise Manager or a SQL DDL command (for example, ALTER TABLE) to directly alter an object in a replicated environment does not necessarily propagate DDL changes to the object at all sites in the system.

Note: Local customization of individual replicas at snapshot or master sites is outside the scope of Oracle's advanced replication facility. As a replication administrator, you must ensure that local customizations do not interfere with any global customizations done with Replication Manager.

After successfully suspending replication activity for a master group, alter the definition of an object in the group as follows:

  1. Click on the target object in the master group at its master definition site.
  2. Click the Properties toolbar button.
  3. Click the General page of the Edit Replication Object property sheet.
  4. Click Alter Replication Object.
  5. Use the Alter Replication Object dialog to alter the definition of the replication object. For example, you might want to add a new column to a replicated table. Make sure to fully qualify all object references.

API Equivalent: DBMS_REPCAT.ALTER_MASTER_REPOBJECT

Considerations

Consider the following issues before and after altering a replication object in a master group:

Removing Objects from a Master Group

To remove objects from a master group:

  1. Click the target master group at the master definition site.
  2. Select the target objects to remove from the group.
  3. Click the Delete toolbar button.

Note: Before dropping an object from a master group, ensure that no snapshots depend on the object.

Note: When you drop a replication object from a master group, Replication Manager automatically removes all corresponding system-generated objects that were necessary to support the replication object.

API Equivalent: DBMS_REPCAT.DROP_MASTER_REPOBJECT

Adding a Master Site to a Master Group

Before adding a new master site to a master group, you must:

To prepare a multimaster replication system for the addition of a new master site, use the Replication Manager setup wizard. When using the setup wizard, consider the following issues:

Note: See "The Replication Setup Wizard" on page 3-4 for more information about using the setup wizard for multimaster configuration.

After you use the setup wizard to prepare a multimaster replication system for the addition of a new master site, you are ready to add the new master site to the group. After suspending replication activity of a master group, add a new destination to a master group:

  1. Click the target master group at its master definition site.
  2. Click the Properties toolbar button.
  3. Click the Destinations page of the Edit Master Group property sheet.
  4. Add one or more destination master sites to the group. A scheduled link to the new master site must already exist before you attempt to address the new master site.

Note: When adding a master site to a master group that contains tables with circular dependencies or a specific table that contains a self-referential constraint, you must precreate the tables at the master site and manually load data at the new site. See "Replicating Object Definitions to Master Sites" on page 3-22 for more information.

API Equivalent: DBMS_REPCAT.ADD_MASTER_DATABASE

Removing a Master Site from a Master Group

After suspending replication activity of a master group, you can remove destinations (master sites) from the group. To remove a master site destination from a master group:

  1. Click the target master group at its master definition site.
  2. Click the Properties toolbar button.
  3. Click the Destinations page of the Edit Master Group property sheet.
  4. Remove one or more destination master sites from the group.

API Equivalent: DBMS_REPCAT.REMOVE_MASTER_DATABASES

Special Circumstances

The sites being removed from a master group do not have to be accessible. When a master site will not be available for an extended period of time due to a system or network failure, you might decide to drop the master site from the master group. However, because the site is unavailable, you most likely will not be able to suspend replication activity for the master group. If this is the case, you are responsible for:

Specifically, the next time that you suspend replication activity for a master group, you must complete the following steps in the following order as soon as possible after the unavailable master sites are removed:

  1. Suspend replication activity for the master group.
  2. Remove all deferred transactions from each master site where the destination for the transaction is a removed master site.
  3. Delete all deferred transactions from removed master sites.
  4. Reexecute or delete all error transactions at each remaining master site.
  5. Ensure that no deferred or error transactions exist at each remaining master. If you cannot remove one or more deferred transactions from a remaining master, execute the DBMS_DEFER_SYS.DELETE_TRAN procedure at the master site.
  6. Ensure that all replicated data is consistent. Use the DBMS_RECTIFIER_DIFF package to determine and fix differences.
  7. Resume replication activity for the master group.

Note: After dropping an unavailable master site from a master group, you should also remove the master group from the site to finish cleanup.

Relocating a Master Group's Definition Site

If the master definition site of a master group becomes unavailable or you simply want to relocate the master destination site for the group

  1. Click the target master group at any master site.
  2. Click the Properties toolbar button.
  3. Click the Destinations page of the Edit Master Group property sheet.
  4. Click Change to change the groups master definition site.
  5. Use the Change Masterdef dialog to change the group's master definition site.

When you relocate the master definition site for a master group, you can choose to notify:

API Equivalent: DBMS_REPCAT.RELOCATE_MASTERDEF

Generating Replication Support for Master Group Objects

After performing administrative operations for a master group, Oracle must generate replication support for your changes before you can resume replication activity for the group. For example, after you add a table to a master group, Oracle must generate the $RR, $RP, and $RL packages and activate internal triggers before it can support the replicated table. When you later add conflict resolution to the table, you must regenerate replication support for the table so that all master sites use the same conflict resolution methods for the table.

Note: To display the status of a replication object, click on the master group that contains the object. The Status field displays the status of each replication object in the group. When an object's status is "Valid," no action is necessary; however, when an object's status is "Needs Gen," you should generate replication support for the object.

Oracle generates replication support for an object using two phases:

  1. When you generate replication support for an object, Oracle begins Phase One by synchronously broadcasting the request to all sites to create the necessary generated packages. These packages are created asynchronously. For procedural replication, Phase One generates the package specification.
  2. Phase Two does not begin until each site indicates to the master definition site that it has generated the packages necessary to support replication. Oracle then begins Phase Two by synchronously broadcasting the request to activate the necessary internal triggers at each site. (For Oracle7 release 7.3 sites, the broadcast request generates the necessary PL/SQL triggers and their associated packages.) Once again, these objects are created asynchronously. For procedural replication, Phase Two generates the package body.

Note: Oracle is optimized to allow additional generation requests and to allow the creation of a master group to proceed after Oracle has broadcast the request to create the packages at each site. It is not necessary to wait until all packages have actually been created at all of the sites to begin processing these types of requests. New administration requests do not execute until after Oracle completes the second phase for generating replication support.

Generating Replication Support for Individual Objects

To generate replication support for an individual object in a master group:

  1. Click on the target object in the master group at its master definition site.
  2. Click the Properties toolbar button.
  3. Click the General page of the Edit Replication Object property sheet.
  4. Click Generate Support to regenerate replication support for the target object.

Note: After generating replication support for one or more objects, you can ensure that the operation was successful by checking the status of the object using Replication Manager.

Generating Replication Support for All Master Group Tables

To generate replication support for all tables in a master group:

  1. Click on the target master group at its master definition site.
  2. Click the Properties toolbar button.
  3. Click the Operations page of the Edit Master Group property sheet.
  4. Click Generate to regenerate replication support for all tables in the target master group.

API Equivalents: DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT

Note: After generating replication support for one or more objects, you can ensure that the operation was successful by checking the status of the object using Replication Manager.

Minimizing Data Propagation

The Min(imize) Communications setting of the Edit Replication Object property sheet determines how much data sites must transfer to perform conflict detection for a table. This setting is valid only for Oracle8 databases and is available only when using the database connection to the group's master definition site.

Note: If any master sites in your replicated environment are running Oracle7 release 7.3, this setting must be disabled. When disabled, Oracle propagates the old and new values of all columns in a row when any column in the row is updated. This is the behavior expected by Oracle7 release 7.3.

When Min(imize) Communications is enabled, the default, Oracle propagates only the new values for updated columns plus the old values of the primary key and the columns in each updated column group.

Additional Information: To learn about additional techniques that minimize data propagation, see "Minimizing Data Propagation" on page 7-30.

Executing DDL Within a Master Group

Replication Manager lets you propagate one or more SQL DDL statements to some or all of the master sites in a master group. This option lets you execute unique DDL that is not specifically supported within Oracle's replication management API. For example, you might want to create rollback segments and users that are necessary to support a replication environment.

Warning: Do not execute DDL that could damage global database integrity in a multimaster environment. For example, do not execute DDL statements to alter a replication object at any site.

To execute DDL at selected master sites in a master group

  1. Click the target master group at its master definition site.
  2. Click the Properties toolbar button.
  3. Click the Operations page of the Edit Master Group property sheet.
  4. Click Execute DDL.
  5. Use the Execute DDL dialog to execute DDL statements at selected destinations.

API Equivalent: DBMS_REPCAT.EXECUTE_DDL

Validating a Master Group

To validate the integrity of a master group across all master sites in a multimaster replication environment, you can validate the master group. To validate a master group:

  1. Click the target master group at its master definition site.
  2. Click the Properties toolbar button.
  3. Click the Validation page of the Edit Master Group property sheet.

The Validation page lets you target specific items to validate, including:

When you are ready to validate the master group, Click Validate.

Viewing Information About Master Groups

Replication Manager can display information about the master groups in an advanced replication system.

Listing Master Groups

To display a list of all master groups at a site:

  1. Open the site's Configuration folder.
  2. Click the subordinate Master Groups folder.

For each master group at the site, the detail panel lists the name of the master group, whether the site is the master definition site for the group, and the status of the group (for example, normal or quiesced).

Listing Objects for a Master Group

To display a list of all objects in a master group at a site:

  1. Open the site's Configuration folder.
  2. Open the subordinate Master Groups folder.
  3. Click a subordinate master group.

For each object in the target master group, the detail panel lists the name of the object, the schema that contains the object, the type (table, index, procedure, and so on) of the object, and the status (for example, valid or needs generation of replication support).

Displaying a Destination Map for a Master Group

Replication Manager uses a destination map to represent visually the configuration of a master group in an advanced replication environment. To display the destination map for a master group at a master site:

  1. Open the site's Configuration folder.
  2. Open the subordinate Master Groups folder.
  3. Open the target master group.
  4. Click the Destination Map folder of the target master group.

A destination map for a master group provides the following visual information about the master group:

A destination map also lets you edit the properties for the scheduled links that appear between master sites. To edit a link in a destination map, use the Edit Database Destination property sheet of Replication Manager. To access the dialog, click on the scheduled link and press Enter, or right-click on the link and click Properties.

Use the Edit Database Destination property sheet to

Displaying Administration Requests for a Master Group

To display the administration requests for a master group at a master site:

  1. Open the site's Configuration folder.
  2. Open the subordinate Master Groups folder.
  3. Open the target master group.
  4. Click the Admin Requests folder of the target master group.

Replication Manager also lets you manage administration requests from this display. For more information about managing administration requests for a master group, see "Managing Administration Requests" on page 3-34.

Displaying Generated Objects Associated with a Master Group

To display the generated objects associated with the replication objects in a master group at a master site:

  1. Open the site's Configuration folder.
  2. Open the subordinate Master Groups folder.
  3. Open the target master group.
  4. Click the Generated Objects folder of the target master group.

Managing Administration Requests

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. All DDL changes to replication groups and the objects within generate administration requests. Many top-level administration requests generate additional replication management API calls to complete the request.

Administration requests are inserted by the master definition site in the administration request queues at all master sites as one distributed transaction. Each master site has a scheduled job, DO_DEFERRED_REPCAT_ ADMIN, that executes requests simultaneously at each site. As administration requests are processed, each site reports back to the master definition site. Oracle removes requests that complete successfully from the administration request queue at the master definition site. However, if any errors are encountered, the administration request remains in the master definition site's administration request queue with an error status.

Replication Manager allows you view and update the status of administration requests. The following sections explain more about how to manage administration requests for a master group in a multimaster advanced replication environment.

Displaying Administration Requests

To display the administration requests for a master group, click on the Admin Requests folder of the master group. The detail panel of Replication Manager lists information for all pending master group administration requests at the corresponding master site, including:

Replication Manager does not automatically update the display of the detail panel. To obtain a more current list of pending administration requests, refresh the display.

Applying Administration Requests

As long as each instance in an Oracle advanced replication facility has one or more SNP processes, each server runs a job at a regular interval to execute all administration requests. If you do not want to wait for Oracle to execute administration requests, use Replication Manager to apply all pending administration requests manually.

  1. Display the administration requests for a master group at the target master site.
  2. Right-click anywhere in the detail window.
  3. Click Apply all admin requests now.

Note: Oracle automatically attempts to apply all administration requests synchronously among all master sites.

API Equivalent: DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN

Purging Administration Requests

Sometimes it is necessary to remove pending administration requests for a master group. For example, certain administration requests might return errors. Even after you resolve the corresponding error situation, administration requests remain in the server's queue unless you manually purge them.

To remove administration requests for a master group

  1. Display the administration requests for a master group at the target master site.
  2. Click one or more target requests.
  3. Click the Delete toolbar button.

API Equivalent: DBMS_REPCAT.PURGE_MASTER_LOG

More about Administration Request Mechanisms

When you use Replication Manager or make a call to a procedure in the DBMS_REPCAT package to administer an advanced replication system, Oracle uses its internal mechanisms to broadcast the request using synchronous replication. If a synchronous broadcast fails for any reason, Oracle returns an error message and rolls back the encompassing transaction.

When an Oracle Server receives an administration request, it records the request in the REPCATLOG view and the corresponding DDL statement in a child table of the REPCATLOG view. When you view administration requests for a master group at a master site, you might observe requests that are awaiting a callback from another master site. Whenever you use Replication Manager to create an administration request for a replication group, Oracle automatically inserts a job into the local job queue, if one does not already exist for the group. This job periodically executes the procedure DO_DEFERRED_REPCAT_ADMIN. Whenever you synchronously broadcast a request, Oracle attempts to start this job immediately in order to apply the replicated changes at each master site.

Assuming that Oracle does not encounter any errors, DO_DEFERRED_ REPCAT_ADMIN will be run whenever a background process is available to execute the job. The initialization parameter JOB_QUEUE_INTERVAL determines how often the background process wakes up. You can experience a delay if you do not have enough background processes available to execute the outstanding jobs.

Note: When JOB_QUEUE_PROCESSES = 0 at a site, you must apply administration requests manually for all groups at the site. See "Applying Administration Requests" on page 3-35 for more information.

For each call of DO_DEFERRED_REPCAT_ADMIN at a master site, the site checks the REPCATLOG view to see if there are any requests that need to be performed. When one or more administration requests are present, Oracle applies the request and updates any local views as appropriate. This event can occur asynchronously at each master site.

The success or failure of an administration request at each master site is noted in the REPCATLOG view at each site. For each master group, Replication Manager displays the corresponding status of each administration request. Ultimately, each master site propagates the status of its administration requests to the master definition site. If a request completes successfully at a master site, Oracle removes the callback for the site from the REPCATLOG view at the master definition site. If the event completes successfully at all sites, all entries in the REPCATLOG view at all sites, including the master definition site, will be removed.

By synchronously broadcasting the change, Oracle ensures that all sites are aware of the change, and thus are capable of remaining in synch. By allowing the change to be applied at the site at a future point in time, Oracle provides you with the flexibility to choose the most appropriate time to apply changes at a site.

If an object requires automatically generated replication support, you must regenerate replication support after altering the object. Oracle then activates the internal triggers and regenerates the packages to support replication of the altered object at all master sites.

Note: Although the DDL must be successfully applied at the master definition site in order for these procedures to complete without error, this does not guarantee that the DDL is successfully applied at each master site. Replication Manager displays the status of all administration requests. Additionally, the REPCATLOG view contains interim status and any asynchronous error messages generated by the request.

Any snapshot sites that are affected by a DDL change are updated the next time you perform a refresh of the snapshot site. While all master sites can communicate with one another, snapshot sites can communicate only with their associated master site.

If you must alter the shape of a snapshot as the result of a change to its master, you must drop and re-create the snapshot.

Advanced Multimaster Replication Options

The following sections explain some additional topics to consider when building and managing a multimaster replication system.

Planning for Parallel Propagation

When you create the scheduled links for an advanced replication environment, each link can asynchronously propagate changes to a destination using either serial or parallel propagation.

Parallel propagation uses the pool of available parallel server processes. This is the same facility Oracle uses for other parallel operations such as parallel query, parallel load, and parallel recovery. Each server process propagates transactions through a single stream. A parallel coordinator process controls these server processes. The coordinator tracks transactions dependencies, allocates work to the server processes, and tracks their progress.

Parallel server processes remain associated with a parallel operation throughout the execution of that operation. When the operation is complete, those server processes become available to process other parallel operations. For example, when Oracle performs a parallel push of the deferred transaction queue to its destination, all parallel server processes used to push the queue remain dedicated to the operation until it completes.

To configure a pool of parallel server processes for a server properly, you must consider several issues related to the configuration of an advanced replication system.

To configure a database server's pool of parallel query processes, use the following initialization parameters:

Additional Information: See Oracle8 Server Concepts.

Understanding Replication Protection Mechanisms

Oracle ensures that transactions propagated to remote sites are never lost and never propagated more than once, even when failures occur.

Note: Successful propagation does not necessarily imply successful application of the transaction at the remote site. Errors such as unresolvable conflicts or running out of storage space can cause the transaction to result in an error, which the remote site keeps track of. See "Displaying Error Transactions" on page 3-43 for more information about viewing and managing error transactions.

Protection against failures is provided for both serial and parallel propagation.

Data Propagation Dependency Maintenance

Oracle maintains dependency ordering when propagating replicated transactions to remote systems. For example,

  1. Transaction A cancels an order.
  2. Transaction B sees the cancellation and processes a refund.

Transaction B is dependent on Transaction A because Transaction B sees the committed update cancelling the order (Transaction A) on the local system.

Oracle propagates Transaction B (the refund) after it successfully propagates Transaction A (the order cancellation). Oracle applies the updates that process the refund after it applies the cancellation.

Parallel Propagation Dependency Tracking

When Oracle on the local system executes a new transaction,

  1. Oracle records the system commit number of the most recent transaction that updated data seen by the new transaction as the dependent system commit number.
  2. Oracle ensures that transactions with system commit numbers less than or equal to the dependent system commit number propagate successfully to the remote system.
  3. Oracle propagates the awaiting, dependent transaction.

Note: When there are no possible dependencies between transactions, Oracle propagates transactions in parallel.

Parallel propagation maintains data integrity in a manner different from that of serial propagation.

Serial Propagation   Parallel Propagation  

Oracle applies all transaction in the same order that they commit on the local system to maintain any dependencies.  

Oracle tracks dependencies and executes them in commit order when dependencies can exist; in parallel when dependencies cannot exist.  

Oracle preserves the order of execution within a transaction in all cases. The deferred transaction executes every remote procedure call at each system in the same order as it was executed within the local transaction.  

Note: A single coordinator process exists for each database link to a remote site. Each database link to the same remote site requires a different connection qualifier.

Additional Information: See "Using Connection Qualifiers for a Master Group" on page 3-17

Monitoring a Multimaster Replication System

Oracle uses its internal system of deferred transactions and job queues to propagate changes among the sites in an advanced replication system. It is important that you monitor regularly the internal workings of a replication environment to ensure that it is running smoothly. Replication Manager provides several features with which you can view and manage administration requests, deferred transactions, and job queues.

The following sections explain how to monitor an advanced replication environment. Additionally, see "Managing Administration Requests" on page 3-34 to learn how to manage the administration requests of a master group.

Managing Deferred and Error Transactions

An advanced replication system using asynchronous data propagation uses an internal system of deferred transactions and job queues to push changes from one site to another. Replication Manager lets you view and manage deferred and error transactions queued at each server in an advanced replication system.

Displaying Deferred Transactions

To display a summary list of a replication site's deferred transactions by their outgoing destination:

  1. Open the Administration folder of the site.
  2. Click on the Deferred Transactions by Dest folder.

The detail panel of Replication Manager lists summary information for all pending deferred transactions by destination.

To display individual deferred transactions for a particular destination:

  1. Click on the destination in the Deferred Transactions by Dest folder.
  2. Expand the destination in the tree panel.

To display the properties for an individual deferred transaction:

  1. Click on the individual deferred transaction.
  2. Click the Properties toolbar button.

To display the deferred calls for an individual deferred transaction:

  1. Expand the individual deferred transaction.
  2. Review the transaction's deferred calls and call destinations, and the transaction's destinations.

Note: Replication Manager does not automatically update the display of the detail panel. To obtain a more current list of pending deferred transactions, refresh the display.

Executing Deferred Transactions

Each instance in an Oracle advanced replication facility that has one or more SNP processes and the necessary scheduled links automatically runs a job at a regular interval to execute deferred transactions automatically at targeted destinations. If you do not want to wait for Oracle to execute a deferred transaction, use Replication Manager to manually push all pending deferred transactions for a particular destination.

  1. Click the destination in the Deferred Transactions by Dest folder for a site.
  2. Click the Properties toolbar button.
  3. Click Reexecute all transactions now of the View Database Destination property sheet to force the execution of all corresponding deferred transactions.

Deleting Deferred Transactions

To delete an individual deferred transaction

  1. Right-click on the individual deferred transaction.
  2. Click Delete Deferred Transaction to delete the target transaction locally or click Delete to all destinations to delete the target transaction from all target replication sites.

Displaying Error Transactions

If for some reason, a deferred transaction cannot execute properly, Oracle logs the transaction as a local error transaction. To display a summary list of a replication site's local error transactions:

  1. Open the Administration folder of the site.
  2. Click on the Local Errors folder.

The detail panel of Replication Manager lists summary information for all error transactions at the site.

To display more information about an individual error transaction:

  1. Click on the individual error transaction.
  2. Click the Properties toolbar button.

To display the deferred calls for an individual error transaction:

  1. Expand the individual error transaction.
  2. Review the transaction's deferred calls and call destinations, and the transaction's destinations.

Executing Error Transactions

When you have resolved the problem that caused an error transaction, you can reexecute the error transaction. To reexecute an error transaction:

  1. Right-click on the individual error transaction.
  2. Click Re-execute Transaction.

Deleting Error Transactions

When you have resolved the problem that caused an error transaction, you can delete the transaction rather than reexecute it. To delete an error transaction:

  1. Click on the individual error transaction.
  2. Click the Delete toolbar button.

Managing Local Jobs

Oracle runs jobs in each site's job queue to complete certain tasks automatically that are necessary to manage an advanced replication environment. For example, when you use Replication Manager to create and enable a scheduled link to a remote site, the local server places a job in its job queue that Oracle periodically runs to push local changes to a remote master.

Replication Manager has several features that you can use to view and manage the job queues of each server in an advanced replication system. The following sections explain more about viewing and managing a server's local jobs.

Displaying a Site's Local Jobs

Oracle creates a job in a site's local job queue on behalf of the following operations:

To display a summary list of a replication site's local job queue:

  1. Open the Administration folder of the site.
  2. Click on the Local Jobs folder.

The detail panel of Replication Manager lists summary information for all local jobs.

To display the properties for an individual local job:

  1. Click on the individual job.
  2. Click the Properties toolbar button.

The pages of the Edit Job property sheet let you view the various properties of the job, including:

Editing the Properties of a Local Job

In certain situations, you might want to edit the properties of a local job. For example, the default execution interval for a master group's administration requests is 10 minutes; the only way to edit this setting is to edit the scheduling properties for the corresponding job.

To edit the properties of a local job:

  1. Click the target job.
  2. Click the Properties toolbar button.

The Edit Job property sheet lets you edit the following properties of a job

Manually Running a Job

Rather than wait for the next execution date for a job, you can force a job to run. To run a job immediately:

  1. Click the target job.
  2. Click the Properties toolbar button.
  3. Click Run Now.

Breaking and Enabling a Job

In certain cases, you might need to temporarily disable (break) a job and then later enable the job again. Or, you might need to enable a broken job after fixing a problem the prevented the job from running properly. For example, if you accidentally drop a database link upon which a job depends, the job will fail and eventually break (after 16 successive failures). After you recreate the necessary database link, you can then enable the broken job.

To break or enable (make normal) a local job:

  1. Click the target job.
  2. Click the Properties toolbar button.
  3. Click Make Broken/Make Normal.

Data Dictionary Views

In addition to using Replication Manager to view information about an advanced replication environment, you can also use the following data dictionary views.




Prev

Next
Oracle
Copyright © 1997 Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index