Search Results ad_patch_hist_temp




Overview
Explore in AI Chat

Overview

AD_PATCH_HIST_TEMP, owned by the APPLSYS schema, is a temporary staging table used by the Oracle Applications DBA (AD) product to record patch-history information during patch application and maintenance operations. It functions as a transient repository into which the AutoPatch and AD utilities write row-level patch file and bug data before that data is validated, transformed, and ultimately persisted to the permanent patch-history tables. Its presence is significant because it isolates in-progress or intermediate patch metadata from the authoritative history records, allowing failed or aborted patching sessions to be discarded without corrupting the master history.

The table is documented as VALID and contains 81 columns in the ETRM 12.2.2 physical schema. The same definition and staging role applies across Oracle EBS 12.1.1 and 12.2.2, where AD utilities such as AutoPatch (adpatch) and its supporting workers interact with the table on every patching cycle. Because the object is explicitly labeled temporary in purpose, its rows carry a short operational lifespan and are typically purged or overwritten as each patch run completes. The heuristic Data Vault classification mined from the foreign-key structure is standalone, meaning the table is not best modeled as a hub, link, or satellite within a Data Vault representation; it should be treated as a transient operational buffer rather than a durable modeled entity.

Key Information Stored

The most operationally important columns fall into three logical groups: patch identity, file/version comparison, and action execution.

No surrogate primary key is documented for this staging table; the combination of PATCH_RUN_ID, BUG_ID, and FILE_ID (or PATCH_RUN_BUG_ID and FILENAME) behaves as the effective business-key candidate for correlating a given file action to a run.

Common Use Cases and Queries

Typical use cases center on troubleshooting, reconciliation, and pre-migration verification. DBAs query AD_PATCH_HIST_TEMP to confirm which files a run actually staged before they were promoted to permanent history, and to detect runs that terminated before completing staging.

  • Identify files staged for a run: SELECT patch_run_id, bug_number, filename, applied_flag, success_flag FROM ad_patch_hist_temp WHERE patch_run_id = :run_id;
  • Report files skipped with reasons: SELECT bug_number, filename, reason_not_applied FROM ad_patch_hist_temp WHERE applied_flag = 'N';
  • Correlate actions to files: join COMMON_ACTION_ID to AD_PATCH_COMMON_ACTIONS to see action code and phase per staged file.
  • Cross-check versions: compare PATCH_FILE_VERS_ID, ONSITE_FILE_VERS_ID, and DB_FILE_VERS_ID to detect version drift.
  • Purge readiness checks: because the table is a transient staging area, queries are frequently written to determine what can safely be cleared after a run completes.

Related Objects

The documented foreign keys establish the object's principal dependencies:

  • AD_PATCH_RUNS — joined on AD_PATCH_HIST_TEMP.PATCH_RUN_ID = AD_PATCH_RUNS.PATCH_RUN_ID; parent run record.
  • AD_BUGS — joined on AD_PATCH_HIST_TEMP.BUG_ID = AD_BUGS.BUG_ID; bug/patch master data.
  • AD_PATCH_RUN_BUGS — joined on AD_PATCH_HIST_TEMP.PATCH_RUN_BUG_ID = AD_PATCH_RUN_BUGS.PATCH_RUN_BUG_ID; bug-in-run association.
  • AD_PATCH_COMMON_ACTIONS — joined on AD_PATCH_HIST_TEMP.COMMON_ACTION_ID = AD_PATCH_COMMON_ACTIONS.COMMON_ACTION_ID; action definitions.
  • AD_PATCH_HIST — the permanent counterpart table into which staged rows are ultimately promoted for durable patch-history reporting.
  • AutoPatch utilities and AD Worker APIs that populate and consume this staging table during patch application.