21 DBMS_APPLY_ADM
The DBMS_APPLY_ADM
package provides subprograms to configure and manage Oracle Apply processes, XStream outbound servers, and XStream inbound servers.
This chapter contains the following topics:
See Also:
Oracle Database XStream Guide for more information about XStream outbound servers and inbound servers
21.1 DBMS_APPLY_ADM Overview
The DBMS_APPLY_ADM
package provides interfaces to start, stop, and configure Oracle Apply processes, XStream outbound servers, and XStream inbound servers.
This package includes subprograms for configuring apply handlers, setting enqueue destinations for messages, and specifying execution directives for messages. This package also provides administrative subprograms that set the instantiation SCN for objects at a destination database. This package also includes subprograms for managing apply errors.
XStream inbound servers and outbound servers can be used in an XStream configuration in a multitenant container database (CDB). A CDB is an Oracle database that includes zero, one, or many user-created pluggable databases (PDBs).
Note:
-
For simplicity, this chapter refers to apply processes, XStream outbound servers, and XStream inbound servers as apply components. This chapter identifies a specific type of apply component when necessary.
-
Using XStream requires purchasing a license for the Oracle GoldenGate product.
See Also:
-
Oracle Database Concepts for more information about CDBs and PDBs
21.2 DBMS_APPLY_ADM Security Model
Security on this package can be controlled by either granting EXECUTE
on this package to selected users or roles, or by granting EXECUTE_CATALOG_ROLE
to selected users or roles..
If subprograms in the package are run from within a stored procedure, then the user who runs the subprograms must be granted EXECUTE
privilege on the package directly. It cannot be granted through a role.
When the DBMS_APPLY_ADM
package is used to manage an Oracle Replication configuration, it requires that the user is granted the privileges of an Oracle Replication administrator.
When the DBMS_APPLY_ADM
package is used to manage an XStream configuration, it requires that the user is granted the privileges of an XStream administrator.
Note:
The user must be granted additional privileges to perform some administrative tasks using the subprograms in this package, such as setting an apply user. If additional privileges are required for a subprogram, then the privileges are documented in the section that describes the subprogram.
See Also:
Oracle Database XStream Guide for information about configuring an XStream administrator
21.3 DBMS_APPLY_ADM Deprecated Subprograms
The NONE
value for the commit_serialization
apply component parameter is deprecated. It is replaced by the DEPENDENT_TRANSACTIONS
value.
Note:
Oracle recommends that you do not use deprecated apply component parameter values. Support for deprecated features is for backward compatibility only.
See Also:
21.4 Summary of DBMS_APPLY_ADM Subprograms
This table topic lists and describes the DBMS_APPLY_ADM
subprograms.
Table 21-1 DBMS_APPLY_ADM Package Subprograms
Subprogram | Description |
---|---|
Alters an apply component |
|
Removes the key columns that were used as the substitute primary key by the |
|
Specifies whether to compare the old value of one or more columns in a row logical change record (row LCR) with the current value of the corresponding columns at the destination site during apply |
|
Creates an apply component |
|
Creates an object dependency |
|
Deletes all the error transactions for the specified apply component |
|
Deletes the specified error transaction |
|
Drops an apply component |
|
Drops an object dependency |
|
Reexecutes the error transactions for the specified apply component |
|
Reexecutes the specified error transaction |
|
Returns the message payload from the error queue for the specified message number and transaction identifier |
|
Enables or disables basic conflict resolution for an apply process and a table |
|
Adds, modifies, or removes a prebuilt DML conflict handler for |
|
Sets a user procedure as a procedure DML handler for a specified operation on a specified database object for a single apply component or for all apply components in the database |
|
Sets the queue where the apply component automatically enqueues a message that satisfies the specified rule |
|
Specifies whether a message that satisfies the specified rule is executed by an apply component |
|
Records the specified instantiation SCN for the specified source database and, optionally, for the schemas at the source database and the tables owned by these schemas |
|
Records the set of columns to be used as the substitute primary key for local apply purposes and removes existing substitute primary key columns for the specified object if they exist |
|
Sets an apply parameter to the specified value |
|
Specifies how a particular error is handled based on its error number |
|
Records the specified instantiation SCN for the specified schema in the specified source database and, optionally, for the tables owned by the schema at the source database |
|
Records the specified instantiation SCN for the specified table in the specified source database |
|
Adds, updates, or drops an update conflict handler for the specified object |
|
Sets or removes a value dependency |
|
Directs the apply component to start applying messages |
|
Stops the apply component from applying any messages and rolls back any unfinished transactions being applied |
Note:
All procedures commit unless specified otherwise. However, the GET_ERROR_MESSAGE
function does not commit.
21.4.1 ALTER_APPLY Procedure
This procedure alters an apply component.
Syntax
DBMS_APPLY_ADM.ALTER_APPLY( apply_name IN VARCHAR2, rule_set_name IN VARCHAR2 DEFAULT NULL, remove_rule_set IN BOOLEAN DEFAULT FALSE, message_handler IN VARCHAR2 DEFAULT NULL remove_message_handler IN BOOLEAN DEFAULT FALSE, ddl_handler IN VARCHAR2 DEFAULT NULL, remove_ddl_handler IN BOOLEAN DEFAULT FALSE, apply_user IN VARCHAR2 DEFAULT NULL, apply_tag IN RAW DEFAULT NULL, remove_apply_tag IN BOOLEAN DEFAULT FALSE, precommit_handler IN VARCHAR2 DEFAULT NULL, remove_precommit_handler IN BOOLEAN DEFAULT FALSE, negative_rule_set_name IN VARCHAR2 DEFAULT NULL, remove_negative_rule_set IN BOOLEAN DEFAULT FALSE);
Parameters
Table 21-2 ALTER_APPLY Procedure Parameters
Parameter | Description |
---|---|
|
The name of the apply component being altered. You must specify the name of an existing apply component. Do not specify an owner. |
|
The name of the positive rule set for the apply component. The positive rule set contains the rules that instruct the apply component to apply messages. If you want to use a positive rule set for the apply component, then you must specify an existing rule set in the form An error is returned if the specified rule set does not exist. If you specify |
|
If If you remove the positive rule set for an apply component, and a negative rule set exists for the apply component, then the apply component dequeues all messages in its queue that are not discarded by the negative rule set. If If the |
|
A user-defined procedure that processes non-LCR messages in the queue for the apply component. See "Usage Notes" in the CREATE_APPLY Procedure for more information about a message handler procedure. |
|
If If If the |
|
A user-defined procedure that processes DDL logical change records (DDL LCRs) in the queue for the apply component. All applied DDL LCRs commit automatically. Therefore, if a DDL handler calls the See "Usage Notes" in the CREATE_APPLY Procedure for more information about a DDL handler procedure. |
|
If If If the |
|
The user in whose security domain an apply component dequeues messages that satisfy its rule sets, applies messages directly to database objects, runs custom rule-based transformations, and runs apply handlers. If If a non- If you change the apply user, then this procedure grants the new apply user dequeue privilege on the queue used by the apply component. It also configures the user as a secure queue user of the queue. In addition to the privileges granted by this procedure, you also should grant the following privileges to the apply user:
These privileges can be granted directly to the apply user, or they can be granted through roles. In addition, the apply user must be granted the By default, this parameter is set to the user who created the apply component by running either the Note: If the apply user for an apply component is dropped using |
|
A binary tag that is added to redo entries generated by the specified apply component. The tag is a binary value that can be used to track LCRs. The tag is relevant only if a capture process at the database where the apply component is running captures changes made by the apply component. If so, then the captured changes include the tag specified by this parameter. If The following is an example of a tag with a hexadecimal value of
|
|
If If If the |
|
A user-defined procedure that can receive internal commit directives in the queue for the apply component before they are processed by the apply component. Typically, precommit handlers are used for auditing commit information for transactions processed by an apply component. An internal commit directive is enqueued in the following ways:
For a captured row LCR, a commit directive contains the commit SCN of the transaction from the source database. For a user message, the commit SCN is generated by the apply component. The precommit handler procedure must conform to the following restrictions:
If a precommit handler raises an exception, then the entire apply transaction is rolled back, and all of the messages in the transaction are moved to the error queue. See "Usage Notes" in the CREATE_APPLY Procedure for more information about a precommit handler procedure. |
|
If If If the |
|
The name of the negative rule set for the apply component. The negative rule set contains the rules that instruct the apply component to discard messages. If you want to use a negative rule set for the apply component, then you must specify an existing rule set in the form An error is returned if the specified rule set does not exist. If you specify If you specify both a positive and a negative rule set for an apply component, then the negative rule set is always evaluated first. |
|
If If you remove the negative rule set for an apply component, and a positive rule set exists for the apply component, then the apply component dequeues all messages in its queue that are not discarded by the positive rule set. If If the |
Usage Notes
The following usage notes apply to this procedure:
Automatic Restart of Apply Components
An apply component is stopped and restarted automatically when you change the value of one or more of the following ALTER_APPLY
procedure parameters:
-
message_handler
-
ddl_handler
-
apply_user
-
apply_tag
-
precommit_handler
The ALTER_APPLY Procedure and XStream Outbound Servers
The following usage notes apply to this procedure and XStream outbound servers:
-
The
apply_user
parameter can change the connect user for an outbound server. -
You cannot specify an apply handler for an outbound server. An outbound server ignores the settings for the following parameters:
message_handler
,ddl_handler
, andprecommit_handler
.The client application can perform custom processing of the LCRs instead if necessary.
-
An outbound server cannot set an apply tag for the changes it processes. An outbound server ignores the setting for the
apply_tag
parameter.
The ALTER_APPLY Procedure and XStream Inbound Servers
Inbound servers can use apply handlers and process only DML and DDL LCRs. Therefore, inbound servers ignore message handlers specified in the message_handler
parameter.
21.4.2 CLEAR_KEY_COLUMNS Procedure
This procedure removes the key columns that were used as the substitute primary key by the SET_KEY_COLUMNS
procedure.
Syntax
DBMS_APPLY_ADM.CLEAR_KEY_COLUMNS(
apply_name IN VARCHAR2 DEFAULT NULL);
Parameter
Table 21-3 CLEAR_KEY_COLUMNS Procedure Parameter
Parameter | Description |
---|---|
|
The apply component name. |
Usage Notes
The following usage notes apply to this procedure:
The CLEAR_KEY_COLUMNS Procedure and XStream Outbound Servers
This procedure has no effect on XStream outbound servers.
The CLEAR_KEY_COLUMNS Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
The CLEAR_KEY_COLUMNS Procedure and CDBs
This procedure removes the columns that are used as a substitute primary key. You must perform the CLEAR_KEY_COLUMNS
procedure in the appropriate PDB.
21.4.3 COMPARE_OLD_VALUES Procedure
This procedure specifies whether to compare the old values of one or more columns in a row logical change record (row LCR) with the current values of the corresponding columns at the destination site during apply.
This procedure is relevant only for UPDATE
and DELETE
operations because only these operations result in old column values in row LCRs. The default is to compare old values for all columns.
This procedure is overloaded. The column_list
and column_table
parameters are mutually exclusive.
Syntax
DBMS_APPLY_ADM.COMPARE_OLD_VALUES( object_name IN VARCHAR2, column_list IN VARCHAR2, operation IN VARCHAR2 DEFAULT 'UPDATE', compare IN BOOLEAN DEFAULT TRUE, apply_database_link IN VARCHAR2 DEFAULT NULL); DBMS_APPLY_ADM.COMPARE_OLD_VALUES( object_name IN VARCHAR2, column_table IN DBMS_UTILITY.LNAME_ARRAY, operation IN VARCHAR2 DEFAULT 'UPDATE', compare IN BOOLEAN DEFAULT TRUE, apply_database_link IN VARCHAR2 DEFAULT NULL);
Parameters
Table 21-4 COMPARE_OLD_VALUES Procedure Parameters
Parameter | Description |
---|---|
|
The name of the source table specified as |
|
A comma-delimited list of column names in the table. There must be no spaces between entries. Specify |
|
A PL/SQL associative array of type |
|
The name of the operation, which can be specified as:
|
|
If If |
|
The name of the database link to a non-Oracle database. This parameter should be set only when the destination database is a non-Oracle database. |
Usage Notes
The following usage notes apply to this procedure:
-
The COMPARE_OLD_VALUES Procedure and XStream Outbound Servers
-
The COMPARE_OLD_VALUES Procedure and XStream Inbound Servers
Conflict Detection
By default, an apply component uses the old column values in a row LCR to detect conflicts. You can choose not to compare old column values to avoid conflict detection for specific tables. For example, if you do not want to compare the old values for a set of columns during apply, then, using the COMPARE_OLD_VALUES
procedure, specify the set of columns in the column_list
or column_table
parameter, and set the compare
parameter to FALSE
.
In addition, when the compare_key_only
apply component parameter is set to Y
, automatic conflict detection is disabled, and the apply component only uses primary key and unique key columns to identify the table row for a row LCR. When the compare_key_only
apply component parameter is set to N
, automatic conflict detection is enabled, and the apply component uses all of the old values in a row LCR to identify the table row for a row LCR.
Note:
-
An apply component compares old values for non-key columns when they are present in a row LCR and when the apply component parameter
compare_key_only
is set toN
. -
This procedure raises an error if a key column is specified in
column_list
orcolumn_table
and thecompare
parameter is set toFALSE
.
See Also:
SET_PARAMETER Procedure for more information about the compare_key_only
apply component parameter
The COMPARE_OLD_VALUES Procedure and XStream Outbound Servers
This procedure has no effect on XStream outbound servers.
The COMPARE_OLD_VALUES Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.4 CREATE_APPLY Procedure
This procedure creates an apply component.
Syntax
DBMS_APPLY_ADM.CREATE_APPLY( queue_name IN VARCHAR2, apply_name IN VARCHAR2, rule_set_name IN VARCHAR2 DEFAULT NULL, message_handler IN VARCHAR2 DEFAULT NULL, ddl_handler IN VARCHAR2 DEFAULT NULL, apply_user IN VARCHAR2 DEFAULT NULL, apply_database_link IN VARCHAR2 DEFAULT NULL, apply_tag IN RAW DEFAULT '00', apply_captured IN BOOLEAN DEFAULT FALSE, precommit_handler IN VARCHAR2 DEFAULT NULL, negative_rule_set_name IN VARCHAR2 DEFAULT NULL, source_database IN VARCHAR2 DEFAULT NULL);
Parameters
Table 21-5 CREATE_APPLY Procedure Parameters
Parameter | Description |
---|---|
|
The name of the queue from which the apply component dequeues messages. You must specify an existing queue in the form Note: The |
|
The name of the apply component being created. A The specified name must not match the name of an existing apply component or messaging client. Note: The |
|
The name of the positive rule set for the apply component. The positive rule set contains the rules that instruct the apply component to apply messages. If you want to use a positive rule set for the apply component, then you must specify an existing rule set in the form If you specify An error is returned if the specified rule set does not exist. |
|
A user-defined procedure that processes non-LCR messages in the queue for the apply component. See "Usage Notes" for more information about a message handler procedure. |
|
A user-defined procedure that processes DDL logical change record (DDL LCRs) in the queue for the apply component. All applied DDL LCRs commit automatically. Therefore, if a DDL handler calls the See "Usage Notes" for more information about a DDL handler procedure. |
|
The user who applies all DML and DDL changes that satisfy the apply component rule sets and who runs user-defined apply handlers. If The apply user is the user in whose security domain an apply component dequeues messages that satisfy its rule sets, applies messages directly to database objects, runs custom rule-based transformations configured for apply component rules, and runs apply handlers configured for the apply component. This user must have the necessary privileges to apply changes. This procedure grants the apply user dequeue privilege on the queue used by the apply component and configures the user as a secure queue user of the queue. In addition to the privileges granted by this procedure, you also should grant the following privileges to the apply user:
These privileges can be granted directly to the apply user, or they can be granted through roles. In addition, the apply user must be granted You can use the Note: If the apply user for an apply component is dropped using See "Usage Notes" for more information about this parameter. |
|
The database at which the apply component applies messages. This parameter is used by an apply component when applying changes from Oracle to non-Oracle systems, such as Sybase. Set this parameter to Note: The |
|
A binary tag that is added to redo entries generated by the specified apply component. The tag is a binary value that can be used to track LCRs. The tag is relevant only if a capture process at the database where the apply component is running captures changes made by the apply component. If so, then the captured changes include the tag specified by this parameter. By default, the tag for an apply component is the hexadecimal equivalent of The following is an example of a tag with a hexadecimal value of HEXTORAW('17') If |
|
Either If If To apply both captured LCRs and messages in a persistent queue, you must create at least two apply components. Note: The |
|
A user-defined procedure that can receive internal commit directives in the queue for the apply component before they are processed by the apply component. Typically, precommit handlers are used for auditing commit information for transactions processed by an apply component. An internal commit directive is enqueued in the following ways:
For a row LCR captured by a capture process or synchronous capture, a commit directive contains the commit SCN of the transaction from the source database. For a message enqueued by a user or application, the commit SCN is generated by the apply component. The precommit handler procedure must conform to the following restrictions:
If a precommit handler raises an exception, then the entire apply transaction is rolled back, and all of the messages in the transaction are moved to the error queue. See "Usage Notes" for more information about a precommit handler procedure. |
|
The name of the negative rule set for the apply component. The negative rule set contains the rules that instruct the apply component to discard messages. If you want to use a negative rule set for the apply component, then you must specify an existing rule set in the form If you specify An error is returned if the specified rule set does not exist. If you specify both a positive and a negative rule set for an apply component, then the negative rule set is always evaluated first. |
|
The global name of the source database for the changes that will be applied by the apply component. The source database is the database where the changes originated. If an apply component applies captured messages, then the apply component can apply messages from only one capture process at one source database. If If you do not include the domain name, then the procedure appends it to the database name automatically. For example, if you specify The rules in the apply component rule sets determine which messages are dequeued by the apply component. If the apply component dequeues an LCR with a source database that is different than the source database for the apply component, then an error is raised. You can determine the source database for an apply component by querying the |
Usage Notes
The following sections describe usage notes for this procedure:
DBA Role Requirement
If the user who invokes this procedure is different from the user specified in the apply_user
parameter, then the invoking user must be granted the DBA
role. If the user who invokes this procedure is the same as the user specified in the apply_user
parameter, then the DBA
role is not required for the invoking user. Only the SYS
user can set the apply_user
to SYS
.
Handler Procedure Names
For the message_handler
, ddl_handler
, and precommit_handler
parameters, specify an existing procedure in one of the following forms:
-
[schema_name.]procedure_name
-
[schema_name.]package_name.procedure_name
If the procedure is in a package, then the package_name must be specified. For example, to specify a procedure in the apply_pkg
package in the hr
schema named process_ddls
, enter hr.apply_pkg.process_ddls
. An error is returned if the specified procedure does not exist.
The user who invokes the CREATE_APPLY
procedure must have EXECUTE
privilege on a specified handler procedure. Also, if the schema_name
is not specified, then the user who invokes the CREATE_APPLY
procedure is the default.
Message Handler and DDL Handler Procedure
The procedure specified in both the message_handler
parameter and the ddl_handler
parameter must have the following signature:
PROCEDURE handler_procedure ( parameter_name IN ANYDATA);
Here, handler_procedure
stands for the name of the procedure and parameter_name
stands for the name of the parameter passed to the procedure. For the message handler, the parameter passed to the procedure is a ANYDATA
encapsulation of a user message. For the DDL handler procedure, the parameter passed to the procedure is a ANYDATA
encapsulation of a DDL LCR.
See Also:
Logical Change Record TYPEs for information about DDL LCRs
Precommit Handler Procedure
The procedure specified in the precommit_handler
parameter must have the following signature:
PROCEDURE handler_procedure ( parameter_name IN NUMBER);
Here, handler_procedure
stands for the name of the procedure and parameter_name
stands for the name of the parameter passed to the procedure. The parameter passed to the procedure is the commit SCN of a commit directive.
The CREATE_APPLY Procedure and XStream Outbound Servers
This procedure cannot create an XStream outbound server. To create an XStream outbound server, use the DBMS_XSTREAM_ADM
package.
The CREATE_APPLY Procedure and XStream Inbound Servers
The following usage notes apply to this procedure and XStream inbound servers:
-
The
CREATE_APPLY
procedure always creates an apply process. The apply process remains an apply process if it receives messages from a source other than an XStream client application, such as a capture process. The apply process can become an inbound server if an XStream client application attaches to it before it receives messages from any other source. After the initial contact, an apply process cannot be changed into an inbound server, and an inbound server cannot be changed into an apply process. -
When creating an inbound server using the
CREATE_APPLY
procedure, set theapply_captured
parameter toTRUE
. Inbound servers only process LCRs captured by a capture process. -
Inbound servers can use apply handlers. Inbound servers process only DML and DDL LCRs. Therefore, inbound servers ignore message handlers specified in the
message_handler
parameter.
21.4.5 CREATE_OBJECT_DEPENDENCY Procedure
This procedure creates an object dependency. An object dependency is a virtual dependency definition that defines a parent-child relationship between two objects at a destination database.
An apply component schedules execution of transactions that involve the child object after all transactions with a lower commit system change number (commit SCN) that involve the parent object have been committed. An apply component uses the object identifier of the objects in the logical change records (LCRs) to detect dependencies. The apply component does not use column values in the LCRs to detect dependencies.
Note:
An error is raised if NULL
is specified for either of the procedure parameters.
See Also:
Syntax
DBMS_APPLY_ADM.CREATE_OBJECT_DEPENDENCY( object_name IN VARCHAR2, parent_object_name IN VARCHAR2);
Parameters
Table 21-6 CREATE_OBJECT_DEPENDENCY Procedure Parameters
Parameter | Description |
---|---|
|
The name of the child database object, specified as |
|
The name of the parent database object, specified as |
Usage Notes
The following usage notes apply to this procedure:
-
The CREATE_OBJECT_DEPENDENCY Procedure and XStream Outbound Servers
-
The CREATE_OBJECT_DEPENDENCY Procedure and XStream Inbound Servers
The CREATE_OBJECT_DEPENDENCY Procedure and XStream Outbound Servers
This procedure has no effect on XStream outbound servers.
The CREATE_OBJECT_DEPENDENCY Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.6 DELETE_ALL_ERRORS Procedure
This procedure deletes all the error transactions for the specified apply component.
Syntax
DBMS_APPLY_ADM.DELETE_ALL_ERRORS( apply_name IN VARCHAR2 DEFAULT NULL);
Parameter
Table 21-7 DELETE_ALL_ERRORS Procedure Parameter
Parameter | Description |
---|---|
|
The name of the apply component that raised the errors while processing the transactions. Do not specify an owner. If |
Usage Notes
The following usage notes apply to this procedure:
The DELETE_ALL_ERRORS Procedure and XStream Outbound Servers
Outbound servers do not enqueue error transactions into an error queue. This procedure has no effect on XStream outbound servers.
The DELETE_ALL_ERRORS Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.7 DELETE_ERROR Procedure
This procedure deletes the specified error transaction.
Syntax
DBMS_APPLY_ADM.DELETE_ERROR( local_transaction_id IN VARCHAR2);
Parameter
Table 21-8 DELETE_ERROR Procedure Parameter
Parameter | Description |
---|---|
|
The identification number of the error transaction to delete. If the specified transaction does not exist in the error queue, then an error is raised. |
Usage Notes
The following usage notes apply to this procedure:
The DELETE_ERROR Procedure and XStream Outbound Servers
Outbound servers do not enqueue error transactions into an error queue. This procedure has no effect on XStream outbound servers.
The DELETE_ERROR Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.8 DROP_APPLY Procedure
This procedure drops an apply component.
Syntax
DBMS_APPLY_ADM.DROP_APPLY( apply_name IN VARCHAR2, drop_unused_rule_sets IN BOOLEAN DEFAULT FALSE);
Parameters
Table 21-9 DROP_APPLY Procedure Parameters
Parameter | Description |
---|---|
|
The name of the apply component being dropped. You must specify an existing apply component name. Do not specify an owner. |
|
If If |
Usage Notes
The following usage notes apply to this procedure:
The DROP_APPLY Procedure and Rules
When you use this procedure to drop an apply component, information about rules created for the apply component is removed from the data dictionary views for rules. Information about such a rule is removed even if the rule is not in either the positive or negative rule set for the apply component. The following are the data dictionary views for rules:
-
ALL_STREAMS_GLOBAL_RULES
-
DBA_STREAMS_GLOBAL_RULES
-
ALL_STREAMS_SCHEMA_RULES
-
DBA_STREAMS_SCHEMA_RULES
-
ALL_STREAMS_TABLE_RULES
-
DBA_STREAMS_TABLE_RULES
The DROP_APPLY Procedure and XStream Outbound Servers
When the DROP_APPLY
procedure is executed on an outbound server, it runs the DROP_OUTBOUND
procedure in the DBMS_XSTREAM_ADM
package. Therefore, it might also drop the outbound server's capture process and queue.
The DROP_APPLY Procedure and XStream Inbound Servers
When the DROP_APPLY
procedure is executed on an inbound server, it runs the DROP_INBOUND
procedure in the DBMS_XSTREAM_ADM
package. Therefore, it might also drop the inbound server's queue.
21.4.9 DROP_OBJECT_DEPENDENCY Procedure
This procedure drops an object dependency. An object dependency is a virtual dependency definition that defines a parent-child relationship between two objects at a destination database.
Note:
-
An error is raised if an object dependency does not exist for the specified database objects.
-
An error is raised if
NULL
is specified for either of the procedure parameters.
See Also:
Syntax
DBMS_APPLY_ADM.DROP_OBJECT_DEPENDENCY( object_name IN VARCHAR2, parent_object_name IN VARCHAR2);
Parameters
Table 21-10 DROP_OBJECT_DEPENDENCY Procedure Parameters
Parameter | Description |
---|---|
|
The name of the child database object, specified as |
|
The name of the parent database object, specified as |
Usage Notes
The following usage notes apply to this procedure:
The DROP_OBJECT_DEPENDENCY Procedure and XStream Outbound Servers
This procedure has no effect on XStream outbound servers.
The DROP_OBJECT_DEPENDENCY Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.10 EXECUTE_ALL_ERRORS Procedure
This procedure re-executes the error transactions in the error queue for the specified apply component.
The transactions are re-executed in commit SCN order. Error re-execution stops if an error is raised.
Syntax
DBMS_APPLY_ADM.EXECUTE_ALL_ERRORS( apply_name IN VARCHAR2 DEFAULT NULL, execute_as_user IN BOOLEAN DEFAULT FALSE);
Parameters
Table 21-11 EXECUTE_ALL_ERRORS Procedure Parameters
Parameter | Description |
---|---|
|
The name of the apply component that raised the errors while processing the transactions. Do not specify an owner. If |
|
If If The user who executes the transactions must have privileges to perform DML and DDL changes on the apply objects and to run any apply handlers. This user must also have dequeue privileges on the queue used by the apply component. |
Usage Notes
The following usage notes apply to this procedure:
-
The EXECUTE_ALL_ERRORS Procedure and XStream Outbound Servers
-
The EXECUTE_ALL_ERRORS Procedure and XStream Inbound Servers
The EXECUTE_ALL_ERRORS Procedure and XStream Outbound Servers
Outbound servers do not enqueue error transactions into an error queue. This procedure cannot be used with XStream outbound servers.
The EXECUTE_ALL_ERRORS Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.11 EXECUTE_ERROR Procedure
This procedure re-executes the specified error transaction in the error queue.
Syntax
DBMS_APPLY_ADM.EXECUTE_ERROR( local_transaction_id IN VARCHAR2, execute_as_user IN BOOLEAN DEFAULT FALSE, user_procedure IN VARCHAR2 DEFAULT NULL);
Parameters
Table 21-12 EXECUTE_ERROR Procedure Parameters
Parameter | Description |
---|---|
|
The identification number of the error transaction to execute. If the specified transaction does not exist in the error queue, then an error is raised. |
|
If If The user who executes the transaction must have privileges to perform DML and DDL changes on the apply objects and to run any apply handlers. This user must also have dequeue privileges on the queue used by the apply component. |
|
A user-defined procedure that modifies the error transaction so that it can be successfully executed. Specify See Also: "Usage Notes" for more information about the user procedure |
Usage Notes
The following usage notes apply to this procedure:
The User Procedure
You must specify the full procedure name for the user_procedure
parameter in one of the following forms:
-
[
schema_name
.]
package_name.procedure_name
-
[
schema_name
.]
procedure_name
If the procedure is in a package, then the package_name
must be specified. The user who invokes the EXECUTE_ERROR
procedure must have EXECUTE
privilege on the specified procedure. Also, if the schema_name
is not specified, then the user who invokes the EXECUTE_ERROR
procedure is the default.
For example, suppose the procedure_name
has the following properties:
-
strmadmin
is theschema_name
. -
fix_errors
is thepackage_name
. -
fix_hr_errors
is theprocedure_name
.
In this case, specify the following:
strmadmin.fix_errors.fix_hr_errors
The procedure you create for error handling must have the following signature:
PROCEDURE user_procedure (
in_anydata IN ANYDATA,
error_record IN DBA_APPLY_ERROR%ROWTYPE,
error_message_number IN NUMBER,
messaging_default_processing IN OUT BOOLEAN,
out_anydata OUT ANYDATA);
The user procedure has the following parameters:
-
in_anydata
: TheANYDATA
encapsulation of a message that the apply component passes to the procedure. A single transaction can include multiple messages. A message can be a row logical change record (row LCR), a DDL logical change record (DDL LCR), or a user message. -
error_record
: The row in theDBA_APPLY_ERROR
data dictionary view that identifies the transaction -
error_message_number
: The message number of theANYDATA
object in thein_anydata
parameter, starting at 1 -
messaging_default_processing
: IfTRUE
, then the apply component continues processing the message in thein_anydata
parameter, which can include executing DML or DDL statements and invoking apply handlers.If
FALSE
, then the apply component skips processing the message in thein_anydata
parameter and moves on to the next message in thein_anydata
parameter. -
out_anydata
: TheANYDATA
object processed by the user procedure and used by the apply component ifmessaging_default_processing
isTRUE
.
If an LCR is executed using the EXECUTE
LCR member procedure in the user procedure, then the LCR is executed directly, and the messaging_default_processing
parameter should be set to FALSE
. In this case, the LCR is not passed to any apply handlers.
Processing an error transaction with a user procedure results in one of the following outcomes:
-
The user procedure modifies the transaction so that it can be executed successfully.
-
The user procedure fails to make the necessary modifications, and an error is raised when transaction execution is attempted. In this case, the transaction is rolled back and remains in the error queue.
The following restrictions apply to the user procedure:
-
Do not execute
COMMIT
orROLLBACK
statements. Doing so can endanger the consistency of the transaction. -
Do not modify
LONG
,LONG
RAW
or LOB column data in an LCR. -
If the
ANYDATA
object in thein_anydata
parameter is a row LCR, then theout_anydata
parameter must be row LCR if themessaging_default_processing
parameter is set toTRUE
. -
If the
ANYDATA
object in thein_anydata
parameter is a DDL LCR, then theout_anydata
parameter must be DDL LCR if themessaging_default_processing
parameter is set toTRUE
. -
The user who runs the user procedure must have the
SELECT
orREAD
privilege on theDBA_APPLY_ERROR
data dictionary view.
Note:
LCRs containing transactional directives, such as COMMIT
and ROLLBACK
, are not passed to the user procedure.
The EXECUTE_ERROR Procedure and XStream Outbound Servers
Outbound servers do not enqueue error transactions into an error queue. This procedure cannot be used with XStream outbound servers.
The EXECUTE_ERROR Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.12 GET_ERROR_MESSAGE Function
This function returns the message payload from the error queue for the specified message number and transaction identifier. The message can be a logical change record (LCR) or a non-LCR message.
This function is overloaded. One version of this function contains two OUT
parameters. These OUT
parameters contain the destination queue into which the message should be enqueued, if one exists, and whether the message should be executed. The destination queue is specified using the SET_ENQUEUE_DESTINATION
procedure, and the execution directive is specified using the SET_EXECUTE
procedure.
Syntax
DBMS_APPLY_ADM.GET_ERROR_MESSAGE( message_number IN NUMBER, local_transaction_id IN VARCHAR2, destination_queue_name OUT VARCHAR2, execute OUT BOOLEAN) RETURN ANYDATA; DBMS_APPLY_ADM.GET_ERROR_MESSAGE( message_number IN NUMBER, local_transaction_id IN VARCHAR2) RETURN ANYDATA;
Parameters
Table 21-13 GET_ERROR_MESSAGE Function Parameters
Parameter | Description |
---|---|
|
The identification number of the message. This number identifies the position of the message in the transaction. Query the |
|
Identifier of the error transaction for which to return a message |
|
Contains the name of the queue into which the message should be enqueued. If the message should not be enqueued into a queue, then this parameter contains |
|
Contains Contains |
Usage Notes
The following usage notes apply to this procedure:
The GET_ERROR_MESSAGE Procedure and XStream Outbound Servers
Outbound servers do not enqueue error transactions into an error queue. This procedure cannot be used with XStream outbound servers.
The GET_ERROR_MESSAGE Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.13 HANDLE_COLLISIONS
This procedure enables or disables basic conflict resolution for an apply process and a table.
Syntax
DBMS_APPLY_ADM.HANDLE_COLLISIONS( apply_name IN VARCHAR2, enable IN BOOLEAN, object IN VARCHAR2, source_object IN VARCHAR2 DEFAULT NULL);
Parameters
Table 21-14 HANDLE_COLLISIONS Procedure Parameters
Parameter | Description |
---|---|
|
The name of the apply process. |
|
If
If If |
|
The schema and name of the target table, specified as For example, if you are changing the setting for table |
|
The schema and object name of the source table, specified as For example, if the change originated at the |
21.4.14 SET_DML_CONFLICT_HANDLER Procedure
This procedure adds, modifies, or removes a prebuilt DML conflict handler for INSERT
, UPDATE
, or DELETE
conflicts on the specified object.
This procedure is overloaded. The column_list
and column_table
parameters are mutually exclusive.
Syntax
DBMS_APPLY_ADM.SET_DML_CONFLICT_HANDLER( apply_name IN VARCHAR2, conflict_handler_name IN VARCHAR2, object IN VARCHAR2 DEFAULT NULL, operation_name IN VARCHAR2 DEFAULT NULL, conflict_type IN VARCHAR2 DEFAULT NULL, method_name IN VARCHAR2 DEFAULT NULL, column_list IN VARCHAR2 DEFAULT NULL, resolution_column IN VARCHAR2 DEFAULT NULL, source_object IN VARCHAR2 DEFAULT NULL);
DBMS_APPLY_ADM.SET_DML_CONFLICT_HANDLER( apply_name IN VARCHAR2, conflict_handler_name IN VARCHAR2, object IN VARCHAR2 DEFAULT NULL, operation_name IN VARCHAR2 DEFAULT NULL, conflict_type IN VARCHAR2 DEFAULT NULL, method_name IN VARCHAR2 DEFAULT NULL, column_table IN DBMS_UTILITY.LNAME_ARRAY, resolution_column IN VARCHAR2 DEFAULT NULL, source_object IN VARCHAR2 DEFAULT NULL);
Parameters
Table 21-15 SET_DML_CONFLICT_HANDLER Procedure Parameters
Parameter | Description |
---|---|
|
The name of the apply process. |
|
The name of the conflict handler. |
|
The schema and name of the target table, specified as For example, if an update conflict handler is being added for table |
|
The name of the operation, which can be specified as:
In order to set up conflict handlers for different operations on the same table, you must make one call per operation. |
|
Type of update conflict handler to create. You can specify one of the prebuilt handlers, which determine whether the column list from the source database is applied for the row or whether the values in the row at the destination database are retained:
|
|
Type of update conflict handler to create. You can specify one of the prebuilt handlers, which determine whether the column list from the source database is applied for the row or whether the values in the row at the destination database are retained:
If If a conflict handler already exists with the same |
|
A comma-separated list of the column names for which the conflict handler is called. The same column cannot be in more than one column list (for a given Specify If a conflict occurs for one or more of the columns in the list when an apply component tries to apply a row logical change record (row LCR), then the conflict handler is called to resolve the conflict. The conflict handler is not called if a conflict occurs only for columns that are not in the list. You cannot use a The only time you can use multiple column groups is when you are specifying a conflict handler for insert or update for Note: Prebuilt conflict handlers do not support LOB, This parameter must be set to
|
|
An array of column names for which the conflict handler is called. This parameter is the same as the Note: The |
|
For the You can specify |
|
The schema and object name of the source table, specified as For example, if the change originated at the |
Usage Notes
The following usage notes apply to this procedure:
-
The SET_DML_CONFLICT_HANDLER Procedure and XStream Outbound Servers
-
The SET_DML_CONFLICT_HANDLER Procedure and XStream Inbound Servers
Modifying an Existing Conflict Handler
If you want to modify an existing conflict handler, then you specify the object
, conflict_type
, and resolution_column
of an the existing conflict handler. You can modify the method_name
or the column_list
.
Removing an Existing Conflict Handler
If you want to remove an existing conflict handler, then specify NULL
for the method_name
and specify the object
, conflict_type
, and resolution_column
of the existing conflict handler.
Series of Actions for Conflicts
If an conflict occurs, then Oracle completes the following series of actions:
-
Calls the appropriate conflict handler to resolve the conflict
-
If no conflict handler is specified or if the conflict handler cannot resolve the conflict, then calls the appropriate error handler for the apply component, object name, and operation name to handle the error
-
If no error handler is specified or if the error handler cannot resolve the error, then raises an error and moves the transaction containing the row LCR that caused the error to the error queue
See Also:
"Signature of a DML Handler Procedure or Error Handler Procedure" for information about setting an error handler
Procedure DML Handlers for Conflicts
If you cannot use a prebuilt conflict handler to meet your requirements, then you can create a PL/SQL procedure to use as a custom conflict handler. You use the SET_DML_HANDLER
procedure to designate one or more custom conflict handlers for a particular table. In addition, a custom conflict handler can process LOB columns and use LOB assembly.
See Also:
A Column Can Be in Only One Column List
When a column is in a column list, and you try to add the same column to another column list, this procedure returns the following error:
ORA-00001: UNIQUE CONSTRAINT (SYS.APPLY$_CONF_HDLR_COLUMNS_UNQ1) VIOLATED
The SET_DML_CONFLICT_HANDLER
Procedure and XStream Outbound Servers
This procedure has no effect on XStream outbound servers.
The SET_DML_CONFLICT_HANDLER
Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
Table 21-16 Valid Combinations of Parameters
Operation | Conflict Type | Method |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Example
The following is an example for setting a conflict handler for the employees
table in the hr
schema:
DECLARE cols DBMS_UTILITY.NAME_ARRAY; BEGIN cols(1) := 'salary'; cols(2) := 'commission_pct'; DBMS_APPLY_ADM.SET_DML_CONFLICT_HANDLER( apply_name => 'appl1', conflict_handler_name => 'emp_handler_update', object => 'hr.employees', operation_name => 'UPDATE', conflict_type => 'ROW_EXISTS', method_name => 'MAXIMUM', resolution_column => 'salary', column_table => cols); END; /
This example sets a conflict handler named emp_handler_update
that is called if a conflict occurs for the salary
or commission_pct
column in the hr.employees
table. If such a conflict occurs, then the salary
column is evaluated to resolve the conflict. If a conflict occurs only for a column that is not in the column list, such as the job_id
column, then this conflict handler is not called.
21.4.15 SET_DML_HANDLER Procedure
This procedure sets or unsets a user procedure as a procedure DML handler for a specified operation on a specified database object for a single apply component or for all apply components in the database. The user procedure alters the apply behavior for the specified operation on the specified object.
Syntax
DBMS_APPLY_ADM.SET_DML_HANDLER( object_name IN VARCHAR2, object_type IN VARCHAR2, operation_name IN VARCHAR2, error_handler IN BOOLEAN DEFAULT FALSE, user_procedure IN VARCHAR2, apply_database_link IN VARCHAR2 DEFAULT NULL, apply_name IN VARCHAR2 DEFAULT NULL, assemble_lobs IN BOOLEAN DEFAULT TRUE);
Parameters
Table 21-17 SET_DML_HANDLER Procedure Parameters
Parameter | Description |
---|---|
|
The name of the source object specified as |
|
The type of the source object. Currently, |
|
The name of the operation, which can be specified as:
The procedure must be run for each operation individually. Specify |
|
If If |
|
A user-defined procedure that is invoked during apply for the specified operation on the specified object. If the procedure is a procedure DML handler, then it is invoked instead of the default apply performed by Oracle. If the procedure is an error handler, then it is invoked when an apply error is encountered. Specify |
|
The name of the database link to a non-Oracle database. This parameter should be set only when the destination database is a non-Oracle database. |
|
The name of the apply component that uses the procedure DML handler or error handler. If If the |
|
If If |
Usage Notes
The following usage notes apply to this procedure:
-
Run the SET_DML_HANDLER Procedure at the Destination Database
-
Signature of a DML Handler Procedure or Error Handler Procedure
Run the SET_DML_HANDLER Procedure at the Destination Database
Run this procedure at the destination database. The SET_DML_HANDLER
procedure provides a way for users to apply logical change records containing DML changes (row LCRs) using a customized apply.
Procedure DML Handlers and Error Handlers
If the error_handler
parameter is set to TRUE
, then it specifies that the user procedure is an error handler. An error handler is invoked only when a row LCR raises an apply error. Such an error can result from a data conflict if no conflict handler is specified or if the update conflict handler cannot resolve the conflict. If the error_handler
parameter is set to FALSE
, then the user procedure is a procedure DML handler, not an error handler, and a procedure DML handler is always run instead of performing the specified operation on the specified object.
This procedure either sets a procedure DML handler or an error handler for a particular operation on an object. It cannot set both a procedure DML handler and an error handler for the same object and operation.
Note:
Currently, setting an error handler for an apply component that is applying changes to a non-Oracle database is not supported.
The apply_name Parameter
If the apply_name
parameter is non-NULL
, then the procedure DML handler or error handler is set for the specified apply component. In this case, this handler is not invoked for other apply components at the local destination database. If the apply_name
parameter is NULL
, the default, then the handler is set as a general handler for all apply components at the destination database. When a handler is set for a specific apply component, then this handler takes precedence over any general handlers. For example, consider the following scenario:
-
A procedure DML handler named
handler_hr
is specified for an apply component namedapply_hr
forUPDATE
operations on thehr.employees
table. -
A general procedure DML handler named
handler_gen
also exists forUPDATE
operations on thehr.employees
table.
In this case, the apply_hr
apply component uses the handler_hr
procedure DML handler for UPDATE
operations on the hr.employees
table.
At the source database, you must specify an unconditional supplemental log group for the columns needed by a DML or error handler.
Signature of a DML Handler Procedure or Error Handler Procedure
You can use the SET_DML_HANDLER
procedure to set either a procedure DML handler or an error handler for row LCRs that perform a specified operation on a specified object. The signatures of a DML handler procedure and of an error handler procedure are described following this section.
In either case, you must specify the full procedure name for the user_procedure
parameter in one of the following forms:
-
[
schema_name
.]
package_name.procedure_name
-
[
schema_name
.]
procedure_name
If the procedure is in a package, then the package_name
must be specified. The user who invokes the SET_DML_HANDLER
procedure must have EXECUTE
privilege on the specified procedure. Also, if the schema_name
is not specified, then the user who invokes the SET_DML_HANDLER
procedure is the default.
For example, suppose the procedure_name
has the following properties:
-
hr
is theschema_name
. -
apply_pkg
is thepackage_name
. -
employees_default
is theprocedure_name
.
In this case, specify the following:
hr.apply_pkg.employees_default
The following restrictions apply to the user procedure:
-
Do not execute
COMMIT
orROLLBACK
statements. Doing so can endanger the consistency of the transaction that contains the LCR. -
If you are manipulating a row using the
EXECUTE
member procedure for the row LCR, then do not attempt to manipulate more than one row in a row operation. You must construct and execute manually any DML statements that manipulate more than one row. -
If the command type is
UPDATE
orDELETE
, then row operations resubmitted using theEXECUTE
member procedure for the LCR must include the entire key in the list of old values. The key is the primary key or the smallest unique index that has at least oneNOT
NULL
column, unless a substitute key has been specified by theSET_KEY_COLUMNS
procedure. If there is no specified key, then the key consists of all nonLOB
, nonLONG
, and nonLONG
RAW
columns. -
If the command type is
INSERT
, then row operations resubmitted using theEXECUTE
member procedure for the LCR should include the entire key in the list of new values. Otherwise, duplicate rows are possible. The key is the primary key or the smallest unique index that has at least oneNOT
NULL
column, unless a substitute key has been specified by theSET_KEY_COLUMNS
procedure. If there is no specified key, then the key consists of all of the table columns, except for columns of the following data types: LOB,LONG
,LONG
RAW
, user-defined types (including object types,REF
s, varrays, nested tables), and Oracle-supplied types (includingAny
types, XML types, spatial types, and media types).
The procedure specified in the user_procedure
parameter must have the following signature:
PROCEDURE user_procedure ( parameter_name IN ANYDATA);
Here, user_procedure
stands for the name of the procedure and parameter_name
stands for the name of the parameter passed to the procedure. The parameter passed to the procedure is a ANYDATA
encapsulation of a row LCR.
See Also:
Logical Change Record TYPEs for more information about LCRs
The procedure you create for error handling must have the following signature:
PROCEDURE user_procedure (
message IN ANYDATA,
error_stack_depth IN NUMBER,
error_numbers IN DBMS_UTILITY.NUMBER_ARRAY,
error_messages IN emsg_array);
If you want to retry the DML operation within the error handler, then have the error handler procedure run the EXECUTE
member procedure for the LCR. The last error raised is on top of the error stack. To specify the error message at the top of the error stack, use error_numbers(1)
and error_messages(1)
.
Note:
-
Each parameter is required and must have the specified datatype. However, you can change the names of the parameters.
-
The
emsg_array
value must be a user-defined array that is a table of typeVARCHAR2
with at least 76 characters.
Running an error handler results in one of the following outcomes:
-
The error handler successfully resolves the error and returns control to the apply component.
-
The error handler fails to resolve the error, and the error is raised. The raised error causes the transaction to be rolled back and placed in the error queue.
LOB Assembly
Do not modify LONG
, LONG
RAW
, or nonassembled LOB column data in an LCR with procedure DML handlers, error handlers, or custom rule-based transformation functions. Procedure DML handlers and error handlers can modify LOB columns in row LCRs that have been constructed by LOB assembly.
The SET_DML_HANDLER Procedure and XStream Outbound Servers
Outbound servers ignore all apply handlers. This procedure has no effect on XStream outbound servers.
The SET_DML_HANDLER Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.16 SET_ENQUEUE_DESTINATION Procedure
This procedure sets the queue where the apply component automatically enqueues a message that satisfies the specified rule.
This procedure modifies the specified rule's action context to specify the queue. A rule action context is optional information associated with a rule that is interpreted by the client of the rules engine after the rule evaluates to TRUE
for a message. In this case, the client of the rules engine is an apply component. The information in an action context is an object of type SYS.RE$NV_LIST
, which consists of a list of name-value pairs.
A queue destination specified by this procedure always consists of the following name-value pair in an action context:
-
The name is
APPLY$_ENQUEUE
. -
The value is an
ANYDATA
instance containing the queue name specified as aVARCHAR2
.
Syntax
DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATION( rule_name IN VARCHAR2, destination_queue_name IN VARCHAR2);
Parameters
Table 21-18 SET_ENQUEUE_DESTINATION Procedure Parameters
Parameter | Description |
---|---|
|
The name of the rule, specified as |
|
The name of the queue into which the apply component enqueues the message. Specify the queue in the form For example, to specify a queue in the If If non- |
Usage Notes
The following usage notes apply to this procedure:
-
The SET_ENQUEUE_DESTINATION Procedure and XStream Outbound Servers
-
The SET_ENQUEUE_DESTINATION Procedure and XStream Inbound Servers
The SET_ENQUEUE_DESTINATION Procedure and Apply Handlers
If an apply handler, such as a procedure DML handler, DDL handler, or message handler, processes a message that also is enqueued into a destination queue, then the apply handler processes the message before it is enqueued.
Considerations for the SET_ENQUEUE_DESTINATION Procedure
The following are considerations for using this procedure:
-
This procedure does not verify that the specified queue exists. If the queue does not exist, then an error is raised when an apply component tries to enqueue a message into it.
-
Oracle Replication capture processes, propagations, and messaging clients ignore the action context created by this procedure.
-
The apply user of the apply component using the specified rule must have the necessary privileges to enqueue messages into the specified queue. If the queue is a secure queue, then the apply user must be a secure queue user of the queue.
-
The specified rule must be in the positive rule set for an apply component. If the rule is in the negative rule set for an apply component, then the apply component does not enqueue the message into the destination queue.
-
If the commit SCN for a message is less than or equal to the relevant instantiation SCN for the message, then the message is not enqueued into the destination queue, even if the message satisfies the apply component rule sets.
The SET_ENQUEUE_DESTINATION Procedure and XStream Outbound Servers
This procedure has no effect on XStream outbound servers.
The SET_ENQUEUE_DESTINATION Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.17 SET_EXECUTE Procedure
This procedure specifies whether a message that satisfies the specified rule is executed by an apply component.
This procedure modifies the specified rule's action context to specify message execution. A rule action context is optional information associated with a rule that is interpreted by the client of the rules engine after the rule evaluates to TRUE
for a message. In this case, the client of the rules engine is an apply component. The information in an action context is an object of type SYS.RE$NV_LIST
, which consists of a list of name-value pairs.
A message execution directive specified by this procedure always consists of the following name-value pair in an action context:
-
The name is
APPLY$_EXECUTE
. -
The value is an
ANYDATA
instance that containsNO
as aVARCHAR2
. When the value isNO
, an apply component does not execute the message and does not send the message to any apply handler.
Syntax
DBMS_APPLY_ADM.SET_EXECUTE( rule_name IN VARCHAR2, execute IN BOOLEAN);
Parameters
Table 21-19 SET_EXECUTE Procedure Parameters
Parameter | Description |
---|---|
|
The name of the rule, specified as |
|
If If If |
Usage Notes
The following usage notes apply to this procedure:
Considerations for the SET_EXECUTE Procedure
The following are considerations for using this procedure:
-
If the message is a logical change record (LCR) and the message is not executed, then the change encapsulated in the LCR is not made to the relevant local database object. Also, if the message is not executed, then it is not sent to any apply handler.
-
Oracle Replication capture processes, propagations, and messaging clients ignore the action context created by this procedure.
-
The specified rule must be in the positive rule set for an apply component for the apply component to follow the execution directive. If the rule is in the negative rule set for an apply component, then the apply component ignores the execution directive for the rule.
The SET_EXECUTE Procedure and XStream Outbound Servers
This procedure has no effect on XStream outbound servers.
The SET_EXECUTE Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.18 SET_GLOBAL_INSTANTIATION_SCN Procedure
This procedure records the specified instantiation SCN for the specified source database and, optionally, for the schemas at the source database and the tables owned by these schemas. This procedure overwrites any existing instantiation SCN for the database, and, if it sets the instantiation SCN for a schema or a table, then it overwrites any existing instantiation SCN for the schema or table.
This procedure gives you precise control over which DDL logical change records (DDL LCRs) from a source database are ignored and which DDL LCRs are applied by an apply component.
Syntax
DBMS_APPLY_ADM.SET_GLOBAL_INSTANTIATION_SCN( source_database_name IN VARCHAR2, instantiation_scn IN NUMBER, apply_database_link IN VARCHAR2 DEFAULT NULL, recursive IN BOOLEAN DEFAULT FALSE, source_root_name IN VARCHAR2 DEFAULT NULL);
Parameters
Table 21-20 SET_GLOBAL_INSTANTIATION_SCN Procedure Parameters
Parameter | Description |
---|---|
|
The global name of the source database. For example, If you do not include the domain name, then the procedure appends it to the database name automatically. For example, if you specify |
|
The instantiation SCN. Specify |
|
The name of the database link to a non-Oracle database. This parameter should be set only when the destination database of a local apply component is a non-Oracle database. |
|
If If Note: If |
|
The global name of the source root database. In a non-CDB, this parameter must be In a CDB, if you want to do the instantiation for a specific container than you must specify both |
Usage Notes
The following usage notes apply to this procedure:
-
Considerations for the SET_GLOBAL_INSTANTIATION_SCN Procedure
-
The SET_GLOBAL_INSTANTIATION_SCN Procedure and XStream Outbound Servers
-
The SET_GLOBAL_INSTANTIATION_SCN Procedure and XStream Inbound Servers
See Also:
-
LCR$_DDL_RECORD Type for more information about DDL LCRs
Instantiation SCNs and DDL LCRs
If the commit SCN of a DDL LCR for a database object from a source database is less than or equal to the instantiation SCN for that source database at a destination database, then the apply component at the destination database disregards the DDL LCR. Otherwise, the apply component applies the DDL LCR.
The global instantiation SCN specified by this procedure is used for a DDL LCR only if the DDL LCR does not have object_owner
, base_table_owner
, and base_table_name
specified. For example, the global instantiation SCN set by this procedure is used for DDL LCRs with a command_type
of CREATE
USER
.
The recursive Parameter
If the recursive
parameter is set to TRUE
, then this procedure sets the instantiation SCN for each schema at a source database and for the tables owned by these schemas. This procedure uses the SET_SCHEMA_INSTANTIATION_SCN
procedure to set the instantiation SCN for each schema, and it uses the SET_TABLE_INSTANTIATION_SCN
procedure to set the instantiation SCN for each table. Each schema instantiation SCN is used for DDL LCRs on the schema, and each table instantiation SCN is used for DDL LCRs and row LCRs on the table.
If the recursive
parameter is set to FALSE
, then this procedure does not set the instantiation SCN for any schemas or tables.
Considerations for the SET_GLOBAL_INSTANTIATION_SCN Procedure
The following are considerations for using this procedure:
-
Any instantiation SCN specified by this procedure is used only for LCRs captured by a capture process. It is not used for user-created LCRs.
-
The instantiation SCN is not set for the
SYS
orSYSTEM
schemas.
The SET_GLOBAL_INSTANTIATION_SCN Procedure and XStream Outbound Servers
Instantiation SCNs are not required for database objects processed by an outbound server. If an instantiation SCN is set for a database object, then the outbound server only sends the LCRs for the database object with SCN values that are greater than the instantiation SCN value. If a database object does not have an instantiation SCN set, then the outbound server skips the instantiation SCN check and sends all LCRs for that database object. In both cases, the outbound server only sends LCRs that satisfy its rule sets.
The apply_database_link
parameter must be set to NULL
or to the local database for this procedure to set an instantiation SCN for an outbound server.
See Also:
Oracle Database XStream Guide for more information about outbound servers and instantiation SCNs
The SET_GLOBAL_INSTANTIATION_SCN Procedure and XStream Inbound Servers
Inbound servers ignore instantiation SCNs. This procedure has no effect on XStream inbound servers.
The SET_GLOBAL_INSTANTIATION_SCN Procedure and CDBs
In a CDB, this procedure must be invoked from the same container as the apply process that uses the instantiation SCN information.
21.4.19 SET_KEY_COLUMNS Procedures
This procedure records the set of columns to be used as the substitute primary key for apply purposes and removes existing substitute primary key columns for the specified object if they exist.
This procedure is overloaded. The column_list
and column_table
parameters are mutually exclusive.
Syntax
DBMS_APPLY_ADM.SET_KEY_COLUMNS( object_name IN VARCHAR2, column_list IN VARCHAR2, apply_database_link IN VARCHAR2 DEFAULT NULL, apply_name IN VARCHAR2 DEFAULT NULL); DBMS_APPLY_ADM.SET_KEY_COLUMNS( object_name IN VARCHAR2, column_table IN DBMS_UTILITY.NAME_ARRAY, apply_database_link IN VARCHAR2 DEFAULT NULL, apply_name IN VARCHAR2 DEFAULT NULL);
Parameters
Table 21-21 SET_KEY_COLUMNS Procedure Parameters
Parameter | Description |
---|---|
|
The name of the table specified as |
|
A comma-delimited list of the columns in the table to use as the substitute primary key, with no spaces between the column names. If the |
|
A PL/SQL associative array of type If the |
|
The name of the database link to a non-Oracle database. This parameter should be set only when the destination database is a non-Oracle database. |
|
The name of the apply component. |
Usage Notes
The following usage notes apply to this procedure:
Considerations for the SET_KEY_COLUMNS Procedure
The following are considerations for using this procedure:
-
When not empty, the specified set of columns takes precedence over any primary key for the specified object. Do not specify substitute key columns if the object has primary key columns and you want to use those primary key columns as the key.
-
Run this procedure at the destination database. At the source database, you must specify an unconditional supplemental log group for the substitute key columns.
-
Unlike true primary keys, columns specified as substitute key column columns can contain
NULL
s. However, Oracle recommends that each column you specify as a substitute key column be aNOT
NULL
column. You also should create a single index that includes all of the columns in a substitute key. Following these guidelines improves performance for updates, deletes, and piecewise updates to LOBs because Oracle can locate the relevant row more efficiently. -
Do not permit applications to update the primary key or substitute key columns of a table. This ensures that Oracle can identify rows and preserve the integrity of the data.
-
If there is neither a primary key, nor a unique index that has at least one
NOT
NULL
column, nor a substitute key for a table, then the key consists of all of the table columns, except for columns of the following data types: LOB,LONG
,LONG
RAW
, user-defined types (including object types,REF
s, varrays, nested tables), and Oracle-supplied types (includingAny
types, XML types, spatial types, and media types).
Duplicate Rows and Substitute Primary Key Columns
A table has duplicate rows when all of the column values are identical for two or more rows in the table, excluding LOB, LONG
, and LONG
RAW
columns. You can specify substitute primary key columns for a table at a destination database using by the SET_KEY_COLUMNS
procedure. When substitute primary key columns are specified for a table with duplicate rows at a destination database, and the allow_duplicate_rows
apply component parameter is set to Y
, meet the following requirements to keep the table data synchronized at the source and destination databases:
-
Ensure that supplemental logging is specified at source database for the columns specified as substitute key columns at the destination database. The substitute key columns must be in an unconditional log group at the source database.
-
Ensure that the substitute key columns uniquely identify each row in the table at the destination database.
The rest of this section provides more details about these requirements.
When there is no key for a table and the allow_duplicate_rows
apply component parameter is set to Y
, a single row LCR with an UPDATE
or DELETE
command type only is applied to one of the duplicate rows. In this case, if the table at the source database and the table at the destination database have corresponding duplicate rows, then a change that changes all of the duplicate rows at the source database also changes all the duplicate rows at the destination database when the row LCRs resulting from the change are applied.
For example, suppose a table at a source database has two duplicate rows. An update is performed on the duplicate rows, resulting in two row LCRs. At the destination database, one row LCR is applied to one of the duplicate rows. At this point, the rows are no longer duplicate at the destination database because one of the rows has changed. When the second row LCR is applied at the destination database, the rows are duplicate again. Similarly, if a delete is performed on these duplicate rows at the source database, then both rows are deleted at the destination database when the row LCRs resulting from the source change are applied.
When substitute primary key columns are specified for a table, row LCRs are identified with rows in the table during apply using the substitute primary key columns. If substitute primary key columns are specified for a table with duplicate rows at a destination database, and the allow_duplicate_rows
apply component parameter is set to Y
, then an update performed on duplicate rows at the source database can result in different changes when the row LCRs are applied at the destination database. Specifically, if the update does not change one of the columns specified as a substitute primary key column, then the same duplicate row can be updated multiple times at the destination database, while other duplicate rows might not be updated.
Also, if the substitute key columns do not identify each row in the table at the destination database uniquely, then a row LCR identified with multiple rows can update any one of the rows. In this case, the update in the row LCR might not be applied to the correct row in the table at the destination database.
An apply component ignores substitute primary key columns when it determines whether rows in a table are duplicates. An apply component determines that rows are duplicates only if all of the column values in the rows are identical (excluding LOB, LONG
, and LONG
RAW
columns). Therefore, an apply component always raises an error if a single update or delete changes two or more nonduplicate rows in a table.
For example, consider a table with columns c1
, c2
, and c3
on which the SET_KEY_COLUMNS
procedure is used to designate column c1
as the substitute primary key. If two rows have the same key value for the c1
column, but different value for the c2
or c3
columns, then an apply component does not treat the rows as duplicates. If an update or delete modifies more than one row because the c1
values in the rows are the same, then the apply component raises an error regardless of the setting for the allow_duplicate_rows
apply component parameter.
See Also:
SET_PARAMETER Procedure for more information about the allow_duplicate_rows
apply component parameter
The SET_KEY_COLUMNS Procedure and XStream Outbound Servers
This procedure has no effect on XStream outbound servers.
The SET_KEY_COLUMNS Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
The SET_KEY_COLUMNS Procedure and CDBs
This procedure defines the columns that are used as a substitute primary key. You must perform the SET_KEY_COLUMNS
procedure in the appropriate PDB.
21.4.20 SET_PARAMETER Procedure
This procedure sets an apply parameter to the specified value.
Syntax
DBMS_APPLY_ADM.SET_PARAMETER ( apply_name IN VARCHAR2, parameter IN VARCHAR2, value IN VARCHAR2 DEFAULT NULL);
Parameters
Table 21-22 SET_PARAMETER Procedure Parameters
Parameter | Description |
---|---|
|
The apply component name. Do not specify an owner. |
|
The name of the parameter you are setting. |
|
The value to which the parameter is set. If |
Apply Component Parameters
Note:
OPTIMIZE_PROGRESS_TABLE
is desupported in
the Oracle Database 19c Release and is no longer available.
Table 21-23 Apply Component Parameters
Parameter Name | Possible Values | Default | Description |
---|---|---|---|
|
|
|
If If Note: Regardless of the setting for this parameter, apply components do not allow changes to duplicate rows for tables with LOB, See Also: "Usage Notes" and "Duplicate Rows and Substitute Primary Key Columns" |
|
|
|
Controls whether the apply component checks and adjusts sequence values. If For ascending sequences, setting this parameter to For descending sequences, setting this parameter to If Note: This parameter is intended for XStream. Do not set this parameter to See Also: SET_PARAMETER Procedure for information about the |
|
|
|
Determines the batching method used to generate batch transactions for reordering. This parameter can be set to one of the following:
Note: This parameter is intended for Oracle GoldenGate. Do not use this parameter in an Oracle Replication environment or in an XStream environment. |
|
|
|
Specifies the conflict detection granularity. This parameter can be set to one of the following:
Note: This parameter is intended for XStream and Oracle GoldenGate. Do not set this parameter for an apply process in an Oracle Replication environment unless XStream optimizations are enabled by the |
|
|
|
The order in which applied transactions are committed. Apply servers can apply nondependent transactions at the destination database in an order that is different from the commit order at the source database. Dependent transactions are always applied at the destination database in the same order as they were committed at the source database. You control whether the apply servers can apply nondependent transactions in a different order at the destination database using the
Regardless of the specification, applied transactions can execute in parallel subject to data dependencies and constraint dependencies. If you specify
At the destination database, these transactions might be committed in the opposite order:
If you specify Note: The See Also: "Usage Notes" |
|
|
|
If If Note: The See Also: "Usage Notes" |
|
|
|
If If If the target table has all of the same constraints as the source table, you can improve the performance by setting this parameter to If the number of LCRs in transaction exceeds the value of the number of the Note: This parameter is intended for XStream. Do not set this parameter to Y for an apply process in an Oracle Replication environment unless XStream optimizations are enabled by the |
|
|
|
If If |
|
|
|
If If When an apply component is restarted, it gets a new session identifier, and the processes associated with the apply component also get new session identifiers. However, the coordinator process number ( |
|
A positive integer |
|
The apply component usually waits until it receives a commit record before starting to apply changes of a transaction. If XStream is enabled and more than Since it is possible that all existing apply servers are handling complete transactions from the source, additional apply servers are automatically created to handle outstanding eager transactions. The apply parameter This apply parameter is relevant only if its value is less than the value of the Note: This parameter is intended for XStream. Do not set this parameter in an Oracle Replication environment unless XStream optimizations are enabled by the |
|
|
|
When this parameter is set to When this parameter is set to Note: This parameter is intended for XStream. Do not set this parameter to |
|
Comma-delimited list of Oracle Replication tags |
|
Controls whether the capture process for an outbound server captures DML changes that are tagged with one of the specified Oracle Replication tags. Whether the capture process captures these changes depends on the settings for the If Note: This parameter is intended for an XStream Out environment in which multiple outbound servers use the same capture process. XStream inbound servers ignore this parameter. Do not set this parameter in an Oracle Replication environment. See Also: "Usage Notes" for the |
|
Comma-delimited list of transaction names |
|
Controls whether the capture process for an outbound server captures DML changes in the specified transaction names. Whether the capture process captures these changes depends on the settings for the If Note: This parameter is intended for an XStream Out environment in which multiple outbound servers use the same capture process. XStream inbound servers ignore this parameter. Do not set this parameter in an Oracle Replication environment. See Also: "Usage Notes" for the |
|
Comma-delimited list of user names |
|
Controls whether the capture process for an outbound server captures DML changes made by the specified users. Whether the capture process captures these changes depends on the settings for the Specify an exact pattern match for each user name. The pattern match is case sensitive. For example, specify If Note: This parameter is intended for an XStream Out environment in which multiple outbound servers use the same capture process. XStream inbound servers ignore this parameter. Do not set this parameter in an Oracle Replication environment. See Also: "Usage Notes" for the |
|
Comma-delimited list of user ID values |
|
Controls whether the capture process for an outbound server captures data manipulation language (DML) changes made by the specified users. Whether the capture process captures these changes depends on the settings for the To view the user ID for a user, query the If Note: This parameter is intended for an XStream Out environment in which multiple outbound servers use the same capture process. XStream inbound servers ignore this parameter. Do not set this parameter in an Oracle Replication environment. See Also: "Usage Notes" for the |
|
|
|
If If In either case, the capture process captures a DML change only if it satisfies the capture process's rule sets. When Note: This parameter is intended for an XStream Out environment in which multiple outbound servers use the same capture process. XStream inbound servers ignore this parameter. Do not set this parameter in an Oracle Replication environment. See Also: "Usage Notes" for the |
|
|
|
If If In either case, the capture process captures a DML change only if it satisfies the capture process's rule sets. When Note: This parameter is intended for an XStream Out environment in which multiple outbound servers use the same capture process. XStream inbound servers ignore this parameter. Do not set this parameter in an Oracle Replication environment. See Also: "Usage Notes" for the |
|
A positive integer from |
|
The minimum number of LCRs that can be grouped into a single transaction. The commit LCR for a transaction is not included in the LCR count for the transaction. This parameter enables an apply component to group LCRs from multiple transactions into a single transaction. The apply component groups only LCRs that are part of committed transactions. If a transaction has more LCRs than the setting for this parameter, then the transaction is applied as a single transaction. The apply component does not split a transaction into separate transactions. This parameter only takes effect if the Note: This parameter is intended for XStream outbound servers and inbound servers. An Oracle Apply process ignores this parameter unless XStream optimizations are enabled by the See Also: "Usage Notes" |
|
|
|
This parameter controls whether the apply component tries to resolve duplicate-record and missing-record errors when applying changes during data loading. This parameter should be set to If Specifically, the apply component performs the following actions when this parameter is set to
If Note: This parameter is intended for an XStream In environment with one or more inbound servers. Do not set this parameter in an Oracle Replication environment. |
|
A valid source transaction ID or |
|
Instructs the apply component to ignore the specified transaction from the source database, effective immediately. Use caution when setting this parameter because ignoring a transaction might lead to data divergence between the source database and destination database. To ignore multiple transactions, specify each transaction in a separate call to the If Note: An apply component ignores this parameter for transactions that were not captured by a capture process. See Also: "Usage Notes" |
|
A valid SCN or |
|
The apply component is disabled before applying a transaction with a commit SCN greater than or equal to the value specified. If Note: An apply component ignores this parameter for transactions that were not captured by a capture process. See Also: "Usage Notes" |
|
A positive integer |
|
Limits the maximum number of apply servers that can be used for an apply component. When the apply parallelism parameter is set greater than one, the apply component adds apply servers when necessary to process transactions until it reaches the limit set by this parameter ( Apply servers that idle for more than 5 minutes are shut down until the configured Runtime statistics for servers that have been shut down are aggregated into apply server 0 so that accurate apply statistics for the entire apply process can be maintained. Note: This parameter is intended for XStream. Do not set this parameter to Y for an apply process in an Oracle Replication environment unless XStream optimizations are enabled by the |
|
A positive integer |
|
Controls the amount of system global area (SGA) memory allocated specifically to the apply component, in megabytes. The memory is allocated for the duration of the apply component's session and is released when the apply component becomes disabled. Note: The sum of system global area (SGA) memory allocated for all components on a database must be less than the value set for the If Note: This parameter is intended for XStream. Do not use or attempt to set this parameter in an Oracle Replication environment unless XStream optimizations are enabled by the See Also: "Usage Notes" |
|
|
|
The frequency at which messages applied by the inbound server are tracked automatically. For example, if this parameter is set to the default value of The tracking label used for automatic message tracking is If |
|
|
|
This parameter affects conflict resolution when an update in the source database sets a column to its existing value. When this parameter is set to When this parameter is set to |
|
A positive integer |
|
The number of apply servers that can concurrently apply transactions. The reader server and the apply server process names are For example, if parallelism is set to Setting the Note: When the value of this parameter is changed from See Also: "Usage Notes" |
|
|
|
The parallelism interval is the interval in seconds at which the current workload activity is computed. The apply component calculates the mean throughput every 5 X The parallelism interval is used only if the Note: This parameter is intended for an XStream In environment with one or more inbound servers. XStream outbound servers ignore this parameter. Do not set this parameter in an Oracle Replication environment unless XStream optimizations are enabled by the See Also: "Usage Notes" |
|
|
|
Whether to preserve encryption for columns encrypted using Transparent Data Encryption. If If Note: When the value of this parameter is changed for a running apply component, the apply component is stopped and restarted automatically. This can take some time depending on the size of the transactions currently being applied. See Also: "Usage Notes" |
|
|
|
Whether to remove blank padding from the right end of a column when automatic data type conversion is performed during apply. If If See Also: "Usage Notes" |
|
|
|
The maximum number of seconds to wait for another instantiation of the same apply component to finish. If the other instantiation of the same apply component does not finish within this time, then the apply component does not start. If See Also: "Usage Notes" |
|
|
|
This parameter controls whether triggers fire when a change is made by the apply component. If If If a trigger's firing property is set to always fire, then the trigger always fires for changes made by the apply component, regardless of the value of the Note: This parameter is intended for an XStream In environment with one or more inbound servers. Do not set this parameter in an Oracle Replication environment. See Also: "Usage Notes" |
|
A positive integer or |
|
The apply component stops as soon as possible after the specified number of seconds since it started. If See Also: "Usage Notes" |
|
|
|
Set this parameter only under the guidance of Oracle Support Services. See Also: "Usage Notes" |
|
A positive integer or |
|
The apply component stops after applying the specified number of transactions. If See Also: "Usage Notes" |
|
A positive integer or |
|
The apply component begins to spill messages from memory to hard disk for a particular transaction when the amount of time that any message in the transaction has been in memory exceeds the specified number. The parameter specifies the age in seconds. When the reader server spills messages from memory, the messages are stored in a database table on the hard disk. These messages are not spilled from memory to a queue table. Message spilling occurs at the transaction level. For example, if this parameter is set to If Query the See Also: "Usage Notes" |
|
A positive integer or |
|
The apply component begins to spill messages from memory to hard disk for a particular transaction when the number of messages in memory for the transaction exceeds the specified number. The number of messages in first chunk of messages spilled from memory equals the number specified for this parameter, and the number of messages spilled in future chunks is either 100 or the number specified for this parameter, whichever is less. If the reader server of an apply component has the specified number of messages in memory for a particular transaction, then when it detects the next message for this transaction, it spills the messages that are in memory to the hard disk. For example, if this parameter is set to
The apply component applies the first 10,100 messages from the hard disk and the last 100 messages from memory. When the reader server spills messages from memory, the messages are stored in a database table on the hard disk. These messages are not spilled from memory to a queue table. Message spilling occurs at the transaction level. For example, if this parameter is set to If Query the See Also: "Usage Notes" |
|
|
|
If If The message specifies the reason why the apply component stopped. |
Usage Notes
The following usage notes apply to this procedure:
Delays Are Possible Before New Parameter Settings Take Effect
When you alter a parameter value, a short amount of time might pass before the new value for the parameter takes effect.
Parameters Interpreted as Positive Integers
For all parameters that are interpreted as positive integers, the maximum possible value is 4,294,967,295
. Where applicable, specify INFINITE
for larger values.
Parameters with a System Change Number (SCN) Setting
For parameters that require an SCN setting, any valid SCN value can be specified.
The SET_PARAMETER Procedure and Replication
You can use the following parameters in Replication if you enable XStream performance optimizations for Oracle Replication using the procedure DBMS_XSTREAM_ADM.ENABLE_GG_XSTREAM_FOR_STREAMS
:
-
apply_sequence_nextval
-
compute_lcr_dep_on_arrival
-
eager_size
-
grouptransops
-
max_parallelism
-
max_sga_size
-
parallelism_interval
The SET_PARAMETER Procedure and XStream Outbound Servers
Outbound servers ignore the settings for the following apply parameters:
-
allow_duplicate_rows
-
commit_serialization
-
compare_key_only
-
compute_lcr_dep_on_arrival
-
disable_on_error
-
eager_size
-
enable_xstream_table_stats
-
grouptransops
-
handlecollisions
-
optimize_self_updates
-
parallelism
-
parallelism_interval
-
preserve_encryption
-
rtrim_on_implicit_conversion
-
suppresstriggers
The commit_serialization
parameter is always set to FULL
for an outbound server, and the parallelism parameter is always set to 1
for an outbound server.
You can use the other apply parameters with outbound servers.
Note:
Using XStream requires purchasing a license for the Oracle GoldenGate product. See Oracle Database XStream Guide.
The SET_PARAMETER Procedure and XStream Inbound Servers
Inbound servers ignore the settings for the following apply parameters:
-
excludetag
-
excludetrans
-
excludeuser
-
excludeuserid
-
getapplops
-
getreplicates
-
ignore_transaction
-
maximum_scn
You can use all of the other apply component parameters with inbound servers.
The default setting for the compare_key_only
parameter for an inbound server is Y
.
The default setting for the parallelism
parameter for an inbound server is 4
.
Note:
Using XStream requires purchasing a license for the Oracle GoldenGate product. See Oracle Database XStream Guide.
21.4.21 SET_REPERROR_HANDLER Procedure
This procedure specifies how a particular error is handled based on its error number.
You can choose between several predefined actions for a given error.
Syntax
DBMS_APPLY_ADM.SET_REPERROR_HANDLER( apply_name IN VARCHAR2, object IN VARCHAR2, error_number IN NUMBER, method IN VARCHAR2, source_object IN VARCHAR2 DEFAULT NULL, max_retries IN NUMBER DEFAULT NULL, delay_csecs IN NUMBER DEFAULT 6000);
Parameters
Table 21-24 SET_REPERROR_HANDLER Procedure Parameters
Parameter | Description |
---|---|
|
The name of the apply process. |
|
The schema and name of the target table, specified as For example, if an update conflict handler is being added for table |
|
The error handling number. If |
|
Specifies the action to take when the given If The possible actions are:
|
|
The schema and object name of the source table, specified as For example, if the change originated at the |
|
Maximum number of times to retry for |
|
The number of centiseconds between retries for |
Usage Notes
The following usage notes apply to this procedure:
Priority of Error Handlers
Any conflict handling specified by SET_UPDATE_CONFLICT_HANDLER
or SET_DML_CONFLICT_HANDLER
is tried before the actions specified by SET_REPERROR_HANDLER
. The PL/SQL procedure specified by SET_DML_HANDLER
is called to handle the error if none of the previously mentioned methods resolve it.
21.4.22 SET_SCHEMA_INSTANTIATION_SCN Procedure
This procedure records the specified instantiation SCN for the specified schema in the specified source database and, optionally, for the tables owned by the schema at the source database. This procedure overwrites any existing instantiation SCN for the schema, and, if it sets the instantiation SCN for a table, it overwrites any existing instantiation SCN for the table.
This procedure gives you precise control over which DDL logical change records (LCRs) for a schema are ignored and which DDL LCRs are applied by an apply component.
Syntax
DBMS_APPLY_ADM.SET_SCHEMA_INSTANTIATION_SCN( source_schema_name IN VARCHAR2, source_database_name IN VARCHAR2, instantiation_scn IN NUMBER, apply_database_link IN VARCHAR2 DEFAULT NULL, recursive IN BOOLEAN DEFAULT FALSE, source_root_name IN VARCHAR2 DEFAULT NULL);
Parameters
Table 21-25 SET_SCHEMA_INSTANTIATION_SCN Procedure Parameters
Parameter | Description |
---|---|
|
The name of the source schema. For example, When setting an instantiation SCN for schema, always specify the name of the schema at the source database, even if a rule-based transformation or apply handler is configured to change the schema name. |
|
The global name of the source database. For example, If you do not include the domain name, then the procedure appends it to the database name automatically. For example, if you specify |
|
The instantiation SCN. Specify |
|
The name of the database link to a non-Oracle database. This parameter should be set only when the destination database of a local apply component is a non-Oracle database. |
|
If If Note: If |
|
The global name of the source root database. In a non-CDB, this parameter must be In a CDB, both |
Usage Notes
The following usage notes apply to this procedure:
-
The SET_SCHEMA_INSTANTIATION_SCN Procedure and XStream Outbound Servers
-
The SET_SCHEMA_INSTANTIATION_SCN Procedure and XStream Inbound Servers
See Also:
-
LCR$_DDL_RECORD Type for more information about DDL LCRs
The SET_SCHEMA_INSTANTIATION_SCN Procedure and LCRs
Any instantiation SCN specified by this procedure is used only for LCRs captured by a capture process. It is not used for user-created LCRs.
Instantiation SCNs and DDL LCRs
If the commit SCN of a DDL LCR for a database object in a schema from a source database is less than or equal to the instantiation SCN for that database object at a destination database, then the apply component at the destination database disregards the DDL LCR. Otherwise, the apply component applies the DDL LCR.
The schema instantiation SCN specified by this procedure is used on the following types of DDL LCRs:
-
DDL LCRs with a
command_type
ofCREATE
TABLE
-
DDL LCRs with a non-
NULL
object_owner
specified and neitherbase_table_owner
norbase_table_name
specified.
For example, the schema instantiation SCN set by this procedure is used for a DDL LCR with a command_type
of CREATE
TABLE
and ALTER
USER
.
The schema instantiation SCN specified by this procedure is not used for DDL LCRs with a command_type
of CREATE
USER
. A global instantiation SCN is needed for such DDL LCRs.
The recursive Parameter
If the recursive
parameter is set to TRUE
, then this procedure sets the table instantiation SCN for each table at the source database owned by the schema. This procedure uses the SET_TABLE_INSTANTIATION_SCN
procedure to set the instantiation SCN for each table. Each table instantiation SCN is used for DDL LCRs and row LCRs on the table.
If the recursive
parameter is set to FALSE
, then this procedure does not set the instantiation SCN for any tables.
The SET_SCHEMA_INSTANTIATION_SCN Procedure and XStream Outbound Servers
Instantiation SCNs are not required for database objects processed by an outbound server. If an instantiation SCN is set for a database object, then the outbound server only sends the LCRs for the database object with SCN values that are greater than the instantiation SCN value. If a database object does not have an instantiation SCN set, then the outbound server skips the instantiation SCN check and sends all LCRs for that database object. In both cases, the outbound server only sends LCRs that satisfy its rule sets.
The apply_database_link
parameter must be set to NULL
or to the local database for this procedure to set an instantiation SCN for an outbound server.
See Also:
Oracle Database XStream Guide for more information about outbound servers and instantiation SCNs
The SET_SCHEMA_INSTANTIATION_SCN Procedure and XStream Inbound Servers
Inbound servers ignore instantiation SCNs. This procedure has no effect on XStream inbound servers.
The SET_SCHEMA_INSTANTIATION_SCN Procedure and CDBs
In a CDB, this procedure must be invoked from the same container as the apply process that uses the instantiation SCN information.
21.4.23 SET_TABLE_INSTANTIATION_SCN Procedure
This procedure records the specified instantiation SCN for the specified table in the specified source database. This procedure overwrites any existing instantiation SCN for the particular table.
This procedure gives you precise control over which logical change records (LCRs) for a table are ignored and which LCRs are applied by an apply component.
Syntax
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN( source_object_name IN VARCHAR2, source_database_name IN VARCHAR2, instantiation_scn IN NUMBER, apply_database_link IN VARCHAR2 DEFAULT NULL, source_root_name IN VARCHAR2 DEFAULT NULL);
Parameters
Table 21-26 SET_TABLE_INSTANTIATION_SCN Procedure Parameters
Parameter | Description |
---|---|
|
The name of the source object specified as When setting an instantiation SCN for a database object, always specify the name of the schema and database object at the source database, even if a rule-based transformation or apply handler is configured to change the schema name or database object name. |
|
The global name of the source database. For example, If you do not include the domain name, then the procedure appends it to the database name automatically. For example, if you specify |
|
The instantiation SCN. Specify |
|
The name of the database link to a non-Oracle database. This parameter should be set only when the destination database of a local apply component is a non-Oracle database. Note: This parameter must be |
|
The global name of the source root database. In a non-CDB, this parameter must be In a CDB, both |
Usage Notes
The following usage notes apply to this procedure:
-
The SET_TABLE_INSTANTIATION_SCN Procedure and XStream Outbound Servers
-
The SET_TABLE_INSTANTIATION_SCN Procedure and XStream Inbound Servers
Instantiation SCNs and LCRs
If the commit SCN of an LCR for a table from a source database is less than or equal to the instantiation SCN for that table at some destination database, then the apply component at the destination database disregards the LCR. Otherwise, the apply component applies the LCR.
The table instantiation SCN specified by this procedure is used on the following types of LCRs:
-
Row LCRs for the table
-
DDL LCRs that have a non-
NULL
base_table_owner
andbase_table_name
specified, except for DDL LCRs with acommand_type
ofCREATE
TABLE
For example, the table instantiation SCN set by this procedure is used for DDL LCRs with a command_type
of ALTER
TABLE
or CREATE
TRIGGER
.
Note:
The instantiation SCN specified by this procedure is used only for LCRs captured by a capture process. It is not used for user-created LCRs.
See Also:
-
LCR$_ROW_RECORD Type for more information about row LCRs
-
LCR$_DDL_RECORD Type for more information about DDL LCRs
The SET_TABLE_INSTANTIATION_SCN Procedure and XStream Outbound Servers
Instantiation SCNs are not required for database objects processed by an outbound server. If an instantiation SCN is set for a database object, then the outbound server only sends the LCRs for the database object with SCN values that are greater than the instantiation SCN value. If a database object does not have an instantiation SCN set, then the outbound server skips the instantiation SCN check and sends all LCRs for that database object. In both cases, the outbound server only sends LCRs that satisfy its rule sets.
The apply_database_link
parameter must be set to NULL
or to the local database for this procedure to set an instantiation SCN for an outbound server.
See Also:
Oracle Database XStream Guide for more information about outbound servers and instantiation SCNs
The SET_TABLE_INSTANTIATION_SCN Procedure and XStream Inbound Servers
Inbound servers ignore instantiation SCNs. This procedure has no effect on XStream inbound servers.
The SET_TABLE_INSTANTIATION_SCN Procedure and CDBs
In a CDB, this procedure must be invoked from the same container as the apply process that uses the instantiation SCN information.
21.4.24 SET_UPDATE_CONFLICT_HANDLER Procedure
This procedure adds, modifies, or removes a prebuilt update conflict handler for the specified object.
Syntax
DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER( object_name IN VARCHAR2, method_name IN VARCHAR2, resolution_column IN VARCHAR2, column_list IN DBMS_UTILITY.NAME_ARRAY, apply_database_link IN VARCHAR2 DEFAULT NULL);
Parameters
Table 21-27 SET_UPDATE_CONFLICT_HANDLER Procedure Parameters
Parameter | Description |
---|---|
|
The schema and name of the table, specified as For example, if an update conflict handler is being added for table |
|
Type of update conflict handler to create. You can specify one of the prebuilt handlers, which determine whether the column list from the source database is applied for the row or whether the values in the row at the destination database are retained:
If |
|
Name of the column used to uniquely identify an update conflict handler. For the
|
|
List of columns for which the conflict handler is called. The same column cannot be in more than one column list. If a conflict occurs for one or more of the columns in the list when an apply component tries to apply a row logical change record (row LCR), then the conflict handler is called to resolve the conflict. The conflict handler is not called if a conflict occurs only for columns that are not in the list. Note: Prebuilt update conflict handlers do not support LOB, |
|
The name of the database link to a non-Oracle database. This parameter should be set only when the destination database is a non-Oracle database. Note: Currently, conflict handlers are not supported when applying changes to a non-Oracle database. |
Usage Notes
The following usage notes apply to this procedure:
-
The SET_UPDATE_CONFLICT_HANDLER Procedure and XStream Outbound Servers
-
The SET_UPDATE_CONFLICT_HANDLER Procedure and XStream Inbound Servers
Modifying an Existing Update Conflict Handler
If you want to modify an existing update conflict handler, then you specify the table and resolution column of an the existing update conflict handler. You can modify the prebuilt method or the column list.
Removing an Existing Update Conflict Handler
If you want to remove an existing update conflict handler, then specify NULL
for the prebuilt method and specify the table, column list, and resolution column of the existing update conflict handler.
Series of Actions for Conflicts
If an update conflict occurs, then Oracle completes the following series of actions:
-
Calls the appropriate update conflict handler to resolve the conflict
-
If no update conflict handler is specified or if the update conflict handler cannot resolve the conflict, then calls the appropriate error handler for the apply component, table, and operation to handle the error
-
If no error handler is specified or if the error handler cannot resolve the error, then raises an error and moves the transaction containing the row LCR that caused the error to the error queue
See Also:
"Signature of a DML Handler Procedure or Error Handler Procedure" for information about setting an error handler
Procedure DML Handlers for Conflicts
If you cannot use a prebuilt update conflict handler to meet your requirements, then you can create a PL/SQL procedure to use as a custom conflict handler. You use the SET_DML_HANDLER
procedure to designate one or more custom conflict handlers for a particular table. In addition, a custom conflict handler can process LOB columns and use LOB assembly.
See Also:
A Column Can Be in Only One Column List
When a column is in a column list, and you try to add the same column to another column list, this procedure returns the following error:
ORA-00001: UNIQUE CONSTRAINT (SYS.APPLY$_CONF_HDLR_COLUMNS_UNQ1) VIOLATED
Update Conflict Handlers and Non-Oracle Databases
Setting an update conflict handler for an apply component that is applying to a non-Oracle database is not supported.
The SET_UPDATE_CONFLICT_HANDLER Procedure and XStream Outbound Servers
This procedure has no effect on XStream outbound servers.
The SET_UPDATE_CONFLICT_HANDLER Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
Examples
The following is an example for setting an update conflict handler for the employees
table in the hr
schema:
DECLARE cols DBMS_UTILITY.NAME_ARRAY; BEGIN cols(1) := 'salary'; cols(2) := 'commission_pct'; DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER( object_name => 'hr.employees', method_name => 'MAXIMUM', resolution_column => 'salary', column_list => cols); END; /
This example sets a conflict handler that is called if a conflict occurs for the salary
or commission_pct
column in the hr.employees
table. If such a conflict occurs, then the salary
column is evaluated to resolve the conflict. If a conflict occurs only for a column that is not in the column list, such as the job_id
column, then this conflict handler is not called.
21.4.25 SET_VALUE_DEPENDENCY Procedure
This procedure sets or removes a value dependency. A value dependency is a virtual dependency definition that defines a relationship between the columns of two or more tables.
An apply component uses the name of a value dependencies to detect dependencies between row logical change records (row LCRs) that contain the columns defined in the value dependency. Value dependencies can define virtual foreign key relationships between tables, but, unlike foreign key relationships, value dependencies can involve more than two database objects.
This procedure is overloaded. The attribute_list
and attribute_table
parameters are mutually exclusive.
Syntax
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY( dependency_name IN VARCHAR2, object_name IN VARCHAR2, attribute_list IN VARCHAR2); DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY( dependency_name IN VARCHAR2, object_name IN VARCHAR2, attribute_table IN DBMS_UTILITY.NAME_ARRAY);
Parameters
Table 21-28 SET_VALUE_DEPENDENCY Procedure Parameters
Parameter | Description |
---|---|
|
The name of the value dependency. If a dependency with the specified name does not exist, then it is created. If a dependency with the specified name exists, then the specified object and attributes are added to the dependency. If |
|
The name of the table, specified as If If |
|
A comma-delimited list of column names in the table. There must be no spaces between entries. |
|
A PL/SQL associative array of type |
Usage Notes
The following usage notes apply to this procedure:
-
The SET_VALUE_DEPENDENCY Procedure and XStream Outbound Servers
-
The SET_VALUE_DEPENDENCY Procedure and XStream Inbound Servers
The SET_VALUE_DEPENDENCY Procedure and XStream Outbound Servers
This procedure has no effect on XStream outbound servers.
The SET_VALUE_DEPENDENCY Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.26 START_APPLY Procedure
This procedure directs the apply component to start applying messages.
Syntax
DBMS_APPLY_ADM.START_APPLY( apply_name IN VARCHAR2);
Parameter
Table 21-29 START_APPLY Procedure Parameter
Parameter | Description |
---|---|
|
The apply component name. A |
Usage Notes
The following usage notes apply to this procedure:
Apply Component Status
The apply component status is persistently recorded. Hence, if the status is ENABLED
, then the apply component is started upon database instance startup. An apply component (a
nnn
) is an Oracle background process. The enqueue and dequeue state of DBMS_AQADM.START_QUEUE
and DBMS_AQADM.STOP_QUEUE
have no effect on the start status of an apply component.
The START_APPLY Procedure and XStream Outbound Servers
This procedure functions the same way for apply processes and outbound servers.
The START_APPLY Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.
21.4.27 STOP_APPLY Procedure
This procedure stops the apply component from applying messages and rolls back any unfinished transactions being applied.
Syntax
DBMS_APPLY_ADM.STOP_APPLY( apply_name IN VARCHAR2, force IN BOOLEAN DEFAULT FALSE);
Parameters
Table 21-30 STOP_APPLY Procedure Parameters
Parameter | Description |
---|---|
|
The apply component name. A |
|
If If The behavior of the apply component depends on the setting specified for the |
Usage Notes
The following usage notes apply to this procedure:
Apply Component Status
The apply component status is persistently recorded. Hence, if the status is DISABLED
or ABORTED
, then the apply component is not started upon database instance startup.
Queue Subprograms Have No Effect on Apply Component Status
The enqueue and dequeue state of DBMS_AQADM.START_QUEUE
and DBMS_AQADM.STOP_QUEUE
have no effect on the STOP
status of an apply component.
The STOP_APPLY force Parameter and the commit_serialization Apply Parameter
The following table describes apply component behavior for each setting of the force
parameter in the STOP_APPLY
procedure and the commit_serialization
apply component parameter. In all cases, the apply component rolls back any unfinished transactions when it stops.
force | commit_serialization | Apply Component Behavior |
---|---|---|
|
|
The apply component stops immediately and does not apply any unfinished transactions. |
|
|
When the apply component stops, some transactions that have been applied locally might have committed at the source database at a later point in time than some transactions that have not been applied locally. |
|
|
The apply component stops after applying the next uncommitted transaction in the commit order, if any such transaction is in progress. |
|
|
Before stopping, the apply component applies all of the transactions that have a commit time that is earlier than the applied transaction with the most recent commit time. |
For example, assume that the commit_serialization
apply component parameter is set to DEPENDENT_TRANSACTIONS
and there are three transactions: transaction 1 has the earliest commit time, transaction 2 is committed after transaction 1, and transaction 3 has the latest commit time. Also assume that an apply component has applied transaction 1 and transaction 3 and is in the process of applying transaction 2 when the STOP_APPLY
procedure is run. Given this scenario, if the force
parameter is set to TRUE
, then transaction 2 is not applied, and the apply component stops (transaction 2 is rolled back). If, however, the force
parameter is set to FALSE
, then transaction 2 is applied before the apply component stops.
A different scenario would result if the commit_serialization
apply component parameter is set to FULL
. For example, assume that the commit_serialization
apply component parameter is set to FULL
and there are three transactions: transaction A has the earliest commit time, transaction B is committed after transaction A, and transaction C has the latest commit time. In this case, the apply component has applied transaction A and is in the process of applying transactions B and C when the STOP_APPLY
procedure is run. Given this scenario, if the force
parameter is set to TRUE
, then transactions B and C are not applied, and the apply component stops (transactions B and C are rolled back). If, however, the force
parameter is set to FALSE
, then transaction B is applied before the apply component stops, and transaction C is rolled back.
See Also:
SET_PARAMETER Procedure for more information about the commit_serialization
apply component parameter
The STOP_APPLY Procedure and XStream Outbound Servers
This procedure functions the same way for apply processes and outbound servers.
The STOP_APPLY Procedure and XStream Inbound Servers
This procedure functions the same way for apply processes and inbound servers.