Oracle7 Server Distributed Systems Volume II: Replicated Data

DBMS_DEFER_SYS.EXECUTE

Purpose

To force a deferred remote procedure call queue at your current master or snapshot site to be pushed to another master site. For additional information, refer to

Syntax

The parameters for the EXECUTE procedure are shown in Table 12 - 23. The syntax for this procedure is shown below:

DBMS_DEFER_SYS.EXECUTE(
		destination		IN 	VARCHAR2,
		stop_on_error		IN 	BOOLEAN := FALSE,
		transaction_count 	IN 	BINARY_INTEGER := 0,
		execution_seconds 	IN 	BINARY_INTEGER := 0,
		execute_as_user	IN	BOOLEAN := FALSE,
		delay_seconds		IN	NATURAL := 0,
		batch_size		IN	NATURAL := 0)

Parameter Description
destination The fully qualified database name of the master site to which you are forwarding changes.
stop_on_error The default, FALSE, indicates that execution should continue even if errors, such as conflicts are encountered. Set this to TRUE if you want to stop execution when the first error is encountered.
transaction_count Execution stops after TRANSACTION_COUNT (number of transactions) or EXECUTION_SECONDS (number of seconds) has occurred. By default, (TRANSACTION_COUNT = 0 and EXECUTION_SECONDS = 0) transactions are executed until there are no more in the queue.
execution_seconds
execute_as_user The default, FALSE, indicates that a deferred call is authenticated at the remote system using the authentication context of the user who originally queued the deferred call (as indicated in the ORIGIN_USER column of the DefTran view). Set this to TRUE if you want the execution of a deferred call to be authenticated at the remote system using the authentication context of the session user.
delay_seconds The routine will sleep for this many seconds (default is 0), before returning when it finds no deferred calls queued for the destination. A non-zero value can reduce execution overhead compared to calling DBMS_DEFER_SYS.EXECUTE from a tight loop.
batch_size Indicates that a COMMIT should occur when the total number of deferred calls executed exceeds this number, and a complete transaction has been executed. If this argument is 0 (the default), a COMMIT occurs after each deferred transaction. For transactions originating at a master site, bundling transactions in this manner does not affect how errors are resolved, or how errors are logged in the DefError view.
For snapshot sites in a multi-master environment, you should always set this parameter to 0. Otherwise, the transactions are bundled before they are forwarded to other master sites, making conflict resolution more difficult.

Table 12 - 23. Parameters for EXECUTE

Parameter	Description
`destination`	The fully qualified database name of the master site to which you are forwarding changes.
`stop_on_error`	The default, FALSE, indicates that execution should continue even if errors, such as conflicts are encountered. Set this to TRUE if you want to stop execution when the first error is encountered.
`transaction_count`	Execution stops after TRANSACTION_COUNT (number of transactions) or EXECUTION_SECONDS (number of seconds) has occurred. By default, (TRANSACTION_COUNT = 0 and EXECUTION_SECONDS = 0) transactions are executed until there are no more in the queue.
`execution_seconds`
`execute_as_user`	The default, FALSE, indicates that a deferred call is authenticated at the remote system using the authentication context of the user who originally queued the deferred call (as indicated in the ORIGIN_USER column of the DefTran view). Set this to TRUE if you want the execution of a deferred call to be authenticated at the remote system using the authentication context of the session user.
`delay_seconds`	The routine will sleep for this many seconds (default is 0), before returning when it finds no deferred calls queued for the destination. A non-zero value can reduce execution overhead compared to calling DBMS_DEFER_SYS.EXECUTE from a tight loop.
`batch_size`	Indicates that a COMMIT should occur when the total number of deferred calls executed exceeds this number, and a complete transaction has been executed. If this argument is 0 (the default), a COMMIT occurs after each deferred transaction. For transactions originating at a master site, bundling transactions in this manner does not affect how errors are resolved, or how errors are logged in the DefError view. For snapshot sites in a multi-master environment, you should always set this parameter to 0. Otherwise, the transactions are bundled before they are forwarded to other master sites, making conflict resolution more difficult.