Release 8.1.5
A67791-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Replication Release 8.1.5 A67791-01 |
|
This chapter explains how to configure and manage an advanced replication system that uses multimaster replication. Advanced replication is only available with the Oracle8i Server Enterprise Edition. To learn more about the differences between Oracle* products and the Oracle8i Server Enterprise Edition, please refer to the book Getting to Know Oracle8i.
This chapter covers the following topics.
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 8, "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 Oracle8i Replication API Reference.
Note:
Oracle converges data from typical advanced replication configurations using row-level replication with asynchronous data propagation. The following sections explain how these mechanisms function.
|
Note: Oracle offers other advanced replication features such as procedural replication and synchronous data propagation for unique application requirements. To learn more about these special configurations, read "Specialized Replication Options". |
Typical transaction processing applications modify small numbers of rows per transaction. Such applications at work in an advanced replication environment will usually depend on Oracle's row-level replication mechanism. With row-level replication, applications use standard DML statements to modify the data of local data replicas. When transactions change local data, the server automatically captures information about the modifications and queues corresponding deferred transactions to forward local changes to remote sites.
To support the replication of transactions in an advanced replication environment, one or more internal system objects are generated to support each replicated table, package or procedure.
Typical advanced replication configurations that rely on row-level replication propagate data level changes using asynchronous data replication. Asynchronous data replication occurs when an application updates a local replica of a table, stores replication information in a local queue, and then forwards the replication information to other replication sites at a later time. Consequently, asynchronous data replication is also called store-and-forward data replication.
As Figure 2-1 shows, Oracle uses its internal system of triggers, deferred transactions, deferred transaction queues, and job queues to propagate data-level changes asynchronously among master sites in an advanced replication system, as well as from an updateable snapshot to its master table.
With serial propagation, Oracle asynchronously propagates replicated transactions, one at a time, in the same order of commit as on the originating site.
With parallel propagation, Oracle asynchronously propagates replicated transactions using multiple, parallel transit streams for higher throughput. When necessary, Oracle orders the execution of dependent transactions to ensure global database integrity.
Parallel propagation uses the same execution mechanism Oracle uses for parallel query, load, recovery, and other parallel operations. Each server process propagates transactions through a single stream. A parallel coordinator process controls these server processes. The coordinator tracks transaction dependencies, allocates work to the server processes, and tracks their progress.
After a site pushes a deferred transaction to its destination, the transaction remains in the deferred transaction queue until another job purges the applied transaction from the queue.
An Oracle advanced replication environment requires several unique database user accounts to function properly, including replication administrators, propagators, and receivers.
In most advanced replication configurations, just one account is used for all purposes: as a replication administrator, a replication propagator, and a replication receiver. However, Oracle also supports distinct accounts for unique configurations.
To create a multimaster advanced replication environment, you must complete the following steps at a minimum:
For detailed information about each step and other optional configuration steps, see the later sections of this chapter.
The following simple example demonstrates the steps necessary to build a multimaster replication 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.
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:
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.
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 ... ;
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.
Before starting to build a multimaster advanced replication environment, you must prepare each participating database with the following:
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:
The following sections explain how to use the Replication Manager setup wizard to prepare the master sites in a multimaster replication system.
The initial page of the replication setup wizard prompts you to indicate what type of replication environment setup that you want to perform.
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
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.
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
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".
After reviewing the default scheduling settings or making any necessary changes, press the Next button to continue.
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".
After reviewing the default purge settings or making any necessary changes, press the Next button to continue.
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:
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, press the OK button. To customize another master site's settings, repeat the process above. When you are finished customizing all master sites, press the Next button to continue.
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.
After using the Replication Manager setup wizard, you should continue configuration by completing the following steps.
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.
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 updateable 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.
To create a new scheduled link:
You can optionally press the Create Scheduled Link button on the toolbar.
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. Press the Create button when you have completed creating your scheduled 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. The database link must already exist.
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.
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.
The amount of time to continue polling the queue, even if the queue is empty. See "Guidelines for Scheduled Links" for more information about this setting.
Check to immediately enable the new scheduled link and push changes to the new destination.
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.
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. See "Planning for Parallel Propagation" for more information.
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.
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.
API Equivalents: DBMS_DEFER_SYS.SCHEDULE_PUSH, DBMS_DEFER_SYS.SCHEDULE_EXECUTION (Oracle7 Database Only)
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.
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.
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.
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".
To edit the refresh interval or propagation characteristics for a scheduled link, or disable a scheduled link
The current properties of the selected scheduled link will appear in the right pane of the Replication Manager user interface.
Use the Scheduled Link property sheet to modify the properties of the scheduled link and apply your changes. Press the Apply button when you have completed your modifications. See "Creating a Scheduled Link" 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)
To list the status of all scheduled links for a site, use Replication Manager.
All of the scheduled links in the selected database will be displayed in the right pane of the Replication Manager user interface. Link name, next date, interval, and last date properties will be displayed for each scheduled link.
API Equivalent: DBMS_DEFER_SYS.DISABLED
To delete a scheduled link
API Equivalent: DBMS_DEFER_SYS.UNSCHEDULE_PUSH
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:
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.
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.
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.
The amount of time to continue polling the 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)
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:
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.
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.
If you manually configured a master or snapshot site or want to modify a site's purge schedule, use the Database Information property sheet. To edit the purge schedule for a site:
The current properties of the selected scheduled link will appear in the right pane of the Replication Manager user interface.
Use the Purge Job page of the Database Information property sheet to modify the purge schedule for the site and apply your changes. Press the Apply button when you have completed your modifications.
API Equivalents: DBMS_DEFER_SYS.SCHEDULE_PURGE, DBMS_DEFER_SYS.SCHEDULE_EXECUTION (Oracle7 only)
To manually purge a master or snapshot site's deferred transaction queue, use the Database Information property sheet. To edit the purge schedule for a site:
The current properties of the selected scheduled link will appear in the right pane of the Replication Manager user interface.
API Equivalents: DBMS_DEFER_SYS.PURGE
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.
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
You can optionally press the Create Master Group button on the toolbar.
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.
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 6, "Conflict Resolution" for more information about configuring conflict resolution for master group objects.
Warning:
API Equivalents: DBMS_REPCAT.CREATE_MASTER_REPGROUP, DBMS_REPCAT.SET_COLUMNS
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 Oracle8i Distributed Database Systems 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 Oracle8i Reference for more information about the parameter OPEN_LINKS.
To remove a master group from all master sites in an advanced replication environment:
API Equivalent: DBMS_REPCAT.DROP_MASTER_REPGROUP
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 the status of the group is "quiesced" before proceeding.
To suspend replication activity for a master group:
The property page for the selected master group will appear in the right pane of the Replication Manager user interface.
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.
API Equivalent: DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY
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.
To resume replication activity for a master group:
The property page for the selected master group will appear in the right pane of the Replication Manager user interface.
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
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:
The property page for the selected master group will appear in the right pane of the Replication Manager user interface.
You will see a list of all objects that are currently contained in the selected master group (the schema, name, and type properties will be displayed for each object).
The Add object(s) to group dialog box will appear.
A list of available objects will be displayed in the Available Objects list.
You will see the new objects appear in the Objects page of the Master Group property sheet.
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
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
Multimaster replication supports the replication of tables with columns that use the following datatypes: NUMBER, DATE, VARCHAR2, CHAR, NVARCHAR2, NCHAR, RAW, ROWID.
Oracle also supports the replication of tables with columns that use the following large object types: binary LOBs (BLOBs), character LOBs (CLOBs), and national character LOBs (NCLOBs). The deferred and synchronous remote procedure call mechanism used for multiple master replication propagates only the piece-wise changes to the supported LOB datatypes when piece-wise updates and appends are applied to these LOB columns.
Oracle does not support the replication of columns that use the LONG and LONG RAW datatypes. Oracle simply omits columns containing these datatypes from replicated tables.
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.
When you add an object to a master group, Replication Manager prompts you whether to "use existing object if present."
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.
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:
When you add a table to a master group, Replication Manager prompts you whether to "copy row 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.
Before adding a 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 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.
If you are currently replicating a large amount of data and want to add a new site to the system, you should consider offline instantiation. For complete information about offline instantiation, see "Snapshot Cloning and Offline Instantiation".
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.
After successfully suspending replication activity for a master group, alter the definition of an object in the group as follows:
The property sheet for the selected replicated object will appear in the right pane of the Replication Manager user interface.
API Equivalent: DBMS_REPCAT.ALTER_MASTER_REPOBJECT
In order to support column subsetting with deployment templates, you need to identify which columns of your replicated table will not be checked for conflicts during update and/or delete operations on the target table.
Complete the following steps to mark the necessary columns:
The replicated object property sheet will appear in the right pane of the Replication Manager user interface.
If you have not explicitly defined any column groups, select the "Shadow Group."
You will not be able to disable the Delete or Update checkboxes for primary key columns.
You will now be able to exclude the columns identified in step 10 above from being replicated to updateable snapshots when using a deployment template).
Consider the following issues before and after altering an object in a master group:
To remove objects from a master group:
The property page for the selected master group will appear in the right pane of the Replication Manager user interface.
You will see a list of all objects that are currently contained in the selected master group (the schema, name, and type properties will be displayed for each object).
A Drop Object confirmation dialog box will allow you to confirm that you want to remove the selected objects.
API Equivalent: DBMS_REPCAT.DROP_MASTER_REPOBJECT
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:
See "The Replication Setup Wizard" for more information about using the setup wizard for multimaster configuration.
Note:
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:
The property page for the selected master group will appear in the right pane of the Replication Manager user interface.
You will see a list of all destinations that are currently defined for the selected master group.
The Add database destinations to the group dialog box will appear.
The Add Destination to Group dialog box will appear.
When you return to the Master Sites page of the Master Group property sheet, you will see the new destinations listed in the Master Sites list.
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" for more information.
Note:
API Equivalent: DBMS_REPCAT.ADD_MASTER_DATABASE
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:
The property page for the selected master group will appear in the right pane of the Replication Manager user interface.
You will see a list of all destinations that are currently defined for the selected master group in the Master Sites list.
API Equivalent: DBMS_REPCAT.REMOVE_MASTER_DATABASES
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:
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 activate internal triggers and packages 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.
Oracle generates replication support for an object using two phases:
To generate replication support for an individual object in a master group:
The property sheet for the selected replicated object will appear in the right pane of the Replication Manager user interface.
To generate replication support for all tables in a master group:
The property page for the selected master group will appear in the right pane of the Replication Manager user interface.
API Equivalents: DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT
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 and greater databases and is available only when using the database connection to the group's master definition site.
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 for Update Conflict Resolution".
Replication Manager can display information about the master groups in an advanced replication system.
To display a list of all master groups at a site:
All master groups of the currently selected database will be displayed in the right pane of the Replication Manager user interface. The master group name, master definition site status (is the selected site the master definition site), master group status, link qualifier, and any remarks will be displayed for each listed master group.
To display a list of all objects in a master group at a site:
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).
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:
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, right-click on the scheduled link and select Edit Destination.
Use the Edit Database Destination property sheet to:
To display the generated objects associated with the replication objects in a master group at a master site:
All generated objects contained in the selected master group will appear in the right pane of the Replication Manager user interface. Object name, schema, object type, status, and any remarks will be displayed for each generated object.
In addition to using Replication Manager to view information about an advanced replication environment, you can also use the following data dictionary views.
The preceding sections of this chapter explained the most commonly performed administrative procedures that involve master groups. For additional information on less commonly performed administrative procedures for master groups, see "Advanced Management of Master and Snapshot Groups".
The following sections explain some additional topics to consider when building and managing a multimaster replication system:
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 the book Oracle8i Concepts.
Oracle ensures that transactions propagated to remote sites are never lost and never propagated more than once, even when failures occur.
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" for more information about viewing and managing error transactions.
Note:
Protection against failures is provided for both serial and parallel propagation.
Oracle maintains dependency ordering when propagating replicated transactions to remote systems. For example,
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.
When Oracle on the local system executes a new transaction,
Parallel propagation maintains data integrity in a manner different from that of serial propagation. With serial propagation, Oracle applies all transaction in the same order that they commit on the local system to maintain any dependencies. With parallel propagation, Oracle tracks dependencies and executes them in commit order when dependencies can exist; in parallel when dependencies cannot exist. With both serial and parallel propagation, Oracle preserves the order of execution within a transaction. The deferred transaction executes every remote procedure call at each system in the same order as it was executed within the local transaction.
Additional Information: See "Using Link Qualifiers for a Master Group".
Certain application conditions can establish dependencies among transactions that force Oracle to serialize the propagation of deferred transactions. When several unrelated transactions modify the same data block in a replicated table, Oracle serializes the propagation of the corresponding transactions to remote destinations.
To minimize transaction dependencies created at the data block level, you should try to avoid situations that concentrate data block modifications into one or a small number of data blocks. For example:
