Oracle7 Server Distributed Systems Manual, Vol. 2 Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index



Go to previous file in sequence Go to next file in sequence

Administering a Replicated Environment


This chapter describes how to administer your replicated database environment. The topics include the following:

Note that most of the activities described in this chapter can be accomplished much more easily by using Oracle's Replication Manager, a GUI interface for replication. See the documentation for Oracle Replication Manager for more information.

Determining the Cause of an Error

When Oracle pushes a deferred transaction from a snapshot or master site to another master site, it uses two-phase commit to ensure that the transaction is not removed from the local queue until it has been successfully propagated to the remote site. A transaction can be successfully propagated without being successfully applied. An error in applying a deferred transaction may be the result of a database problem, such as a lack of available space in a table that you are attempting to update, or may be the result of an unresolvable update conflict. If an error occurs, Oracle performs the following actions at the destination site:

Deferred transactions consist of a series of deferred remote procedure calls that must be applied in a given order to maintain transaction consistency. The DefError view provides the ID of the transaction that could not be applied. You can use this ID to locate the queued calls associated with this transaction. These calls are stored in the DefCall view. You can use the procedures in the DBMS_DEFER_QUERY package to determine the arguments to the procedures listed in the DefCall view.

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.

Determining the Type of an Argument

The DefCall view provides you with the name of each remote procedure call associated with a particular deferred transaction, and the number of arguments to the procedure. Before you can get the value of an argument to a deferred remote procedure call, you must know the type of the argument. Use the GET_ARG_TYPE function in the DBMS_DEFER_QUERY package to determine the type of an argument, as shown in the following example:

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.

Determining the Value of an Argument

Once you know the type of an argument to a deferred remote procedure call, you can next determine the value of this argument by using the appropriate function in the DBMS_DEFER_QUERY package. For example, if you wanted to get the value of an argument of type VARCHAR2, you would use the GET_VARCHAR2_ARG function, as shown in the following example:

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.

Manually Resolving an Error

Once you have determined the cause of an error, you may need to perform one or more of the following actions at the destination site after fixing the error:

There may also be times when you need to delete a transaction from the deferred transaction queue.

Re-executing a Transaction

To re-execute a deferred transaction that did not initially complete successfully, call the EXECUTE_ERROR procedure in the DBMS_DEFER_SYS package, as shown in the following example:

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.

Deleting a Transaction from the DefError View

To delete a transaction from the DefError view, call the DELETE_ERROR procedure in the DBMS_DEFER_SYS package, as shown in the following example:

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

Additional Information: The parameters for the DELETE_ERROR procedure are described in Table 12 - 18.

Deleting a Transaction from the Deferred Transaction Queue

To delete a transaction from the deferred transaction queue, call the DELETE_TRAN procedure in the DBMS_DEFER_SYS package, as shown in the following example:

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:

After Oracle deletes a transaction, if the transaction is not queued for any other destinations, Oracle removes the appropriate entries from the DefTran and DefCall views as well.

Additional Information: The parameters for the DELETE_TRAN procedure are described in Table 12 - 19.

Recovery

Databases using symmetric replication are distributed databases. Follow the guidelines for distributed database backups outlined in the Oracle7 Server Administrator's Guide when creating backups of symmetric replication databases. Follow the guidelines for coordinated distributed recovery in the Oracle7 Server Administrator's Guide when recovering a symmetric replication database.

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.

Changing Master Definition Sites

To change your master definition site to another master site in your replicated environment, call the RELOCATE_MASTERDEF procedure in the DBMS_REPCAT package, as shown in the following example:

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.

Usage Notes

It is not necessary for either the old or new master definition site to be available when you call RELOCATE_MASTERDEF. In a planned reconfiguration, you should invoke RELOCATE_MASTERDEF with NOTIFY_MASTERS TRUE and INCLUDE_OLD_MASTERDEF TRUE. If just the master definition site fails, you should invoke RELOCATE_MASTERDEF with NOTIFY_MASTERS TRUE and INCLUDE_OLD_MASTERDEF FALSE. If several master sites and the master definition site fail, the replication administrator should invoke RELOCATE_MASTERDEF at each operational master with NOTIFY_MASTERS FALSE.

Changing a Snapshot Site's Master

To change the master database of a snapshot replicated object group to another master site, call the SWITCH_SNAPSHOT_MASTER procedure in the DBMS_REPCAT package, as shown in the following example:

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.

Auditing the Successful Resolution of Conflicts

Whenever the symmetric replication facility detects and successfully resolves an update, delete, or uniqueness conflict, you can view information about what method was used to resolve the conflict by querying the RepResolution_Statistics view. This view is only updated if you have chosen to turn on conflict resolution statistics gathering for the table involved in the conflict.

Gathering Conflict Resolution Statistics

Use the REGISTER_STATISTICS procedure in the DBMS_REPCAT package to collect information about the successful resolution of update, delete, and uniqueness conflicts for a table. The following example gathers statistics for the EMP table in the ACCT_REC schema:

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

Viewing Conflict Resolution Statistics

After you call REGISTER_STATISTICS for a table, each conflict that is successfully resolved for that table is logged in the RepResolution_Statistics view. Information about unresolved conflicts is always logged to the DefError view, whether the object is registered or not.

Additional Information: The RepResolution_Statistics view is described in Table 13 - 18 and the DefError view is described in Table 13 - 23.

Canceling Conflict Resolution Statistics Gathering

Use the CANCEL_STATISTICS procedure in the DBMS_REPCAT package if you no longer want to collect information about the successful resolution of update, delete, and uniqueness conflicts for a table. The following example cancels statistics gathering on the EMP table in the ACCT_REC schema:

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.

Removing Statistics Information

If you registered a table to log information about the successful resolution of update, delete, and uniqueness conflicts, you can remove this information from the RepResolution_Statistics view by calling the PURGE_STATISTICS procedure in the DBMS_REPCAT package.

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.

Determining Outstanding Changes

After making changes to your replicated environment at the master definition site, you can use the WAIT_MASTER_LOG procedure in the DBMS_REPCAT package to determine if these changes have been applied to your current master site.

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.

Applying Outstanding Changes

Whenever you alter a replicated object group, the DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN procedure must run at each master site in order for the changes applied at the master definition site to be visible everywhere. Usually this procedure is periodically invoked at each master site by a background process and no manual intervention is required.

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 [*], 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.

Removing Log Information

If you resolved an error condition from a replication administration request, you can remove related error messages in the RepCatLog view by calling the PURGE_MASTER_LOG procedure in the DBMS_REPCAT package, as shown in the following example:

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.

Importing and Exporting Replicated Data

The following sections describe how to use the Import, Export, and SQL*Loader utilities with replicated data.

Loading and Import of Replicated Data

When importing or loading data into replicated tables you need to consider whether you want the data to be replicated to other sites by symmetric replication. You might not wish to use symmetric replication to replicate the data if you are loading or importing a large amount of data and are therefore performing the load or import at each site.

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:

Using Export/Import to Reorganize Deferred RPC Queues and Replication Catalogs

You may occasionally need to reorganize deferred remote procedure call queues to reclaim fragmented space (you are less likely to need to reorganize replication catalogs, but you can use similar procedures).

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:

Performing Checks on Imported Data

After performing an export/import of a replicated object or an object used by the symmetric replication facility (for example, the RepSchema view), you should run the REPCAT_IMPORT_CHECK procedure in the DBMS_REPCAT package.

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.

Supplying Asynchronous DDL

If you need to perform a task for which Oracle does not provide a method, you can supply the DDL that you want to have executed at each master site by calling the EXECUTE_DDL procedure in the DBMS_REPCAT package.

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.

Determining Differences Between Replicated Tables

When administering a replicated environment, you may periodically want to check whether the contents of two replicated tables are identical. The following procedures in the DBMS_RECTIFIER_DIFF package let you identify, and optionally rectify, the differences between two tables when both sites are release 7.3 or higher:

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);

Attention: If you have any additional constraints on the "comparison" table you must ensure that they will not be violated when you call RECTIFY. You may need to update the table directly using the information from the missing rows table. If so, be certain to DELETE the appropriate rows from the missing rows tables.

Updating Comments

There are several procedures in the DBMS_REPCAT package that allow you to update the comment information in the various views associated with replication. Table 7 - 1 lists the appropriate procedure to call for each view.

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.
Table 7 - 1. Updating Comments in Symmetric Replication Facility Views




Go to previous file in sequence Go to next file in sequence
Prev Next
Oracle
Copyright © 1996 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index