Re: DBA_LOCK fields

x$kglck keeps only track of "library cache locks" not transaction locks. Also there is no way of relating row level locks back to sessions. The info is stored in the block (that is on disk) and you would have to read all the blocks your database to find out what rows are block by which session.

The information on the TX lock:

    id1 = undo segment number << 16 | slot     id2 = sequence

Anjo

I work for Oracle, but speak for myself !

MarkP28665 wrote:

> From: "Andrew Barnett" <nobody_at_spamandeggs.bp.com> >>
> say I update a row in table fred. there's now a row lock on that row, and an
> entry in v$lock that points to fred. say I now update a second row in fred.
> there's still only one entry in v$lock. my question is, since the kernel can
> keep track of individual row locks, where can I find out which rowid is locked
> by which session? I tried to make sense of x$kglck, or whatever it's called,
> but it seemed to also have only one row. <<
>
> Oracle stores row lock information in the data block of the locked row, not in
> memory. There is no way to determine if a row is locked without quering it
> unless someone else is already waiting on it. Since 7.2 the v$session table
> has contained columns for the file id, block, and row number of the locked row
> a session is waiting on.
>
> I hope this is helpful.
>
> Mark Powell -- Oracle 7 Certified DBA
> - The only advice that counts is the advice that you follow so follow your own
> advice -
Received on Sat Mar 21 1998 - 00:00:00 CST