Results for “imported_id”

24 results




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

Overview

AD_PATCH_RUNS is a table owned by the APPLSYS schema within the Applications DBA (AD) product module of Oracle E-Business Suite. It stores high-level Autopatch history, recording exactly one row per patch driver applied to an Applications tier. In releases 12.1.1 and 12.2.2, this table functions as the central audit ledger for patching activity, capturing the release context, APPL_TOP target, driver identity, execution window, and success or failure outcome for each patch invocation. Because it isolates patch metadata from the underlying filesystem and driver definitions, it is the primary reference point for DBAs and release engineers investigating patch lineage, troubleshooting failures, or reporting compliance against applied patches.

From a dimensional modeling perspective, the foreign key topology suggests a satellite-leaning classification. AD_PATCH_RUNS hangs off AD_PATCH_DRIVERS and AD_APPL_TOPS via its OWNER-side foreign keys, and is itself referenced by several descriptor-style child tables such as AD_PATCH_RUN_BUGS and AD_PATCH_COND_HISTORY. This pattern is characteristic of a satellite attached to a driver hub rather than an independent hub, though the dependency on AD_APPL_TOPS also gives it a link-like quality connecting a driver to a specific Applications tier.

Key Information Stored

The table contains 29 documented columns. The surrogate primary key is PATCH_RUN_ID, enforced by the unique index AD_PATCH_RUNS_PK and the redundant unique index AD_PATCH_RUNS_U1. A second unique index, AD_PATCH_RUNS_U2, spans START_DATE, APPL_TOP_ID, and PATCH_DRIVER_ID, and serves as the principal business-key candidate — it guarantees that a given driver is not recorded twice against the same APPL_TOP at the same start time.

Common Use Cases and Queries

Patch administrators query this table to reconstruct the Autopatch timeline for an environment, verify whether a driver succeeded, and correlate failures with downstream objects.

  • Recent patch history for an APPL_TOP: SELECT patch_run_id, patch_driver_id, start_date, end_date, success_flag FROM ad_patch_runs WHERE appl_top_id = :x ORDER BY start_date DESC;
  • Failure analysis: filter success_flag = 'N' and inspect FAILURE_COMMENTS to categorize root causes.
  • Release-migration reporting: join RELEASE_ID and UPDATED_TO_RELEASE_ID to AD_RELEASES to track upgrade progression.
  • Driver-to-bug reconciliation: join PATCH_RUN_ID to AD_PATCH_RUN_BUGS to list bugs delivered per driver run.
  • Duplicate-detection audits: use the AD_PATCH_RUNS_U2 key columns to confirm no overlapping driver runs occurred on a tier.

Related Objects

  • AD_PATCH_DRIVERS — parent hub of driver definitions via AD_PATCH_RUNS.PATCH_DRIVER_ID.
  • AD_APPL_TOPS — target Applications tier via APPL_TOP_ID.
  • AD_RELEASES — referenced twice, through RELEASE_ID and UPDATED_TO_RELEASE_ID.
  • AD_PATCH_RUN_BUGS — child table listing bugs per run via PATCH_RUN_ID.
  • AD_FIXED_ISSUES — child table mapping fixed issues to a run.
  • AD_PATCH_COND_HISTORY — conditional patch evaluation history keyed by PATCH_RUN_ID.
  • AD_TE_LEVEL_HISTORY — tablespace/edition level changes attributed to a run.
  • AD_PATCH_HIST_TEMP / AD_PATCH_HIST_SNAPS_TEMP — staging tables used during patch history import and snapshot creation, all correlated by PATCH_RUN_ID.