Help with "select .... for update ... nowait" message

Hi,
How can I get the Oracle 10 g2 server return code issued when a cursor attemps to select ... for update nowait
and modify the control in the pl/sql block accordingly if one row is already involved in a transaction?
Many thanks
Edited by: JeanParis on Feb 9, 2009 2:57 AM
Hi again
i have done a search and I found ( dated 2004 ):
it will raise an exception 54. you have to catch it.
So that means I have to manage the cursor inside an inner block et loop until the lock is released?
Edited by: JeanParis on Feb 9, 2009 3:02 AM
Edited by: JeanParis on Feb 9, 2009 3:03 AM

The thing to be wary of is locking the session for ages. The cliched version of this problem is if the other user has gone to lunch without committing. Do we really want to tie up our user for an uunlimited amount of time?
So it's a good idea to embed the SLEEP() within a finite loop FOR in in 1..10 (or 5 or whatever) and then fail if we still can't get the lock. That at least allows our user to make a decision on whether to try again or do something else more interesting.
It becomes even important when the program is an autonomic procedure (batch job, daemon) because they are capable of spinning until the databse gets taken down.
Cheers, APC
blog: http://radiofreetooting.blogspot.com

Similar Messages

Should i use SELECT for update NOWAIT ?

Hi:
Do I need to use, in my pl/sql triggers and procedures, the SELECT FOR UPDATE NOWAIT sentence, to avoid locks before using update table sentences ? Is it common to use it on stored procedures and triggers?
Thanks
Joao Oliveira

First, what, exactly do you mean by "avoid locks"? I was interpreting that to mean "I want to avoid creating locks in my session that might block someone else", not "I want to avoid having my SELECT wait for locks to be released-- I want it to fail immediately". If you meant the latter, then SELECT ... FOR UPDATE NOWAIT would be what you want. If you meant the former, then pessimistic locking is not what you want.
Second, what sort of Oracle Forms architecture do you have? Are you still using old-school client-server applications? Or are you using a three-tiered approach? As Tom discusses in that thread, pessimistic locking is only an option when your client application is able to maintain database state across calls (i.e. client/server systems) not when you have stateless connections (which is the norm in the three-tier model). The old client-server versions of Forms would automatically and transparently do pessimistic locking. Since you didn't mention anything about your architecture, most of us probably assumed the more common stateless client architecture (note how Tom's answers progress over the 5 years in that thread as client/server architecture became less and less common).
Third, while your question is appropriate for either the Database - General forum or the SQL and PL/SQL forum, that generally means that you are free to post it either forum, not that it should be posted in both. The vast majority of the folks that hang out in one forum hang out in the other. It's also rather frustrating to answer a post in one forum only to discover that there is another post in a different forum where someone else had already covered the same points half an hour earlier or to discover that there was additional information in another thread that might have changed your answer.
Fourth, if you are going to do pessimistic locking, that requires that you are able to maintain state across various database calls, that you are locking on the lowest possible level of granularity, and that you are able to time out sessions relatively aggressively to ensure that someone doesn't open a record, thereby locking it, go to lunch (or have their system die) and then block everyone else from working. Assuming that is the case, and that you have some reasonable way to handle the error that gets generated other than simply retrying the operation, adding NOWAIT is certainly an option. Most applications, particularly those getting written today, cannot guarantee all these things, so pessimistic locking is generally not appropriate there.
Looking at your other thread (where there is new information that would be useful in this discussion, one of the reasons that multiple threads are generally a bad idea), it seems that you have an ERP application and you are concerned about the performance of entering orders. Obviously, there shouldn't be any locking issues on the ORDER or ORDER_DETAILS tables, assuming that multiple users aren't going to be inserting the same order at the same time. The contention would almost certainly come when multiple orders are trying to update the STOCK and INVENTORY tables, since multiple orders presumably rely on the same rows in those tables. In that case, I'm not sure what adding a NOWAIT would buy you-- unless you were going to roll back the entire order because someone is updating the STOCK row for #2 pencils and your order has an item of #2 pencils, you'd have to keep retrying the operation until you were able to modify the STOCK row, which would be less efficient than just letting that update block until the row was free.
Now, you could certainly redesign the application to minimize that contention by not trying to update what I assume are aggregate tables like STOCK and INVENTORY directly as part of your OLTP processing or, at least, by minimizing the time that you're locking a row. You could, for example, make STOCK and INVENTORY materialized views rather than tables that refresh ON COMMIT, which should decrease the time that your locks are held. You could also have those tables refreshed asynchronously, which would be even more efficient but may require that you reasses your holdback requirements.
Justin

Trigger with SELECT-FOR-UPDATE

There is a trigger on a table, which updates a particular column with SYSDATE BEFORE an INSERT OR UPDATE in the table.
CREATE OR REPLACE TRIGGER my_schema.trg_Order
BEFORE INSERT OR UPDATE
ON my_schema.ORDER
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
:NEW.LAST_UPDATE_DATE := SYSDATE;
END;
If I update the record using PL/SQL with SELECT-FOR-UPDATE & then UPDATE, the column LAST_UPDATE_DATE is not updated with the SYSDATE.
But if it is done by using the UPDATE Statement, then the column LAST_UPDATE_DATE is correctly updated with the SYSDATE.
Why? How can I ensure that for SELECT-FOR-UPDATE & then UPDATE will also update the LAST_UPDATE_DATE with SYSDATE.

The Table Order has a BLOB column.

Lock Cascade With Select for UPDATE

If I had a employee table and a phone table with a parent/child relationship and a primary key constraint on the employee table-will issuing a select for update on the employee also lock the corresponding child rows on the phone table ?
If not how can I bring this about ?

You only need two sessions:
First session: Issue the 'select for update'
statements for the row(s) in both tables, don't
rollback or commit
Second session: try to update a row that you tried to
lock in the first session (with NOWAIT).
Thanks. I can try this definitely. A basic question.
You are asking me to do a join on both the tables right ?
Not two individual SQL statements ?
Updating the primary key is known as a Bad Idea (tm).
The key should never be touched because it should be
meaningless. When you have a column that holds 'real'
information it is no candidate for a primary key.
Rgds,
GuidoYes I am aware of that. I was just wondering what is the meaning behind this statement from this link ?
http://www.akadia.com/services/ora_locks_survival_guide.html
And the exact phrase from that link under the section Referential Integrity Locks (RI Locks)
"RI constraints are validated by the database via a simple SELECT from the dependent (parent) table in question-very simple, very straightforward. If a row is deleted or a primary key is modified within the parent table, all associated child tables need to be scanned to make sure no orphaned records will result. "
Thanks again.

Inconsistent Locking with Select for Update

Hi,
I seem to be having some issues in using SELECT FOR UPDATE and was hoping to get some insight from the Oralce Guru's out there.
I have a J2EE application, running in WebLogic 8.1.4 using Oralce 9.2.0.1.0.
The application contains code that requires locking to be done on a specific table with multiple transactions (tx) requesting the same lock. Eg:
Tx 1: Select * from Zone where Zoneid = 'Zone1' for update (Obtains lock)
Tx 2: Select * from Zone where Zoneid = 'Zone1' for update (waits)
Tx 100: Select * from Zone where Zoneid = 'Zone1' for update
Tx1 commits.
It appears that the following transactions, i.e. Tx2 - Tx100 do not seem to execute in the order the lock was requested. That is Tx 100 always appears to be the second last transaction to execute, after which some arbitrary transaction between Tx2 - Tx99 will execute after Tx100 has committed.
This seems to tell me that the lock is not being handed in a FIFO manner and is causing us great pain as our data is not longer consistent.
Does anyone know how i might be able to trace which transaction is being awarded the lock? Also if anyone has any suggestion on how to troubleshoot/solve this issue, greatly appreciated.
TIA
Prem

Oracle does not have a lock queue/manager at all. The locked status of a record is essentially an attribute of the record itself. It is stored on the datablock header. When a transaction requests a lock and can't get it, and is willing to wait (SELECT FOR UPDATE without NOWAIT), it first spins while waiting for the lock (four times as I recall), then sleeps waiting for the lock. The the more times it sleeps before getting the lock, the longer it will sleep before trying again.
What is likely happening here is that transaction 100 is still spinning when transaction 1 commits, so checks back more frequently and gets the lock first. The rest get the lock whenever they wake up and noone else has taken the lock.
If you need the transaction to occur in order, then I do not think you can use Oracle's native locking mechanism. Depending on what exactly you are trying to do, you may want to look at Advanced Queueing, or possibly the built-in package DBMS_LOCK.
HTH
John

[ORACLE 9] Select For Update Nowait - Managing the Nowait

Hi,
Our application ( Oracle E Business R11) has a Form that allows Updates.
The problem is, when a user updates a record in the form, we want to prevent another user to open the same form, to avoid locks.
So I thought that I could
a) issue a 'select ...for update nowait',
b) get a code from Oracle
c )and use this code to prevent the form to be reopened.
I tried catching the Nowait in the exception section but I cannot get it to work.
Here is my code:
declare
v_var varchar2(40) := '---';
lv_nom           tmp_delegue_jbm.del_nom%type;
begin
v_var := 'Phase 1';
select   del_nom
into     lv_nom
from     tmp_delegue_jbm
where    del_id = 3
for update of del_nom nowait;
dbms_output.put_line( 'Phase: ' || v_var );
v_var := 'Phase 2';
update tmp_delegue_jbm
set del_nom = del_nom || ' in'
where del_id = 3;
dbms_output.put_line( 'Phase: ' || v_var );
exception
   when others then -- Should deal with the nowait situation
         dbms_output.put_line( 'Error: ' || v_var || ' - ' || sqlerrm );
end;
[End Code]
Many thanks

Far easier to poke a value into memory using DBMS_APPLICATION_INFO.SET_ACTION or SET_MODULE and have any session calling the form check first to see of another session has it already opened. Just make sure your exception handlers clear the lock.
http://www.morganslibrary.org/reference/dbms_applic_info.html

SELECT FOR UPDATE NOWAIT

Hi everyone!
I have procedure that looks like this:
procedure set_expired_users(
    p_QID   integer,
    p_Value integer default 1)
is
    l_mdate timestamp(3) := null;
begin
    l_mdate := get_mdate(p_Value);
    MERGE INTO cached_lists cl
    USING (SELECT distinct s.rootof as list_id, p_Value as is_expired, l_mdate as mdate
           FROM   zzz_userrelflat f, zzz_users u, zzz_temp_nn z, speclists s, lists_table lt
           WHERE u.grp <> 1
                  AND f.userm = u.id
                  AND lt.id = z.id
                  AND f.userg = lt.ra
                  AND z.qid = p_QID
                  AND userm <> -2
                  AND s.ruser = userm) t
    ON (cl.list_id = t.list_id)
    when matched then
      UPDATE SET cl.is_expired = t.is_expired, cl.mdate = decode(t.mdate, null, cl.mdate, t.mdate)
    when not matched then
      INSERT VALUES (t.list_id, t.is_expired, l_mdate);
end set_expired_users;As you can see there is no commit, commit executes in other stored procedures after that. in some cases I have bottleneck(enq TX), I rewrote procedure:
procedure set_expired_users(
    p_QID   integer,
    p_Value integer default 1)
is
    l_mdate timestamp(3) := null;
    busy_lock exception;
    PRAGMA exception_init(busy_lock,-54);
      cursor cur_upd is
    SELECT 1 from cached_lists cl where cl.list_id in (SELECT distinct s.rootof as list_id
           FROM   zzz_userrelflat f, zzz_users u, zzz_temp_nn z, speclists s, lists_table lt
           WHERE u.grp <> 1
                  AND f.userm = u.id
                  AND lt.id = z.id
                  AND f.userg = lt.ra
                  AND z.qid = p_QID
                  AND userm <> -2
                  AND s.ruser = userm) FOR UPDATE NOWAIT;
begin
open cur_upd;
    l_mdate := get_mdate(p_Value);
   MERGE INTO cached_lists cl
    USING (SELECT distinct s.rootof as list_id, p_Value as is_expired, l_mdate as mdate
           FROM   zzz_userrelflat f, zzz_users u, zzz_temp_nn z, speclists s, lists_table lt
           WHERE u.grp <> 1
                  AND f.userm = u.id
                  AND lt.id = z.id
                  AND f.userg = lt.ra
                  AND z.qid = p_QID
                  AND userm <> -2
                  AND s.ruser = userm) t
    ON (cl.list_id = t.list_id)
    when matched then
      UPDATE SET cl.is_expired = t.is_expired, cl.mdate = decode(t.mdate, null, cl.mdate, t.mdate)
    when not matched then
      INSERT VALUES (t.list_id, t.is_expired, l_mdate);
        close cur_upd;
      exception
when busy_lock then
    null;
end set_expired_users;Is this a good method to exclude enq TX?
Sincerely,
Pavel.

In my opinion, you shouldn't rewrite that procedure, but you should rethink (ie. streamline) the overall transaction and try to reduce the wait times between the procedure call and the commit/rollback.

Can Someone help with SQL for update ?

Hi,
can someone help me with this code
2 tables.
table 1 = User_master
table 2 = update_users
I need to update user_master like so...
update user_master
set status = 'I'
where user_id IN ()
problem is I have to over 10k user_id to update.
So created new table called update_users and imported all user_id's into that table.
How can I read all user_id's from that table, then update user_master status column for all
users id's found in update_users ?
I already tried this...
update p.user_id from user_master p
set status = 'I'
where user_id = (select user_id from update_users where p.user_id=user_id)
It did not work -
ERROR at line 2:
ORA-01427: single-row subquery returns more than one row
Thanks,

There are no duplicates. Each user_id is unique.Are you sure? the error message indicates otherwise. You might see if the following query returns any rows;
select user_id, count(*)
from update_users
group by user_id
having count(*) > 1;Also, you might want to post the exact statement that you used to generate the error. The statement that you posted raises an error de to the syntax;
update p.user_id from user_master p
set status = 'I'
where user_id = (select user_id
                 from update_users
                 where p.user_id = user_id)
ORA-00971: missing SET keywordPerhaps you ran something like;
select * from user_master;
   USER_ID STATUS
         1 A
         2 A
         3 A
select * from update_users;
   USER_ID
         1
         2
update user_master p
set status = 'I'
where user_id = (select user_id
                 from update_users
                 where p.user_id = user_id);
2 rows updated
select * from user_master;
   USER_ID STATUS
         1 I
         2 I
         3 A

JDBC-thin on Solaris 2.7, 1002 on "FOR UPDATE NOWAIT"

Has there been a patch to allow SELECT... FOR UPDATE NOWAIT
in the jdbc thin connection layer?
I have a program which runs transactions against Oracle 7.3 or
8.05, and I'm finding that it works fine on my NT workstation
against, 7.3.4....
But when I run it against oracle 8.0.5 from a Solaris 2.7 system,
I'm getting ORA-1002 errors whenever I select for update nowait.
I'm oracle has a fix for this, but I haven't seen it yet.
I did see a message about BUG 597589 posted on 02-Sep-1998.
Was this ever fixed? The BUG database makes no mention of it.
The only work-around seems to be to set autocommit, but I suspect
that will lead to deadlocks in my application, if it even works!
Has anyone else dealt with this problem?
Thanks in advance,
Kevin Fries
null

Has there been a patch to allow SELECT... FOR UPDATE NOWAIT
in the jdbc thin connection layer?
I have a program which runs transactions against Oracle 7.3 or
8.05, and I'm finding that it works fine on my NT workstation
against, 7.3.4....
But when I run it against oracle 8.0.5 from a Solaris 2.7 system,
I'm getting ORA-1002 errors whenever I select for update nowait.
I'm oracle has a fix for this, but I haven't seen it yet.
I did see a message about BUG 597589 posted on 02-Sep-1998.
Was this ever fixed? The BUG database makes no mention of it.
The only work-around seems to be to set autocommit, but I suspect
that will lead to deadlocks in my application, if it even works!
Has anyone else dealt with this problem?
Thanks in advance,
Kevin Fries
null

FOR UPDATE NOWAIT Fails to Detect Lock

Locking a bitmap indexed row would cause other rows locked. I heard that, if FOR UPDATE NOWAIT is used on these accidentally locked rows (Oracle SQL High Performance Turning by Prentice hall), it may not be able to detect the lock. Is it true? I cannot find related documenation from Oracle's manual. And, what should we do to prevent an incorrect lock status returned by FOR UPDATE NOWAIT?

SELECT FOR UPDATE NOWAIT detects locks affected DATA blocks.
Look the example below:
SQL> create table t1 (id number, bit_col number);
Table created.
SQL> begin
2 insert into t1 values(0,1);
3 insert into t1 values(1,1);
4 insert into t1 values(2,2);
5 insert into t1 values(3,3);
6 insert into t1 values(4,4);
7 end;
8 /
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.
SQL> create bitmap index t1_bit on t1(bit_col);
Index created.Now in session 1 we change the bitmap-indexed column and it affects
index node:
SQL> update t1
2 set bit_col = 4
3 where id = 2;
1 row updated.In accordance to bitmap index structure this operator locks the index section
the locked row pertains to:
2th session waits for the lock release even when it tries to lock another row -
two rows pertain to the same index section which is locked by the first session:
SQL> update t1
2 set bit_col = 2
3 where id = 3;After rollback in the first session the second one gets the resource:
SQL> update t1
2 set bit_col = 2
3 where id = 3;
1 row updated.Now lets do rollback in both and repeate the first UPDATE in the first session:
SQL> update t1
2 set bit_col = 4
3 where id = 2;
1 row updated.In the second session we can lock the row (not index section) using
SELECT FOR UPDATE:(in contrast with UPDATE statement which changes
indexed column):
SQL> select * from t1 where id=3 for update nowait;
ID BIT_COL
3 3But certainly we detect row-level lock in the data block for ID = 2:
SQL> select * from t1 where id=2 for update nowait;
select * from t1 where id=2 for update nowait
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specifiedRgds.

Disallow select for update

Hi,
I am making a read only user, with select rights on all of the tables in another scheme. How do I dissalow this user to lock the production table with select for update?
Regards
Nico

Good idea in principle, but there may be more efficient solutions than DISTINCT. Any operation which prevents view merging appears to work (or rather not work) e.g.
CREATE OR REPLACE VIEW view_name
AS
   SELECT /*+ NO_MERGE */ column_name
   FROM   table_name;...is sufficient to raise ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc. when attempting SELECT ... FOR UPDATE.
It is important to note though that /*+ NO_MERGE */ could theoretically be ignored by the optimizer - another cheap alternative you might consider would be to reference ROWNUM in the view definition, e.g.
CREATE OR REPLACE VIEW view_name
AS
   SELECT column_name
   FROM   table_name
   WHERE ROWNUM >= 1;

Memory Leak - select for update

Hi All.
Doing an application using OCI 8.1.7 I faced with a memory leak. (or it seems to). The leak is caused by OCIStmtExecute with SELECT FOR UPDATE statement when the iters parameter of that function is 0. In all other cases it works Ok. Below you can find a code causes a leak:
const char* sqlStatement = "select integercol from test_types for update";
OCIStmt* ociStatementHandle = 0;
OCIHandleAlloc(ociEnvHandle,(dvoid **)&ociStatementHandle,
OCI_HTYPE_STMT, (size_t) 0, (dvoid **) 0));
OCIStmtPrepare(ociStatementHandle, ociErrorHandle,
(text*)sqlStatement, strlen(sqlStatement), OCI_NTV_SYNTAX, OCI_DEFAULT));
int int_test;
OCIDefine* ociDefineHandle = 0;
OCIDefineByPos(ociStatementHandle, &ociDefineHandle, ociErrorHandle,
1, (dvoid *)&int_test, (sword) sizeof(int), SQLT_INT, (dvoid *) 0, (ub2 *)0,
(ub2 *)0, OCI_DEFAULT));
ub4 iters = 0; // (0 causes a leak)
for( int i=0; i < 100000; i++ )
OCIStmtExecute(ociServiceHandle, ociStatementHandle, ociErrorHandle, iters, (ub4) 0, (CONST OCISnapshot *) NULL, (OCISnapshot *) NULL, OCI_DEFAULT));
If I change iter to 1 the leak disappears, but it is not suitable of course. Oracle documentation says following:
iters (IN)
For non-SELECT statements, the number of times this statement is executed is equal to iters - rowoff.
For SELECT statements, if iters is non-zero, then defines must have been done for the statement handle. The execution fetches iters rows into these predefined buffers and prefetches more rows depending upon the prefetch row count. If you do not know how many rows the SELECT statement will retrieve, set iters to zero.
This function returns an error if iters=0 for non-SELECT statements.
Did somebody face the problem? Do you know how to fix it?
null

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Bjorn Engsig ([email protected]):
Are you saying, that the memory leak disappears if you don't do 'for update' in the query?
Also, is the memory leak on the client or server side?<HR></BLOCKQUOTE>
Yes, the leak appeares ONLY for 'select ... for update' statements.
It is a client side leak, the client is Win2000.
null

Help, question about "select ... for update nowait"

There is a proc code. In the beginning of the code, I used a SQL "select ... for update nowait" in order to prevent from another proc executing at the same time. When the case happens, "-54, ORA-00054: resource busy and acquire with NOWAIT specified" will be printed in the screen.
But there is a question: I need to print sth to indicate "another proc is running". I used "if (sqlca.sqlcode == -54)" as precondition, such as:
if (sqlca.sqlcode == -54) {
printf("There is another proc running.\n");
However, this line will not be printed. I doubt that the code quits directly when using "select ... for update nowait" so as not to set value (-54) to sqlca.sqlcode.
So, could you suggest whether there is another way that I can use to print "There is another proc running" when another proc is running?
Thx a lot for your kindly reply.

Yes, that link. Scroll down a bit and you will see:
The calling application gets a PL/SQL exception, which it can process using the error-reporting functions SQLCODE and SQLERRM in an OTHERS handler. Also, it can use the pragma EXCEPTION_INIT to map specific error numbers returned by raise_application_error to exceptions of its own, as the following Pro*C example shows:
EXEC SQL EXECUTE
/* Execute embedded PL/SQL block using host
variables v_emp_id and v_amount, which were
assigned values in the host environment. */
DECLARE
null_salary EXCEPTION;
/* Map error number returned by raise_application_error
to user-defined exception. */
PRAGMA EXCEPTION_INIT(null_salary, -20101);
BEGIN
raise_salary(:v_emp_id, :v_amount);
EXCEPTION
WHEN null_salary THEN
INSERT INTO emp_audit VALUES (:v_emp_id, ...);
END;
END-EXEC;
This technique allows the calling application to handle error conditions in specific exception handlers.

Error message: "playlists selected for updating no longer exist"

I tried to update my ipod nano and I guess I had deleted a playlist, but since then, I have not been able to update. Every time I try, I get the following message:
"Cannot be updated because all of the playlists selected for updating no longer exist."
I haven't been able to highlight which playlists are selected to begin with.
I read through the manual and thought that maybe rebooting the whole system might work. So I deleted Itunes from my computer and re-installed.
Then I tried re-setting my ipod. So now I have nothing on my ipod.
I also deleted everything from my library, thinking it might help to start from scratch. Nothing has worked.
How do I "select" and "unselect" playlists so I can get up and running again?

Here you go.
http://discussions.apple.com/thread.jspa?messageID=607312&#607312

SELECT FOR UPDATE with the SKIP LOCK clause

Hi,
I have a query regarding the SELECT FOR UPDATE with the SKIP LOCK clause.
Whether this will be really good for parallel processing.
Also if we are selecting a set of records in a cursor whether the lock will be done at the records level once we fetch the records?
Also do we have any known issues with this one?
We are trying to figure out whether this will fit for business requirement, we are trying to do a implement a threading kind of thing for our stored procedure invocation in background using shell script.
Any suggestion or feedback on this will be helpful for us.
Thanks a lot for the support given....
Regards,
Basil Abraham.

http://www.oracle.com/technology/oramag/oracle/08-mar/o28plsql.html
Please read the above thread for few information...Thanks!

Help with "select .... for update ... nowait" message

Similar Messages

Maybe you are looking for