Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> Re: row level (transactional) locking problem
Either join works:
v$session.addr = v$transaction.ses_addr v$session.taddr = v$transaction.taddr
Session 165:
update t1 ... where pk_col = 99;
select to_char(sysdate,'hh24:mi') from dual;
time for 4-hour lunch break session waits for message from client
Session 266
update t1 ... where pk_col = 99;
session waits for TX enqueue mode 6
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The educated person is not the person who can answer the questions, but the person who can question the answers -- T. Schick Jr
Next public appearances:
March 2004 Hotsos Symposium - The Burden of Proof
March 2004 Charlotte NC OUG - CBO Tutorial
April 2004 Iceland
One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html
Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____UK___February
____UK___June
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
Jonathan,
Thanks for your reply (I didn't know how to map XID from a block dump to v$lock.id1/id2 info)
As to distributed transactions, IOTs, bitmap indexes - NO to all.
I will definitely check (when I get there again - secure site w/ no remote access) v$session.taddr for 165 (may be the way I join v$session.taddr = v$transaction.addr is incorrect? Mark suggested v$session.addr = v$transaction.sess_addr - is this how it should work?)
As far as waits is concerned (v$session_wait) - yes 165 waits on 'SQL*Net message from client'.
So how 165 can possibly be blocking 226?
Thanks,
Boris Dali.
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Mon Feb 09 2004 - 12:50:42 CST
![]() |
![]() |