Search Results ad_parallel_updates_u1




Overview

APPLSYS.AD_PARALLEL_UPDATES is a control and tracking table used by the Oracle E-Business Suite Applications DBA (AD) utilities to coordinate parallel update operations against application tables. Each row in the table corresponds to a single parallel script execution, and the ETRM dependency metadata documents the table with the comment "One row per parallel script." The object resides in the APPLSYS schema, is marked VALID, and is stored in the APPS_TS_INTERFACE tablespace — an interface-oriented storage area that reflects its role as a transient coordination structure rather than a persistent transactional entity.

The table supports the worker-based update mechanism in which the AD parallel processing framework divides work across multiple concurrent workers. Columns such as OBJECT_ID, DB_BLOCK_SIZE, AVG_ROW_LEN, ID_COLUMN, and NUM_WORKERS capture the physical and structural characteristics of the target table so the framework can compute appropriate chunk sizes and worker counts. INITIALIZED_FLAG records whether a given table has already been prepared for processing. From a heuristic Data Vault modeling perspective, this object is classified as standalone, meaning it functions as an independent hub-like registry of parallel update jobs rather than participating in a broader link or satellite network. It is referenced by the APPS synonym AD_PARALLEL_UPDATES, which provides the standard APPS-layer access path.

Key Information Stored

The table contains twelve documented columns. The most significant are:

  • UPDATE_ID — A sequence-generated numeric identifier for each parallel update row. This is the surrogate primary key and is enforced by unique index AD_PARALLEL_UPDATES_U1.
  • UPDATE_TYPE — A numeric code describing the category of parallel update being performed.
  • OWNER — The schema (VARCHAR2(30)) that owns the table targeted for update.
  • TABLE_NAME — The name of the table being processed (VARCHAR2(30)).
  • SCRIPT_NAME — The name of the script executing the update (VARCHAR2(30)). Together, OWNER, TABLE_NAME, and SCRIPT_NAME form the second business-key candidate, enforced by unique index AD_PARALLEL_UPDATES_U2.
  • OBJECT_ID — The Oracle dictionary object number for the target table, sourced from sys.obj$.
  • DB_BLOCK_SIZE — Database block size in bytes, used for sizing calculations.
  • ID_COLUMN — The column in the target table that holds unique identifiers, used for range partitioning of work.
  • AVG_ROW_LEN — Average row length of the target table, informing chunk sizing.
  • NUM_WORKERS — The number of workers allocated to the update.
  • INITIALIZED_FLAG — Indicates whether the target table has been initialized for parallel processing.
  • CREATION_DATE — Standard who column recording when the row was created.

Common Use Cases and Queries

DBAs and support engineers query this table to diagnose parallel update behavior, verify worker allocation, and confirm which scripts have processed which tables. A typical pattern joins the registration row to the target table metadata using OBJECT_ID, or filters by script to audit recent activity:

  • Identify active parallel jobs: SELECT UPDATE_ID, SCRIPT_NAME, TABLE_NAME, NUM_WORKERS, INITIALIZED_FLAG FROM APPLSYS.AD_PARALLEL_UPDATES WHERE INITIALIZED_FLAG = 'Y';
  • Audit coverage by owner and table: SELECT OWNER, TABLE_NAME, SCRIPT_NAME, UPDATE_TYPE FROM APPLSYS.AD_PARALLEL_UPDATES ORDER BY CREATION_DATE DESC;
  • Confirm sizing parameters passed to workers: select DB_BLOCK_SIZE, AVG_ROW_LEN, ID_COLUMN for a given OBJECT_ID.

Reporting use cases include post-patch validation (confirming that expected tables were registered and processed) and capacity analysis (correlating NUM_WORKERS with table size and row length to tune future runs).

Related Objects

The metadata documents a dependency from AD_PARALLEL_UPDATES.UPDATE_ID to QA_RESULTS_UPDATE_HISTORY, indicating that update results and history are recorded in a companion table keyed by the update identifier. The primary consumers and related objects are:

  • APPS.AD_PARALLEL_UPDATES — The APPS-layer synonym through which the table is normally accessed.
  • APPLSYS.QA_RESULTS_UPDATE_HISTORY — Referenced by UPDATE_ID; stores historical outcomes of each parallel update.
  • sys.obj$ — The data dictionary source for OBJECT_ID values populated in this table.
  • The target application tables registered in OWNER/TABLE_NAME — The physical tables whose update work is coordinated by each row.
  • AD parallel processing scripts — The scripts identified in SCRIPT_NAME that create, update, and consume these rows during concurrent execution.