Results for “ad_patch_cond_history”

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

Overview

APPLSYS.AD_PATCH_COND_HISTORY is an Oracle E-Business Suite Applications DBA (AD) repository table that records the historical results of patch prerequisite and condition evaluations performed by the AutoPatch (adpatch) utility during patch application. When adpatch encounters a conditional prerequisite — for example, a check on the technology stack (TECHSTACK) or on a specific product-level patch level — it evaluates that condition and stores the outcome for the associated patch run. This table therefore provides an audit trail of "why" a patch proceeded, was skipped, or failed at a given condition, tied back to a single execution of adpatch.

From a dimensional modeling perspective, the ETRM metadata suggests a heuristic Data Vault classification of satellite. The table carries descriptive, historized attributes (condition name, level, result) keyed by an execution identifier, and it references a parent hub-like source (AD_PATCH_RUNS) through a foreign key. This classification is a modeling suggestion only; the table is not a formally declared Data Vault structure within EBS.

Key Information Stored

The table is documented with seven columns in the ETRM 12.2.2 physical schema. The most significant are summarized below.

• PATCH_RUN_ID — Foreign key to AD_PATCH_RUNS. Identifies the specific AutoPatch execution during which the condition was evaluated. This is the primary grouping column for any historical query.
• COND_TE_NAME — The name of the condition on the trackable entity. Together with COND_TE_LEVEL, it identifies which conditional prerequisite was evaluated.
• COND_TE_LEVEL — The level at which the condition is defined (for example, APPL_TOP, product, or patch level).
• CONDITION — The condition expression or operator evaluated by adpatch (for example, equal-to, greater-than-or-equal).
• REQUIRED_LEVEL — The level value against which the actual entity state was compared to satisfy the condition.
• REQUIRED_TE_ABBR — The abbreviation of the required trackable entity.
• TRACKABLE_ENTITY_ABBR — The abbreviation of the trackable entity whose condition is being checked.

The metadata does not document a surrogate primary key or unique index for this table; the FK on PATCH_RUN_ID is the only declared relationship. Business-key candidates are the combination of PATCH_RUN_ID, COND_TE_NAME, COND_TE_LEVEL, and TRACKABLE_ENTITY_ABBR, since a given run may evaluate several distinct conditions.

Common Use Cases and Queries

The primary use case is post-patch troubleshooting: determining which conditions adpatch checked during a failed or skipped patch, and what values it required. A typical reporting query joins the condition history back to the patch run:

• List all conditions evaluated for a given run: SELECT COND_TE_NAME, COND_TE_LEVEL, CONDITION, REQUIRED_LEVEL FROM AD_PATCH_COND_HISTORY WHERE PATCH_RUN_ID = :run_id;
• Identify runs where a specific trackable entity was constrained: SELECT PATCH_RUN_ID, CONDITION, REQUIRED_LEVEL FROM AD_PATCH_COND_HISTORY WHERE TRACKABLE_ENTITY_ABBR = 'TECHSTACK';
• Trace a patch's condition history chronologically by joining AD_PATCH_RUNS on PATCH_RUN_ID to retrieve patch name, start time, and status alongside each condition.

These queries support DBA audits of patch execution, root-cause analysis of conditional prerequisite failures, and verification that required technology stack levels were present before patching.

Related Objects

• AD_PATCH_RUNS — Direct parent via AD_PATCH_COND_HISTORY.PATCH_RUN_ID = AD_PATCH_RUNS.PATCH_RUN_ID; supplies patch name, timing, and run status.
• AD_PATCH_DRIVER_FILES — Related patch execution metadata; useful for correlating driver-level activity with condition checks.
• AD_PATCH_RUN_BUGS — Records bug fixes applied in the same run, often reviewed alongside condition history.
• AD_APPLIED_PATCHES — Registry of successfully applied patches; used to confirm whether conditioned patches ultimately landed.
• AD_TRACKABLE_ENTITIES — Defines the trackable entities referenced by TRACKABLE_ENTITY_ABBR and REQUIRED_TE_ABBR.
• AD_PATCH_CONDITIONS — Stores the defined conditions that the history table records results against.