Re: Wich parameter could cause this lock behaviour?

Tobbe wrote:
> Hi there!
>

--snip--
> Both tests below are done with only one user connected. (the sql-plus
> session)
>
> 1. )
> My test-server (Win 2003), also tried on some other servers which had clean
> 9.2 installs (not upgraded from 8.1)
>
> Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production
>
> drop table test;
> create table test(n number(2));
> insert into test values(1);
> commit;
> select * from test where n = 1 for update nowait;
>
> select type, lmode, decode(lmode,2,'row-share',3,'row-exclusive'),
> decode(type,'TM',(select object_name from dba_objects where
> object_id=id1)) name from v$lock
> where sid = (select sid from v$mystat where rownum=1);
>
> this results in:
>
> TY LMODE DECODE(LMODE, NAME
> -- ---------- ------------- --------
> TX 6
> TM 2 row-share TEST
>
>
> 2. )
> The other server (Win 2000):
>
> Oracle9i Enterprise Edition Release 9.2.0.7.0 - Production
>
> Same sql as above
>
> results in:
>
> TY LMODE DECODE(LMODE, NAME
> -- ---------- ------------- ----------------
> TX 6
> TM 3 row-exclusive TEST
>
> Why do i get a row exclusive on this?
>
> I have searched in the documentation, metalink and the internet for info
> regarding this, but it seems that

--snip--
> TIA.
>
> Best Regards
>
> Tobias Rangne

You are not seeing weird things. The behavior for select for update did change starting 9.2.0.6. from a row-share to row-exclusive.

See Bugs: 4115353 and 3646162 for reasons why.

Anurag Received on Mon Jan 16 2006 - 12:16:46 CST