Search Results dbms_repcat_sna_internal




Overview
Explore in AI Chat

Overview

DBMS_REPCAT_SNA_INTERNAL is an Oracle-supplied PL/SQL package owned by the SYS schema and shipped with the Oracle database kernel, not with the E-Business Suite application schema. Its presence in an EBS 12.1.1 or 12.2.2 environment reflects the underlying database release rather than any EBS-specific feature. The "_INTERNAL" suffix indicates that the package is a private implementation unit: it exists to support the public DBMS_REPCAT_SNA package and is not intended for direct invocation by application code, database administrators, or custom developers.

The package belongs to the Symmetric Replication and Advanced Replication infrastructure of the Oracle database. DBMS_REPCAT_SNA provides the change-capture and synchronous-update mechanisms used by multi-master replication, and it dispatches its core work to the internal package documented here. In EBS terms, this package is part of the plumbing that supports distributed deployments where replicated database objects are synchronized across nodes. It is classified in the ETRM repository as an OTHER API, meaning it is not a supported public interface and carries no documented business-level procedures.

Key Procedures and Functions

The ETRM documentation for this object records zero documented procedures or functions. This is expected for an internal support package: its callable units are not published, are not guaranteed to remain stable across database patch levels, and are deliberately omitted from the visible API surface. The only documented fact about its interface is that it exposes callable units consumed by DBMS_REPCAT_SNA, which is itself the entry point for replication administration.

Because no public signatures are documented, no parameter lists should be assumed. Administrators and developers should treat every routine inside DBMS_REPCAT_SNA_INTERNAL as inaccessible and subject to change without notice. Any requirement to configure or troubleshoot replication in an EBS instance should be addressed through the public DBMS_REPCAT family, database documentation, or Oracle Support guidance rather than by calling this package.

Tables Accessed

The provided metadata does not enumerate any base tables referenced directly by DBMS_REPCAT_SNA_INTERNAL, and no references via APPS synonyms are documented. This is consistent with an SYS-owned database package: it operates on Oracle replication catalog objects owned by SYS, such as the DEF$ and REPCAT$ dictionary tables, rather than on EBS application tables. There is no evidence that the package reads or writes any APPS schema table, and no EBS product data is affected by its execution.

Its dependency list confirms this narrow scope. The package references DBMS_DB_VERSION for release-dependent behaviour, DBMS_REPCAT_DECL for shared type and constant declarations, the STANDARD package for base PL/SQL constructs, and SYS_STUB_FOR_PURITY_ANALYSIS, which is a standard artefact generated when a package's purity is asserted rather than analysed. No EBS-specific dependency appears.

Usage Notes

DBMS_REPCAT_SNA_INTERNAL is not invoked from EBS forms, concurrent programs, or supported custom code. It is called internally by DBMS_REPCAT_SNA during replication setup and synchronisation activity, and the documented dependency list shows it is referenced by only one other package: DBMS_REPCAT_SNA itself. It also appears in its own reference list, indicating internal recursion or self-referential calls within the package body.

For EBS administrators, the practical implication is straightforward. The object appears in dependency and code-search queries, and it may surface during cloning, database upgrades, or replication diagnostics, but it requires no configuration and exposes no extension points. It should never be modified, wrapped, or called directly. Status is recorded as VALID, indicating correct compilation in the reference environment. Upgrade and patching of this package is governed entirely by the Oracle database release applied beneath the EBS application tier, not by EBS patching itself.