Search Results ad_parallel_update_units




Overview
Explore in AI Chat

Overview

AD_PARALLEL_UPDATE_UNITS is a table owned by the APPLSYS schema in Oracle E-Business Suite, classified under the AD — Applications DBA product. Its documented purpose is to support the Large Table Updates framework, an internal EBS utility that decomposes high-volume UPDATE operations against very large application tables into discrete, parallelizable work units. Each row in this table represents one such unit of work, allowing the AD utilities to track, schedule, and confirm progress across multiple concurrent workers rather than executing a single monolithic UPDATE.

From a heuristic Data Vault modeling perspective, the table is classified as standalone, meaning it does not participate in a classic hub-link-satellite topology. It is best understood as a transaction/audit-style record of update progress, keyed internally and linked to a single external history table.

Key Information Stored

The table contains 13 documented columns. The unique business-key candidate is defined by the index AD_PARALLEL_UPDATE_UNITS_U1 on the combination of UPDATE_ID and UNIT_ID, which uniquely identifies each unit of work within a given update run. The most significant columns are:

  • UNIT_ID — surrogate identifier for the individual parallel work unit.
  • UPDATE_ID — foreign key to QA_RESULTS_UPDATE_HISTORY, tying the unit to its parent update run.
  • STATUS — the processing state of the unit (e.g., pending, in progress, complete).
  • RELATIVE_FNO — relative file number of the data file containing the segment.
  • START_BLOCK / END_BLOCK — the block range delimiting the unit's assigned segment region.
  • START_ID / END_ID — the row identifier range the unit is responsible for updating.
  • WORKER_ID — the parallel worker assigned to the unit, supporting concurrency tracking.
  • START_DATE / END_DATE — timestamps marking the beginning and completion of processing.
  • ROWS_PROCESSED — the number of rows affected by the unit, useful for progress and throughput reporting.
  • DATA_OBJECT_ID — the database object identifier of the target segment, supporting precise segment mapping.

Common Use Cases and Queries

This table is primarily consulted for monitoring and troubleshooting large update runs. DBAs and technical consultants query it to determine whether an update has stalled, which worker owns a given segment, and how many rows have been processed. A typical progress query aggregates processed rows per update run:

  • SELECT UPDATE_ID, STATUS, SUM(ROWS_PROCESSED) FROM APPLSYS.AD_PARALLEL_UPDATE_UNITS GROUP BY UPDATE_ID, STATUS;
  • SELECT UNIT_ID, WORKER_ID, START_DATE, END_DATE FROM APPLSYS.AD_PARALLEL_UPDATE_UNITS WHERE UPDATE_ID = :id ORDER BY UNIT_ID;
  • Identifying stalled units: SELECT * FROM ... WHERE STATUS NOT IN ('COMPLETE') AND START_DATE < SYSDATE - 1;

Reporting use cases include throughput analysis, worker utilization, and segment-level coverage verification following a failed or interrupted update.

Related Objects

The documented relationship data identifies one foreign key: QA_RESULTS_UPDATE_HISTORY, joined on UPDATE_ID. This history table records the parent update run to which each parallel unit belongs. Because the table is classified as standalone, no other FK relationships to hubs or links are documented. In practice, related framework objects include the Large Table Updates driver views and the AD worker/parallel processing utilities that populate STATUS, WORKER_ID, and ROWS_PROCESSED, while the segment-identifying columns (RELATIVE_FNO, DATA_OBJECT_ID, START_BLOCK, END_BLOCK) relate conceptually to DBA_EXTENTS and DBA_SEGMENTS for physical block mapping.