High enq: TX - row lock contention on RAC database
Hi Gurus,
I have SAP applications running on 5 Oracle 10g (10.2.0.5) RAC nodes.
I could observe high row lock contention in the database.
db file sequential read 13.555.789.712 7.148.542.630 5.27 65
enq: TX - row lock contention 45.685.386 1.622.457.531 355.14 15
CPU 0 1.123.793.901 10
gc buffer busy 969.769.720 365.874.242 3.77 3
gc cr grant 2-way 7.565.517.708 161.443.528 .21 1
log file sync 244.392.565 155.406.980 6.36 1
gc current block busy 86.643.267 139.935.394 16.15 1
db file parallel read 80.779.109 124.238.490 15.38 1
gc current block 3-way 2.412.777.861 98.748.193 .41 1
read by other session 227.935.152 95.543.751 4.19 1
I am able to observe one or two update/insert statements in this state.
I would need your help in go ahead for analyzing and finding out the problematic SQL statements.
Though there is no performance issue at the moment, I would like to initiate this proactively.
Database parameters are set consistently with the latest patches for 10.2.0.5.
Br,
Venky
If you are licensed for diagnostic pack, look at the ASH data in v$active_session_history and dba_hist_active_sess_history.
Using the p1/p2/p3 columns and the blocking information, you should be able to see what sessions were waiting on and what sql was being run for the sessions waiting.
Similar Messages
-
How to find sql causing "enq: TX - row lock contention"
Hi,
In one of our database we keep finding "enq: TX - row lock contention" for 2-3 days. But, then it stopped. The time it happened it blocked other sessions for some long time and it got resolved automatically. Now from ADDM report we got sql queries which waited for this but, we can not find which query from which module was causing the issue. What I should look for that past information. Please help.
Database is 10gR2 on AIX.
Regards,
Gourabmoreajays wrote:
Try executing below query real time
alter session set nls_date_format='dd-mon-yyyy hh24:mi:ss';
SELECT vp.spid,c.inst_id,b.session_id sid,c.serial#,a.object_name,
a.owner object_owner,
Decode(b.locked_mode, 0, 'None',
1, 'Null (NULL)',
2, 'Row-S (SS)',
3, 'Row-X (SX)',
4, 'Share (S)',
5, 'S/Row-X (SSX)',
6, 'Exclusive (X)',
b.locked_mode) locked_mode,
b.oracle_username,
c.program,
d.event,
c.status,
c.last_call_et,
c.sql_address,
e.sql_text, c.logon_time
FROM all_objects a,
gv$locked_object b,
gv$session c,
gv$session_wait d,
gv$sqlarea e,
gv$process vp
WHERE a.object_id = b.object_id
and b.session_id=c.sid
and c.sid=d.sid and c.paddr=vp.addr
and e.address=c.sql_address and lower(d.event) like '%enq%'
ORDER BY 1;
The OP asked for a way of find a historic blocker, not a current blocker.
This query - apart from being one that no-one should want to run on a production system - doesn't say anything about the past, and doesn't identify a blocker.
It reports the sessions that are being blocked, and EVERY table that is currently locked by each session whether or not the table is involved in the current statement.
You're using the gv$ (RAC) views but haven't put in any suitable join predicates on the instance (inst_id) columns; the OP is on 10g so you don't need to join to v$session_wait to pick up the wait information; and the join to v$sqlarea forces a "full tablescan" of the library cache (child cursor derived view) because you're joining on address rather than sql_id.
Regards
Jonathan Lewis -
Enq : TX row lock contention with no lock holder !!
Hi, all.
The database is 2 node RAC (oracle 11.2.0.3 ) on a unix machine.
Today morning, I found the instances sufferred "enq : TX row lock contention" YESTERDAY.
I issued the following query,
but block_session, blocking_session_serial# and blocking_inst_id column are null.
select a.instance_number,a.sample_time,a.session_id,a.session_serial#,a.sql_id,
a.event,a.wait_class, a.p1, a.p2, a.p3,a.current_obj#,
a.blocking_session,a.blocking_session_serial#,a.blocking_inst_id
from dba_hist_active_sess_history a
where a.instance_number=1
and a.event='enq: TX - row lock contention'
order by a.instance_number,sample_id
Any advice will be greately appreciated.
Thanks in advance.
Best Regards.In addition to run the script , also download and run Snapper script from Tanel Poder which would give even more detail for the session .
http://files.e2sn.com/scripts/snapper.sql
HTH
Aman.... -
Enq: TX - row lock contention on dual
Dear Team,
In my database i can see lots of enq: TX wait in dual
SID MODULE SQL_ID EVENT SECONDS_IN_WAIT BLOCKING_SESSION STATUS
2944 IAPPRAISOR_V20.fmx 5pjx5pj5xsmn7 enq: TX - row lock contention 38 2920 ACTIVE
3050 IAPPRAISOR_V20.fmx enq: TX - row lock contention 769 2915 ACTIVE
3071 IAPPRAISOR_V20.fmx 5pjx5pj5xsmn7 enq: TX - row lock contention 38 2920 ACTIVE
3097 IAPPRAISOR_V20.fmx enq: TX - row lock contention 767 3050 ACTIVE
3117 IAPPRAISOR_V20.fmx 5pjx5pj5xsmn7 enq: TX - row lock contention 572 3319 ACTIVE
SQL> select * from table(dbms_xplan.display_awr('5pjx5pj5xsmn7'));
PLAN_TABLE_OUTPUT
SQL_ID 5pjx5pj5xsmn7
SELECT SYSDATE FROM SYS.DUAL
Plan hash value: 1546270724
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | 2 (100)| |
| 1 | FAST DUAL | | 1 | 2 (0)| 00:00:01 |
Is there any idea why select on sys.dual putting execlusive lock? Database version 10.2.0.5.
Thanks and Regards,
Rajib SutradharShow us the result of
set linesize 120
set trimspool on
select * from v$lock where sid = 'sid of holding session'l;
select * from v$lock where sid = 'sid of one waiting session'l;Please read the note below about readable output.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.) -
Enq: TX - row lock contention wait event
Hi,
I would like to find which DML query has not given COMMIT or ROLLBACK after the execution. Because one of the development database have more table locks and developer reported that their session was hanging. I referred AWR report also and more timed waits occurred in the enq: TX - row lock contention. I need to trace which DML query has not commit or rollback.
Please help me to solve the issue.
Database version: 11.2.0.1.0
Foreground Wait Events
Event
Waits
%Time -outs
Total Wait Time (s)
Avg wait (ms)
Waits /txn
% DB time
enq: TX - row lock contention
320
0
72,047
225147
0.20
99.53
log file sync
547
0
14
26
0.35
0.02
library cache lock
13
0
11
843
0.01
0.02
SQL*Net break/reset to client
1,080
0
2
1
0.69
0.00
SQL*Net message to client
659,006
0
1
0
421.63
0.00
direct path sync
3
0
1
299
0.00
0.00
SQL*Net more data from client
5,541
0
1
0
3.55
0.00
db file scattered read
554
0
0
1
0.35
0.00
SQL*Net more data to client
14,975
0
0
0
9.58
0.00
db file sequential read
2,817
0
0
0
1.80
0.00
ADR block file read
4
0
0
43
0.00
0.00
enq: CR - block range reuse ckpt
2
0
0
71
0.00
0.00
asynch descriptor resize
38,073
100
0
0
24.36
0.00
latch: shared pool
61
0
0
1
0.04
0.00
control file sequential read
6,900
0
0
0
4.41
0.00
Disk file operations I/O
550
0
0
0
0.35
0.00
cursor: pin S
1
0
0
8
0.00
0.00
direct path write temp
34
0
0
0
0.02
0.00
library cache: mutex X
5
0
0
1
0.00
0.00
latch: In memory undo latch
2
0
0
1
0.00
0.00
buffer busy waits
14
0
0
0
0.01
0.00
SQL*Net message from client
658,990
0
294,847
447
421.62
jobq slave wait
669
99
333
497
0.43
PL/SQL lock timer
1
100
1
998
0.00Oracle does not and cannot tell you from historical views (e.g. AWR) which DMLs have not COMMITed or ROLLBACKed. A Transaction ends with a COMMIT or ROLLBACK. The transaction could have a million (or more) DML statements with a million (or more) SELECT statements between the first DML and the COMMIT / ROLLBACK.
Even identifying such DMLs in real time is close to impossible. Because the session holding the lock may have issued a dozen or a million subsequent SQL statements while other sessions are waiting for the lock. You can only identify the session that is the lock holder (the BLOCKING_SESSION in V$SESSION).
If you have tracing enabled for all sessions, then you could review the trace file for the BLOCKING_SESSION to identify the DML(s) the session has executed.
Hemant K Chitale -
Enq: TX - row lock contention problem
Hi ,
Db version 10.2.0.4
os solaris.
i have upgraded my database from 9.2.0.4 to 10.2.0.4 by using exp/imp as my database is small.
I have created new instance of 10g and changed parameter values as 9i(as required). then imported from 9i to 10g instance.
After importing in 10g instance we are face application wide performance problem..the response time of the applicatoin was very slow...
i have taken awr report of various times and have seeen
SELECT puid,ptimestamp FROM PPOM_OBJECT WHERE puid IN (:1) FOR UPDATE
this query is causing the problem..enq: TX - row lock contention
Cache Sizes
~~~~~~~~~~~ Begin End
Buffer Cache: 756M 756M Std Block Size: 8K
Shared Pool Size: 252M 252M Log Buffer: 1,264K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 2,501.54 3,029.25
Logical reads: 2,067.79 2,504.00
Block changes: 17.99 21.78
Physical reads: 0.02 0.03
Physical writes: 0.41 0.50
User calls: 140.74 170.44
Parses: 139.55 168.99
Hard parses: 0.01 0.01
Sorts: 10.65 12.89
Logons: 0.32 0.38
Executes: 139.76 169.24
Transactions: 0.83
% Blocks changed per Read: 0.87 Recursive Call %: 17.60
Rollback per transaction %: 0.00 Rows per Sort: 16.86
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 100.00 In-memory Sort %: 100.00
Library Hit %: 100.03 Soft Parse %: 100.00
Execute to Parse %: 0.15 Latch Hit %: 99.89
Parse CPU to Parse Elapsd %: 93.19 % Non-Parse CPU: 94.94
Shared Pool Statistics Begin End
Memory Usage %: 86.73 86.55
% SQL with executions>1: 90.99 95.33
% Memory for SQL w/exec>1: 79.15 90.58
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
CPU time 397 86.3
enq: TX - row lock contention 508 59 115 12.7 Applicatio
log file sync 2,991 5 2 1.1 Commit
log file parallel write 3,238 5 2 1.1 System I/O
SQL*Net more data to client 59,871 4 0 1.0 Network
^LTime Model Statistics DB/Inst: WGMUGPR2/wgmugpr2 Snaps: 706-707
-> Total time in database user-calls (DB Time): 460.5s
-> Statistics including the word "background" measure background process
time, and so do not contribute to the DB time statistic
-> Ordered by % or DB time desc, Statistic name
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
enq: TX - row lock contentio 508 .0 59 115 0.2
log file sync 2,991 .0 5 2 1.0
log file parallel write 3,238 .0 5 2 1.1
SQL*Net more data to client 59,871 .0 4 0 20.1
control file parallel write 1,201 .0 1 1 0.4
SQL*Net more data from clien 3,393 .0 1 0 1.1
SQL*Net message to client 509,864 .0 1 0 170.9
os thread startup 3 .0 1 196 0.0
db file parallel write 845 .0 1 1 0.3
-> % Total DB Time is the Elapsed Time of the SQL statement divided
into the Total Database Time multiplied by 100
Elapsed CPU Elap per % Total
Time (s) Time (s) Executions Exec (s) DB Time SQL Id
59 1 1,377 0.0 12.9 bwnt27fp0z3gm
Module: syncdizio_op@snstr09 (TNS V1-V3)
SELECT puid,ptimestamp FROM PPOM_OBJECT WHERE puid IN (:1) FOR UPDATE
41 41 459 0.1 8.9 8cdswsp7cva2h
Module: syncdizio_op@snstr09 (TNS V1-V3)
select rpad(argument_name, 32, ' ') || in_out || ' ' || nvl(type_subname, data_t
ype) info from user_arguments where package_name IS NULL and object_name = uppe
r(:1) and argument_name is not null order by object_name, position
39 38 7,457 0.0 8.4 271hn6sgra2d8
Module: syncdizio_op@snstr09 (TNS V1-V3)
SELECT DISTINCT t_0.puid FROM PIMANTYPE t_0 WHERE (UPPER(t_0.ptype_name) = UPPER
(:1))
23 22 459 0.0 4.9 g92t08k78tgrw
Module: syncdizio_op@snstr09 (TNS V1-V3)
SELECT PIMANTYPE.puid, ptimestamp, ppid, rowning_siteu, rowning_sitec, pis_froze
n, ptype_class, ptype_name FROM PPOM_OBJECT, PIMANTYPE WHERE PPOM_OBJECT.puid =
(PIMANTYPE.puid)
22 22 158,004 0.0 4.9 chqpmv9c05ghq
Module: syncdizio_op@snstr09 (TNS V1-V3)
SELECT puid,ptimestamp FROM PPOM_OBJECT WHERE puid = :1
17 17 2,294 0.0 3.7 3n5trh11n1x8w
Module: syncdizio_op@snstr09 (TNS V1-V3)
SELECT PTYPECANNEDMETHOD.puid, ptimestamp, ppid, rowning_siteu, rowning_sitec, p
is_frozen, pobject_desc, psecure_bits,VLA_344_5, pmethod_name, pmsg_name, ptype_
name, pexec_seq, paction_type FROM PPOM_OBJECT,PBUSINESSRULE, PTYPECANNEDMETHOD
WHERE PTYPECANNEDMETHOD.puid IN (:1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,in 9i there is a parameter ENQUEUE_RESOURCES but in 10g relese 2 its got obsoleted....
am new to performace tunning please advice me....!
Regards
VamshiThe CBO has changed substantially between 9.2.x and 10.2.x. Pl see MOS Doc 754931.1 (Cost Based Optimizer - Common Misconceptions and Issues - 10g and Above). Pl verify that statistics have been gathered and are current - pl see MOS Doc 605439.1 (Master Note: Recommendations for Gathering Optimizer Statistics on 10g).
Looking at your output, it seems to me that the database is entirely CPU-bound. 86.3% of time is spent on CPU. The last 5 SQL statements in the output, all of the elapsed time is spent on CPU.
Pl post your init.ora parameters, along with your hardware specs. This question might be more appropriate in the "Database - General" forum.
HTH
Srini -
Enq: TX - row lock contention-Trace file shared.
Hi Team,
I am having enq: TX - row lock contention in top wait event. it is occuring between 10pm - 2am.
We are having sqlloader job running every one hour(conventional path). But for the specific period of time i am getting "Global Enqueue Services Deadlock detected". Between 10-5. I analyzed realated trace file it is make me little confusion.I found there are four insert query culprit for this locking. out of four sql , tow of them are ran by same SID, other two insert ran by same id. I got confused because how same sid locking them self. trace file below. Please help me on this. during this period oracle maintanence window is active.Thanks
Trace file:
*** 2012-10-09 03:40:31.135
user session for deadlock lock 0x15365e060
sid: 1104 ser: 22256 audsid: 8797820 user: 49/iurth flags: 0x45
pid: 71 O/S info: user: oracle, term: UNKNOWN, ospid: 8601
image: oracle@sgh0909
client details:
O/S info: user: user, term: , ospid: 30888
machine: sgj89909 program: sqlldr@sgj89909 (TNS V1-V3)
application name: SQL Loader Conventional Path Load, hash value=1935272243
action name: der/sample.ctl, hash value=3241011749
current SQL:
INSERT INTO sample (ID,SU,TIME,PMAN_S,CV_OS,PRD_US,P_DS,PM_LY_DRD_S,PMP_PY_DIDS,PP_S,PMP_RECV_FRMS) VALUES (:NE,:SID,CAST(TO_DATE(:PNG_TE, 'DDMMYYY,PMP_TRAN_FRMS,PMP_RECV_FRMS) VALUES (:NE_ID,:SUB_ID,CAST(TO_DATE(:POLLING_TIME, 'DDMMYYYYHH24MISS') AS DATE),:PMP_TRAN_OCTS,:PMP_RECV_OCTS,:PMP_DISCARD_US,:PMP_DISCARD_DS,:PMP_POLICY_DISCARD_US,:PMP_POLICY_DISCARD_DS,:PMP_TRAN_FRMS,:PMP_RECV_FRMS) ÷ {+ (Cõ{+ (Cõ{+ ð÷ ð÷ ú;6üΠì/' „P' û[þ‡»q hdšÙÿ – $µ + л{+ XdšÙÿ cšÙÿ л{+ M L šÙ ƒß @ešÙÿ ’Ü cšÙÿ lcšÙÿ M „P' L
*** 2012-10-09 03:40:31.533
Short stack dump:
<-ksedsts()+315<-ksdxfstk()+32<-ksdxcb()+1764<-sspuser()+112<-__restore_rt()<-semtimedop()+10<-sskgpwwait()+265<-skgpwwait()+156<-ksliwat()+1546<-kslwaitctx()+162<-kjusuc()+3868<-ksipgetctx()+1456<-ksqcmi()+22853<-ksqgtlctx()+4311<-ksqgelctx()+601<-ktcwit1()+333<-ktbgtl0()+1321<-kdimod0()+4581<-kdiblLockPiece()+968<-kdiblLockRange()+1639<-kdiblcfls()+189<-kdiblFinish1()+978<-kdibliFinish()+73<-kxibDoFinish()+90<-kxibFinish()+431<-qerltcEndLoadProcessing()+614<-qerltcLoadStateMachine()+858<-qerltcInsertValues()+218<-qerltcFetch()+1373<-insexe()+1095<-opiexe()+5609<-opiodr()+1220<-ttcpip()+1227<-opitsk()+1449<-opiino()+1026<-opiodr()+1220<-opidrv()+580<-sou2o()+90<-opimai_real()+145<-ssthrdmain()+177<-main()+215<-__libc_start_main()+244<-_start()+41
user session for deadlock lock 0x1537feef8
sid: 1107 ser: 44863 audsid: 8797823 user: 49/iurth flags: 0x45
pid: 57 O/S info: user: oracle, term: UNKNOWN, ospid: 4540
image: oracle@sgh0909
client details:
O/S info: user: user, term: , ospid: 7569
machine: sgj89909 program: sqlldr@sgj89909 (TNS V1-V3)
application name: SQL Loader Conventional Path Load, hash value=1935272243
action name: der/sample.ctl, hash value=3241011749
current SQL:
INSERT INTO sample (ID,SU,TIME,PMAN_S,CV_OS,PRD_US,P_DS,PM_LY_DRD_S,PMP_PY_DIDS,PP_S,PMP_RECV_FRMS) VALUES (:NE,:SID,CAST(TO_DATE(:PNG_TE, 'DDMMYYY,PMP_TRAN_FRMS,PMP_RECV_FRMS) VALUES (:NE_ID,:SUB_ID,CAST(TO_DATE(:POLLING_TIME, 'DDMMYYYYHH24MISS') AS DATE),:PMP_TRAN_OCTS,:PMP_RECV_OCTS,:PMP_DISCARD_US,:PMP_DISCARD_DS,:PMP_POLICY_DISCARD_US,:PMP_POLICY_DISCARD_DS,:PMP_TRAN_FRMS,:PMP_RECV_FRMS) ÷ {+ (Cõ{+ (Cõ{+ ð÷ ð÷ –R<üΠì/' „P' hdšÙÿ _ž $µ + л{+ XdšÙÿ cšÙÿ л{+ M L šÙ ƒß @ešÙÿ ’Ü cšÙÿ lcšÙÿ M „P' L
Short stack dump:
<-ksedsts()+315<-ksdxfstk()+32<-ksdxcb()+1764<-sspuser()+112<-__restore_rt()<-semtimedop()+10<-sskgpwwait()+265<-skgpwwait()+156<-ksliwat()+1546<-kslwaitctx()+162<-kjusuc()+3868<-ksipgetctx()+1456<-ksqcmi()+22853<-ksqgtlctx()+4311<-ksqgelctx()+601<-ktcwit1()+333<-ktbgtl0()+1321<-kdimod0()+4581<-kdiblLockPiece()+968<-kdiblLockRange()+1639<-kdiblcfls()+189<-kdiblFinish1()+978<-kdibliFinish()+73<-kxibDoFinish()+90<-kxibFinish()+431<-qerltcEndLoadProcessing()+614<-qerltcLoadStateMachine()+858<-qerltcInsertValues()+218<-qerltcFetch()+1373<-insexe()+1095<-opiexe()+5609<-opiodr()+1220<-ttcpip()+1227<-opitsk()+1449<-opiino()+1026<-opiodr()+1220<-opidrv()+580<-sou2o()+90<-opimai_real()+145<-ssthrdmain()+177<-main()+215<-__libc_start_main()+244<-_start()+41
user session for deadlock lock 0x1528de490
sid: 1107 ser: 44863 audsid: 8797823 user: 49/iurth flags: 0x45
pid: 57 O/S info: user: oracle, term: UNKNOWN, ospid: 4540
image: oracle@sgh0909
client details:
O/S info: user: user, term: , ospid: 7569
machine: sgj89909 program: sqlldr@sgj89909 (TNS V1-V3)
application name: SQL Loader Conventional Path Load, hash value=1935272243
action name: der/sample.ctl, hash value=3241011749
current SQL:
INSERT INTO sample (ID,SU,TIME,PMAN_S,CV_OS,PRD_US,P_DS,PM_LY_DRD_S,PMP_PY_DIDS,PP_S,PMP_RECV_FRMS) VALUES (:NE,:SID,CAST(TO_DATE(:PNG_TE, 'DDMMYYY,PMP_TRAN_FRMS,PMP_RECV_FRMS) VALUES (:NE_ID,:SUB_ID,CAST(TO_DATE(:POLLING_TIME, 'DDMMYYYYHH24MISS') AS DATE),:PMP_TRAN_OCTS,:PMP_RECV_OCTS,:PMP_DISCARD_US,:PMP_DISCARD_DS,:PMP_POLICY_DISCARD_US,:PMP_POLICY_DISCARD_DS,:PMP_TRAN_FRMS,:PMP_RECV_FRMS) ÷ {+ (Cõ{+ (Cõ{+ ð÷ ð÷ ÍïEüΠì/' „P' hdšÙÿ €¦ $µ + л{+ XdšÙÿ cšÙÿ л{+ M L šÙ ƒß @ešÙÿ ’Ü cšÙÿ lcšÙÿ M „P' L
*** 2012-10-09 03:40:32.452
Short stack dump:
<-ksedsts()+315<-ksdxfstk()+32<-ksdxcb()+1764<-sspuser()+112<-__restore_rt()<-semtimedop()+10<-sskgpwwait()+265<-skgpwwait()+156<-ksliwat()+1546<-kslwaitctx()+162<-kjusuc()+3868<-ksipgetctx()+1456<-ksqcmi()+22853<-ksqgtlctx()+4311<-ksqgelctx()+601<-ktcwit1()+333<-ktbgtl0()+1321<-kdimod0()+4581<-kdiblLockPiece()+968<-kdiblLockRange()+1639<-kdiblcfls()+189<-kdiblFinish1()+978<-kdibliFinish()+73<-kxibDoFinish()+90<-kxibFinish()+431<-qerltcEndLoadProcessing()+614<-qerltcLoadStateMachine()+858<-qerltcInsertValues()+218<-qerltcFetch()+1373<-insexe()+1095<-opiexe()+5609<-opiodr()+1220<-ttcpip()+1227<-opitsk()+1449<-opiino()+1026<-opiodr()+1220<-opidrv()+580<-sou2o()+90<-opimai_real()+145<-ssthrdmain()+177<-main()+215<-__libc_start_main()+244<-_start()+41
user session for deadlock lock 0x1528de2e0
sid: 1104 ser: 22256 audsid: 8797820 user: 49/iurth flags: 0x45
pid: 71 O/S info: user: oracle, term: UNKNOWN, ospid: 8601
image: oracle@sgh0909
client details:
O/S info: user: user, term: , ospid: 30888
machine: sgj89909 program: sqlldr@sgj89909 (TNS V1-V3)
application name: SQL Loader Conventional Path Load, hash value=1935272243
action name: der/sample.ctl, hash value=3241011749
current SQL:
INSERT INTO sample (ID,SU,TIME,PMAN_S,CV_OS,PRD_US,P_DS,PM_LY_DRD_S,PMP_PY_DIDS,PP_S,PMP_RECV_FRMS) VALUES (:NE,:SID,CAST(TO_DATE(:PNG_TE, 'DDMMYYY,PMP_TRAN_FRMS,PMP_RECV_FRMS) VALUES (:NE_ID,:SUB_ID,CAST(TO_DATE(:POLLING_TIME, 'DDMMYYYYHH24MISS') AS DATE),:PMP_TRAN_OCTS,:PMP_RECV_OCTS,:PMP_DISCARD_US,:PMP_DISCARD_DS,:PMP_POLICY_DISCARD_US,:PMP_POLICY_DISCARD_DS,:PMP_TRAN_FRMS,:PMP_RECV_FRMS) ÷ {+ (Cõ{+ (Cõ{+ ð÷ ð÷ DlJüΠì/' „P' hdšÙÿ ¾® $µ + л{+ XdšÙÿ cšÙÿ л{+ M L šÙ ƒß @ešÙÿ ’Ü cšÙÿ lcšÙÿ M „P' L
Short stack dump:
<-ksedsts()+315<-ksdxfstk()+32<-ksdxcb()+1764<-sspuser()+112<-__restore_rt()<-semtimedop()+10<-sskgpwwait()+265<-skgpwwait()+156<-ksliwat()+1546<-kslwaitctx()+162<-kjusuc()+3868<-ksipgetctx()+1456<-ksqcmi()+22853<-ksqgtlctx()+4311<-ksqgelctx()+601<-ktcwit1()+333<-ktbgtl0()+1321<-kdimod0()+4581<-kdiblLockPiece()+968<-kdiblLockRange()+1639<-kdiblcfls()+189<-kdiblFinish1()+978<-kdibliFinish()+73<-kxibDoFinish()+90<-kxibFinish()+431<-qerltcEndLoadProcessing()+614<-qerltcLoadStateMachine()+858<-qerltcInsertValues()+218<-qerltcFetch()+1373<-insexe()+1095<-opiexe()+5609<-opiodr()+1220<-ttcpip()+1227<-opitsk()+1449<-opiino()+1026<-opiodr()+1220<-opidrv()+580<-sou2o()+90<-opimai_real()+145<-ssthrdmain()+177<-main()+215<-__libc_start_main()+244<-_start()+41
Global blockers dump start:---------------------------------
DUMP LOCAL BLOCKER/HOLDER: block level 3 res [0x2a001d][0x1cb9d],[TX]
----------resource 0x1341d3c30----------------------
resname : [0x2a001d][0x1cb9d],[TX]
Local node : 4
dir_node : 4
master_node : 4
hv idx : 14
hv last r.inc : 32
current inc : 32
hv status : 0
hv master : 4
open options : dd
grant_bits : KJUSERNL KJUSEREX
grant mode : KJUSERNL KJUSERCR KJUSERCW KJUSERPR KJUSERPW KJUSEREX
count : 3 0 0 0 0 1
val_state : KJUSERVS_NOVALUE
valblk : 0x5f4f4354532c504d505f524543565f4f OCTS,PMPRECV_O
access_node : 4
vbreq_state : 0
state : x0
resp : 0x1341d3c30
On Scan_q? : N
Total accesses: 8568
Imm. accesses: 7210
Granted_locks : 1
Cvting_locks : 3
value_block: 5f 4f 43 54 53 2c 50 4d 50 5f 52 45 43 56 5f 4f
GRANTED_Q :
lp 0x1537feef8 gl KJUSEREX rp 0x1341d3c30 [0x2a001d][0x1cb9d],[TX]
master 4 gl owner 0x154b13128 possible pid 4540 xid 39000-0005-00048D1F bast 0 rseq 1329 mseq 0 history 0x14951495
open opt KJUSERDEADLOCK
CONVERT_Q:
lp 0x1537ff0a8 gl KJUSERNL rl KJUSERPR rp 0x1341d3c30 [0x2a001d][0x1cb9d],[TX]
master 4 gl owner 0x155b0dd28 possible pid 12781 xid 37000-0005-00082EBC bast 0 rseq 1329 mseq 0 history 0x49a5149a
convert opt KJUSERGETVALUE
lp 0x1513ef168 gl KJUSERNL rl KJUSERPR rp 0x1341d3c30 [0x2a001d][0x1cb9d],[TX]
master 4 gl owner 0x159aaf240 possible pid 1347 xid 48000-0005-0001FACA bast 0 rseq 1329 mseq 0 history 0x49a5149a
convert opt KJUSERGETVALUE
lp 0x15365e060 gl KJUSERNL rl KJUSERPR rp 0x1341d3c30 [0x2a001d][0x1cb9d],[TX]
master 4 gl owner 0x154b105e0 possible pid 8601 xid 47000-0005-00024CDE bast 0 rseq 1329 mseq 0 history 0x49a5149a
convert opt KJUSERGETVALUE
----------enqueue 0x1537feef8------------------------
lock version : 2128337
Owner node : 4
grant_level : KJUSEREX
req_level : KJUSEREX
bast_level : KJUSERNL
notify_func : (nil)
resp : 0x1341d3c30
procp : 0x1510e0ee0
pid : 12781
proc version : 10700
oprocp : (nil)
opid : 0
group lock owner : 0x154b13128
possible pid : 4540
xid : 39000-0005-00048D1F
dd_time : 0.0 secs
dd_count : 0
timeout : 0.0 secs
On_timer_q? : N
On_dd_q? : N
lock_state : GRANTED
Open Options : KJUSERDEADLOCK
Convert options : KJUSERNOQUEUE KJUSERNODEADLOCKWAIT
History : 0x14951495
Msg_Seq : 0x0
res_seq : 1329
valblk : 0x2c3a504d505f504f4c4943595f444953 ,:PMP_POLICY_DIS
DUMP LOCAL BLOCKER: initiate state dump for DEADLOCK
possible owner[57.4540] on resource TX-002A001D-0001CB9D
*** 2012-10-09 03:40:32.794
Submitting asynchronized dump request [28]
DUMP LOCAL BLOCKER/HOLDER: block level 3 res [0x2f0003][0x1eee9],[TX]
----------resource 0x1355e6868----------------------
resname : [0x2f0003][0x1eee9],[TX]
Local node : 4
dir_node : 4
master_node : 4
hv idx : 64
hv last r.inc : 32
current inc : 32
hv status : 0
hv master : 4
open options : dd
grant_bits : KJUSERNL KJUSEREX
grant mode : KJUSERNL KJUSERCR KJUSERCW KJUSERPR KJUSERPW KJUSEREX
count : 1 0 0 0 0 1
val_state : KJUSERVS_NOVALUE
valblk : 0x5f4f4354532c504de00e0e5101000000 _OCTS,PMQ
access_node : 4
vbreq_state : 0
state : x0
resp : 0x1355e6868
On Scan_q? : N
Total accesses: 13955
Imm. accesses: 11923
Granted_locks : 1
Cvting_locks : 1
value_block: 5f 4f 43 54 53 2c 50 4d e0 0e 0e 51 01 00 00 00
GRANTED_Q :
lp 0x1528de2e0 gl KJUSEREX rp 0x1355e6868 [0x2f0003][0x1eee9],[TX]
master 4 gl owner 0x154b105e0 possible pid 8601 xid 47000-0005-00024CDE bast 0 rseq 1980 mseq 0 history 0x49a51495
open opt KJUSERDEADLOCK
CONVERT_Q:
lp 0x1528de490 gl KJUSERNL rl KJUSERPR rp 0x1355e6868 [0x2f0003][0x1eee9],[TX]
master 4 gl owner 0x154b13128 possible pid 4540 xid 39000-0005-00048D1F bast 0 rseq 1980 mseq 0 history 0x49a5149a
convert opt KJUSERGETVALUE
----------enqueue 0x1528de2e0------------------------
lock version : 2643245
Owner node : 4
grant_level : KJUSEREX
req_level : KJUSEREX
bast_level : KJUSERNL
notify_func : (nil)
resp : 0x1355e6868
procp : 0x1510f9800
pid : 4540
proc version : 21634
oprocp : (nil)
opid : 0
group lock owner : 0x154b105e0
possible pid : 8601
xid : 47000-0005-00024CDE
dd_time : 0.0 secs
dd_count : 0
timeout : 0.0 secs
On_timer_q? : N
On_dd_q? : N
lock_state : GRANTED
Open Options : KJUSERDEADLOCK
Convert options : KJUSERNOQUEUE KJUSERNODEADLOCKWAIT
History : 0x49a51495
Msg_Seq : 0x0
res_seq : 1980
valblk : 0x2c3a504d505f504f4c4943595f444953 ,:PMP_POLICY_DIS
DUMP LOCAL BLOCKER: initiate state dump for DEADLOCK
possible owner[71.8601] on resource TX-002F0003-0001EEE9
*** 2012-10-09 03:40:32.794
Submitting asynchronized dump request [28]
Global blockers dump end:-----------------------------------
Global Wait-For-Graph(WFG) at ddTS[0.108ea] :
BLOCKED 0x15365e060 3 wq 2 cvtops x1 TX 0x2a001d.0x1cb9d [47000-0005-00024CDE] 4
BLOCKER 0x1537feef8 3 wq 1 cvtops x28 TX 0x2a001d.0x1cb9d [39000-0005-00048D1F] 4
BLOCKED 0x1528de490 3 wq 2 cvtops x1 TX 0x2f0003.0x1eee9 [39000-0005-00048D1F] 4
BLOCKER 0x1528de2e0 3 wq 1 cvtops x28 TX 0x2f0003.0x1eee9 [47000-0005-00024CDE] 4Your scenario involves mode 4 (KJUSERPR) and mode 6 (KJUSEREX) TX locks.
Mode 4 (S) TX locks can have a few causes, including ITLs, unique indexes and bitmap indexes.
It could be a very similar scenario to this recent thread where the situation was primary/unique key collisions from inserts on different nodes:
Re: Cause of Deadlock -
Enq: TX - row lock contention in AWR reports
Dears,
One of my friends asked me to give him a help on analyzing a performance problem they are experimenting from time to time. First of all I am sorry to tell you that he didn’t gave me a lot of information. I will share with you all what I have been sent and would like to have your precious advice according to the available information.
It is a third party software installed on oracle data base 10.2.0.4.0. He said that from time to time the application hangs. He sends me an AWR reports supplied by the local DBA. Unfortunately, the local DBA send only the AWR information he thinks are most important to be looked at (he did not include the load profile and the instance efficiency Percentages part in this AWR for example).
Here below is the available information I can share with you
Snap time sessions cursors/session
Begin Snap 09-mars-11 08:00:03 31 6.5
End Snap 09-mars-11 08:39:49 41 9.8
Elapsed 39.77 (mins)
DB Time 536.65(mins)
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
enq: TX - row lock contention 8,468 25,344 2,993 78.7 Application
read by other session 714,628 4,604 6 14.3 User I/O
db file sequential read 323,264 1,977 6 6.1 User I/O
CPU time 171 .5
db file scattered read 1,885 49 26 .2 User I/OThe AWR reports presents also the following SQL statement as the top SQL of its ‘’SQL ordered by Elapsed Time’’ part
UPDATE xxxx.table1
SET col1 = :1,
col2 = :2,
col3 = :3,
col4 = :4,
WHERE ID = :13
AND colx = :14;And the following sql at its “SQL ordered by Reads’ part
SELECT t1.*
FROM xxxx.table1 t1
LEFT OUTER JOIN xxxx.table2 t2
ON t1.id = t2.id
LEFT OUTER JOIN xxxx.table3 t3
ON t1.id = t3.id
LEFT OUTER JOIN xxxx.table4 t4
ON t1.id = t4.id
WHERE t1.col1 = :1
AND t1.col2 IN (:2,:3, :4);And finally in the Segments by Row Lock Waits part of the AWR I have this:
Owner tablespace name object name object type row lock waits %of capture
xxxx xxxx table1 TABLE 54 100 There are no bitmap indexes on this OLTP data base. There are no unindexed foreign keys and it seems that there are no selects done over a dblink.
I am waiting to have the table table1 script and its indexes
Given those information I think that the locking problem is due to this update on table table1 which is not followed immediately by a commit or a rollback. But, instead, several selects that might be taking a long time are done before reaching the commit that ends the lock on the table table1
What do you think about the possible reason of this lock?
Thanks in advance
Mohamed HouriDears,
I did get the suspected query and asked for its several explain plans thanks to the dbms_xplan.display_awr. The most important thing to point out is that the last where clause of this query seems to be dynamically filled-up
SELECT t1.*
FROM xxxx.table1 t1
LEFT OUTER JOIN xxxx.table2 t2
ON t1.id = t2.id
LEFT OUTER JOIN xxxx.table3 t3
ON t1.id = t3.id
LEFT OUTER JOIN xxxx.table4 t4
ON t1.id = t4.id
WHERE t1.col1 = :1
AND t1.col2 in (:2 , :3 , :4 , :5 , :6 , :7 , :8 )
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 14 (100)| |
| 1 | NESTED LOOPS OUTER | | 1 | 280 | 14 (0)| 00:00:01 |
| 2 | NESTED LOOPS OUTER | | 1 | 226 | 9 (0)| 00:00:01 |
| 3 | NESTED LOOPS OUTER | | 1 | 216 | 6 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| TABLE1 | 1 | 141 | 4 (0)| 00:00:01 |
| 5 | INDEX RANGE SCAN | SYS_C0010893 | 1 | | 3 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| TABLE2 | 1 | 75 | 2 (0)| 00:00:01 |
| 7 | INDEX UNIQUE SCAN | SYS_C0010774 | 1 | | 1 (0)| 00:00:01 |
| 8 | INDEX RANGE SCAN | SYS_C0010896 | 3 | 30 | 3 (0)| 00:00:01 |
| 9 | TABLE ACCESS BY INDEX ROWID | TABLE3 | 11 | 594 | 5 (0)| 00:00:01 |
| 10 | INDEX RANGE SCAN | SYS_C0010910 | 11 | | 3 (0)| 00:00:01 |
SELECT t1.*
FROM xxxx.table1 t1
LEFT OUTER JOIN xxxx.table2 t2
ON t1.id = t2.id
LEFT OUTER JOIN xxxx.table3 t3
ON t1.id = t3.id
LEFT OUTER JOIN xxxx.table4 t4
ON t1.id = t4.id
WHERE t1.col1 = :1
AND t1.col2 in (:2 , :3 , :4 , :5 , :6 , :7 , :8 , :9 , :10 , :11 , :12 , :13 , :14 , :15 , :16 ,
:17 , :18 , :19 , :20 , :21 , :22 , :23 , :24 , :25 , :26 , :27 , :28 , :29 , :30 , :31 , :32 ,
:33 , :34 , :35 , :36 , :37 , :38 , :39 , :40 , :41 , :42 , :43 , :44 , :45 , :46 , :47 , :48 ,
:251 , :252 , :253 , :254 , :255 , :256 , :257 ) ;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 5943 (100)| |
| 1 | NESTED LOOPS OUTER | | 9210 | 2536K| 5943 (1)| 00:01:12 |
| 2 | NESTED LOOPS OUTER | | 885 | 195K| 1784 (0)| 00:00:22 |
| 3 | NESTED LOOPS OUTER | | 255 | 55080 | 1019 (0)| 00:00:13 |
| 4 | INLIST ITERATOR | | | | | |
| 5 | TABLE ACCESS BY INDEX ROWID| TABLE1 | 255 | 35955 | 509 (0)| 00:00:07 |
| 6 | INDEX UNIQUE SCAN | SYS_C0010893 | 255 | | 258 (0)| 00:00:04 |
| 7 | TABLE ACCESS BY INDEX ROWID | TABLE2 | 1 | 75 | 2 (0)| 00:00:01 |
| 8 | INDEX UNIQUE SCAN | SYS_C0010774 | 1 | | 1 (0)| 00:00:01 |
| 9 | INDEX RANGE SCAN | SYS_C0010896 | 3 | 30 | 3 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | TABLE3 | 10 | 560 | 5 (0)| 00:00:01 |
| 11 | INDEX RANGE SCAN | FK_TABLE3 | 10 | | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------- Suddenly there is an INLIST ITERATOR that pops up and which seems to be started 255 times and the ‘quick’ query which in normal situation (small in list) executes in less than 1 second starts now taking more than 1 minute to complete.
As far as it is a third party software, they can’t change the query.
Do you have any idea on how to solve this problem?
Here below are the optimizer parameters
SQL> show parameter optimizer
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUEThanks in advance
Mohamed Houri -
Enq: TX - row lock contention in forms 10g sequency number generation
Iam Getting the Deadlock issue in oracle formdeveloper 10g database is 11g Acutually in our small Hospital organization using different forms generating entrying labrequest form finally save time
one sequency number will generated i have give procedure below every save criteria form using below procedure some time iam getting lock iam using blocksession query i have find out some
OSUSER
MACHINE
TERMINAL
PROGRAM
SQL_ID
LOGON_TIME
BLOCKING_SESSION_STATUS
BLOCKING_SESSION
EVENT
user423
UMCCDOM\LEVEL4-MICU
LEVEL4-MICU
PrjMcr.EXE
0ccngw7dfkmgb
23/09/2013 11:34:41 AM
VALID
277
enq: TX - row lock contention
SYSTEM
WORKGROUP\PRIAPPSVR
PRIAPPSVR
frmweb.exe
0ccngw7dfkmgb
23/09/2013 11:32:50 AM
VALID
186
enq: TX - row lock contention
SYSTEM
WORKGROUP\PRIAPPSVR
PRIAPPSVR
frmweb.exe
0ccngw7dfkmgb
22/09/2013 2:49:47 PM
VALID
277
enq: TX - row lock contention
SYSTEM
WORKGROUP\PRIAPPSVR
PRIAPPSVR
frmweb.exe
0ccngw7dfkmgb
23/09/2013 7:00:22 AM
VALID
186
enq: TX - row lock contention
user290
UMCCDOM\LEVEL2-N
LEVEL2-N
PrjMcr.EXE
0ccngw7dfkmgb
23/09/2013 10:28:06 AM
VALID
277
enq: TX - row lock contention
lock are happen after open the code i have find out used FOR UPDATE in procedure please tell me any alternative for this every labrequest form saving time using this procedure for generating prefix sequence number multiple user using with different systems
PROCEDURE Gsp_GenSeqNum (I_SvPrefixCd IN VARCHAR2,I_SvUserName IN VARCHAR2,
O_SvSeqNum OUT VARCHAR2) IS
--This Procedure generates the sequence number
--by retrieving the prefix based on the code
--supllied to the procedure.
CURSOR crSeqGenerator IS
SELECT Gsn_prefix_last_num, Gsn_prefix_year
FROM G_SEQUENCE_NUMBER
WHERE Gsn_prefix_Cd = I_SvPrefixCd
AND Gsn_prefix_year = TO_CHAR(SYSDATE,'YYYY')
FOR UPDATE OF Gsn_prefix_last_num;
udSeqNum G_SEQUENCE_NUMBER.Gsn_Prefix_last_num%TYPE;
udNextSeqNum G_SEQUENCE_NUMBER.Gsn_Prefix_last_num%TYPE;
udYear G_SEQUENCE_NUMBER.Gsn_Prefix_year%TYPE;
udPrefix G_SEQUENCE_PREFIX.Gsp_Prefix_Value%TYPE;
BEGIN
SELECT Gsp_Prefix_Value
INTO udPrefix
FROM G_SEQUENCE_PREFIX
WHERE Gsp_Prefix_Cd = I_SvPrefixCd;
OPEN crSeqGenerator;
FETCH crSeqGenerator
INTO udSeqNum,
udYear;
IF crSeqGenerator%FOUND THEN
udNextSeqNum :=udSeqNum + 1;
O_SvSeqNum := udPrefix||'/'||TO_CHAR(SYSDATE,'YY')
||'/'||LPAD(TO_CHAR(udNextSeqNum),6,'0');
ELSE
INSERT INTO G_SEQUENCE_NUMBER VALUES(I_SvPrefixCd,TO_CHAR(SYSDATE,'YYYY'),0,I_SvUserName,SYSDATE);
udSeqNum :=0;
udNextSeqNum :=udSeqNum + 1;
O_SvSeqNum:=UdPrefix||'/'||TO_CHAR(SYSDATE,'YY')
||'/'||LPAD(TO_CHAR(udNextSeqNum),6,'0');
END IF;
UPDATE G_SEQUENCE_NUMBER
SET Gsn_Prefix_last_num=udNextSeqNum
WHERE Gsn_Prefix_Cd = I_SvPrefixCd
AND Gsn_Prefix_year=TO_CHAR(SYSDATE,'YYYY');
CLOSE crSeqGenerator;
END Gsp_GenSeqNum;
Thanks
subbuThis application is inbuit with some modules VB (cath ,cardio)and oracle forms for required sequence number generation different time used this procedure whereever required the sequence Prefix generation.If i replace the procedure sequene to oracle standard sequency if the user cannot save the form unnessary sequency generated order is missing from sequence.
-
Enq: TX - row lock contention in TOP 5 wait event
DB version:11.1.0.7.0
I am having enq: TX - row lock contention in top 5 wait event.
AWR analyze period - 9-10(pm). During this time only one sql loader is running to insert the data. No other job are running. So there is no chance of other session blocking this session. is there any chance of row lock contention happen by same session.
SQL> SELECT INDEX_NAME,INDEX_TYPE,UNIQUENESS FROM DBA_INDEXES WHERE TABLE_NAME='DATA_DATA';
INDEX_NAME INDEX_TYPE UNIQUENES
CIDX BITMAP NONUNIQUE
VIDX BITMAP NONUNIQUE
Thanks.SQL> SELECT INDEX_NAME,INDEX_TYPE,UNIQUENESS FROM DBA_INDEXES WHERE TABLE_NAME='DATA_DATA';
INDEX_NAME INDEX_TYPE UNIQUENES
CIDX BITMAP NONUNIQUE
VIDX BITMAP NONUNIQUEYou have bitmap indexes here on a table being inserted into. Bitmap Indexes are another source of lock(and deadlock) in OLTP application. You said that the SQLloader was the unique active program but may be you are also triggering another procedure after the load. Procedure in which you might be using also automomous transactions and so on...
Check first if your table is subject to DML operation in a a multi-user concurrent accesss and in which case you have to get rid of those bitmap indexes
http://hourim.wordpress.com/2011/03/14/deadlock-%e2%80%93-part-1-bitmap-index/
Best regards
Mohamed Houri
www.hourim.wordpress.com -
Enq: TX - row lock contention in Select without for update
We have deployed a new Version of our Software on the test-system of our customer.
While the software runs fine on our Systems (Oracle EE 10.2.0.4 as well as Oracle EE 11.2.0.2 on EL 5.4 x86_64) it runs sluggish on our Customer's system (Oracle EE 10.2.0.4 on Solaris 10 x64).
During analysis of the problem I came across this:
SQL ID: Plan Hash: 3934983510
SELECT ts.message_id_t235
FROM t235_time_series ts,
t238_timeseries_reported tsr
WHERE ts.time_series_id_t235 = tsr.timeseries_id_t238
AND tsr.message_id_t238 = :b2
AND ts.current_state_t235 = :b1
AND ROWNUM = 1
call count cpu elapsed disk query current rows
======= ====== ======== ========== ========== ========== ========== ==========
Parse 0 0.00 0.00 0 0 0 0
Execute 8 0.01 *137.55* 0 8 5 0
Fetch 8 0.00 0.00 0 60 0 8
======= ====== ======== ========== ========== ========== ========== ==========
total 16 0.01 137.55 0 68 5 8
Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 90 (recursive depth: 1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
======================================== Waited ========== ============
*enq:* *TX* *=* *row* *lock* *contention* 281 0.64 *137.01*
********************************************************************************As you can see the statement is very primitive. The Tables used are very huge (100M+ Rows) but have no bitmap indexes. How can this statement wait on enq: TX = row lock contention?
Thanks in advance!
Best regards,
Sven
Edited by: user12182396 on Feb 4, 2011 5:43 AM
Edited by: user12182396 on Feb 4, 2011 6:02 AMuser12182396 wrote:
We have deployed a new Version of our Software on the test-system of our customer.
While the software runs fine on our Systems (Oracle EE 10.2.0.4 as well as Oracle EE 11.2.0.2 on EL 5.4 x86_64) it runs sluggish on our Customer's system (Oracle EE 10.2.0.4 on Solaris 10 x64).
During analysis of the problem I came across this:
SQL ID: Plan Hash: 3934983510
SELECT ts.message_id_t235
FROM t235_time_series ts,
t238_timeseries_reported tsr
WHERE ts.time_series_id_t235 = tsr.timeseries_id_t238
AND tsr.message_id_t238 = :b2
AND ts.current_state_t235 = :b1
AND ROWNUM = 1
call count cpu elapsed disk query current rows
======= ====== ======== ========== ========== ========== ========== ==========
Parse 0 0.00 0.00 0 0 0 0
Execute 8 0.01 *137.55* 0 8 5 0
Fetch 8 0.00 0.00 0 60 0 8
======= ====== ======== ========== ========== ========== ========== ==========
total 16 0.01 137.55 0 68 5 8
Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 90 (recursive depth: 1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
======================================== Waited ========== ============
*enq:* *TX* *=* *row* *lock* *contention* 281 0.64 *137.01*
******************************************************************************** As you can see the statement is very primitive. The Tables used are very huge (100M+ Rows) but have no bitmap indexes. How can this statement wait on enq: TX = row lock contention?
Are either of these tables subject to distributed transactions through database links ? If so then it is possible for a select statement to wait on a TX enqueue in mode 4 if it's trying to read a block which is subject to change by another tranaction that is stuck between the PREPARE and COMMIT phases of a "2 phase commit".
However, I have to say that don't know whether this would show up as: "enq: TX - row lock contention" or "enq: TX - contention". If you monitor the system for a while - checking v$lock for lock types TX, or query v$active_session_history (if you're licensed to use it) you may be able to check the lock mode.
If this is the problem then it's generally indicative of a networking problem of some sort - possibly simple congestion because of excess traffic.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, START and END the text with the tag {noformat}{noformat} (the word "code" in lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.) -
How to find the offending DML for "enq: TX - row lock contention"
Hello All,
1) How can I find the offending DML for "enq: TX - row lock contention". I have tracked down the Blocking and Waiting Sessions as well as the Database Object too. But i am not able to find the DML (with values of bind variables) or the row for which both these sessions are fighting for?
Current Wait Event: enq: TX - row lock contention
Current Wait Class: Application
Wait Duration: 5:15 (mm:ss)
P1: name|mode 1415053318
P2: usn<<16 | slot 12058642
P3: sequence 39951
Object: USERNAME.MEMBER 2) Also does *"enq: TX - row lock contention"* means Both the sessions are fighting for the same Row only or it can be different rows but same database block? If they are fighting for different rows, then can we try increasing the initrans of tables/indexes to prevent this wait.
Please advice.
Regards,
TommyThanks Randolf, Mark and Aman for your valuable inputs. We are using 10.2 and the lock mode held and requested is 6. And the Wait Event is "enq: TX - row lock contention".
Based on the above facts and based on Randolf's Blog, can we ignore the following cases?:
- Same unique key written by different sessions: Because mode held and requested in ym case is 6 whereas in Randolf example it is 6 and 4 respectively
- Unindexed foreign keys and modifications to parent table primary keys: Because Wait Event in my case is "enq: TX - row lock contention"
- Insufficient block space and ITL slot shortage: Because Wait Event in my case is "enq: TX - row lock contention" and not enq: TX - allocate ITL entry
- Segments with low MAXTRANS settings Only pre-10g: But Mine is 10g
And the possible scenarios left out scenarios are:
- Bitmap indexes
- Same Row modified by different sessions
I will now try to find out the sql/dml that is causing the problem. Thank you all for your help once again.
SESS ID1 ID2 LMODE REQUEST TY
Holder: 138 393224 1330 6 0 TX
Waiter: 140 393224 1330 0 6 TX -
Enq: TX - row lock contention
DB version: 10.2.0.3
Could someone provide the possible reasons for this type of lock. I have an update locks atleast once or more a day with this type of lock and will not be finished until I kill off the session.
I have run query below and also several queries to diagnose and also using diag and tuning packs.
select s1.username || '@' || s1.machine
|| ' ( SID=' || s1.sid || ' ) is blocking '
|| s2.username || '@' || s2.machine || ' ( SID=' || s2.sid || ' ) ' AS blocking_status
from v$lock l1, v$session s1, v$lock l2, v$session s2
where s1.sid=l1.sid and s2.sid=l2.sid
and l1.BLOCK=1 and l2.request > 0
and l1.id1 = l2.id1
and l2.id2 = l2.id2 ;The output is like:
1234 is blocking 1235
But, the session 1234 and 1235 are accessing two independant tables and there are NO referential constraints defined between these two. Also, when I try to get a sql_text for 1234, there is no output displayed. However, the session 1235 is running an update for one record.
Could someone let me know the possible reasons for this. I'm unable to find a solution. The update query runs so often and it's not blocking all the updates. There are only a few updates one or two per day will be blocked by other sessions and will not be completed until I kill off the session.
Thanks in advance for your suggestions.Thanks for the response. I'm unable to find sql_text for 1234 and the below is the SQL for 1235.
UPDATE tab1 SET col_2=:1 WHERE col_1=:2;The col_1 is the PK on a single column. So, it's updating a single record.
I have run the below query to get the object details of the sessions.
select do.object_name,object_type,sid
from v$session s, dba_objects do
where sid in (1234,1235)
and s.ROW_WAIT_OBJ# = do.OBJECT_ID ;
OBJECT_NAME OBJECT_TYPE SID
TAB2 INDEX 1234
TAB1 TABLE 1235 The blocking object type will be TABLE also sometimes. But, those two objects are independant. -
Guys,
I really appreciate your views on this.. Please can some one who have worked on RAC and have an understanding how RAC works, guide me.
We currently are running a loadtest on one of the new RAC system and we are seeing excessive row lock contention for one table. The table basically has very few rows, say about 6-8 and pretty much every user uses this table to lock rows before fetching some data from other tables. When have a heavy load, we see very high wait on this table and enq TX : Row lock contention.
What is the best way to avoid this ? Is there anyway, we can modify the design of the application and ensure locking.. The typical query that locks the rows in the table looks like this
SELECT WL0.CLUB_NAME, WL0.SCHEDULE_ID FROM VF_BINGO_NEXT_CLUB_DRAW WL0 WHERE ( WL0.CLUB_NAME = :1 ) FOR UPDATE As said, they table has only 6-8 rows, so query plan etc doesn't apply. Please can someone who have extensive application knowledge guide me thru ?
Many thanks in advance.
G> But is there a way to alliviate the concurrency issue, if there is a genuine
requirement to hold lock on a table. What other options do we have other
than locking ?
The purpose of a lock is to ensure data consistency - only 1 process can change that row. So what I find puzzling is why so many app sessions want to change that single row. What data does that row hold that requires continual change? Just what is the purpose of this data if it is consistently and continually changing? What business requirement does it attempt to solve?
To be honest, this sounds like a major design problem to me.
Like the surrogate key generator approach I mentioned. You create a PK_SEQUENCE table with columns (tablename, pk_value). Any insert against a table requires a lock on PK_SEQUENCE for the table being inserted into - a read of the PK_VALUE, incrementing it by one and then updating that row with the latest sequence. This way each INSERT gets a "nice sequential number" to use as surrogate key for new rows.
Even when this is done as an autonomous transaction, it introduces a very expensive resource - why? Because only one session at a time can be serviced by that resource.
If there are a lot of INSERTs into a table, this approach will quickly become a severe bottleneck as every single insert requires a new surrogate key value and a lock on that PK_SEQUENCE table to obtain that value.
This problem is solved by allowing/enabling such a resource to serve multiple sessions concurrently. Which is for example what Oracle Sequence objects do within this example I've described.
The bottom line is that the design you describe introduced a bottleneck by create an expensive and serialised resource that can only serve a single session at a time.
You need to re-look at the business requirement - and find another way to solve it than to introduce this type of serialised resource and contention. -
V$system_event, timeouts and row lock contention
Hello everyone,
What is the meaning of the total_timeouts column in the v$system_event view if it is related to the event "enq: TX - row lock contention"?
How can we have a timeout since "query timeout" is a non existent concept on Oracle?
Maybe I am wrong.
Regards.
CarlHello everyone,
What is the meaning of the total_timeouts column in
the v$system_event view if it is related to the event
"enq: TX - row lock contention"?
How can we have a timeout since "query timeout" is a
non existent concept on Oracle?
Maybe I am wrong.
Regards.
CarlThe value for timeouts, in this case, indicates the number of times one of the sessions had to wait a full 3 second time slice while waiting for a second session to either commit or roll back, in anticipation of a potential primary key violation. If the second session commits, the first session will receive an error indicating a primary key violation.
Test setup:
In session 2:
CREATE TABLE T1 (C1 VARCHAR2(20) PRIMARY KEY);
INSERT INTO T1 VALUES ('ORACLE');
In session 1:
INSERT INTO T1 VALUES ('ORACLE');
After executing tha above, allow 60 seconds to elapse after the insert in session 1, and then check the delta values in either V$SYSTEM_EVENT or V$SESSION_EVENT:
20 waits on ENQ: TX - ROW LOCK CONTENTION, 19 timeouts, 59.99 seconds, with an average wait of 2.9995 seconds.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.
Maybe you are looking for
-
Time Machine - won't back two external drives
At least I cannot get it to do what I want. Our MacBook died. Not sure what's wrong but it does not appear to be the hard drive. Also, that drive has not been backed up in a few months. The main drive is a 320 GB with 246 GB used. The Backup USB d
-
Adobe 6 professional Versus Adobe 8 professional
I work in the insurance field and it seems to be an issue where an Adobe 6 .pdf file is opened with Adobe 8 professional the formatting seems to be different. Is there away not to have that changed so it will not change automatically?
-
Soap Tester in WL 7.0/Workshop available for other generated services?
When creating a web service using WL 7.0/Workshop I get a Soap Tester. If I create a service in WL 7.0 using an Ant task service gen or client gen will I get a Soap Tester? What about web services written from scratch within WL 7.0? Any feedback woul
-
Try-catch & throw Exception Question
Method evenNumber can throw IOException, and the caller of method evenNumber (in this case, method evenNumberTest and method evenNumberTest2) should catch the IOException. Otherwise, it will have compile error as the one in method evenNumberTest2. My
-
Getting "generic error" when linking clips. Generic not a helpful word.
Getting "generic error" when linking clips. Generic not a helpful word.