Search Results ad_snapshots




Overview
Explore in AI Chat

Overview

The AD_SNAPSHOTS table is a core repository table within the Oracle E-Business Suite (EBS) Applications DBA (AD) module. It serves as the master registry for file-system snapshots, which are critical records of the state of an application's file system at a specific point in time. These snapshots are integral to the patching and maintenance infrastructure of Oracle EBS, particularly for the AutoPatch (adpatch) utility. They provide a mechanism to track changes, enable rollback capabilities, and maintain a historical audit trail of modifications made to the application's code and configuration files during patching cycles. The table is owned by the APPLSYS schema and is a validated, active object in both EBS 12.1.1 and 12.2.2.

Key Information Stored

The table's primary key is SNAPSHOT_ID, a unique identifier for each snapshot record. As indicated by its foreign key relationships, the table stores essential contextual metadata linking each snapshot to its specific environment. The APPL_TOP_ID column references AD_APPL_TOPS, tying the snapshot to a particular APPL_TOP file system. The RELEASE_ID column references AD_RELEASES, associating the snapshot with a specific EBS release level. While the full column list is not detailed in the provided metadata, typical data would include timestamps for snapshot creation, a snapshot name or description, the type of snapshot (e.g., pre-patch, post-patch), and status information. This structure allows administrators to query exactly what the file system state was for a given APPL_TOP at a given release.

Common Use Cases and Queries

The primary use case is auditing and troubleshooting the patching process. Before applying a patch, AutoPatch may create a "pre-patch" snapshot, and after completion, a "post-patch" snapshot. Database administrators can query this history to understand the sequence of applied changes. A common reporting query would list all snapshots for a specific APPL_TOP, ordered chronologically. For instance:

  • SELECT snapshot_id, creation_date, snapshot_type FROM applsys.ad_snapshots WHERE appl_top_id = (SELECT appl_top_id FROM ad_appl_tops WHERE name = 'MY_APPL_TOP') ORDER BY creation_date;

Another critical scenario involves dependency analysis before a patch rollback, where the system references snapshot data to determine which files need to be reverted. Queries joining AD_SNAPSHOTS to its child tables, AD_SNAPSHOT_FILES and AD_SNAPSHOT_BUGFIXES, are used to generate detailed manifests of changed files and associated bug fixes captured in each snapshot.

Related Objects

The AD_SNAPSHOTS table sits at the center of a relational model for snapshot management. It has defined foreign key relationships with several other AD tables. It references parent tables AD_APPL_TOPS and AD_RELEASES for environmental context. It is referenced as a parent by the detail tables AD_SNAPSHOT_FILES, which stores the individual files captured in each snapshot, and AD_SNAPSHOT_BUGFIXES, which links snapshots to specific bug fixes or patches. This design ensures data integrity, where a snapshot record must be associated with a valid APPL_TOP and release, and where detailed file and bug records cannot exist without a master snapshot entry.