Oracle7 Server Distributed Systems Volume II: Replicated Data

Generating Replication Support

The triggers, packages and procedures needed to support replication are not created until you call the GENERATE_REPLICATION_SUPPORT procedure in the DBMS_REPCAT package, as shown in the following example:

DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT(
    sname            => 'acct_rec', 
    oname            => 'emp', 
    type             => 'table',
    distributed      => TRUE,
    gen_rep2_trigger => FALSE
    gen_obj_owner    => 'REPADMIN');

You must call this procedure from the master definition site for each object in the replicated object group (tables, packages, package bodies, and procedures). If you are generating replication support for an object that is not owned by the replication administrator, the owner of the object must have the EXECUTE privilege on the DBMS_DEFER package.

Note: If your compatibility mode is set to 7.3.0 or greater, the DISTRIBUTED option must be set to TRUE. If the compatibility mode at any of your snapshot sites is earlier than 7.3.0, you must set GEN_REP2@_TRIGGER to TRUE and set compatibility mode of the master site to 7.3.0.0.

Because the generated triggers may include calls to the generated procedures (to support synchronous replication), Oracle generates replication support in two phases. When you call GENERATE_REPLICATION_SUPPORT, Oracle begins phase one by synchronously broadcasting the request to all sites to create the necessary generated packages. These packages are created asynchronously as described . For procedural replication, phase one generates the package specification.

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 generate the necessary triggers and their associated packages at each site. Once again, these objects are created asynchronously as described . For procedural replication, phase two generates the package body.

Note: Oracle has been optimized to allow additional calls to GENERATE_REPLICATION_SUPPORT and to allow CREATE_MASTER_REPOBJECT 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. Any other procedures will not be executed until after GENERATE_REPLICATION_SUPPORT completes phase two.

There may be times when you only need to create the generated packages, such as when you change conflict resolution methods for an object, and other times when you only need to generate the triggers, such as when you change propagation methods for a site. In these situations, you can save time by using the DBMS_REPCAT procedures GENERATE_REPLICATION_PACKAGE (described ) and GENERATE_REPLICATION_TRIGGER (described ) as appropriate. Once again, Oracle can begin processing these requests before phase two of GENERATE_REPLICATION_SUPPORT begins.

Transaction Ownership

Under synchronous propagation, a transaction is owned by the owner of the trigger and will be propagated to the remote sit with that owner's privileges. You can change the ownership of the transaction, usually to the replication administrator who has full privileges at the remote site, by using GEN_OBJ_OWNER.

Row-Level Replication

If you want to use row-level replication for a table, you should call GENERATE_REPLICATION_SUPPORT immediately after any calls that define the replicated table, including CREATE_MASTER_REPOBJECT, ALTER_MASTER_REPOBJECT, ALTER_MASTER_PROPAGATION, SET_COLUMNS, and any conflict resolution routines, such as ADD_UPDATE_RESOLUTION. You may make multiple definition calls (for example, you may add multiple conflict resolution methods), before generating replication support. If you have only modified the propagation method, you may prefer to call GENERATE_REPLICATION_TRIGGER. If you have only modified the conflict resolution method for a table, you may prefer to call GENERATE_REPLICATION_PACKAGE.

Procedural Replication

If you are generating support for a package (body), Oracle generates the package (body) wrapper and you need to designate a prefix for the package (body). You should use the same prefix for the package body as you do for the package. If you do not designate a prefix, the default prefix is "defer_".

All of the parameters to your replicated procedure must be IN parameters, and must be of type: NUMBER, DATE, VARCHAR2, CHAR, ROWID or RAW. When generating wrappers, you should call GENERATE_REPLICATION_SUPPORT immediately after calling CREATE_MASTER_REPOBJECT, ALTER_MASTER_PROPAGATION, or ALTER_MASTER_REPOBJECT.

If you have only modified the propagation method, you may prefer to call GENERATE_REPLICATION_TRIGGER. You may also call GENERATE_REPLICATION_TRIGGER instead of GENERATE_REPLICATION_SUPPORT after adding a new master site (assuming that you have already called GENERATE_REPLICATION_SUPPORT for each object).

If you are using procedural replication, you should generate support for your replicated packages. Refer to , for information on how to design your replicated procedures to work with tables that also support row-level replication. If you do not generate replication support for your replicated packages, you assume responsibility for making sure that the transactions are properly applied at each replicated site.

Additional Information: The parameters for the GENERATE_REPLICATION_SUPPORT procedure are described in Table 12 - 145, and the exceptions are listed in Table 12 - 146.