Row Locking on Updates

In SQL, there is a specified FOR UPDATE NOWAIT function a part of the SELECT statement for the row. Is there a NOWAIT option for the UPDATE statement?
IE. Oracle documents a SELECT from <table> where <condition> FOR UPDATE NOWAIT to lock a row, but is there a similar UPDATE <table> SET <change> where <condition> NOWAIT?

Hi pl_sequel,
You could try using a user lock using the DBMS_LOCK package. The locks requested can have runtime specified names which means they can be tied more specifically to the action you are trying to perform rather than just a true/false gateway mechanism.
Regards
Andre

Similar Messages

How and when the database release a row lock?

Dear experts,
We are using the following statement to obtain a row lock in a table in the database(ORACLE of course),
SELECT * FROM {TABLE_NAME} WHERE ID = 1 for update
and if we succeed grabbing the row lock we will continue to issue a update statement every 30 seconds to preserve the lock as far as possible.
here is the update statement to preserve the lock,
UPDATE {TABLE_NAME} SET time = ? WHERE ID = 1.
As you see more longer we keep holding the row lock , more update statements are submitted in the pending transaction.
In normal case our application can grab the exclusive row lock and works for a long time,however sometimes a connection reset exception is thrown
and our application will close the connection(I assume the pending transaction will be rolled back by the database) and exit the JVM.
Since other applications will keep trying to grab the same row lock to become the master role,
we expect one of them can succeed but they are all failed because the database has not released the row lock as expected.
Can someone explain more details about how and when the row lock can get released in our use case?
Thanks,
SuoNayi
Edited by: SuoNayi on 2013-5-30 上午8:12

Hm. Is this part of an XA transaction by any chance? I know that Oracle maintains separate bookkeeping for such transactions which can cause rows to stay 'locked' even when the regular DBA views will indicate there is no user currently locking the record at all. I have no idea about the actual details and what you need to do to clean up such a situation, that is something a DBA should know and do.
If not... well this is more of a question for people who know the DBMS, which makes it a target for the Oracle DBMS forums. Java developers don't tend to have DBA-level knowledge of the database, you should ask the question where you have more chance of people with expertise answering stuff:
General Database Discussions

TX - row lock contention in SELECT query without update clause

Hi,
We are having problem in one of our application on production. The ASH report shows 'eq: Tx row lock contention' for only Select statements. There is no FOR UPDATE in the select statements. The exact statement is
enq: TX - row lock contention : SELECT COUNT (1) FROM Table1 WHERE col1= :1 AND col2= :1 AND col3= :1 AND ROWNUM = 1
enq: TX - row lock contention : SELECT MODULE_CD , MSG_DESC , SEVERITY FROM GS_ERROR_MSG WHERE MSG_NUM = :1
I don't know why the select are locking the table rows and resulting in waits..
Our environment is Oracle 10g and Forms & Reports..
Please help.
-- Prashant

Hi,
are you sure that there is no dml against the tables?
You can query v$active_session_history (eg column BLOCKING_SESSION) to see which session locked the row.
HTH..
- wiZ

How can I retain updates made in multiple locked rows and override scope rollback defined for row locking purposes ?

I have a set of stored procedures in SQL
One of which is called to build a list of entries to submit to a web service
Those queries are called by identical processes running on different machines, so to prevent duplicate processing we lock rows that are presently being processed.
BEGIN
TRAN TRAN1
SELECT t.[TransactionId],t.[ContentIdentifier]
FROM [dbo].[Transactions]
t WITH(READPAST,
UPDLOCK,
ROWLOCK)where
(t.Quarantined
<> 1)
COMMIT
A Second stored procedure simply updates the Quarantined flag.
My C# code
TransactionOptions transactionOptions
=
new
TransactionOptions();
transactionOptions.IsolationLevel
=
IsolationLevel.ReadCommitted;
transactionOptions.Timeout
=
new
TimeSpan(0,
10,
0);
using (TransactionScope
scopeMain =
new
TransactionScope(TransactionScopeOption.Required,
transactionOptions))
TransactionsReady = DAL.GetFilesForProcessingByServiceType(i);
using (TransactionScope
scopeSuppress =
new
TransactionScope(TransactionScopeOption.Suppress,
transactionOptions))
foreach (var
Transaction in TransactionsReady)
{ try
returnData = proxy.Submit(stuffToProcess);
using (var
scopeInner =
new System.Transactions.TransactionScope())
DAL.QuarantineTransaction(Transaction.TransactionId);
scopeInner.Complete();
scopeSuppress.Complete();
scopeMain.Complete();
The problem I experience is that if I have the Transaction Scope scopeSuppress uncommented, then the QuarantineTransaction stored procedure deadlocks.
However if I comment out the ScopeSuppress, while the process then works, if it is interrupted mid-way, then all of the Quarantine flags get reset, meaning the entire batch of items will get re-submitted next
pass (this is not desirable).
What I actually want to occur, is for the Quarantine flag to be retained on all processed records so that even if the program terminates unexpectedly, processed items remain processed but all the row locks are
released.
Does anyone know of a way to achieve this ?

The hour is late where I sit, so I don't have the time to dive into this in detail.
However, if memory serves, TransactionScopes defaults to Serializable isolation level, which may explain the deadlocks you are getting.
Erland Sommarskog, SQL Server MVP, [email protected]

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 can I use multiple row insert or update into DB in JSP?

Hi all,
pls help for my question.
"How can I use multiple rows insert or update into DB in JSP?"
I mean I will insert or update the multiple records like grid component. All the data I enter will go into the DB.
With thanks,

That isn't true. Different SQL databases have
different capabilities and use different syntax, That's true - every database has its own quirks and extensions. No disagreement there. But they all follow ANSI SQL for CRUD operations. Since the OP said they wanted to do INSERTs and UPDATEs in batches, I assumed that ANSI SQL was sufficient.
I'd argue that it's best to use ANSI SQL as much as possible, especially if you want your JDBC code to be portable between databases.
and there are also a lot of different ways of talking to
SQL databases that are possible in JSP, from using
plain old java.sql.* in scriptlets to using the
jstlsql taglib. I've done maintenance on both, and
they are as different as night and day.Right, because you don't maintain JSP and Java classes the same way. No news there. Both java.sql and JSTL sql taglib are both based on SQL and JDBC. Same difference, except that one uses tags and the other doesn't. Both are Java JDBC code in the end.
Well, sure. As long as you only want to update rows
with the same value in column 2. I had the impression
he wanted to update a whole table. If he only meant
update all rows with the same value in a given column
with the same value, that's trivial. All updates do
that. But as far as I know there's know way to update
more than one row where the values are different.I used this as an example to demonstrate that it's possible to UPDATE more than one row at a time. If I have 1,000 rows, and each one is a separate UPDATE statement that's unique from all the others, I guess I'd have to write 1,000 UPDATE statements. It's possible to have them all either succeed or fail as a single unit of work. I'm pointing out transaction, because they weren't coming up in the discussion.
Unless you're using MySQL, for instance. I only have
experience with MySQL and M$ SQL Server, so I don't
know what PostgreSQL, Oracle, Sybase, DB2 and all the
rest are capable of, but I know for sure that MySQL
can insert multiple rows while SQL Server can't (or at
least I've never seen the syntax for doing it if it
does).Right, but this syntax seems to be specific to MySQL The moment you use it, you're locked into MySQL. There are other ways to accomplish the same thing with ANSI SQL.
Don't assume that all SQL databases are the same.
They're not, and it can really screw you up badly if
you assume you can deploy a project you've developed
with one database in an environment where you have to
use a different one. Even different versions of the
same database can have huge differences. I recommend
you get a copy of the O'Reilly book, SQL in a
Nutshell. It covers the most common DBMSes and does a
good job of pointing out the differences.Yes, I understand that.
It's funny that you're telling me not to assume that all SQL databases are the same. You're the one who's proposing that the OP use a MySQL-specific extension.
I haven't looked at the MySQL docs to find out how the syntax you're suggesting works. What if one value set INSERT succeeds and the next one fails? Does MySQL roll back the successful INSERT? Is the unit of work under the JDBC driver's control with autoCommit?
The OP is free to follow your suggestion. I'm pointing out that there are transactions for units of work and ANSI SQL ways to accomplish the same thing.

Read only users and row locks

Can read-only users obtain row locks on non-temporary (i.e,. visible to other users) tables, for example through SELECT FOR UPDATE, even though they couldn't not ultimately modify said tables?

Yes.
Here is an example with Oracle XE 11G and HR schema:
Connecting as user having only CREATE SESSION and SELECT privilege on HR.JOBS table:
SQL> desc hr.jobs;
Name                                      Null?    Type
JOB_ID                                    NOT NULL VARCHAR2(10)
JOB_TITLE                                 NOT NULL VARCHAR2(35)
MIN_SALARY                                         NUMBER(6)
MAX_SALARY                                         NUMBER(6)
SQL> select * from session_roles;
no rows selected
SQL> select * from session_privs;
PRIVILEGE
CREATE SESSION
SQL> select owner, table_name, privilege from user_tab_privs;
OWNER                          TABLE_NAME
PRIVILEGE
HR                             JOBS
SELECT
SQL> select job_title from hr.jobs for update;
JOB_TITLE
President
Administration Vice President
Administration Assistant
Finance Manager
Accountant
Accounting Manager
Public Accountant
Sales Manager
Sales Representative
Purchasing Manager
Purchasing Clerk
JOB_TITLE
Stock Manager
Stock Clerk
Shipping Clerk
Programmer
Marketing Manager
Marketing Representative
Human Resources Representative
Public Relations Representative
19 rows selected.
SQL>Now connecting as HR following statement hangs:
SQL> connect hr/hr
Connected.
SQL> select * from jobs for update;Going back to first session:
SQL> update hr.jobs set min_salary=0;
update hr.jobs set min_salary=0
ERROR at line 1:
ORA-01031: insufficient privileges

How to release row lock by using jdbc

hi, currently we are using jdbc to create a connection and create a row lock , is there anyway to release the row lock? right now i am using resultset.close(), but this cause me problem since it release other resultset's row lock too. please help.

hi, from your post, i understood that u know how to do row locking..
How was it done ??
I'm currently looking for answer to do row locking in Microsoft Access...
These are the SQL stmt i've done without success..
SELECT * FROM BSPerson WITH UPDLOCK WHERE ID = 'P001';
SELECT * FROM BSPerson WHERE ID = 'P001' FOR UPDATE;
Both stmt having error........
Please help !
A miliion thanks....

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.

How to count the number of Rows to be Updated before Update takes place..

Hi all,
I have a requirement, where i have to count the number of rows to be updated before updating it. SQL%ROWCOUNT gives the no. of rows updated ( after update takes place). How do i get to know the count of no. of rows to be updated/inserted/ deleted. I was looking for a simple solution, as above SQL%Rowcount. But i couldn't find any. I can use a Function and Return the value which will give me number of rows to be updated, But is there any Simple Logic other than this.. or any count function. Your Help is Appreciated. Thanks!

If you really want to do this (I have no clue why you would need it), then you can piggy back on any existing pessimistic locking you may already have in place.
However, it would require two loops through the records of which you want to know the count before you update, and a second pass to update them.
I would really re-think the need for this, though.
SQL> create table t0304(c number);
Table created.
SQL> insert into t0304 select rownum from all_objects where rownum <= 10;
10 rows created.
SQL> commit;
Commit complete.
SQL> select * from t0304;
         C
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
10 rows selected.
SQL> declare
2    cursor mycursor is select * from t0304 where mod(c,2) = 0 for update;
3    i number := 0;
4 begin
5    for r in mycursor loop
6      i := i + 1;
7    end loop;
8    dbms_output.put_line(i);
9    for r in mycursor loop
10      update t0304 set c = c + 20 where current of mycursor;
11    end loop;
12 end;
13 /
5
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.
SQL> select * from t0304;
         C
         1
        22
         3
        24
         5
        26
         7
        28
         9
        30
10 rows selected.
SQL>Edited by: Steve Howard on Mar 4, 2011 5:57 PM

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>

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;

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 Locking on Updates

Similar Messages

Maybe you are looking for