Search Results ad_parallel_workers

Overview

AD_PARALLEL_WORKERS is a table owned by the APPLSYS schema in Oracle E-Business Suite, classified under the AD — Applications DBA product. It exists to support the Large Table Updates framework, an internal Oracle Applications DBA utility that partitions and parallelizes bulk data manipulation against very large tables. Because operations such as patching, seed data refresh, and mass migrations can involve millions of rows, the framework splits the target work into disjoint ranges and dispatches each range to a concurrent worker. AD_PARALLEL_WORKERS is the bookkeeping table that records which worker process was assigned which range, when it started, when it finished, and how many rows it processed.

The table is documented as standalone from a data-vault perspective, meaning the mined foreign-key structure does not suggest clear hub, link, or satellite groupings; the classification should be read as a modeling suggestion rather than a definitive architectural statement. The single documented foreign key, UPDATE_ID → QA_RESULTS_UPDATE_HISTORY, ties each worker row to the overall update run it belongs to, which effectively makes AD_PARALLEL_WORKERS an activity/child table for the Large Table Updates framework.

Key Information Stored

The documented physical schema for 12.2.2 exposes 11 columns:

• WORKER_ID — identifier of the individual parallel worker; combined with UPDATE_ID it forms the business-key candidate.
• UPDATE_ID — the parent update run identifier, foreign key to QA_RESULTS_UPDATE_HISTORY.
• START_UNIT_ID / END_UNIT_ID — the unit-level boundaries (e.g., a logical partition or chunk of the target table) the worker is responsible for.
• START_ROWID / END_ROWID — the physical row identifier boundaries defining the worker's assigned slice of the table.
• START_ID / END_ID — the numeric or surrogate ID boundaries for the range the worker processes, where the target table is keyed on a numeric column.
• ROWS_PROCESSED — count of rows affected by that worker, used for progress monitoring and reconciliation.
• SESSION_ID / SESSION_SERIAL_NO — the Oracle session and serial number of the worker, enabling DBAs to correlate the table row with an active or historical v$session entry for troubleshooting.

The surrogate primary key is not separately documented, but the unique index AD_PARALLEL_WORKERS_U1 on (UPDATE_ID, WORKER_ID) is the official business-key candidate. Practically, this also serves as the composite primary identifier for each worker assignment within a run.

Common Use Cases and Queries

DBAs and developers use this table primarily to monitor progress and diagnose failures of large table updates. A typical query joins back to the parent run:

• Current run status — SELECT w.worker_id, w.rows_processed, w.start_rowid, w.end_rowid FROM ad_parallel_workers w WHERE w.update_id = :update_id ORDER BY w.worker_id;
• Throughput check — aggregate ROWS_PROCESSED per worker and compare against the total target table row count to estimate completion.
• Session correlation — join SESSION_ID and SESSION_SERIAL_NO to v$session to identify long-running or stuck workers.
• Failure triage — inspect START_UNIT_ID/END_UNIT_ID and START_ID/END_ID to determine which specific range was not completed when a run aborted.
• Historical reporting — track run duration and worker counts across patch cycles to size parallel degree for future updates.

Related Objects

• QA_RESULTS_UPDATE_HISTORY — parent of AD_PARALLEL_WORKERS via UPDATE_ID; holds metadata about each Large Table Updates run.
• AD_PARALLEL_WORKERS_U1 — unique index defining the business key (UPDATE_ID, WORKER_ID).
• APPLSYS schema — owning schema containing the table and its indexes.
• V$SESSION — dynamic performance view joined on SESSION_ID and SESSION_SERIAL_NO for live worker monitoring.
• AD Parallel / Large Table Updates framework packages — internal APIs that insert and update AD_PARALLEL_WORKERS rows as workers are dispatched and complete.
• FND_CONCURRENT_REQUESTS — concurrent request records that often drive the parent update run and provide timing context.