0

I'm trying to identify blocking sessions using the following query:

SELECT
  v1.sid esid,  v1.blocking_session bsid,  v1.process,  v1.wait_class,  v1.event,  v1.sql_id,  v1.seconds_in_wait waitss,  v2.blocking_session bsid2,  v2.process,
  v2.sql_id,  v2.wait_class,  v2.event
from
  v$session v1, v$session v2
where
  v1.blocking_session is not null and v1.blocking_session = v2.sid
order by
  waitss desc

Here is sample output:

ESID    BSID    PROCESS WAIT_CLASS  EVENT                           SQL_ID          WAITSS  BSID2   PROCESS_1 SQL_ID_1 WAIT_CLASS_1 EVENT_1
2707    2313    8526    Application enq: TX - row lock contention   05v90pbavkptk   11      (null)  28152     (null)   Idle         SQL*Net message from client

Which indicates that the blocking session is idle. Maybe I'm missing something but I don't understand how an idle session that is not executing any statement can be blocking anything.

0
3

It would appear the idle session has a lock on at least one record required by the blocked query. The user has already executed a query that acquired a lock. Normally the lock will be held until they commit or rollback the transaction.

I've run into this a few times when a developer went for lunch while in the middle of updating or inserting data. The lock was removed shortly after they returned from lunch.

If their session times out or you kill their session, the transaction should rollback and release the lock.

If you can determine what location they are connected from you may be able to contact them and request they commit or rollback their transaction.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.