Search Results nclob_arg

Overview

SYS.DBMS_DEFER is the Oracle-supplied PL/SQL package that provides the foundational deferred remote procedure call (RPC) interface used by Oracle's advanced replication and distributed transaction infrastructure. Within the Oracle E-Business Suite 12.1.1 and 12.2.2 technical stack, this package operates entirely in the SYS schema and is classified as an OTHER-type API. It is a core dependency of the deferred transaction queue framework that underpins multi-master replication, materialized view refresh scheduling, and the propagation of queued transactional changes between database nodes.

In practice, DBMS_DEFER allows a session to defer a call to a remote procedure rather than execute it immediately. The RPC is placed on the local deferred transaction queue, and a background process—typically the deferred transaction push job—later transmits the queued call to the destination site for execution. This decoupling mechanism is essential in EBS environments that rely on Oracle Advanced Replication or Symmetric Replication, because it permits application transactions to complete without blocking on network round-trips to remote nodes.

Key Procedures and Functions

The ETRM metadata documents 31 procedures and functions in DBMS_DEFER. The most significant are the argument-registration routines that form a contiguous sequence: a caller begins with TRANSACTION, then issues one or more argument routines in the exact order the remote procedure expects them, and finally invokes CALL to enqueue the deferred invocation. A COMMIT_WORK routine finalizes the queued work.

The argument routines supply typed values to the deferred call queue:

• NUMBER_ARG, DATE_ARG, VARCHAR2_ARG, NVARCHAR2_ARG, NVARCHAR2_ARG variants, CHAR_ARG, NCHAR_ARG, RAW_ARG, ROWID_ARG, BLOB_ARG, CLOB_ARG, NCLOB_ARG, TIME_ARG, TIMESTAMP_ARG, and TTZ_ARG register scalar and LOB arguments matching their declared datatypes.
• The ANY_* variants—ANY_VARCHAR2_ARG, ANY_CHAR_ARG, and ANY_CLOB_ARG—accept the generic SYS.ANYDATA encapsulation, which the package relies on (as confirmed by the dependency on SYS.ANYDATA).

Together these routines populate the deferred call arguments table before the corresponding remote invocation is flush-queued.

Tables Accessed

The ETRM excerpt lists no direct application tables accessed through APPS synonyms, which is expected: DBMS_DEFER is a SYS-owned dictionary-level package. It operates against the core replication catalog tables, principally DEFCALL, DEFCALLDEST, DEFTRAN, and DEFTRANDEST, which hold the deferred call headers, destinations, transaction identifiers, and argument payloads respectively. These are the repository structures used by the deferred transaction queue. The package also depends on DBMS_DEFER_QUERY, which provides the read-side interrogation interface for those same queue tables.

Usage Notes

DBMS_DEFER is not typically invoked directly by EBS forms, concurrent programs, or customer-written application code. It is instead called internally by higher-level packages, as confirmed by the dependency listing: DBMS_DEFER is referenced by 11 other packages, including DBMS_ASYNCRPC_PUSH, DBMS_DEFER_DEFINER, DBMS_DEFER_ENQ_UTL, DBMS_DEFER_INTERNAL_SYS, DBMS_DEFER_QUERY_UTL, DBMS_DEFER_REPCAT, DBMS_DEFER_SYS_DEFINER, DBMS_DEFER_SYS_PART1, DBMS_DEFERGEN_WRAP, and DBMS_REPCAT_UTL4. These wrappers and definer-rights shims handle privilege escalation, replication catalog integration, and queue management on behalf of the base package.

Administrators interact with the deferred queue indirectly through DBMS_DEFER_SYS (pushing, purging, and scheduling the queue) rather than through DBMS_DEFER itself. Direct use of DBMS_DEFER is reserved for advanced replication configuration and diagnostic scripts. Because the package executes with SYS privileges and manipulates the replication catalog, EXECUTE grants are normally restricted to PUBLIC only for the wrapper interfaces, and any custom invocation should be undertaken with a clear understanding of its impact on the deferred transaction queue. In EBS 12.1.1 and 12.2.2 environments, its presence should be regarded as infrastructure supporting replication deployments rather than as an application-level API.