Search Results clone_schema
Overview
SYSTEM.AD_CLONE_UTILS is an Oracle E-Business Suite database package used to support schema cloning, synchronization, and merging operations within an EBS environment. Unlike most AD (Application DBA) utilities that reside in the APPS schema, this package is owned by SYSTEM, reflecting its low-level, cross-schema nature. It provides the programmatic foundation for the Oracle EBS Rapid Clone, AutoConfig, and related schema management workflows, allowing administrators and utilities to duplicate, synchronize, or merge database schemas — typically during cloning, patching, or environment refresh activities.
The package declares the AUTHID CURRENT_USER pragma, meaning it executes with the privileges of the calling schema rather than its owner. This design allows it to be invoked flexibly from different administrative contexts while still operating on the target schemas passed as parameters. The package also defines constants that describe the key states and phases of a cloning operation — SOURCE, CLONE, and SPEC schema types; CLONE, MERGE, SYNC, and UNKNOWN phases; and statuses including UNKNOWN, COMPLETED, INCOMPLETE, FAILED, and INPROGRESS. These constants give the utility a consistent vocabulary for tracking the progress and outcome of schema operations across the EBS toolchain.
Key Procedures and Functions
The package exposes fifteen documented procedures and functions, covering the full lifecycle of a schema operation:
- GET_DB_VERSION — Returns the database version string, useful for conditional logic during migration or cloning utilities.
- PRINTLN — Writes a diagnostic message, typically routed to DBMS_OUTPUT, used for progress and error reporting.
- CLONE_TABLE — Clones an individual table from a source schema to a target schema, with options for primary key constraints, partition preservation, tablespace assignment, and overwrite behavior.
- CLONE_SCHEMA — Performs a full clone of a schema, accepting source and target schema names and a degree of parallelism for the operation.
- SYNC_SCHEMA — Synchronizes a clone schema with its source, reconciling differences after the initial clone.
- MERGE_SCHEMA — Merges a clone schema back into the source, typically used after applying changes in a staging environment.
- CLEAN_UP — Removes intermediate objects, clone schemas, and specification schemas created during the operation.
- GET_STATUS — Reports the current phase and status of a schema operation.
- IS_PHASE_COMPLETE — Returns whether a given phase (CLONE, MERGE, or SYNC) has completed successfully.
- VALIDATE_SCHEMAS — Verifies that the source and target schemas are in a suitable state before an operation begins.
- CREATE_SCHEMA — Creates a target schema as part of the cloning workflow.
- REPOINT_SYNONYMS — Redirects synonyms to point at the cloned objects, ensuring application code resolves to the new environment.
- CLEANUP_CHKFILE_INFO — Clears checkpoint file information associated with the operation.
- CLEANUP_SPEC_SCHEMA and CLEANUP_CLONE_SCHEMA — Perform targeted removal of the specification and clone schemas respectively.
Tables Accessed
The package queries a defined set of data dictionary and EBS objects, accessed primarily through APPS synonyms. DBA_OBJECTS and DBA_SOURCE are used to enumerate and inspect objects and their PL/SQL source for cloning and validation. DBA_SYNONYMS and DBA_TAB_COLUMNS support synonym repointing and column-level metadata inspection. DBA_TYPES provides type information needed to reconstruct dependent objects. DBMS_OUTPUT supports the PRINTLN routine. V$INSTANCE supplies instance context, while AD_GENERIC_TEMP is used as a scratch table for intermediate processing. The reference to PLITBLM is a legacy internal table used by the original toolkit.
Usage Notes
AD_CLONE_UTILS is not exposed through EBS forms. It is invoked through administrative scripts, Rapid Clone components, and the AD Administration (adadmin) toolchain, always in a database session with sufficient privileges to operate across schemas. Because it executes with AUTHID CURRENT_USER, the calling session must have the necessary DDL and dictionary access. Direct custom invocation is possible but discouraged outside supported cloning and patching workflows, as the package manipulates core dictionary objects and schema structures. In the 12.1.1 and 12.2.2 environments documented, it is referenced by no other packages, confirming its role as a top-level administrative utility rather than an internal API dependency.