Search Results delete_processed_units

Overview

APPS.AD_PARALLEL_UPDATES_PKG is a core Oracle E-Business Suite Applications DBA (AD) utility package that provides the parallel processing engine used by AutoPatch, AD Merge Patch, and other AD utilities to apply data changes to large tables concurrently. Rather than updating a target table in a single serial transaction, the package partitions the affected rows into work units that are distributed across multiple parallel workers, allowing the same UPDATE or migration script to execute simultaneously against disjoint row sets. This dramatically reduces the elapsed time required for upgrades, patch application, and table reorganization on high-volume tables.

The package is declared AUTHID CURRENT_USER, so executing privileges are evaluated against the invoker's schema rather than the APPS schema owner. It is a low-level infrastructure package: it is referenced by 55 other packages and is not intended for direct end-user or functional use. The header revision string ($Header: adprupds.pls 120.2.12010000.1) confirms the shipped file is unchanged between the 12.1.1 and 12.2.2 releases, so behavior is consistent across both code lines.

Key Procedures and Functions

The package exposes eleven documented entry points, organized around the lifecycle of a parallel update job.

• INITIALIZE_ROWID_RANGE — Sets up a parallel update job whose units are defined by ranges of ROWIDs. It supports both a variant that accepts an explicit processed-row mode (PRESERVE_PROCESSED_UNITS or DELETE_PROCESSED_UNITS) and a simpler overload that defaults that behavior. Constants ROWID_RANGE, ID_RANGE_BY_ROWID, and ID_RANGE select the partitioning strategy.
• INITIALIZE_ID_RANGE — Establishes a job whose units are defined by numeric ID ranges (optionally with sub-ranges and custom SQL). Constants such as ID_RANGE_SUB_RANGE, ID_RANGE_SUB_RANGE_SQL, and ID_RANGE_SCAN_EQUI_ROWSETS drive the variant selected. Optional parameters allow a custom SQL statement and explicit begin/end ID bounds.
• PROCESSED_ROWID_RANGE — Records progress for a worker that has processed a batch of ROWID-based units, tracking the count and the last ROWID handled so the next batch can resume.
• PROCESSED_ID_RANGE — The ID-range equivalent of the above, marking ID-based units as processed.
• GET_ROWID_RANGE_WRAPPER — A convenience wrapper that retrieves the next ROWID range for a worker, abstracting the underlying range computation.
• GET_ROWID_RANGE — Core function returning the next batch of ROWIDs to process for a given worker.
• GET_ID_RANGE — Core function returning the next ID range to process for a given worker.
• PURGE_PROCESSED_UNITS — Removes or marks completed work units, depending on the processed mode selected at initialization.
• DELETE_UPDATE_INFORMATION — Cleans up the AD_PARALLEL_UPDATES control rows for a completed update job, removing residual job metadata so the tables do not accumulate stale entries. This is the routine users typically inquire about when searching for "delete_update_information."
• REINITIALIZE_AFTER_TABLE_REORG — Resets internal range information after a table has been reorganized (for example, an export/import or ALTER TABLE MOVE), so subsequent range calculations remain valid.

Tables Accessed

• AD_PARALLEL_UPDATES — The master control table holding job definitions, update type, and process mode.
• AD_PARALLEL_UPDATES_S — The sequence/status companion to the master table.
• AD_PARALLEL_UPDATE_UNITS — Stores the individual work units (ROWID or ID ranges) and their processed state.
• AD_PARALLEL_WORKERS — Tracks each parallel worker, its assigned units, and progress.
• DBMS_LOCK, DBMS_ROWID, DBMS_SYSTEM, V$SESSION — Used for worker synchronization, ROWID manipulation, session control, and monitoring active sessions respectively.

Usage Notes

AD_PARALLEL_UPDATES_PKG is invoked almost exclusively by AD utilities and the parallel update driver scripts—AutoPatch, AD Merge Patch, and table reorganization routines—rather than by Oracle Forms or standard concurrent programs. Functional developers rarely call it directly; when they do, it is within custom patch or data-migration scripts that must update very large tables in parallel and that already presume the AD parallel infrastructure (worker rows, control tables) is present.

Timing: initialize methods are called once at the start of a job, GET_* routines are called repeatedly by each worker to claim the next range, PROCESSED_* routines commit progress, and PURGE_PROCESSED_UNITS or DELETE_UPDATE_INFORMATION is called at completion to clear control data. Any custom usage should respect the constant update-type and processed-mode values, and should assume the package is not reentrant across unrelated jobs. Because privileges are evaluated as CURRENT_USER, the invoking schema must own or have appropriate synonyms to the AD tables.