Search Results ad_parallel_updates




Overview
Explore in AI Chat

Overview

AD_PARALLEL_UPDATES is an Applications DBA (AD) product table owned by the APPLSYS schema and classified as VALID in Oracle E-Business Suite releases 12.1.1 and 12.2.2. Its documented purpose is to serve as the control and coordination table for the Large Table Updates framework, the AutoPatch-adjacent mechanism that Oracle uses to apply high-volume data corrections (such as seeded row updates, data fixes, or bulk transformations against large transactional tables) in a parallelized manner. Rather than executing a single serial UPDATE across millions of rows, the framework divides the affected row set into ranges and dispatches concurrent workers, with AD_PARALLEL_UPDATES persisting the definition, physical characteristics, and initialization state of each parallelizable update unit.

The ETRM relationship metadata classifies this object heuristically as standalone, meaning no dependent foreign keys fan out from it and no parent joins into it beyond a single optional linkage. In Data Vault modeling terms, this suggests treating AD_PARALLEL_UPDATES as a hub-like reference table for update executions rather than a link or satellite, because it holds one durable business key per update definition and carries descriptive attributes directly on the same row. The heuristic should be regarded as a modeling suggestion rather than a normative rule, since the table is an operational control structure rather than an analytical fact source.

Key Information Stored

The table exposes 12 documented columns. The surrogate primary identifier is UPDATE_ID, enforced by unique index AD_PARALLEL_UPDATES_U1. A second unique index, AD_PARALLEL_UPDATES_U2, spans OWNER, TABLE_NAME, and SCRIPT_NAME, establishing the natural business key that uniquely identifies a given update script applied against a given table in a given schema.

  • UPDATE_ID — surrogate key and foreign key to QA_RESULTS_UPDATE_HISTORY; the join spine linking a control row to its execution history.
  • UPDATE_TYPE — categorizes the nature of the parallel update operation.
  • OWNER, TABLE_NAME, SCRIPT_NAME — the business-key triple identifying which schema, which target table, and which SQL script define the update.
  • OBJECT_ID — dictionary object identifier for the target table, useful for resolving metadata without string matching.
  • DB_BLOCK_SIZE — block size of the tablespace holding the target, used by the framework to size row ranges.
  • AVG_ROW_LEN — average row length statistics, informing range partitioning and worker chunk sizing.
  • ID_COLUMN — names the driving numeric column used to split the row set into contiguous worker ranges.
  • NUM_WORKERS — degree of parallelism, i.e. how many concurrent workers the framework should spawn.
  • INITIALIZED_FLAG — indicates whether the update has been prepared and chunked, and is ready for execution.
  • CREATION_DATE — timestamp when the control row was registered.

Common Use Cases and Queries

DBAs consult this table when diagnosing why a Large Table Updates run stalled, was unevenly distributed across workers, or left rows unconverted. Typical queries inspect uninitialized or low-parallelism definitions:

  • Locate pending work: SELECT UPDATE_ID, OWNER, TABLE_NAME, SCRIPT_NAME FROM AD_PARALLEL_UPDATES WHERE INITIALIZED_FLAG = 'N';
  • Review parallelism settings for a target: SELECT SCRIPT_NAME, NUM_WORKERS, AVG_ROW_LEN, DB_BLOCK_SIZE FROM AD_PARALLEL_UPDATES WHERE TABLE_NAME = :table_name;
  • Join to execution history to confirm completion: SELECT p.UPDATE_ID, p.SCRIPT_NAME, h.STATUS FROM AD_PARALLEL_UPDATES p, QA_RESULTS_UPDATE_HISTORY h WHERE p.UPDATE_ID = h.UPDATE_ID;
  • Confirm the driving key chosen for range splitting via ID_COLUMN before tuning NUM_WORKERS upward for very large tables.

Related Objects

  • QA_RESULTS_UPDATE_HISTORY — referenced through AD_PARALLEL_UPDATES.UPDATE_ID; holds per-execution results consumed by the parallel update framework.
  • AD_PARALLEL_UPDATES_U1 and AD_PARALLEL_UPDATES_U2 — the unique indexes enforcing the surrogate and business keys respectively.
  • AD_APPLIED_PATCHES / AD_PATCH_DRIVER_FILES — patch driver context in which Large Table Updates scripts are typically invoked.
  • DBA_TABLES and DBA_TAB_STATISTICS — dictionary views supplying OBJECT_ID, AVG_ROW_LEN, and DB_BLOCK_SIZE equivalents for verification.