Identifying locked rows

Question

I have an uncommited session in one window and I'm attempting to locate the locked row for Oracle 10.2.0.4. I'm unable to locate the row successfully.
I issue the following to retrieve the information on the session locking the row. I could clearly see the session holding a DML lock.
SQLPLUS> select dbms_rowid.rowid_create (1, ROW_WAIT_OBJ#, ROW_WAIT_FILE#, ROW_WAIT_BLOCK#, ROW_WAIT_ROW#)
from v$session where sid=1324;
USERNAME START_TIME STATUS SID SERIAL# SECONDS_IN_WAIT SQL_ID SQL_FULLTEXT TY
ALEX 08/25/11 20:36:30 INACTIVE 1199 30613 49 update test set CUSTOMER_ID=1235 where CUSTOMER_ID=11111 TM
I select the detailed information of the location of the locked row to retrieve the RowID, but I'm not getting back the expected result. I'm getting back values -1,0,0,0 for columns ROW_WAIT_OBJ#, ROW_WAIT_FILE#, ROW_WAIT_BLOCK#, and ROW_WAIT_ROW# respectively. I can't locate the row with the following:
select row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#
from v$session where sid=1199;
SQLPLUS> 2
ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW#
-1 0 0 0
How do I identify the locked updated row? I'm not able to in my test.
Any help would be appreciated.
Thanks

Answer 1

user12006502,
I am struggling to see EXACTLY what you are doing. You are showing output without showing the SQL statements that produce the output. Additionally, there may be foreign key or other constraints involved - as it stands, the best that I can do is guess, and I would prefer not to do that. For example, assume that your table name is T1 rather than TEST. What if, someone created an index like this:
CREATE UNIQUE INDEX T1_CUSTOMER ON T1(DECODE(CUSTOMER,'KEITH','0','JOHN','0',CUSTOMER));
{pre}
Then, in that same session executed the following without a commit:
INSERT INTO T1 VALUES ('JOHN',0);Now, in another session you enter the following:
UPDATE T1 SET CUSTOMER='KEITH' WHERE CUSTOMER='RON';Your session then hangs for seemingly no reason.
The person with the other session issues the following:
SELECT
  SID,
  TYPE,
  ID1,
  ID2,
  LMODE,
  REQUEST,
  BLOCK
FROM
  V$LOCK
WHERE
  SID=(SELECT SID FROM V$MYSTAT WHERE ROWNUM=1);
SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
222 AE        100          0          4          0          0
222 TM      70568          0          3          0          0
222 TX      65554       1424          6          0          1It seems that the first session has a TX lock that is blocking another session, a TM lock that is NOT blocking another session, and an AE lock that is not blocking another session.  Now, in that session, the following is executed:
SELECT /*+ ORDERED */
  S.SID,
  S.STATUS,
  SW.EVENT,
  SW.WAIT_TIME WT,
  SW.STATE,
  SW.SECONDS_IN_WAIT S_I_W,
  S.SQL_ID,
  S.SQL_CHILD_NUMBER,
  S.ROW_WAIT_OBJ# OBJ#,
  S.ROW_WAIT_FILE# FILE#,
  S.ROW_WAIT_BLOCK# BLOCK#,
  S.ROW_WAIT_ROW# ROW#,
  SW.P1,
  SW.P2,
  SW.P3
FROM
  V$SESSION_WAIT SW,
  V$SESSION S
WHERE
  S.USERNAME IS NOT NULL
  AND SW.SID=S.SID
  AND SW.EVENT NOT LIKE '%SQL*Net%'
  AND SW.EVENT NOT IN ('Streams AQ: waiting for messages in the queue',
  'wait for unread message on broadcast channel');
SID STATUS   EVENT                                 WT STATE                    S_I_W SQL_ID        SQL_CHILD_NUMBER       OBJ#      FILE#     BLOCK#       ROW#         P1         P2         P3
223 ACTIVE   enq: TX - row lock contention          0 WAITING                    146 9gag614u0kvyx                0         -1          0          0          0 1415053316      65554       1424Notice in the above the -1 for the OBJ#.  You must provide the DDL and the DML for people to help you, otherwise you are forcing people to guess what you have done to set up the test case.
At the minimum, provide the DDL to recreate the table (and any indexes).  If you do not have the DML, you can use the following technique to retrieve it:
SET PAGESIZE 0
SET LONG 90000
SET LINESIZE 200
COLUMN OBJECT_DEF FORMAT A200
SPOOL 'GETMETA.SQL'
SELECT
  DBMS_METADATA.GET_DDL('TABLE',TABLE_NAME,OWNER) OBJECT_DEF
FROM
  DBA_TABLES
WHERE
  TABLE_NAME IN ('T1');When I executed the above for my test table T1, I saw the following:
  CREATE TABLE "TESTUSER"."T1"
   (    "CUSTOMER" VARCHAR2(6),
        "CUSTOMER_ID" NUMBER
   ) SEGMENT CREATION IMMEDIATE
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "USER_DATA"That said, you could also have a trigger on the table that performs some action on an UPDATE, which could also cause problems.
Here is an example of what a full test case would look like:
DROP TABLE T1 PURGE;
CREATE TABLE T1 (
  CUSTOMER VARCHAR2(6),
  CUSTOMER_ID NUMBER);
INSERT INTO T1 VALUES('BETTY',1235);
INSERT INTO T1 VALUES('RON',0);
INSERT INTO T1 VALUES('BLAKE',0);
COMMIT;In session 1 you execute the following and receive confirmation that the update was successful:
UPDATE T1 SET CUSTOMER='KEITH' WHERE CUSTOMER='RON';
1 row updated.You check V$LOCK for this session and notice that the session has 3 locks, none of which are blocking:
SELECT
  SID,
  TYPE,
  ID1,
  ID2,
  LMODE,
  REQUEST,
  BLOCK
FROM
  V$LOCK
WHERE
  SID=(SELECT SID FROM V$MYSTAT WHERE ROWNUM=1);
SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
223 AE        100          0          4          0          0
223 TM      70568          0          3          0          0
223 TX     262153       1493          6          0          0In another session, you attempt to drop the table and are greeted with an error:
DROP TABLE T1 PURGE;
DROP TABLE T1 PURGE
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expiredSo, you try the update statement - the same one performed in the first session:
UPDATE T1 SET CUSTOMER='KEITH' WHERE CUSTOMER='RON';The session hangs.
Back in the first session, you check the locks for the first session:
SELECT
  SID,
  TYPE,
  ID1,
  ID2,
  LMODE,
  REQUEST,
  BLOCK
FROM
  V$LOCK
WHERE
  SID=(SELECT SID FROM V$MYSTAT WHERE ROWNUM=1);
SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
223 AE        100          0          4          0          0
223 TM      70568          0          3          0          0
223 TX     262153       1493          6          0          1Note the blocking lock.
Let's check the waits:
SELECT /*+ ORDERED */
  S.SID,
  S.STATUS,
  SW.EVENT,
  SW.WAIT_TIME WT,
  SW.STATE,
  SW.SECONDS_IN_WAIT S_I_W,
  S.SQL_ID,
  S.SQL_CHILD_NUMBER,
  S.ROW_WAIT_OBJ# OBJ#,
  S.ROW_WAIT_FILE# FILE#,
  S.ROW_WAIT_BLOCK# BLOCK#,
  S.ROW_WAIT_ROW# ROW#,
  SW.P1,
  SW.P2,
  SW.P3
FROM
  V$SESSION_WAIT SW,
  V$SESSION S
WHERE
  S.USERNAME IS NOT NULL
  AND SW.SID=S.SID
  AND SW.EVENT NOT LIKE '%SQL*Net%'
  AND SW.EVENT NOT IN ('Streams AQ: waiting for messages in the queue',
  'wait for unread message on broadcast channel');
SID STATUS   EVENT                                 WT STATE                    S_I_W SQL_ID        SQL_CHILD_NUMBER       OBJ#      FILE#     BLOCK#       ROW#         P1         P2         P3
222 ACTIVE   enq: TX - row lock contention          0 WAITING                    333 9gag614u0kvyx                1      70568          4      42601          1 1415053318     262153       1493Notice that the second session is waiting in an enqueue, the STATE is WAITING and the OBJ#, FILE#, BLOCK#, and ROW# all contain values.
Please provide a full test case, otherwise people may provide to you an answer that has nothing to do with the question that you are asking.
Notice in the above that the spaces were retained in my posted output from the SQL statements.  To do the same, place the following tag before and after your code sections (do not include the space before and after the brackets):
{ code }
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.