| Oracle7 Server Distributed Systems Manual, Vol. 2 |  Library |
 Product |
 Contents |
 Index |
| Oracle7 Server Distributed Systems Manual, Vol. 2 | Library |
Product |
Contents |
Index |
After you successfully resolve the error at the destination site, it is removed from the DefError view, as well as the DefCall and DefTran views at the destination site. Because the transaction queued for this site was removed from the originating queue when the transaction was originally pushed, resolving the transaction at the destination site has no effect on the queue at the originating site.
type_no := DBMS_DEFER_QUERY.GET_ARG_TYPE( call_no => 234, deferred_tran_db => 'acct_hq.hq.com', arg_no => 3, deferred_tran_id => '1.7.356');
In this example, the GET_ARG_TYPE function returns the datatype of the third argument to the deferred remote procedure call with ID number 234 that originated from the ACCT_HQ database.
Additional Information: The parameters for the GET_ARG_TYPE function are described in Table 12 - 9, the exceptions are listed in Table 12 - 10, and the possible return values are described in Table 12 - 11.
val := DBMS_DEFER_QUERY.GET_VARCHAR2_ARG( callno => 234, deferred_tran_db => 'acct_hq.hq.com', arg_no => 3)
Whereas the call to GET_ARG_TYPE in the previous example returned only the datatype of the third argument to the procedure with ID number 234, the call to the GET_VARCHAR2_ARG function returns the actual value passed for this argument.
The type of the argument value that you want to retrieve determines the name of the function that you need to call. The supported datatypes are: NUMBER, VARCHAR2, CHAR, DATE, RAW, and ROWID. The datatype of the return value must match the datatype of the function name.
Additional Information: The parameters for all of the GET_datatype_ARG functions are described in Table 12 - 12, and the exceptions are listed in Table 12 - 13.
DBMS_DEFER_SYS.EXECUTE_ERROR( deferred_tran_id => '234', deferred_tran_db => 'acct_hq.hq.com', destination => 'acct_ny.ny.com');
This example re-executes the transaction with ID number 234 that originated at the ACCT_HQ site and was queued for execution at the ACCT_NY site.
Upon successful execution, the transaction is removed from the DefError view, as well as the local deferred transaction views. Although when you call EXECUTE_ERROR you must always specify the database for which the transaction was originally queued (that is, the site where you want to re-execute a transaction), you can choose to re-execute a single transaction, all transactions originating from a given location, or all transactions, regardless of their originating location.
If you call EXECUTE_ERROR for a single transaction, that transaction is not committed, even if it completes successfully. If you are satisfied with the results of the transaction, you should issue the SQL command COMMIT WORK. If EXECUTE_ERROR re-executes multiple transactions, each transaction is committed as it completes.
Additional Information: The parameters for the EXECUTE_ERROR procedure are described in Table 12 - 24.
DBMS_DEFER_SYS.DELETE_ERROR( deferred_tran_id => '234', deferred_tran_db => 'acct_hq.hq.com', destination => 'acct_ny.ny.com');
This example removes the transaction with ID number 234 that originated at the ACCT_HQ site and was queued for execution at the ACCT_NY site from the DefError view.
Calling DELETE_ERROR removes the specified transaction from the DefError view, as well as the local deferred transaction views. By passing null for selected arguments, you can remove all transactions associated with a particular site from the DefError view. For example, assuming that you have sites A, B, and C, you can choose to remove from the DefError view
DBMS_DEFER_SYS.DELETE_TRAN( deferred_tran_id => '234', deferred_tran_db => 'acct_hq.hq.com', destination => 'acct_ny.ny.com');
This example deletes the transaction with ID number 234 that originated at the ACCT_HQ site and was queued for execution at the ACCT_NY site.
Calling DELETE_TRAN removes the transaction from the queue for the destination database. If you do not specify a destination database, the transaction is removed from the queues for all destinations. For example, assuming that you have sites A, B, and C you can choose to delete:
Additional Information: The parameters for the DELETE_TRAN procedure are described in Table 12 - 19.
If you fail to follow the coordinated distributed recovery guidelines, there is no guarantee that your symmetric replication databases will be consistent. For example, a restored master site may have propagated different transactions to different masters. You may need to perform extra steps to correct for an incorrect recovery operation. One such method is as to drop and recreate all replicated objects in the recovered database.
You should consider removing pending deferred transactions and deferred error records from the restored database, and resolve any outstanding distributed transactions before dropping and recreating replicated objects. If the restored database was a master definition site for some replicated environments, you should designate a new master definition site (as described below) before dropping and creating objects. Any snapshots mastered at the restored database should be fully refreshed, as well as any snapshots in the restored database.
To provide continued access to your data, you may need to change master definition sites (assuming the database being recovered was the master definition site), or remaster snapshot sites (assuming their master site is being recovered). These techniques are described in the following sections.
DBMS_REPCAT.RELOCATE_MASTERDEF( gname => 'acct', old_masterdef => 'acct_hq.hq.com', new_masterdef => 'acct_ny.ny.com', notify_masters => TRUE, include_old_masterdef => TRUE);
In this example, the master definition site for the ACCT replicated object group is changed from ACCT_HQ to ACCT_NY. The former master definition site remains as a master site in the replicated environment. By default, all master sites, including the former master definition site, are notified of this change.
Additional Information: The parameters for the RELOCATE_MASTERDEF procedure are described in Table 12 - 159, and the exceptions are listed in Table 12 - 160.
DBMS_REPCAT.SWITCH_SNAPSHOT_MASTER( gname => 'acct', master => 'acct_ny.ny.com' execute_as_user => 'FALSE');
In this example, the master site for the ACCT object group is changed to the ACCT_NY database.
You must call this procedure at the snapshot site whose master site you want to change. The new database must be a master site in the replicated environment.
When you call this procedure, Oracle uses the new master to perform a full refresh of each snapshot in the local object group.
The entries in the SYS.SLOG$ table at the old master site for the switched snapshot are not removed. As a result, the MLOG$ table of the switched updatable snapshot at the old master site has the potential to grow indefinitely, unless you purge it by calling DBMS_SNAPSHOT.PURGE_LOG.
Additional Information: The parameters for the SWITCH_SNAPSHOT_MASTER procedure are described in Table 12 - 171, and the exceptions are listed in Table 12 - 172.
DBMS_REPCAT.REGISTER_STATISTICS( sname => 'acct_rec', oname => 'emp');
Additional Information: The parameters for the REGISTER_STATISTICS procedure are described in Table 12 - 157, and the exceptions are listed in Table 12 - 158
Additional Information: The RepResolution_Statistics view is described in Table 13 - 18 and the DefError view is described in Table 13 - 23.
DBMS_REPCAT.CANCEL_STATISTICS( sname => 'acct_rec', oname => 'emp');
Additional Information: The parameters for the CANCEL_STATISTICS procedure are described in Table 12 - 86, and the exceptions are listed in Table 12 - 87.
The following example purges the statistics gathered about conflicts resolved due to inserts, updates, and deletes on the EMP table between January 1 and March 31:
DBMS_REPCAT.PURGE_STATISTICS( sname => 'acct_rec', oname => 'emp', start_date => '01-JAN-95', end_date => '31-MAR-95);
Additional Information: The parameters for the PURGE_STATISTICS procedure are described in Table 12 - 153, and the exceptions are listed in Table 12 - 154.
In the following example, this procedure waits until either 120 seconds have passed or there are at most 5 records in the local RepCatLog view that represent administrative activities for the ACCT replicated object group that have not completed before returning the actual number of incomplete activities.
Activities that have completed with or without an error are not considered. This allows you to determine if changes that were asynchronously propagated to a master site have been applied.
incomplete NATURAL; DBMS_REPCAT.WAIT_MASTER_LOG( gname => 'acct', record_count => 5, timeout => 120, true_count => incomplete);
If there are N master sites and one master definition site for a replicated object group, most asynchronous administrative requests eventually create N+1 log records at the master definition site and one log record at each master. ADD_MASTER_DATABASE is an exception, and may create a log record at the master definition site and a log record at the new master site for each object in the replicated object group.
Additional Information: The parameters for the WAIT_MASTER_LOG procedure are described in Table 12 - 173, and the exceptions are listed in Table 12 - 174.
Whenever you add a new master site to your replicated environment, a job is automatically inserted into the job queue. This job periodically executes the procedure DO_DEFERRED_REPCAT_ADMIN. Whenever you alter a replicated object group, Oracle attempts to start this job immediately in order to apply the replicated changes at each master site.
In the following example, the local outstanding deferred administrative procedures for the ACCT replicated object group are executed (with the assistance of job queues) for all master sites. Had ALL_SITES been set to the default value, FALSE, the deferred administrative procedures would have been executed at the current master site only.
DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN( gname => 'acct', all_sites => true);
Note: DO_DEFERRED_REPCAT_ADMIN executes only those administrative requests submitted by the connected user that called DO_DEFERRED_REPCAT_ADMIN. Requests submitted by other users are ignored.
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.
Attention: If the deferred changes involve generating replication support as described ![[*]](jump.gif)
, it will be necessary to invoke DO_DEFERRED_REPCAT_ADMIN twice to insure that both phases 1 and 2 are executed due to object dependencies.
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.
Additional Information: The parameters for the DO_DEFERRED_REPCAT_ADMIN procedure are described in Table 12 - 115, and the exceptions are listed in Table 12 - 116.
DBMS_REPCAT.PURGE_MASTER_LOG( id => 1763, source => 'acct_ny.ny.com', gname => 'acct');
This procedure removes all local log records corresponding to the request on the ACCT replicated object group that originated at the ACCT_NY master with the identification number 1763. If any parameter is NULL, Oracle treats it as a wildcard.
Like most other procedures in the DBMS_REPCAT package that are executed at a master site, a side effect of PURGE_MASTER_LOG is to perform any local deferred administrative requests for the given replicated object group. This administration is attempted before the log is purged.
Additional Information: The parameters for the PURGE_MASTER_LOG procedure are described in Table 12 - 151, and the exceptions are listed in Table 12 - 152.
If you wish to replicate loaded or imported data using symmetric replication you must ensure that the replication triggers fire as data is loaded or imported. The direct path of SQL*Loader cannot be used. You must be certain that the replication triggers are created and enabled before importing and loading data.
If you do not wish to replicate loaded or imported data using symmetric replication you can use the direct path of SQL*Loader, or you can explicitly disable replication while loading or importing data. To disable the replication of the data, use either of the following methods:
Warning: Do not (accidentally) copy the contents of the deferred remote procedure call queues or the replication catalogs between databases. This includes using Export/Import to transfer data, or copying files to create a new database. The only exception is when you replace one database with another database that has the same global name. Error message 23327 is issued during import if you attempt to import the data from a deferred remote procedure call queue into a database with a different global name.
To reorganize deferred remote procedure call queues or replication catalogs using Export/Import, complete the following steps:
In the following example, the procedure checks the objects in the ACCT replicated object group at a snapshot site to ensure that they have the appropriate object identifiers and status values:
DBMS_REPCAT.REPCAT_IMPORT_CHECK( gname => 'acct', master => FALSE);
Additional Information: The parameters for the REPCAT_IMPORT_CHECK procedure are described in Table 12 - 163, and the exceptions are listed in Table 12 - 164.
The following example creates an index on the NAME column of the EMP table at the ACCT_NY master site. Had the default, NULL, been used for the MASTER_LIST argument, the index would have been created at all master sites.
DBMS_REPCAT.EXECUTE_DDL( gname => 'acct', master_list => 'acct_ny.ny.com', ddl_text => 'CREATE INDEX name_idx ON
acct_rec.emp(name)');
You can call this procedure only from the master definition site. The DDL is applied asynchronously at each of the designated sites as described . The RepCatLog view contains interim status and any asynchronous error messages generated by the request. Although the replicated object group need not be quiesced when you invoke EXECUTE_DDL, you may prefer to quiesce the environment first by calling DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY.
Additional Information: The parameters for the EXECUTE_DDL procedure are described in Table 12 - 141, and the exceptions are listed in Table 12 - 142.
DIFFERENCES
The DIFFERENCES procedure compares two replicas of a table, and determines all rows in the first replica that are not in the second and all rows in the second that are not in the first. The output of this procedure is stored in two user-created tables. The first table stores the values of the missing rows, and the second table is used to indicate which site contains each row.
RECTIFY
The RECTIFY procedure uses the information generated by the DIFFERENCES procedure to rectify the two tables. Any rows found in the first table and not in the second are inserted into the second table. Any rows found in the second table and not in the first are deleted from the second table.
To restore equivalency between all copies of a replicated table, you should complete the following steps:
CREATE TABLE missing_rows_data
(
empno NUMBER,
sal NUMBER,
bonus NUMBER
)
CREATE TABLE missing_rows_location
(
present VARCHAR2(128),
absent VARCHAR2(128),
r_id ROWID
)
DBMS_RECTIFIER_DIFF.DIFFERENCES(
sname1 => 'hr',
oname1 => 'employee',
reference_site => 'ny.com',
sname2 => 'hr',
oname2 => 'employee',
comparison_site => 'sf.com',
where_clause => '',
column_list => 'empno,sal,bonus',
missing_rows_sname => 'scott',
missing_rows_oname1 => 'missing_rows_data',
missing_rows_oname2 => 'missing_rows_location',
missing_rows_site => 'ny.com',
max_missing => 100,
commit_rows => 50);
Figure 7 - 1. Determining Differences Between Replicas
DBMS_RECTIFIER_DIFF.RECTIFY(
sname1 => 'hr',
oname1 => 'employee',
reference_site => 'ny.com',
sname2 => 'hr',
oname2 => 'employee',
comparison_site => 'sf.com',
column_list => 'empno,sal,bonus',
missing_rows_sname => 'scott',
missing_rows_oname1 => 'missing_rows_data',
missing_rows_oname2 => 'missing_rows_location',
missing_rows_site => 'ny.com',
commit_rows => 50);
| View | DBMS_REPCAT Procedure | Additional Information |
| RepGroup | COMMENT_ON_REPGROUP( gname IN VARCHAR2, comment IN VARCHAR2) | The parameters for the COMMENT_ON_REPGROUP procedure are described in Table 12 - 92, and the exceptions are listed in Table 12 - 93. |
| RepObject | COMMENT_ON_REPOBJECT( sname IN VARCHAR2, oname IN VARCHAR2, type IN VARCHAR2, comment IN VARCHAR2) | The parameters for the COMMENT_ON_REPOBJECT procedure are described in Table 12 - 96, and the exceptions are listed in Table 12 - 97. |
| RepSites | COMMENT_ON_REPSITES( gname IN VARCHAR2, master IN VARCHAR, comment IN VARCHAR2) | The parameters for the COMMENT_ON_REPSITES procedure are described in Table 12 - 94, and the exceptions are listed in Table 12 - 95. |
| RepColumn_Group | COMMENT_ON_COLUMN_GROUP( sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2, comment IN VARCHAR2) | The parameters for the COMMENT_ON_COLUMN_GROUP procedure are described in Table 12 - 88, and the exceptions are listed in Table 12 - 89. |
| RepPriority_Group | COMMENT_ON_PRIORITY_GROUP( gname IN VARCHAR2, pgroup IN VARCHAR2, comment IN VARCHAR2) | The parameters for the COMMENT_ON_PRIORITY_GROUP procedure are described in Table 12 - 90, and the exceptions are listed in Table 12 - 91. |
| RepPriority_Group (site priority group) | COMMENT_ON_SITE_PRIORITY( gname IN VARCHAR2, name IN VARCHAR2, comment IN VARCHAR2) | The parameters for the COMMENT_ON_SITE_PRIORITY procedure are described in Table 12 - 90, and the exceptions are listed in Table 12 - 91. |
| RepResolution (uniqueness conflicts) | COMMENT_ON_UNIQUE_RESOLUTION( sname IN VARCHAR2, oname IN VARCHAR2, constraint_name IN VARCHAR2, sequence_no IN NUMBER, comment IN VARCHAR2) | The parameters for the COMMENT_ON_UNIQUE_RESOLUTION procedures are described in Table 12 - 98, and the exceptions are listed in Table 12 - 99. |
| RepResolution (update conflicts) | COMMENT_ON_UPDATE_RESOLUTION( sname IN VARCHAR2, oname IN VARCHAR2, column_group IN VARCHAR2, sequence_no IN NUMBER, comment IN VARCHAR2) | The parameters for the COMMENT_ON_UNIQUE_RESOLUTION procedures are described in Table 12 - 98, and the exceptions are listed in Table 12 - 99. |
| RepResolution (delete conflicts) | COMMENT_ON_DELETE_RESOLUTION( sname IN VARCHAR2, oname IN VARCHAR2, sequence_no IN NUMBER, comment IN VARCHAR2) | The parameters for the COMMENT_ON_UNIQUE_RESOLUTION procedures are described in Table 12 - 98, and the exceptions are listed in Table 12 - 99. |
|
Prev Next |
 Copyright © 1996 Oracle Corporation. All Rights Reserved. |
Library |
Product |
Contents |
Index |