Search Results dbms_streams_datapump




Overview

SYS.DBMS_STREAMS_DATAPUMP is an Oracle-supplied PL/SQL package that belongs to the Oracle Streams infrastructure and provides the Data Pump integration layer used by Streams-based replication and capture/apply processes. In the Oracle E-Business Suite 12.1.1 and 12.2.2 environments, this package is not an application-facing API but a SYS-owned internal utility that supports export and import operations performed against Streams metadata and queues. Its presence in the ETRM dependency inventory confirms that the package is VALID in a standard EBS installation and that it participates in the internal call chain underlying database-level data movement utilities.

The package sits within the broader DBMS_STREAMS family. Whereas packages such as DBMS_STREAMS_ADM, DBMS_CAPTURE_ADM, and DBMS_APPLY_ADM configure capture and apply processes, DBMS_STREAMS_DATAPUMP specifically bridges Streams and the Data Pump engine so that Streams-related objects and metadata can be exported and imported in a controlled fashion.

Key Procedures and Functions

The ETRM documentation excerpt for DBMS_STREAMS_DATAPUMP records zero explicitly documented procedures or functions. The metadata classifies the API as OTHER, and the published dependency information lists only the package and package body entries without enumerating callable subprograms. Because the documented inventory exposes no named routines, no parameter lists are reproduced here; inventing signatures would misrepresent the shipped interface.

Functionally, the package is known to supply internal entry points that Data Pump invokes when a Streams-enabled export or import is executed. These routines coordinate the movement of Streams metadata — rules, rule sets, capture and apply definitions — alongside the underlying queue tables. This is consistent with the dependency chain, in which DBMS_STREAMS_PUB_RPC and DBMS_INTERNAL_SAFE_SCN reference the package, indicating that public RPC entry points and SCN-safety logic depend on it during data movement operations.

Tables Accessed

The ETRM metadata records no application tables accessed through APPS synonyms for this package. This is expected: DBMS_STREAMS_DATAPUMP operates on SYS-owned Streams dictionary and queue objects rather than on EBS application schema tables. Any table references are resolved internally within the SYS schema, principally the Streams metadata views and the capture/apply queue tables that Data Pump must serialize during export and import. Because the object is owned by SYS and classified as an internal utility, EBS application modules do not query it directly, and no APPS synonym dependency is documented.

Usage Notes

DBMS_STREAMS_DATAPUMP is not invoked from Oracle E-Business Suite forms, concurrent programs, or standard application code. It is engaged indirectly when a DBA or administrator performs a Data Pump export or import against a database in which Oracle Streams has been configured, or when EBS cloning and migration procedures execute database-level data movement. In these scenarios the Data Pump client calls into the package to handle Streams-specific metadata.

  • Reserved for database administration and internal database engine use; never called from EBS application PL/SQL.
  • Invoked transitively during Streams-aware Data Pump operations, typically as part of migration, cloning, or replication maintenance.
  • Referenced by DBMS_STREAMS_PUB_RPC and DBMS_INTERNAL_SAFE_SCN, indicating its role in RPC-based Streams operations and SCN consistency checks.
  • Because it is SYS-owned and undocumented at the procedure level in ETRM, customization or direct invocation is neither supported nor advisable.
  • Its VALID status in EBS 12.1.1 and 12.2.2 confirms that the package is expected in a healthy, fully installed EBS database; invalid status would ordinarily signal a failed database component installation.

Administrators encountering this package in dependency or invalidation reports should treat it as a core database component and direct remediation efforts toward recompiling SYS-owned objects rather than attempting application-level fixes.