Oracle7 Server Distributed Systems Volume II: Replicated Data

Diagnosing Problems with DBA_REPCATLOG Entries

The DBA_REPCATLOG view shows the interim and final status for asynchronous administrative activities. You should examine this table before enabling a replication environment with RESUME_MASTER_ACTIVITY. You should also examine it whenever you suspect replication administration problems. The master definition site uses its DBA_REPCATLOG view to record both local and remote activities. Each of these activities is explained below.

For each local activity, there is a row in the master definition site's DBA_REPCATLOG view. The STATUS column in this row begins with the value READY. If the activity completes normally, the row is deleted from the DBA_REPCATLOG view. If the activity encounters a problem, the Oracle error number is captured in the ERRNUM column and the error message is captured in the MESSAGE column. These columns are helpful when diagnosing symmetric replication problems.

For a remote activity, the symmetric replication facility creates two rows that appear in the DBA_REPCATLOG view: one at the master definition site with a STATUS value of AWAIT_CALLBACK, and one at the remote master with a STATUS value of READY. What happens to these two log rows depends on whether the remote activity completes normally.

If the remote activity completes normally, the remote master updates its row in the DBA_REPCATLOG view to DO_CALLBACK and commits. When it establishes communication with the master definition site, the remote master deletes the associated row from its DBA_REPCATLOG view and the corresponding row at the master definition site and commits.

If the remote activity encounters a problem, the remote master updates the ERRNUM and MESSAGE columns and sets the STATUS column to ERROR for the associated row in the DBA_REPCATLOG view for the remote master. When it establishes communication with the master definition site, the remote master updates the row in the DBA_REPCATLOG view at the master definition site with the local ERRNUM, MESSAGE, and STATUS values. Then the remote master deletes the associated row in its DBA_REPCATLOG view and commits.

DO_DEFERRED_REPCAT_ADMIN executes the requests in the local DBA_REPCATLOG submitted by the user that invoked DO_DEFERRED_REPCAT_ADMIN in the order determined by the ID column. When DO_DEFERRED_REPCAT_ADMIN is executed at a master that is not the master definition site, it does as much as possible. Some asynchronous activities such as populating a replicated table require communication with the master definition site. If this communication is not possible, DO_DEFERRED_REPCAT_ADMIN stops executing rows from DBA_REPCATLOG to avoid executing DBA_REPCATLOG rows out of order. Some communication with the master definition site, such as the final step of updating or deleting a DBA_REPCATLOG row at the master definition site, can be deferred and will not prevent DO_DEFERRED_REPCAT_ADMIN from executing additional rows in the DBA_REPCATLOG.

Entries Not Removed from Log

Occasionally, you may notice that an entry in the DBA_REPCATLOG view is not removed as anticipated, yet the STATUS is not ERROR. Here are some items to check if the symmetric replication facility does not appear to be working properly.

Ensure that there is not a problem with the execution of the job queue. Job queue errors are described .

Submit a trivial job at the master site to ensure that it runs as expected. In a newly created database, jobs are not automatically enabled until the database is shut down and restarted. You can call DBMS_IJOB.SET_ENABLED(TRUE) to avoid restarting the database. (Note the I, for internal, in DBMS_IJOB.)

Additionally, check the LOG_USER column in the DBA_JOBS view to ensure that the replication job is being run on behalf of the replication administrator. Check the USERID column of the DBA_REPCATLOG view to ensure that the replication administrator was the user that submitted the request. DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN only performs those administrative requests submitted by the user that calls this procedure.

Ensure the relevant databases are running and communication is possible.

Ensure that you have the necessary private database link for the symmetric replication facility, and that the user designated in the CONNECT TO clause (generally the surrogate replication administrator) has the necessary privileges, as described . Note that database links are required in both directions, and that privileges must be granted at both sites.

Ensure that you have the necessary private database link for the replication administrator, and that the replication administrator has been granted the necessary privileges, as described . Note that database links are required in both directions, and that privileges must be granted at both sites.

Disabling Job Queues

When diagnosing a replication problem, you may find it useful to disable the job queue at one or more masters. To do this, shut down the master and restart it with a value of zero for JOB_QUEUE_PROCESSES. To avoid restarting the database, you can call DBMS_IJOB.SET_ENABLED(FALSE). (Note the I, for internal, in DBMS_IJOB.) You must then connect to the master site and execute the procedure DO_DEFERRED_REPCAT_ADMIN, to execute asynchronous administrative activities at that master. This lets you have better control over the execution time of administrative activities.