Search Results create_snapshot_repgroup




Overview

SYS.DBMS_REPCAT_SNA is a server-side PL/SQL package owned by the SYS schema and shipped as a core component of Oracle's Advanced Replication infrastructure. In Oracle E-Business Suite 12.1.1 and 12.2.2 it provides the administrative API for managing "snapshot" replication groups — the read-only, periodically refreshed copies of master data that historically underpinned multi-tier EBS deployments. The package name derives from "SNA" (snapshot) and "REPCAT" (replication catalog), reflecting its role as the snapshot-side counterpart to the master-side catalog administration packages such as DBMS_REPCAT and DBMS_REPCAT_DEFINER.

Its principal business function is to let administrators define, register, propagate, refresh, and tear down snapshot replication groups, snapshot replication objects, and snapshot replication schemas without manipulating the underlying replication catalog tables directly. It therefore supports the topology that distributed EBS implementations used to push reference and transaction data from a central master site to regional or reporting sites.

Key Procedures and Functions

ETRM documents 18 callable units within this package. They fall into several logical families:

Tables Accessed

The ETRM metadata defines dependency relationships rather than an explicit table list. Documented dependencies show SYS.DBMS_REPCAT_SNA referencing DBMS_REPCAT_DECL and STANDARD, and being referenced by DBMS_OFFLINE_SNAPSHOT_INTERNAL, DBMS_REPCAT_DEFINER, and by itself. Functionally, the package operates against the Advanced Replication catalog — principally the system tables that record replication groups, replicated objects, and site topology — which is why its operations are tightly bound to DBMS_REPCAT_DECL and the REPCAT_DEFINER wrapper. No APPS-schema synonyms are documented as referenced by this package.

Usage Notes

DBMS_REPCAT_SNA is not exposed through standard EBS forms. In EBS 12.1.1, snapshot administration was normally driven by administrative scripts and by the Oracle-supplied replication management tooling; in 12.2.2 the majority of distributed EBS replication scenarios were replaced by other mechanisms, and Advanced Replication groups were largely de-supported for new deployments. Where the package is still invoked, it is typically called from SQL*Plus or a concurrent-program wrapper running as a privileged account, never from concurrent manager sessions owned by APPS unless explicitly granted. Custom code should treat every procedure as a DDL-level administrative action: calls must be executed in the correct site context, sequenced with master-site administration, and followed by metadata validation. Because the package is SYS-owned and marked OTHER in the API classification, direct invocation should be restricted to controlled maintenance windows and never embedded in application runtime logic.