Search Results ad_patch_run_bug_actions




Overview
Explore in AI Chat

Overview

The AD_PATCH_RUN_BUG_ACTIONS table is a core repository table within the Oracle E-Business Suite Applications DBA (AD) module. It functions as a detailed log of the individual file-level actions performed by a specific bug fix during an Oracle Applications patch run. This table is critical for the patching infrastructure, as it records the precise operations (e.g., copy, link, generate) executed on database objects and application files. It provides the granular audit trail that links a high-level bug fix, recorded in AD_PATCH_RUN_BUGS, to the concrete changes applied to the EBS file system and database, enabling troubleshooting, validation, and impact analysis of applied patches.

Key Information Stored

The table's primary purpose is to store the relationship between a bug fix in a patch run and the actions it executes. Its key columns, as defined by its foreign key relationships, establish these critical links. The ACTION_ID column serves as the unique primary key for each recorded action. The PATCH_RUN_BUG_ID column is a foreign key to AD_PATCH_RUN_BUGS, tethering each action to its parent bug fix within a specific patch driver execution. The COMMON_ACTION_ID foreign key to AD_PATCH_COMMON_ACTIONS categorizes the type of operation performed. Crucially, the table links to file and version metadata via the FILE_ID (to AD_FILES) and multiple AD_FILE_VERSIONS foreign keys (PATCH_FILE_VERSION_ID, ONSITE_FILE_VERSION_ID, ONSITE_PKG_VERSION_IN_DB_ID), documenting the specific file versions involved in the action from both the patch and the target system.

Common Use Cases and Queries

This table is primarily queried for diagnostic and audit reporting following patch applications. Database administrators use it to investigate failed patches, verify file updates, and understand the scope of a fix. A common query involves joining to AD_PATCH_RUN_BUGS and AD_FILES to list all files touched by a particular bug number in a recent patch run. Another standard use case is validating that a file was updated to the correct version by comparing the PATCH_FILE_VERSION_ID with the ONSITE_FILE_VERSION_ID. Sample SQL often follows this pattern:

  • Identifying actions for a specific bug: SELECT * FROM APPLSYS.AD_PATCH_RUN_BUG_ACTIONS WHERE PATCH_RUN_BUG_ID = (SELECT PATCH_RUN_BUG_ID FROM APPLSYS.AD_PATCH_RUN_BUGS WHERE BUG_NUMBER = '12345678');
  • Reporting all file changes from a patch run: SELECT b.BUG_NUMBER, f.FILE_NAME, a.* FROM AD_PATCH_RUN_BUG_ACTIONS a, AD_PATCH_RUN_BUGS b, AD_FILES f WHERE a.PATCH_RUN_BUG_ID = b.PATCH_RUN_BUG_ID AND a.FILE_ID = f.FILE_ID AND b.PATCH_RUN_ID = &run_id;

Related Objects

The AD_PATCH_RUN_BUG_ACTIONS table is a central node in the AD patching schema, with documented foreign key relationships to several key metadata tables. It is a child of the AD_PATCH_RUN_BUGS table via the PATCH_RUN_BUG_ID column. It references the AD_PATCH_COMMON_ACTIONS table via COMMON_ACTION_ID to define the action type. Its connections to file management tables are extensive: it links to the AD_FILES base table via FILE_ID and maintains three separate relationships with the AD_FILE_VERSIONS table to track the version of the file in the patch (PATCH_FILE_VERSION_ID), the version on the target system before the action (ONSITE_FILE_VERSION_ID), and the version of a related database package (ONSITE_PKG_VERSION_IN_DB_ID). These relationships collectively provide a complete technical history of a patch action.