Oracle7 Server Distributed Systems Volume II: Replicated Data

Contents Index Home Previous Next

Selecting a Propagation Method

When you add a new database site, you get to select a default propagation method for that site. Because this propagation method determines how the new site both sends changes to and receives changes from all existing sites, the order in which you add sites is important.

For example, suppose that you have three sites: A, B, and C. If you first create site A as the master definition site, and then add site B with a propagation_mode of SYNCHRONOUS, site A will send changes to site B synchronously and site B will send changes to site A synchronously. There is no need to schedule execution at either site, because neither site is creating deferred transactions. Now suppose that you create site C with a propagation_mode of ASYNCHRONOUS. The propagation modes are now as illustrated in Figure 4 - 4.

Figure 4 - 4. Selecting a Propagation Method

You must now schedule propagation of the deferred transaction queue from site A to site C, from site B to site C, and from site C to site A and to site B. But even more importantly, what if you created site A as the master definition site, then site C with a propagation_mode of ASYNCHRONOUS, then added site B with a propagation_mode of SYNCHRONOUS? Now the propagation modes would be as shown in Figure 4 - 5.

Figure 4 - 5. Ordering Considerations

Each time that you add a new site to your replicated environment, you must consider the effects of this addition on how changes are sent to and received from existing sites.

Altering Propagation

If you are not satisfied with the default propagation method between sites, you can alter the method used to send changes from one site to a given set of sites by calling DBMS_REPCAT.ALTER_MASTER_PROPAGATION, as shown in the following example:

DBMS_REPCAT.ALTER_MASTER_PROPAGATION(
            gname            => 'acct',
            master           => 'site_a',
            dblink_list      => 'site_b, site_c',
            propagation_mode => 'synchronous');

Site A, as illustrated in Figure 4 - 5, would synchronously propagate its updates to sites B and C, after the triggers are regenerated. Site A would continue to receive changes from these sites asynchronously.

You must call this procedure from site A, and the replicated object group for which you are altering the propagation mode must be quiesced. After altering the propagation mode for an object group, be sure to make the appropriate GENERATE_REPLICATION_SUPPORT, DBMS_DEFER_SYS.SCHEDULE_EXECUTION, or DBMS_DEFER_SYS.UNSCHEDULE_EXECUTION call at the designated master site.

Additional Information: The parameters for the ALTER_MASTER_PROPAGATION procedure are described in Table Table 12 - 72, and the exceptions are listed in Table Table 12 - 73.

Generating Replication Triggers

After altering the propagation mode of an object group, you need to regenerate the supporting triggers for these objects at each site in the replicated environment. To generate the supporting triggers and their associated packages for all members of an object group for a given set of master sites, call the DBMS_REPCAT.GENERATE_REPLICATION_TRIGGER procedure, as shown in the following example:

DBMS_REPCAT.GENERATE_REPLICATION_TRIGGER( gname => 'acct');

Because no list of master sites was specified in this example, Oracle will regenerate the supporting triggers and their associated packages for the objects in the GNAME object group at all master sites. You must call this procedure from the master definition site for the given replicated object group. Oracle must successfully create the necessary triggers at the master definition site for this procedure to complete successfully. These objects are asynchronously created at the other master sites as described [*].

Attention: The GENERATE_REPLICATION_TRIGGER procedure is overloaded to allow you to generate support for a single object at all master sites or for an object group at a list of sites. Because the parameter types are the same for both calls, you may need to use named notation to indicate whether you are calling the procedure for a single object or for an object group.

Additional Information: The parameters for the GENERATE_REPLICATION_TRIGGER procedure are described in Table 12 - 147, and the exceptions are listed in Table 12 - 148.


Contents Index Home Previous Next