Results for “purge_batch_id”

50+ results




Overview
Explore in AI Chat

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

Overview

PA_PURGE_PRJ_DETAILS is a transactional audit table in the Oracle Projects (PA) module of Oracle E-Business Suite, owned by the PA schema. It records the outcome of a project purge batch — that is, the row-count statistics describing how many records were physically purged and how many were archived for each project and each underlying database table processed during a purge run. It functions as the granular, per-project, per-table counterpart to the summarized header information held in PA_PURGE_BATCHES_ALL.

From the perspective of a heuristic Data Vault classification, the FK structure indicates a standalone table: it references PA_PURGE_BATCHES_ALL but is not itself referenced by any other object. This suggests it is best modeled as a satellite hanging off the purge-batch hub, capturing descriptive and measurable attributes (record counts) qualified by project and table name. The combination of PURGE_BATCH_ID, PROJECT_ID, and TABLE_NAME behaves as a natural composite business key, making the table effectively an auditable fact-style satellite for purge execution statistics.

Key Information Stored

The table contains 14 documented columns. The columns of primary functional interest are:

  • PURGE_BATCH_ID — Foreign key to PA_PURGE_BATCHES_ALL, identifying the specific purge batch execution that produced these statistics.
  • PROJECT_ID — The project whose records were purged or archived within that batch.
  • TABLE_NAME — The name of the underlying database table whose rows were processed (for example, project-related transactional tables).
  • NUM_RECS_PURGED — Count of records physically deleted.
  • NUM_RECS_ARCHIVED — Count of records archived rather than deleted.
  • REQUEST_ID — Concurrent program request that initiated the purge.
  • PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Standard concurrent program context identifying the executable and its last update.
  • CREATED_BY, CREATION_DATE, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard WHO audit columns recording user and timestamp of row creation and last modification.

The unique index PA_PURGE_PRJ_DETAILS_U1 spans (PURGE_BATCH_ID, PROJECT_ID, TABLE_NAME), confirming that this triplet is the documented business-key candidate and enforcing one statistical row per project/table combination per batch. No separate surrogate primary key is documented; the table is keyed on the composite unique index.

Common Use Cases and Queries

Typical uses include auditing a purge run, verifying how many rows were removed versus archived, and reconciling purge volume against the batch header.

  • Batch-level reconciliation: join to PA_PURGE_BATCHES_ALL on PURGE_BATCH_ID to compare summarized vs. per-table counts: SELECT d.TABLE_NAME, SUM(d.NUM_RECS_PURGED), SUM(d.NUM_RECS_ARCHIVED) FROM PA_PURGE_PRJ_DETAILS d WHERE d.PURGE_BATCH_ID = :batch_id GROUP BY d.TABLE_NAME;
  • Per-project purge audit: list all tables processed for a given project: SELECT TABLE_NAME, NUM_RECS_PURGED, NUM_RECS_ARCHIVED FROM PA_PURGE_PRJ_DETAILS WHERE PROJECT_ID = :project_id ORDER BY TABLE_NAME;
  • Trend reporting: aggregate archived vs. purged totals by CREATION_DATE or REQUEST_ID to monitor purge activity over time.
  • Compliance evidence: demonstrate that specific historical records for named projects were archived prior to purging.

Related Objects