Introduction
ORA-04021: timeout occurred while waiting to lock object occurs when Oracle tries to get a lock on an object, but another session is already using or holding that object.
Oracle waits for some time for the lock to become available. If the lock is not released within the timeout period, Oracle returns:
ORA-04021: timeout occurred while waiting to lock object
This error is commonly seen during package compilation, deployments, patching, or DDL changes, especially in busy production and Oracle EBS environments.
Common Causes
1. Package or Procedure Is Currently in Use
Suppose we are trying to compile a package:
ALTER PACKAGE APPS.XX_CUSTOM_PKG COMPILE;
At the same time, another application session or concurrent request is executing the same package.
Oracle cannot immediately get the required lock, so it waits. If the session continues using the package, ORA-04021 may occur.
2. DDL Operation on a Busy Object
Operations such as:
CREATE OR REPLACE, ALTER. DROP, TRUNCATE
require locks on database objects.
If another session is using the object, the DDL may have to wait.
3. Long-Running Sessions or Jobs
A long-running job may keep an object in use for a longer period.
This is common with:
- Oracle EBS Concurrent Requests
- Scheduled jobs
- Batch programs
- Long-running PL/SQL procedures
- Application sessions
4. Deployment During Business Hours
If a package is deployed while users or applications are actively using it, there is a higher chance of getting ORA-04021.
This is why critical object changes are usually better performed during a maintenance window.
How to Find the Session Holding the Object
If you know the object name, check DBA_DDL_LOCKS.
For example:
SELECT s.sid,
s.serial#,
s.username,
s.status,
s.machine,
s.program,
l.owner,
l.name,
l.type,
l.mode_held,
l.mode_requestedFROM v$session sJOIN dba_ddl_locks l
ON s.sid = l.session_idWHERE l.name = ‘XX_CUSTOM_PKG’;
This helps identify the sessions that are holding or requesting locks on the object.
You can then check more information about the session:
SELECT sid,
serial#,
username,
status,
machine,
program,
module,
sql_idFROM v$sessionWHERE sid = <SID>;
This helps us understand who is using the object and from which application or program.
Solution
1. Wait for the Session to Complete
If the session is performing valid work, the safest option is to wait for it to complete.
Once the session releases the object, retry the compilation or deployment.
2. Stop the Job or Application Using the Object
If the object is being used by a scheduled job, concurrent request, or application process, stop or complete that activity before performing the deployment.
For Oracle EBS, always check whether an active Concurrent Request is using the package before terminating the database session.
3. Kill the Session – Only If Required
If the session is confirmed to be stale or it is safe to terminate:
ALTER SYSTEM KILL SESSION ‘SID,SERIAL#’ IMMEDIATE;
Example:
ALTER SYSTEM KILL SESSION ‘125,45678’ IMMEDIATE;
Important: In production, never kill a session without checking what it is doing and understanding the business impact.
Real-Time Example
Consider an Oracle EBS environment where we are deploying a new version of a custom package:
CREATE OR REPLACE PACKAGE BODY APPS.XX_CUSTOM_PKGAS
…END;/
The command keeps waiting and finally returns:
ORA-04021: timeout occurred while waiting to lock object APPS.XX_CUSTOM_PKG
After checking the database, we find that an EBS Concurrent Request is currently executing the same package.
The situation is:
EBS Concurrent Request
↓
Using XX_CUSTOM_PKG
↓
DBA tries to replace the package
↓
Oracle waits for the lock
↓
Lock is not released
↓
ORA-04021
Instead of immediately killing the session, we allow the concurrent request to complete.
Once it completes, we execute the package deployment again and it completes successfully.
Conclusion
ORA-04021 usually means that the object we are trying to modify is currently being used or locked by another session.
The troubleshooting approach is simple:
Identify the object → Find the session → Check what the session is doing → Wait/stop it safely → Retry the operation
