Results for “action_phase”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The AD_PATCH_COMMON_ACTIONS table, owned by the APPLSYS schema in Oracle E-Business Suite, is a core repository for the common actions performed by the AutoPatch utility. AutoPatch (adpatch) is the primary mechanism used to apply patches, run file generation, and execute driver scripts during an EBS patching cycle. Rather than hard-coding each discrete operation, AutoPatch stores reusable action definitions in this table, allowing individual patch runs to reference a shared, centrally maintained library of actions. This design reduces duplication across patch definitions and provides an auditable, queryable record of what operations the patching infrastructure is capable of performing.

The table is present in both 12.1.1 and 12.2.2, though the documented 19-column physical schema referenced here corresponds to the 12.2.2 ETRM snapshot. Its role is procedural rather than transactional business data: it sits beneath the Applications DBA (AD) module and is used almost exclusively during patching, upgrade, and AD administration activities.

Based on the heuristic Data Vault classification mined from the foreign-key structure, this table is described as satellite-leaning. In data-vault modeling terms, that classification is a suggestion: the table appears to hold descriptive attributes (action definitions, phases, argument payloads) that hang off a business key rather than acting as a pure hub or a pure link. The COMMON_ACTION_ID unique index and the separate CONCAT_ATTRIBS unique index both function as candidate business keys.

Key Information Stored

Among the 19 documented columns, the following are the most significant for understanding what an action represents and how it is invoked.

• COMMON_ACTION_ID — The surrogate primary key, enforced by AD_PATCH_COMMON_ACTIONS_PK and also indexed uniquely by AD_PATCH_COMMON_ACTIONS_U1. Every action is identified by this numeric identifier.
• ACTION_CODE — The operational code defining the type of action AutoPatch will perform.
• CONCAT_ATTRIBS — A concatenated attribute string acting as a secondary business-key candidate, enforced by the unique index AD_PATCH_COMMON_ACTIONS_U2. It typically holds a composite identifier used to express the action's distinguishing characteristics.
• ACTION_PHASE, NUMERIC_PHASE, NUMERIC_SUB_PHASE — Define the sequencing of the action within the patch driver, controlling when the action executes relative to other phases and sub-phases.
• ACTION_ARGUMENTS — The runtime arguments passed to the action.
• CHECKFILE_ARGS — Arguments associated with the checkfile validation logic for the action.
• ACTION_CHECK_OBJ, ACTION_CHECK_OBJ_USERNAME, ACTION_CHECK_OBJ_PASSWD — Define the object, username, and password used when performing an object existence or validation check.
• ACTION_WHAT_SQL_EXEC — The SQL execution specification run as part of the action.
• ACTION_TIERLIST_IN_DRIVER — Indicates the tier list in the driver, controlling whether the action applies to a particular node tier.
• ACTION_LANG_CODE — The language code under which the action is applicable.
• LOADER_DATA_FILE_ID — Foreign key to AD_FILES, linking the action to its associated loader data file.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY — Standard audit columns recording who created or last modified the action and when.

Common Use Cases and Queries

Because this is infrastructure metadata, typical queries are investigative: DBA teams examine it to understand what actions a patch run performed, to debug failures, or to trace how a given loader file was consumed.

Listing all actions referenced by a patch run joins through the foreign table that references this one:

• SELECT rbug.COMMON_ACTION_ID, ca.ACTION_CODE, ca.ACTION_PHASE FROM ad_patch_run_bug_actions rbug JOIN ad_patch_common_actions ca ON rbug.COMMON_ACTION_ID = ca.COMMON_ACTION_ID;

Locating the source file for an action joins to AD_FILES:

• SELECT ca.COMMON_ACTION_ID, ca.ACTION_CODE, f.FILE_NAME FROM ad_patch_common_actions ca JOIN ad_files f ON ca.LOADER_DATA_FILE_ID = f.FILE_ID;

Investigating a specific action by its business key uses the CONCAT_ATTRIBS unique index, while looking up actions by phase or SQL execution content supports troubleshooting failed driver steps and reconstructing the order in which actions were dispatched. Historical analysis can also be performed against AD_PATCH_HIST_TEMP, which retains a COMMON_ACTION_ID reference for prior patch activity.

Related Objects

• AD_PATCH_RUN_BUG_ACTIONS — References this table through COMMON_ACTION_ID; records the actions executed for each patch run and bug.
• AD_PATCH_HIST_TEMP — References COMMON_ACTION_ID; retains historical action data during patch processing.
• AD_FILES — Referenced by LOADER_DATA_FILE_ID; provides the loader data file definition associated with an action.
• AD_PATCH_COMMON_ACTIONS_PK / _U1 / _U2 — The primary key and unique indexes enforcing identity and business-key uniqueness on COMMON_ACTION_ID and CONCAT_ATTRIBS.
• adpatch / AutoPatch driver — The utility that consumes these action definitions during patch application, using ACTION_PHASE and NUMERIC_SUB_PHASE for sequencing.

Collectively, these relationships place AD_PATCH_COMMON_ACTIONS at the center of the AutoPatch action model, bridging file definitions and executed patch actions across the EBS patching lifecycle.