Results for “wait_loop_time”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

AD_SESSIONS is an Oracle E-Business Suite base table owned by the APPLSYS schema and delivered as part of the AD (Applications DBA) product family. Its documented purpose is to store information on all AD sessions for an Applications System. In practice, each row represents a single invocation of an AD administration utility—such as adpatch, adadmin, AutoConfig, or a parallel worker process—along with the runtime context and progress counters associated with that invocation. Because the table captures session identity, operating system context, APPL_TOP placement, and job-scheduling statistics, it functions as the control-plane record for long-running patching and maintenance operations, and it is frequently inspected when diagnosing stalled or orphaned AD sessions.

The ETRM metadata classifies this object heuristically as standalone under Data Vault modeling conventions. That classification indicates that AD_SESSIONS is neither a pure hub nor a pure link nor a pure satellite, but a self-contained operational state table whose identifying key (SESSION_ID) is generated by the AD utilities themselves rather than resolved from a shared business key registry. Modelers should treat it as a source for satellite-style descriptive attributes (status, timing, counters) rather than as part of a conformed dimensional backbone.

Key Information Stored

The table carries 27 documented columns in the 12.2.2 ETRM schema. The most operationally significant are:

• SESSION_ID — the surrogate primary key and sole unique business-key candidate, enforced by the unique index AD_SESSIONS_U1. It is the value referenced throughout AD log files and concurrent request output.
• UTILITY_NAME — identifies which AD utility owns the session (for example adpatch or adadmin), which determines how the remaining columns are interpreted.
• STATUS and CONTROL_CODE — the current lifecycle state of the session and the control signal applied to it (such as a request to pause or terminate).
• APPL_TOP_ID, APPL_TOP_PATH, and TOPDIR — the foreign key to AD_APPL_TOPS plus denormalized path information identifying which Applications tier the session is working against.
• RUN_ON_NODE and OS_USER_NAME — the host and operating system account executing the session, essential for multi-node deployments.
• OS_PROCESS_ID — the underlying OS process identifier, used to correlate with operating system process listings.
• INVOKDIR — the directory from which the utility was invoked.
• START_DATE, CREATION_DATE, and LAST_UPDATE_DATE — timing columns supporting duration analysis and staleness detection.
• PRIORITY and WAIT_LOOP_TIME — scheduling parameters governing how the session yields to other workers.
• JS_TOTAL_JOBS, JS_COMPLETED_JOBS, and JS_REMAINING_JOBS — aggregate job-stream counters used to estimate completion of parallel patching runs.
• JS_CURR_PHASE and the JS_JOBS_*_IN_CURR_PHASE columns — phase-level breakdowns of assigned, ready, waiting, and remaining jobs.
• CONTEXT_INFO — environment context captured at session start.
• ANY_CHANGE_WHILE_INACTIVE_FLAG and LOCKS_OVERRIDDEN_BY — concurrency and lock-override indicators used to audit conflicts between overlapping maintenance windows.

Common Use Cases and Queries

The most common operational query lists currently active AD sessions by node and status, allowing DBAs to detect sessions that have exceeded their expected duration:

• Detect stalled sessions: SELECT SESSION_ID, UTILITY_NAME, RUN_ON_NODE, START_DATE FROM AD_SESSIONS WHERE STATUS NOT IN ('C','X') ORDER BY START_DATE;
• Correlate with the OS: join OS_PROCESS_ID to the operating system process tree to confirm a session's worker is still alive.
• Monitor patch progress: compare JS_COMPLETED_JOBS against JS_TOTAL_JOBS and use JS_CURR_PHASE to report phase completion percentages.
• Audit parallel worker distribution: group by RUN_ON_NODE to confirm that workers are spread as intended across APPL_TOPs.
• Clean up orphaned records: identify rows with old LAST_UPDATE_DATE values where no corresponding OS process exists.

The SESSION_ID is also useful as a correlation key when reconciling AD log files (adpatch*.log, adwork*.log) against database state, since the utility writes the same identifier into both the log and this table.

Related Objects

• AD_APPL_TOPS — referenced through the documented foreign key AD_SESSIONS.APPL_TOP_ID → AD_APPL_TOPS, providing the APPL_TOP definition for each session.
• AD_TASK_INSTANCES / AD_WORKER_JOBS — child job records that expand the JS_* counter columns into per-job detail for a given SESSION_ID.
• AD_PATCH_DRIVERS and AD_PATCH_RUNS — patching records whose executions are tracked by nested AD sessions.
• FND_CONCURRENT_REQUESTS — concurrent manager requests often spawned by or alongside AD utilities; useful for cross-referencing long-running maintenance activity.
• FND_NODES — the node registry joined on RUN_ON_NODE for host-level reporting.

These objects should be treated as the primary join targets when building operational dashboards or troubleshooting scripts around AD_SESSIONS.