Search Results ad_patch_hist_snaps_temp

Overview

AD_PATCH_HIST_SNAPS_TEMP is a temporary staging table owned by the APPLSYS schema within the Applications DBA (AD) product of Oracle E-Business Suite. It is documented as a transient work area used during the process of updating patch history snapshots. In EBS 12.1.1 and 12.2.2, the AD utilities — adpatch, adop, and the AutoPatch driver infrastructure — maintain a history of every patch applied to the instance. When a patch run is recorded, the corresponding file-level and bug-level detail must be aggregated into snapshot structures. Rather than insert those rows directly into the permanent snapshot tables, AutoPatch stages the intermediate results in AD_PATCH_HIST_SNAPS_TEMP, validates them, and then merges them into the final history tables.

The object is application-managed and has no user-facing maintenance interface. Under a heuristic Data Vault classification derived from its foreign-key structure, the table would model as a link candidate, since it associates patch runs, bugs, files, and file versions via multiple foreign keys rather than acting as an independent hub or a pure descriptive satellite.

Because the contents are staging data, rows are typically truncated or reused between patch cycles. Persistence is not guaranteed, and any query against this table outside an active patch operation is likely to return incomplete or stale results.

Key Information Stored

The 22 documented columns describe a row at the level of "a file action taken by a patch run against a particular bug." The most significant are:

• PATCH_RUN_ID — foreign key to AD_PATCH_RUNS; identifies the AutoPatch run that produced the row.
• BUG_ID — foreign key to AD_BUGS; the patch or bug number that drove the file change.
• FILE_ID — internal identifier of the file within the AD file inventory.
• FILE_VERSION_ID — foreign key to AD_FILE_VERSIONS; the specific version of the patched file.
• APP_SHORT_NAME and FILENAME — human-readable application and file identity, useful for ad hoc reporting without joining the file tables.
• ACTION_CODE — the operation performed (typically copy, generate, link, or similar AutoPatch action).
• VERSION_SEGMENT1 through VERSION_SEGMENT10 — the ten-part file version string, decomposed for comparison and sorting.
• TRANSLATION_LEVEL — the language/translation context of the file.
• CLIB_ARCH_FILE_ID and DEST_FILE_ID — source archive and destination file references.
• FILE_TYPE_FLAG and IREP_GATHERED_FLAG — classification and status indicators.

The metadata does not document a surrogate primary key column; the table is a staging construct whose natural key is the combination of PATCH_RUN_ID, BUG_ID, and FILE_ID for a given run.

Common Use Cases and Queries

Typical uses are diagnostic and investigative rather than reporting-oriented. DBAs inspect this table during a failed or partially applied patch to determine which files were staged before the process aborted.

• Correlating files changed by a specific patch run:

  SELECT app_short_name, filename, action_code
  FROM   applsys.ad_patch_hist_snaps_temp
  WHERE  patch_run_id = :run_id;

• Finding all staged files tied to a bug number:

  SELECT b.bug_number, t.filename, t.file_version_id
  FROM   applsys.ad_patch_hist_snaps_temp t,
         applsys.ad_bugs b
  WHERE  t.bug_id = b.bug_id;

• Verifying a patch's file footprint before the snapshot is committed, by joining to AD_FILE_VERSIONS for version metadata.
• Clearing residual rows after a failed run so that the next AutoPatch invocation starts clean.

Related Objects

The foreign keys in this staging table identify its principal dependencies:

• AD_PATCH_RUNS — joined on PATCH_RUN_ID; the parent record of each patch execution.
• AD_BUGS — joined on BUG_ID; the bug or patch identity list.
• AD_FILE_VERSIONS — joined on FILE_VERSION_ID; version control detail for patched files.
• AD_FILES — referenced indirectly via FILE_ID for the file inventory.
• AD_PATCH_HIST_SNAPS — the permanent snapshot target that this temporary table feeds.
• AD_PATCH_DRIVERS and AD_APPLIED_PATCHES — companion AD tables describing driver and applied-patch context, useful when correlating a staging row back to the patch that produced it.

No published PL/SQL API is documented for direct manipulation; access is strictly through the AD utilities.