Row lock class concurrency Monitor

Greetings,
We are getting ready to release my first webapp and need a �row-locking� class of sorts. For example, when a user logs in they have choices of searches where they can query the db. There is a link in the reulstSet that brings them to a detail screen. If that �detail� or row is currently open in a browser, I want to know about it.
I wonder about when a user closes their browser from the �detail� view, how can I know?
I am thinking about using a filter to track all active 'rows' and using an application scope class to track the 'locked' rows. I am developing on a Mainframe db (DMSii) that has essentially no modern capabilities. We use struts as a framework and EAServer as a container.
I could be so far from base that I am a spectator, so if there is any CONSTRUCTIVE advice or examples to point to, It would be greatly appreciated.
thanks,
mccools

You can use Rowset, RowsetEvent and RowSetListener implementation for tracking the rows.
"I wonder about when a user closes their browser from the �detail� view, how can I know?"
For this you can use the SessionBindingListener implementation.
Hope this helps.
Regards,
Rohan Kamat

Similar Messages

DB row lock from servlet.

Hi to all,
we're developing a J2EE application (with NO Ejb, actually we cannot use them) in which users can select orders from a DB2 database, modify the order, or create a new order. Any order is implemented by a class (Order.java) that exposes methods to execute SELECTs, INSERTs and UPDATEs to the db2 order table; the class mantains a Connection to the database and it's responsible to manage the connection, resultset, prepared statement and so on, and it's possible to specify if we want only read data (executing a select) or read for update the data (so, executing a select ... for update).
Users can access the data via web: the instances of Order are created by a servlet, which load the data and show them passing the Order instance to a JSP that fills up a form.
The problem is we want to lock the row corrisponding to the data mapped into Order instance. Initially, we thought we can instantiate an Order, load data with a select for update, saving on a session the instance, and redirect to the Jsp for visualization, without closing the connection; when the user send data via a form, the order is retrieved from the session, updates are performed and session closed. Unluckily, this approach does not work 'cause the Web Container rolls back automatically all unclosed connection. The row lock is lost.
In very few words, we are trying to keep-alive a Connection after a Servlet method ends. It seems that Servlet specification 2.3 does not allow this, while specification 2.2 does.
How can we avoid this problem ? We cannot just implement an application-level Lock manager, because the database is a legacy database and data are concurrently accessed by legacy applications.
Any suggestion would be very appreciated.
Thanx in advance !
Claudio.

Heck (can you say "hec|<" or will the **** filter nuke it?), I had a reply all written up.
And then I noticed you were cross-posting.
Please don't.

Index contention & row lock contention

Hi,
Recently our application loaded a handsome amount of data into our production database. The process took around 5 to 6 hours. During this process, we observed that the performance degraded.
The major wait events are
1) TX index contention (concurrency) and
2) ROW LOCK CONTENTION (application).
The sql which lead to index contention is a simple insert statement into a table x and row lock contention is into a table y.
Both x and y are major detail tables of our application. X has around 4 foreign keys, one foriegn key is referencing table y. the foreign key column x is indexed.
our database is on 10gR2 and using ASSM.
The data block wait event stats during the load process is as follows
select * from dba_hist_waitstat where snap_id between '21454' and '21462' AND WAIT_COUNT>0 and class='data block';
SNAP_ID DBID INSTANCE_NUMBER CLASS WAIT_COUNT TIME
21454 3937665896 1 data block 195089769 33899167
21455 3937665896 1 data block 195095958 33902183
21456 3937665896 1 data block 195096398 33902377
21457 3937665896 1 data block 195097225 33902843
21458 3937665896 1 data block 195628987 34037147
21459 3937665896 1 data block 195944006 34055524
21460 3937665896 1 data block 195944496 34055642
21461 3937665896 1 data block 196183308 34112433
21462 3937665896 1 data block 196213292 34127409
9 rows selected.
select snap_id,eq_type,req_reason, total_req#, total_wait#,failed_req#, cum_wait_time from dba_hist_enqueue_stat where snap_id between '21454' and '21462' and failed_req#>0 and eq_type='TM'
SYS@sqdb AS SYSDBA> /
SNAP_ID EQ REQ_REASON TOTAL_REQ# TOTAL_WAIT# FAILED_REQ# CUM_WAIT_TIME
21454 TM contention 682928465 14 2735 1750
21455 TM contention 682939964 14 2735 1750
21456 TM contention 682950668 14 2735 1750
21457 TM contention 682967980 14 2735 1750
21458 TM contention 682983109 14 2735 1750
21459 TM contention 682998136 14 2735 1750
21460 TM contention 683006816 14 2735 1750
21461 TM contention 683018179 14 2735 1750
21462 TM contention 683432945 14 2735 1750
9 rows selected.
I dont see any significant ITL contention on these objects compared to other contention. (from segment statistics)
SYS@sqdb AS SYSDBA> select b.object_name,a.snap_id, a.physical_writes_total,a.physical_writes_delta,a.physical_reads_total,a.physical_reads_delta, a.itl_waits_total,a.itl_waits_delta from dba_hist_seg_stat a,(select object_id,object_name from dba_objects where owner='ABCD') b where snap_id between '21454' and '21462' and a.obj#= b.object_id and a.itl_waits_delta> 0 order by itl_waits_delta,2,1;
OBJECT_NAME SNAP_ID PHYSICAL_WRITES_TOTAL PHYSICAL_WRITES_DELTA PHYSICAL_READS_TOTAL PHYSICAL_READS_DELTA ITL_WAITS_TOTAL ITL_WAITS_DELTA
IX4_Y 21462 37958 169 105668 174 38 1
IX4_X 21462 102380 1480 147196 5780 56 1
As per the application design, for each row of Y, there are multiple number of rows in X and it varies. What additional information do you think I should be collecting and any tips to fix the issue?
Thanks,
Murthy

hi
Are you using in your insert statement something like "SELECT ... FOR UPDATE"
post the result of this query during the error:
SELECT * FROM DBA_BLOCKERS;
SELECT * FROM DBA_WAITERS;

UnitOfWork doesn't release pessimistic row lock???

I have an application that polls a DB table for new "submissions", then forwards them to another server to handle them asynchronously. When the asynchronous response comes back, my application verifies that all response have been received from the server, then sends a combined response. My problem is that the asynchronous response listener threads appear to deadlock when pessimistically locking the submission row, even though the transaction that locked it has been closed for ~1s.
Some psuedocode may help explain the problem. This is my DB polling thread
while( true ) {
Submission s = getNextSubmissionAndLockPessimistically();
if( s == null )
return null;
Server s2 = getServerCapableOfRunning( s );
if( s2 != null )
return s2;
uow.revertAndResume();
I am worried that in the instance that a server capable of running the submission could not be found, or is too full, the UnitOfWork#revertAndResume method does not release the row lock for the submission. Are there any scenarios where this can occur?
On another note, I occasionally receive "Query sent to unactivated UnitOfWork" exceptions during the uow.revertAndResume() call. My code only uses the first UnitOfWork returned by EntityManager#getUnitOfWork(). Could the two be related? Does anyone have any ideas on how to fix this exception?
Thanks,
Dan

Thank you for the detailed description of how the locks are released; I mistakenly assumed the revertObject/revertAndResume would release them. I will refactor my code to create EntityManager/UnitOfWork instances in loop and release/close them instead of reverting.
As for the "unactivated UnitOfWork" exception, here is one of my stack traces:
Exception [TOPLINK-6027] (Oracle TopLink Essentials - 2.0 (Build b41-beta2 (03/30/2007))): oracle.toplink.essentials.exceptions.QueryException
Exception Description: Query sent to a unactivated UnitOfWork.
Query: ReadAllQuery(my.package.ServerLimits)
at oracle.toplink.essentials.exceptions.QueryException.querySentToInactiveUnitOfWork(QueryException.java:893)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2217)
at oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:937)
at oracle.toplink.essentials.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:86)
at oracle.toplink.essentials.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:76)
at oracle.toplink.essentials.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:90)
at oracle.toplink.essentials.indirection.IndirectList.buildDelegate(IndirectList.java:193)
at oracle.toplink.essentials.indirection.IndirectList.getDelegate(IndirectList.java:315)
at oracle.toplink.essentials.indirection.IndirectList.size(IndirectList.java:640)
at oracle.toplink.essentials.internal.queryframework.CollectionContainerPolicy.sizeFor(CollectionContainerPolicy.java:184)
at oracle.toplink.essentials.internal.indirection.TransparentIndirectionPolicy.getRealAttributeValueFromObject(TransparentIndirectionPolicy.java:252)
at oracle.toplink.essentials.mappings.ForeignReferenceMapping.getRealAttributeValueFromObject(ForeignReferenceMapping.java:370)
at oracle.toplink.essentials.mappings.CollectionMapping.getRealAttributeValueFromObject(CollectionMapping.java:559)
at oracle.toplink.essentials.mappings.CollectionMapping.getRealCollectionAttributeValueFromObject(CollectionMapping.java:574)
at oracle.toplink.essentials.mappings.CollectionMapping.mergeIntoObject(CollectionMapping.java:734)
at oracle.toplink.essentials.internal.descriptors.ObjectBuilder.mergeIntoObject(ObjectBuilder.java:2114)
at oracle.toplink.essentials.internal.descriptors.ObjectBuilder.mergeIntoObject(ObjectBuilder.java:2096)
at oracle.toplink.essentials.internal.sessions.MergeManager.mergeChangesOfOriginalIntoWorkingCopy(MergeManager.java:450)
at oracle.toplink.essentials.internal.sessions.MergeManager.mergeChanges(MergeManager.java:251)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.revertAndResume(UnitOfWorkImpl.java:3527)
at my.package.DbInterface.getNextSubmissionAndServer(DbInterface.java:460)
at my.package.PollingThread.waitForNextSubmission(PollingThread.java:175)
at my.package.PollingThread.run(PollingThread.java:122)
This particular error could be related to the DB lock obtained on the Server object, which has a One-To-Many relationship to the ServerLimits.
However, there is another exception that I am worried about:
Exception [TOPLINK-6027] (Oracle TopLink Essentials - 2.0 (Build b41-beta2 (03/30/2007))): oracle.toplink.essentials.exceptions.QueryException
Exception Description: Query sent to a unactivated UnitOfWork.
Query: ReadAllQuery(my.package.Submission)
at oracle.toplink.essentials.exceptions.QueryException.querySentToInactiveUnitOfWork(QueryException.java:893)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2217)
at oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:937)
at oracle.toplink.essentials.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:86)
at oracle.toplink.essentials.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:76)
at oracle.toplink.essentials.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:90)
at oracle.toplink.essentials.internal.indirection.UnitOfWorkValueHolder.instantiateImpl(UnitOfWorkValueHolder.java:160)
at oracle.toplink.essentials.internal.indirection.UnitOfWorkValueHolder.instantiate(UnitOfWorkValueHolder.java:232)
at oracle.toplink.essentials.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:90)
at oracle.toplink.essentials.indirection.IndirectList.buildDelegate(IndirectList.java:193)
at oracle.toplink.essentials.indirection.IndirectList.getDelegate(IndirectList.java:315)
at oracle.toplink.essentials.indirection.IndirectList.add(IndirectList.java:140)
at my.package.db.Transaction.addSubmission(Transaction.java:422)
at my.package.DbInterface.createNewSubmission(DbInterface.java:284)
at my.package.EngineInterface.executeObjectFn(EngineInterface.java:446)
at my.package.EngineInterface.executeBooleanFn(EngineInterface.java:412)
at my.package.EngineInterface.search(EngineInterface.java:252)
at my.package.mdb.RequestListenerBean.onMessage(RequestListenerBean.java:457)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.evermind.server.ejb.interceptor.joinpoint.EJBJoinPointImpl.invoke(EJBJoinPointImpl.java:35)
at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
at com.evermind.server.ejb.interceptor.system.DMSInterceptor.invoke(DMSInterceptor.java:52)
at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
at com.evermind.server.ejb.interceptor.system.SetContextActionInterceptor.invoke(SetContextActionInterceptor.java:44)
at com.evermind.server.ejb.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:119)
at com.evermind.server.ejb.InvocationContextPool.invoke(InvocationContextPool.java:55)
at oracle.j2ee.connector.messageinflow.MessageEndpointImpl.OC4J_invokeMethod(MessageEndpointImpl.java:297)
at RequestListenerBean_EndPointProxy_44242m8.onMessage(Unknown Source)
at oracle.j2ee.ra.jms.generic.WorkConsumer.run(WorkConsumer.java:268)
at oracle.j2ee.connector.work.WorkWrapper.runTargetWork(WorkWrapper.java:242)
at oracle.j2ee.connector.work.WorkWrapper.doWork(WorkWrapper.java:215)
at oracle.j2ee.connector.work.WorkWrapper.run(WorkWrapper.java:190)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:819)
at java.lang.Thread.run(Thread.java:595)
The code that caused this error is about as simple as it can get:
EntityManager em = (EntityManager) emf.createEntityManager();
UnitOfWork uow = em.getUnitOfWork();
try
// locate owning transaction and the RECEIVED_FROM_ESB type
Transaction tx = locate( Transaction.class, em, uow, txId );
ServerFunction fn = locate( ServerFunction.class, em, uow, fnId );
TrackingType trackingType = locate( TrackingType.class, em, uow, TrackingType.RECEIVED_FROM_ESB );
// create submission
Submission submission = new Submission();
submission.setPriority( priority );
submission.setRequestId( requestId );
submission.setNistId( nistId );
submission.setFunction( fn );
// create RECEIVED_FROM_ESB tracking status
TrackingStatus status = new TrackingStatus();
status.setTrackingType( trackingType );
status.setStatusTime( new Timestamp( System.currentTimeMillis() ) );
submission.addTrackingStatus( status );
tx.addSubmission( submission );
em.persist( submission );
uow.commit();
em.close();
return submission.getId();
finally
if( uow.isActive() )
uow.release();
if( em.isOpen() )
em.close();
There is a One-To-Many mapping from Transaction to Submission, and a One-To-Many mapping from Submission to TrackingStatus.
If anyone can offer any insight into what I'm doing wrong, I'd appreciate it!
Thanks,
Dan

Acquiring database row lock in session bean

I am getting a "ora-01002 fetch out of sequence" exception when trying to acquire a row lock by doing a select for update nowait sql command.
The code that is trying to get the lock is running inside a session bean deployed in both weblogic 6.0 sp2 and JBOSS 3.0.4. I have read some other threads in the JDBC forum and they suggest me to use the con.setAutoCommit(false) to avoid this error. This solution works on weblogic but not on JBOSS. In JBOSS I got a message saying I should not be setting the auto commit value in a container managed transaction.
Is there something I could do to do avoid the error without explicitly setting this value in the code?
Thanks.

Below are the settings in my ejb-jar.xml, weblogic-ejb-jar.xml, and jboss.xml. Can you see any wrong with the transaction settings?
Please help.
************ejb-jar.xml*************
<ejb-jar>
      <enterprise-beans>
            <session>
              <ejb-name>mybean.MybeanRemoteHome</ejb-name>
              <home>testing.mybean.MybeanRemoteHome</home>
              <remote>testing.mybean.MybeanRemote</remote>
              <ejb-class>mybean.Mybean</ejb-class>
              <session-type>Stateless</session-type>
              <transaction-type>Container</transaction-type>
            </session>
      </enterprise-beans>
      <container-transaction>
        <method>
          <ejb-name>mybean.MybeanRemoteHome</ejb-name>
          <method-intf>Remote</method-intf>
          <method-name>*</method-name>
        </method>
        <trans-attribute>Required</trans-attribute>
      </container-transaction>
</ejb-jar>
************weblogic-ejb-jar.xml*************
<weblogic-ejb-jar>
    <weblogic-enterprise-bean>
        <ejb-name>mybean.MybeanRemoteHome</ejb-name>
    <stateless-session-descriptor>
      <pool>
        <max-beans-in-free-pool>10</max-beans-in-free-pool>
        <initial-beans-in-free-pool>5</initial-beans-in-free-pool>
      </pool>
    </stateless-session-descriptor>
    <jndi-name>mybean.MybeanRemoteHome</jndi-name>
    </weblogic-enterprise-bean>
    <transaction-isolation>
          <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
          <method>
            <ejb-name>mybean.MybeanRemoteHome</ejb-name>
            <method-intf>Remote</method-intf>
            <method-name>*</method-name>
          </method>
    </transaction-isolation>
</weblogic-ejb-jar>
************jboss.xml*************
<jboss>
   <enterprise-beans>
       <session>
          <ejb-name>mybean.Mybean</ejb-name>
          <jndi-name>mybean.MybeanRemoteHome</jndi-name>
          <local-jndi-name>mybean.MybeanLocalHome</local-jndi-name>
       </session>
   </enterprise-beans>
   <resource-managers>
   </resource-managers>
</jboss>

Tuning row lock contention wait events

Hello everyone,
Working on 10g/windows
Top 5 events
EVENT TOTAL_WAITS TIME_WAITED AVG_MS PERCENT
CPU 9462339 48
enq: TX - row lock contention 12531 3660728 2921.34 18
control file parallel write 1300731 3088079 23.74 16
log file parallel write 1510503 1264080 8.37 6
log file sync 1072553 968007 9.03 5
Distribution of row lock wait during the last 4 days in the database server
END_INTERVAL_TIME TOTAL_WAITS TIME_WAITED_MICRO AVG_WAIT_MS
2008-04-01 16:00:58 909 2721008230 2993.41
2008-04-01 15:00:27 50 149941140 2998.82
2008-03-31 12:00:42 193 575595397 2982.36
2008-03-29 23:00:13 172 513058700 2982.9
2008-03-29 22:00:37 164 483940046 2950.85
2008-03-27 22:00:35 565 1667120838 2950.66
2008-03-26 18:00:59 348 1042918982 2996.89
My analysis:
It's obvious that the row lock contention wait time is huge, and this direct me to find out SQL stmt, causing this.
all the SQL statement was SELECT ....... FOR UPDATE stmt.
I was also able to find out locked tables.
My tuning idea:
1. I'm thinking to reorganize hot tables as well as their indexes, but by instinct it seems to not give so much value to avoid the huge row lock wait time.
2. I'm also seeing if I can reduce the number of rows per block, by increasing PCTFREE and diminishing PCTUSED, so the contention will spread over many blocks instead of one heavy block.
Question
As SQL stmt related to those locked tables are select ... for update, how could I tune this kind of stmt?
Does someone have other idea to come up with this row lock contention?
Tanks for your effort and help

Taking another look at your suggested function based index, it depends on the data type of the DEV.POS_FOLIO_ID.POS_FOLIO_ID column. If the column is defined as a number, and it is a primary key, there will already be a usable index on that column.
Yesterday, I wrote this: "Once I understood why or how the sessions were trying to insert duplicate primary key values, I would try to determine why the average number of seconds for the wait event is almost 3 seconds (maybe a timeout)."
After fixing the formatting of the top 5 wait events (total duration unknown):
EVENT                        TOTAL_WAITS TIME_WAITED   AVG_MS PERCENT
CPU                                         94,623.39             48
enq: TX - row lock contention     12,531    36,607.28 2921.34    18
control file parallel write    1,300,731    30,880.79    23.74    16
log file parallel write        1,510,503    12,640.80     8.37     6
log file sync                  1,072,553     9,680.07     9.03     512,531 * 3 second time out = 37,593 seconds = 10.44 hours.
What if the reason for the 3 second average wait time is due to a timeout. I performed a little experiment... I changed a row in a test table and then made a pot of coffee.
In session 1:
CREATE TABLE T1 (
C1 NUMBER(10),
C2 NUMBER(10),
PRIMARY KEY (C1));
INSERT INTO T1
SELECT
ROWNUM,
ROWNUM*10
FROM
DUAL
CONNECT BY
LEVEL<=1000000;
COMMIT;I now have a test table with 1,000,000 rows. I start monitoring the changes in the wait events roughly every 60 seconds, and V$SESSION_WAIT and V$LOCK roughly 4 times per second.
Back in session 1:
UPDATE
T1
SET
C1=-C1
WHERE
C1<=100;I have now modified the first 100 rows that were inserted into the table, time to make the pot of coffee.
In session 2, I try to insert a row with a primary key value of -10:
INSERT INTO T1 VALUES (
-10,
10);Session 2 hangs.
If I take the third 60 second snap of the system wide wait events as the zero point, and the 11th snap as the end point. There were 149 waits on ENQ: TX - ROW LOCK CONTENTION, 148 time outs, 446.62 seconds of total time in the wait event, with an average wait time of 2.997450 seconds.
Rolling down to the session level wait events, SID 208 (my session 2) had 149 waits on ENQ: TX - ROW LOCK CONTENTION, for a total time of 446.61 seconds with an average wait time of 2.997383 seconds. All of the 149 waits and the wait time was in this one session that was locked up for the full duration of this time period because session 1 was making a pot of coffee.
Rolling down to V$SESSION_WAIT (sampled roughly 4 times per second): At the start of the third time interval, SID 208 has been in the ENQ: TX - ROW LOCK CONTENTION wait event for 39 seconds and is actively waiting trying to execute SQL with a hash value of 1001532423, the wait object is -1, wait file is 0, wait block is 0, wait row is 0, P1 is 1415053316, P2 is 196646, P3 is 4754.
At the end of the 11th time interval: , SID 208 has been in the ENQ: TX - ROW LOCK CONTENTION wait event for 483 seconds and is actively waiting trying to execute SQL with a hash value of 1001532423, the wait object is -1, wait file is 0, wait block is 0, wait row is 0, P1 is 1415053316, P2 is 196646, P3 is 4754.
Rolling down to V$LOCK (sampled roughly 4 times per second): I see that SID 214 (session 1) is blocking SID 208 (session 2). SID 214 has a TX lock in mode 6 with ID1 of 196646 and ID2 of 4754. SID 208 is requesting a TX lock in mode 4 with ID1 of 196646 and ID2 of 4754.
So, it seems that I need a faster coffee pot rather than an additional index on my table. It could be that the above process would have found that the application associated with SID 214 was abandoned or crashed and for some reason the lock was not released for a long period of time, a little less than 10.44 hours in your case.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Heavy row lock contention

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.

Row lock contention...

Hello,
I am working on Oracle 10.2.0.4 on AIX .
In awr reports we found 'row lock contention' as top wait events. As my knowledge There are two types of locks..
1. Deadlock - where oracle will automatically rollback the locking query and generate deadlock trace file.
2. A user session update some rows and not commit/rollback , so other sessions which need to lock same rows , were witing. So dba need to manully kill first
session which was holding lock.
We want to know , in which of above scenario in awr report we can see 'row lock contention' wait.
any idea ..

Ok, first, I think your definitions are a bit off.
There is the concept of a lock, or an enqueue. The terms 'lock' and 'enqueue' are synonymous, in Oracle.
A lock (or enqueue) protects a 'resource'. A TX (transaction) enqueue protects rows which have been locked. Only one transaction is permitted to modify a specific row in a specific table, at a time, for obvious reasons.
A row-level lock occurs when a session attempts to modify a row that another session has already locked. When that occurs, the session attempting the lock will wait on a TX enqueue.
These types of locks occur all the time in Oracle, and are not necessarily a bad thing. They are a sign that Oracle is protecting the integrity of your data, and that's a good thing.
However, when waits on row-level locks begin to dominate the response time of your application, then you have a problem. Generally, this is going to come down to your application design. How can you avoid concurrent sessions colliding on their updates to specific rows? This is something that only you, with your knowledge of your application, can answer.
Finally, you mentioned the term 'deadlock' before. A deadlock occurs when two or more sessions are simultaneously holding a lock that the other is waiting on, while waiting on a lock the other is holding.
A simple example would be as follows:
Consider table_a, with row1 and row2.
Session 1 takes a lock on row1, no problem.
Session 2 takes a lock on row2, no problem.
Now, session 1 attempts to take a lock on row2, but session 2 has lock, so it waits.
Now, session 2 attempts to take a lock on row1, but session 1 has lock, so it waits.
This is a deadlock. It would wait forever. But, the Oracle kernel has a deadlock detection mechanism. So, within 3 seconds, Oracle will detect a deadlock, and one of the sessions (usually the one that has been waiting the longest) will catch ORA-00060 deadlock detected, and statement level rollback will occur.
Hope that clarifies your questions and/or doubts,
-Mark

Row lock contention error to resolve

hi,
i m facing sever issue with row lock contention error for the statement and causing concurrency and application usage more making database vulnerable
UPDATE RULE_DATA SET RULE_DATA = :B3 , UPDATED_BY = :B2 , UPDATED_DATE = SYSDATE WHERE RULE_DATA_SEQ_ID = :B1
RETURNING PAT_GEN_DETAIL_SEQ_ID INTO :O0
in this query RULE_DATA_SEQ_ID is primary key and and having index too, how can i over come row lock contention error ,
if i try like this will it work
UPDATE RULE_DATA SET RULE_DATA = :B3 , UPDATED_BY = :B2 , UPDATED_DATE = SYSDATE WHERE RULE_DATA_SEQ_ID = :B1
RETURNING PAT_GEN_DETAIL_SEQ_ID INTO :O0
log errors into temp_log (sysdate||:O0 ) REJECT LIMIT UNLIMITED;
commit;
please help me;

select sid, sql_text from v$session s, v$sql q
where sid in (select sid from v$session
where state in ('WAITING')
and wait_class != 'Idle'
and event='enq: TX - row lock contention'
and (q.sql_id = s.sql_id or q.sql_id = s.prev_sql_id));
from the above query if found the sid and sql_text,
actually three procedures been called at once as a batch from java and given auto commit at once for the batch;
and in one of the procedure it is called by multiple times with different seq_id's
what i thought is by logging error can we skip the update statement from locking , this what happening
where v_tariff_detail_seq_id will be 25,26,28,29,30 like records
begin
IF v_tariff_detail_seq_id = 0 THEN
INSERT INTO pat_tariff_details (
tariff_detail_seq_id,
pat_gen_detail_seq_id,
ward_type_id ,
room_type_id ,
days_of_stay ,
requested_amount,
approved_amount,
maximum_allowed_amount,
notes,
added_by,
added_date )
VALUES (
pat_tariff_details_seq.NEXTVAL ,
v_pat_gen_detail_seq_id,
v_ward_type_id ,
v_room_type_id ,
v_days_of_stay ,
v_requested_amount ,
v_approved_amount,
v_maximum_allowed_amount,
v_notes,
v_added_by,
SYSDATE );
ELSE
UPDATE pat_tariff_details SET
room_type_id = v_room_type_id,
days_of_stay = v_days_of_stay,
requested_amount = v_requested_amount,
approved_amount = v_approved_amount,
maximum_allowed_amount = v_maximum_allowed_amount,
notes = v_notes,
updated_by = v_added_by,
updated_date = SYSDATE
WHERE tariff_detail_seq_id = v_tariff_detail_seq_id;
END IF;
end;
version is Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
Edited by: user13134817 on Nov 2, 2012 2:39 AM

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
Vamshi

The 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 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 Houri

Dears,
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 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 AM

user12182396 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,
Tommy

Thanks 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

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.
Carl

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.
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.

Row lock class concurrency Monitor

Similar Messages

Maybe you are looking for