Search Results dbms_repcat_internal




Overview
Explore in AI Chat

Overview

SYS.DBMS_REPCAT_INTERNAL is an Oracle-supplied, internal PL/SQL package that forms part of the Oracle Advanced Replication infrastructure shipped with the database kernel. It is owned by SYS, holds VALID status, and is classified under the ETRM API classification of OTHER, indicating that it is not a published, customer-callable application programming interface but rather a supporting engine used by the higher-level replication packages.

Within Oracle E-Business Suite 12.1.1 and 12.2.2, this package underpins the replication management layer that Oracle EBS historically relied upon for multi-node and multi-master deployments, particularly in Distributed/Advanced Replication topologies used to synchronize reference and transactional data across database instances. The package encapsulates low-level catalog manipulation and internal bookkeeping that the documented, user-facing replication APIs delegate to, shielding the public packages from direct dictionary access. Because it is an internal package, Oracle does not document its callable surface, and Oracle support generally discourages direct invocation.

Key Procedures and Functions

The ETRM metadata records zero documented procedures or functions for this package. This is consistent with its status as an internal implementation package: its callable objects are deliberately excluded from the public Oracle documentation set and are not exposed as supported entry points.

Functionally, DBMS_REPCAT_INTERNAL serves as the shared internal utility layer beneath the replication administration stack. It provides the private routines that the public replication packages invoke to manage replicated object metadata, validate internal state, and perform privileged catalog operations on behalf of the calling package. No parameter lists are documented, and none should be assumed or constructed from inference; any attempt to call the package directly relies on undocumented and version-dependent signatures.

The dependency metadata confirms that the package depends only on SYS and the STANDARD package, reflecting its role as a foundational, self-contained kernel utility rather than a package layered on other application logic.

Tables Accessed

The ETRM metadata does not document any tables referenced through APPS synonyms; no application-level tables are attributed to this package. As an internal replication component owned by SYS, it operates against the Oracle Replication catalog — the internal dictionary views and base tables that store replication group definitions, object registrations, and administrative state — rather than against EBS application schema objects.

The absence of documented table references in the ETRM extract reflects the fact that dictionary access is performed internally under SYS privileges and is not surfaced as an application dependency. Consequently, no EBS product schema tables are listed as read or written by this package.

Usage Notes

DBMS_REPCAT_INTERNAL is not intended for direct invocation by EBS forms, concurrent programs, or custom code. It is invoked indirectly and exclusively by Oracle's own replication packages. The ETRM dependency report identifies thirteen referencing packages, including DBMS_REPCAT_ADMIN, DBMS_REPCAT_UTL, DBMS_REPCAT_UTL3, DBMS_REPCAT_UTL4, DBMS_REPCAT_MAS, DBMS_REPCAT_CONF, DBMS_REPCAT_SNA_UTL, DBMS_REPCAT_OBJ_UTL, DBMS_REPCAT_FLA_UTL, DBMS_OFFLINE_RGT_INTERNAL, DBMS_OFFLINE_UTL, DBMS_REPUTIL, and DBMS_STREAMS_ADM_UTL, in addition to recursion within the package itself. It is also exposed to PUBLIC by synonym, though this exposure is a packaging artifact rather than an invitation to call it.

In EBS environments, replication administration is performed through supported interfaces — typically the DBMS_REPCAT family and, in supported configurations, Oracle GoldenGate or Streams-based alternatives. Because DBMS_REPCAT_INTERNAL has zero documented procedures, any direct reference in custom code constitutes an unsupported dependency that risks breaking on patching or upgrade, notably across the 12.1.1 to 12.2.2 boundary where the underlying database release changes. Administrators should confirm validity through DBA_OBJECTS and treat invalidations during patching as expected internal recompilation events rather than application defects.