Oracle7 Server Distributed Systems Volume II: Replicated Data
Propagating DDL Changes Among Master Sites
Whenever you make a Data Definition Language (DDL) change in a replicated environment, for example, by calling DBMS_REPCAT.ALTER_MASTER_REPOBJECT, this change must be propagated to all other sites in the replicated environment. Note that, in this manual, "DDL changes" refer to any schema-level changes, whether they involve user-supplied DDL statements (as is the case with ALTER_MASTER_REPOBJECT), or not (as is the case with CREATE_MASTER_REPOBJECT and other DDL-like procedures).
Warning: Schema level changes should only be made using the procedures provided in the DBMS_REPCAT package. As a replication administrator, you must ensure that any local customizations made outside the scope of the replication facility do not interfere with replication activities.
1. When you make a DDL change using the procedures provided in the DBMS_REPCAT package, the request for a DDL change is synchronously broadcast to each master site, where the request is recorded in the RepCatLog view. The DDL statement is stored in a child table of the RepCatLog view at each site. At the master definition site, the RepCatLog view also indicates that the master definition site is awaiting a callback from each master site. If this synchronous broadcast fails, for any reason, you receive an error message, and the transaction is rolled back.
2. Whenever you synchronously broadcast an event (such as when you make a DDL change), Oracle automatically inserts a job into the job queue, if one does not already exist for the replicated schema. This job periodically executes the procedure DO_DEFERRED_REPCAT_ADMIN. Whenever you synchronously broadcast an event, 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. For more information on scheduling jobs, see Chapter 10.
If the initialization parameter JOB_QUEUE_PROCESSES is set to zero at a master site, you must manually connect to that site and invoke DO_DEFERRED_REPCAT_ADMIN to execute asynchronous requests at that site. Because this procedure may use dynamic SQL to perform DDL, you must never invoke it as a remote procedure call.
3. The next time that DO_DEFERRED_REPCAT_ADMIN is called at each master site, that site checks the RepCatLog view to see if there are any actions that need to be performed. When Oracle sees the request for a DDL change in the RepCatLog view, it applies the DDL statement in the child table to the current master site and updates any local views as appropriate. This event can occur asynchronously at each master site.
4. The success or failure of this action at each master site is noted in the RepCatLog view at each site. Ultimately, this information is propagated to the master definition site. If the event completed successfully at a master site, the callback for that site is removed from the RepCatLog view at the master definition site.
5. If the event completed successfully at all sites, all entries in the RepCatLog view at all sites, including the master definition site, will have been removed.
By synchronously broadcasting the change Oracle ensures that all sites are aware of the change, and thus are capable of remaining in sync. 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 this support after you alter the object by calling the GENERATE_REPLICATION_SUPPORT procedure. Oracle then updates the generated triggers, packages and procedures as necessary to support replication of the altered object at all master sites.
Note that 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. 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 only communicate with their associated master site. For more information on snapshot site refresh, see ![[*]](jump.gif)
.
If you must alter the shape of a snapshot as the result of a change to its master, you must drop and recreate the snapshot by calling the DBMS_REPCAT.DROP_SNAPSHOT_REPOBJECT procedure and then the DBMS_REPCAT.CREATE_SNAPSHOT_REPOBJECT procedure.