V$SESSION: SID 892, 901 REQUEST=6, EVENT=enq: TX - row lock contention
Top SQL by elapsed time/CPU/IO, active and blocking sessions, current lock contention, buffer cache hit ratio, redo log switches, tablespace usage, and top database wait events.
Oracle EBS database performance degradation manifests as slow page response, concurrent program timeouts, and lock wait events that are invisible to the application layer but fully visible in Oracle's V$ dynamic performance views. When the Oracle DBA team is not embedded in the support engagement, the Oracle EBS consultant is often the first to identify database-level root causes by reading the V$ views that are accessible from an application schema connection — V$SESSION, V$SQL, V$LOCK, V$WAIT_STAT, and V$SYSSTAT — and interpreting what they reveal about the database workload.
Blocking sessions are the most operationally impactful database performance issue in Oracle EBS. A blocking session holds an exclusive lock on a row or table that another session is waiting to modify. The blocked session is suspended and cannot complete until the blocker either commits or is killed. In Oracle EBS, the most common blocking scenario is a concurrent program that holds a lock on FND_CONCURRENT_REQUESTS or on an application table row, blocking both other concurrent programs and end-user transactions from completing. SYS-03 identifies blocking chains — the root blocker, all blocked sessions, and the SQL they were executing at the moment of the snapshot.
Top SQL by buffer gets (logical reads) and elapsed time are the second major diagnostic target. A single poorly-performing SQL statement executing thousands of times per hour can saturate the buffer cache and force physical disk reads for all other sessions. SYS-03 captures the top 10 SQL statements by buffer gets and by elapsed time from V$SQL, with the execution plan hash value for the DBA team to analyze. This provides the application team with the specific SQL and its source module before escalating to the DBA for execution plan analysis.
SYS-03 provides a read-only Oracle EBS database performance snapshot — no DML, no schema changes, no index creation — using only V$ views accessible from an application schema. The output is a structured diagnostic snapshot that the consultant can hand to the DBA team with specific SQL, session IDs, and wait event names to investigate.
SYS-03 systematically investigates every major condition that can cause the issue this diagnostic targets. Below is the complete coverage breakdown.
Representative output showing the diagnostic running against a real-world scenario. The script identifies every condition, states the root cause, and generates the fix.
════════════════════════════════════════════════════════════
ORACLE EBS R12 — DATABASE PERFORMANCE SNAPSHOT
════════════════════════════════════════════════════════════
Environment : PROD
Snapshot Date : 25-FEB-2026 10:44:18
Case Number : SYS-504180
════════════════════════════════════════════════════════════
[ SECTION 1 — BLOCKING SESSIONS ] STATUS: ✗ BLOCKING CHAIN
────────────────────────────────────────────────────────────
✗ BLOCKING CHAIN DETECTED
Blocker SID 881 : User APUSER — Validate Payables Invoices — holding 14m
Blocked SID 892 : User GLUSER — Post Journals — waiting 14m
Blocked SID 901 : User APUSER2 — Create Accounting — waiting 12m
Lock Object : AP_INVOICES_ALL — row lock on INVOICE_ID 4841022
[ SECTION 2 — TOP SQL (BUFFER GETS) ] STATUS: ⚠ HIGH LOAD
────────────────────────────────────────────────────────────
SQL_ID 7gk2a8fqm4h : 8,241,084 buffer gets — 14,882 executions ⚠
Module : SQLAP — Validate Payables Invoices
Text : SELECT * FROM AP_INVOICES_ALL WHERE ORG_ID = :b1...
[ SECTION 3 — TOP WAIT EVENTS ] STATUS: ⚠ LOCK WAITS
────────────────────────────────────────────────────────────
⚠ 'enq: TX - row lock contention' — 14m 22s total wait time
'db file sequential read' — 2m 18s — within normal range ✓
'log file sync' — 18s — healthy ✓
[ SECTION 4 — TABLESPACE ] STATUS: ✓ PASS
────────────────────────────────────────────────────────────
All tablespaces > 20% free — no space pressure ✓
[ SECTION 5 — BUFFER CACHE ] STATUS: ✓ PASS
────────────────────────────────────────────────────────────
Buffer cache hit ratio: 98.4% — healthy ✓
════════════════════════════════════════════════════════════
DIAGNOSTIC SUMMARY
════════════════════════════════════════════════════════════
Blocking chain — SID 881 holding row lock on AP_INVOICES_ALL
Top SQL driving excessive buffer gets — plan review recommended
FIX: Terminate blocker SID 881 (DBA), share top SQL with DBA team
════════════════════════════════════════════════════════════
Snapshot saved : CONS_BACKUP.SYS_PERF_SNAPSHOT_504180 ✓
Registry ID : 7122
════════════════════════════════════════════════════════════
Every table touched by SYS-03 data fixes is backed up before the first UPDATE fires. Backup is verified by row count. One script restores the original state if needed.
Backup happens before any DML. Script aborts if backup creation fails.
This article is produced automatically at the end of every SYS-03 execution — written from actual run output. No manual documentation required.
The most urgent database-level issue in EBS. A stuck or long-running session holds an exclusive lock that cascades — 1 blocker can freeze 10+ sessions. SYS-03 identifies the root blocker, all blocked sessions, and the exact SQL and object involved for the DBA termination decision.
A single SQL statement with millions of buffer gets can degrade performance for every other session. SYS-03 surfaces the SQL_ID and module source from V$SQL. The DBA team uses the plan hash value to identify whether a missing index or a bad plan is the cause.
A tablespace below 10% free will cause ORA-01653 errors the moment a program tries to extend a segment. SYS-03 identifies the tablespace, current free space, and the largest segments to support the DBA's space allocation decision.
Log switches more than 4 per hour indicate redo log files are undersized for the current transaction volume. Each switch causes a brief checkpoint stall. SYS-03 identifies the switch frequency and the current redo log file sizes.
| View | Type | Purpose |
|---|---|---|
| V$SESSION | V$ View | Active sessions — SID, user, program, status, wait event |
| V$SQL | V$ View | SQL in shared pool — buffer gets, elapsed time, executions, plan hash |
| V$LOCK | V$ View | Lock holders and waiters — type, mode, object |
| V$WAIT_STAT | V$ View | Wait event statistics — total waits, total wait time by event |
| V$SYSSTAT | V$ View | System statistics — buffer gets, physical reads, redo size |
| DBA_SEGMENTS | DBA View | Segment sizes — for tablespace capacity analysis |
| DBA_FREE_SPACE | DBA View | Tablespace free space by datafile |
Before any data is modified in a production Oracle database, AP-01 walks through a four-stage decision process. Every condition identified by the diagnostic maps to exactly one resolution path.
Oracle's own forms and concurrent programs are always the first option. If the condition can be corrected through Oracle's standard UI — a form, a concurrent program, a setup screen — that path is taken first. No consultant SQL required, no database risk, and the fix is fully supported by Oracle. The diagnostic identifies these conditions explicitly and states the exact front-end navigation path.
When the front-end path is unavailable or would require an unacceptable volume of manual steps, a direct fix is evaluated against explicit criteria. All of the following must be true before proceeding:
Certain table areas are never touched directly, regardless of how well the underlying structure is understood. The diagnostic flags these conditions and generates the Service Request documentation:
XLA_EVENTS, XLA_AE_HEADERS — incorrect changes corrupt the subledger audit trail in ways undetectable until period close fails or an auditor requests a reconciliationWF_ITEMS, WF_ITEM_ACTIVITY_STATUSES — ad-hoc DML can corrupt the workflow engine state instance-wideA timestamped backup table is created and row-count verified before the first UPDATE fires. Explicit parameter confirmation is required — the script will not self-execute. After execution, a verification query confirms the expected state. A complete change record — rows affected, before and after values, database username, timestamp — is written to the FIX_BACKUP_REGISTRY and becomes the primary artifact in the knowledge base entry for this incident.
| Condition Identified | Resolution Path | Notes |
|---|---|---|
| Blocking session — root blocker holding lock | Functional First | The DBA terminates the root blocking session via ALTER SYSTEM KILL SESSION after confirming with the session owner that termination is safe. SYS-03 provides the exact SID, SERIAL#, and the SQL the session was running. |
| Top SQL excessive buffer gets — driving high logical read load | Functional First | Share the SQL_ID and plan hash value from SYS-03 with the DBA team for execution plan analysis. Application-level fix is to identify the module generating the SQL and review the query or underlying EBS setup. |
| Tablespace approaching full — < 10% free | Functional First | Alert the DBA team with the tablespace name, current free percentage, and growth rate from the SYS-03 snapshot. DBA action: add datafile or enable autoextend. SYS-03 documents the tablespace state before and after. |
| Buffer cache hit ratio below threshold — < 95% | Functional First | Escalate to DBA with the SYS-03 buffer cache statistics and the top SQL driving physical reads. DBA action: review DB_CACHE_SIZE parameter and identify scan-heavy queries. |
| Redo log switches too frequent — > 4/hour | Functional First | Escalate to DBA with redo log switch frequency from SYS-03. DBA action: increase redo log file size. SYS-03 documents the switch pattern and the database archiving mode. |
| Active session spike — sudden increase in concurrent users | Functional First | SYS-03 identifies the module and program driving the session spike. Application-level action depends on the source — a runaway concurrent program, a batch job, or an end-user load event. |
| Specific wait event dominating | Functional First | SYS-03 identifies the dominant wait event and its total duration in the snapshot window. The DBA team interprets the wait class (I/O, Concurrency, Application) and recommends the fix. |
| Performance data needed for Oracle Support SR | Direct Fix | SYS-03 packages the V$ snapshot data into CONS_BACKUP.SYS_PERF_SNAPSHOT_<case#> in a format suitable for upload to Oracle Support. The snapshot includes all session, SQL, and wait event data from the moment the issue was occurring. |
Before any data fix runs, the script verifies pre-flight conditions and creates a complete verified backup. If any check fails, the script aborts. There is no partial execution path.
Before the first UPDATE fires, the script creates a complete copy of every row to be modified. Tables are named CONS_BACKUP.<TABLE>_<CASE#> and persist permanently after execution.
INSERT from the backup table. No reconstruction required.The knowledge base article is generated automatically from the script's execution output. No manual documentation required. It becomes the institutional record — for the team, for auditors, and for every future engagement in the same environment.
References the Oracle public documentation for this diagnostic area. These links open directly on docs.oracle.com.
| R12 Guide (PDF) | Title & Chapter | Detail |
|---|---|---|
| 120apug.pdf | Oracle Payables User's Guide — Ch. 3: Payables Open Interface Import | pp. 3-139 to 3-151: Large interface table volume and purge program for performance |
| 120invug.pdf | Oracle Inventory User's Guide — Period Close | Pending transaction volume and MTL_MATERIAL_TRANSACTIONS cleanup for performance |
| 120poug.pdf | Oracle Purchasing User's Guide — Ch. 9: Receipt Accruals | AP/PO accrual reconciliation report and accrual write-off for large table cleanup |
SYS-03 is one of 65 diagnostic scripts covering every major Oracle EBS and Fusion module. William A. Green Consulting runs the script in your environment, applies guided data fixes, and builds the knowledge base that prevents the same issues from recurring.
See this script run autonomously — Oracle AI Platform →