Search Results migrate_objects




Overview
Explore in AI Chat

Overview

FND_EXEC_MIG_CMDS is an Oracle E-Business Suite (EBS) internal PL/SQL package owned by the APPS schema. Its name reflects its role as the execution engine for migration commands: it processes command records that describe how database objects should be manipulated during a migration or bulk object-management operation. The package header is declared with AUTHID DEFINER, meaning all PL/SQL inside it executes with the privileges of its owner (APPS), not the calling user. This is consistent with an administrative utility that must manipulate objects owned by other schemas.

The package operates on two companion tables, FND_TS_MIG_CMDS and FND_TS_MIG_STATUS, which together form a command/status queue. Command rows are read, interpreted, and executed; progress and outcome information is written back to the status table. Commands include enabling or disabling constraints, triggers and policies, and stopping or starting Advanced Queueing queues. The presence of DBMS_LOCK references further indicates that the package serializes its work so concurrent migration requests do not interfere with one another. References to DBMS_APPLICATION_INFO allow the execution to be labelled in V$SESSION for monitoring long-running migrations.

Key Procedures and Functions

The package exposes twelve documented procedures, organized around a prepare/execute/restore pattern:

  • PROCESS_LINE_CHILD_CMDS — Processes the child commands associated with a given command line number, providing the line-level iteration that drives command execution.
  • MIGRATE_OBJECTS — The central orchestrator. It accepts an owner, an AQ (Advanced Queueing) status, and an execution mode, and performs the overall migration operation for the specified schema.
  • DISABLE_CONS, DISABLE_TRIGGER, DISABLE_POLICIES — Pre-migration teardown procedures that disable constraints, triggers, and (row-level security) policies for the given owner so that bulk data/object operations are not blocked or audited.
  • STOP_QUEUES — Halts Advanced Queueing queues for the owner using DBMS_AQ, preventing message consumption during migration.
  • DISABLE — A convenience wrapper that invokes the individual disable operations as a group.
  • ENABLE_CONS, ENABLE_TRIGGER, ENABLE_POLICIES — Post-migration restoration procedures that re-enable the constraints, triggers, and policies turned off earlier.
  • START_QUEUES — Restarts the queues stopped before migration.
  • ENABLE — A convenience wrapper that invokes the individual enable operations as a group.

Every procedure returns an x_return_status OUT parameter of type VARCHAR2 so that callers can determine success or failure. No procedure parameters beyond those shown in the header should be assumed.

Tables Accessed

The package reads and writes the following objects, primarily through APPS synonyms:

  • FND_TS_MIG_CMDS — The command table holding the migration instructions (the "cmds") to be processed.
  • FND_TS_MIG_STATUS — The status table where execution results and progress are recorded.
  • DBMS_APPLICATION_INFO, DBMS_AQ, DBMS_LOCK — Supplied Oracle packages used for session labelling, queue control, and serialization.
  • PLITBLM — An Oracle internal table supporting PL/SQL package instantiation/state.
  • V$SESSION — Queried to inspect the session context, typically in connection with the DBMS_APPLICATION_INFO registration.

Usage Notes

FND_EXEC_MIG_CMDS is not a public API and is not referenced by other documented packages (referenced by 0 packages in ETRM). It is an internal helper invoked by migration or object-management utilities within EBS. In practice, it is called by the framework that populates FND_TS_MIG_CMDS, iterating the command lines and calling MIGRATE_OBJECTS for each schema to be processed, then using the ENABLE and DISABLE wrappers around that work. It is not exposed through a standard concurrent program or form entry point and should not be invoked directly by customers; custom code that does so risks leaving constraints, triggers, policies, or queues disabled if the enable phase is not executed successfully. Always verify the returned status and confirm that the ENABLE phase has completed before returning the system to normal operation.