Performance of using a Select For Update vs a correlated subquery

I was wondering wether or not it is more effecient to use the
Select ... For Update (with a cursor etc.) versus a correlated
subquery.
I can accomplish the same thing with either however performance
at our site is an issue.

Use select for update cursor as that is faster as it updates
based on the rowid. One thing to keep in mind is that rowid is
session specific and the rows to be updated get locked so that
nobody else can update them till the lock is released. I have
had very good performance results with these cursors.
Good luck !
Sudha

Similar Messages

Select for update no wait distributed polling strategy

I have an esb process which currently uses 'logicaldeletepolling strategy'.
I need to change it to use the 'select for update no wait' distributed polling strategy.
What steps do I need to perform on the existing process ?

Hi,
Try: http://download-east.oracle.com/docs/cd/B31017_01/integrate.1013/b28994/adptr_db.htm#sthref558 (Oracle® Application Server Adapters for Files, FTP, Databases, and Enterprise Messaging User's Guide
10g Release 3 (10.1.3.1.0)
Part Number B28994-02).
Also you can reconfigure DB adapter (I think this's the best way): laucnch adapter configuration wizard in JDev and at step 9 (adapter options) check distributed polling checkbox (query now contains for update clause).

Select for update no wait polling strategy for an esb process

I have an esb process which currently uses 'logicaldeletepolling strategy'.
I need to change it to use the 'select for update no wait' distributed polling strategy.
What steps do I need to perform on the existing process ?

What do you mean by
same record is opened Do you mean, queried by another form? This is not possible.... other session can always query a table (with approp privs)
You are confusing me....
1) you update DEPT using a form (not clear which one - but it is irrelevant)
2) Another form is querying the DEPT table and you want to know this? Why? What do you care?
If you are worried about a lost update, don't... Forms takes care of this

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

When is SELECT FOR UPDATE used

DB version:10gR2
Since another thread of mine on this subject didn't go well, i am starting another thread.
When exactly is SELECT..FOR UPDATE statement used? With the exception of using SELECT...FOR UPDATE in CURSOR declaration, I've rarely seen SELECT ...FOR UPDATE being used explicitlyby PL/SQL gurus in our firm. Why didn't they use SELECT..FOR UPDATE(i mean a stand alone SELECT FOR UPDATE, <em>not as a part of Cursor</em>) to lock rows before UPDATE/DELETE/INSERT in their codes?
Edited by: M.Everett on Oct 20, 2008 12:00 PM
edited the initial post to let the users know that I am refering to a stand alone SELECT FOR UPDATE statement, not the part of a cursor

M.Everett wrote:
What i gather from various sources in the Internet:
1. SELECT FOR UPDATE is used mainly on CURSORs and very rarely used as a stand alone statement (if this is not the case you would have seen SELECT FOR UPDATE statements before every UPDATEs and DELETEs in PL/SQL codes)
2. Stand alone SELECT FOR UPDATEs are used mainly when dealing with CLOB, BLOB
Am i right in making these conclusions?1. This is probably a fair assumption.
2. Not really. SELECT FOR UPDATE is not a requirement when dealign with (C|B)LOBs.
SELECT FOR UPDATE allows an easy form of reference when you come to update rows in a cursor loop (although cursor loops should be rarely used), because rather than having to include a where condition on key columns you can just refer to the CURRENT ROW. Obviously, the main reason for using SFUs is the locking and this can become a requirement in some business environments where a user "picks up" a record to deal with and other users will then not see that record in their list or be able to select it for themselves.
;)

OpenSQL DataSource not allowed if select-for-update is used Error?

Hi,
I have created an enterprise application, EJB (Session + entity) + WAR, and corresponding ear file deployes with the following warning message, I have done similar apps in the past without erros.
Warning: DataSource TMP_EMPLOYEES_DATA is OpenSQL. It is used by an abstract schema that uses select-for-update locking. It is now allwed to use OpenSQL DataSource if select-for-updaet is used.
Any idea?
Thanks

Hi Ezatullah, all,
while I do not propose an alternative solution, I'd like to add some explanation to the error message itself: Open SQL for Java strives to provide portable semantics across the set of supported databases and does not offer features which can not be provided by all the databases.
Now, a SELECT .. FOR UPDATE in the semantics as used here is not generally available, in particular not regarding the locking semantics.
Thus, the feature is rejected in combination with a Open SQL/JDBC data source.
Best Regards, Dietmar

JDBC Thin: Can use "select for update"?

Hello,
Can anyone tell me if/how can I solve the concurrency
upon a result set?
JDK 1.2 documentation contains the following Connection's
method:
"public Statement createStatement(int resultSetType,
int resultSetConcurrency)
throws SQLException
JDBC 2.0 Creates ..."
Thanks,
Alexandra
null

We don't have support for JDBC 2.0 yet.
You can use SQL with 'for update' clause in the present
8i drivers. However, make sure that autoCommit
is OFF
Alexandra (guest) wrote:
: Hello,
: Can anyone tell me if/how can I solve the concurrency
: upon a result set?
: JDK 1.2 documentation contains the following Connection's
: method:
: "public Statement createStatement(int resultSetType,
: int resultSetConcurrency)
: throws SQLException
: JDBC 2.0 Creates ..."
: Thanks,
: Alexandra
Oracle Technology Network
http://technet.oracle.com
null

Deadlock detected during SELECT FOR UPDATE - an application error?

I have a general question about how Oracle prevents deadlocks from affecting
applications: do I need to build support into the application for handling
deadlocks when they occur in this particular scenario, or should Oracle handle
this for me? I'd like to know whether this is "normal" behavior for an Oracle
application, or if there is an underlying problem. Consider the following situation:
Two sessions issue individual SELECT FOR UPDATE queries. Each query locates
records in the table using a different index. These indexes point to rows in a
different order from each other, meaning that a deadlock will occur if the two
statement execute simultaneously.
For illustrative purposes, consider these rows in a hypothetical table.
ALPHABET
alpha
bravo
charlie
delta
echo
foxtrot
golf
hotel
Index A results in traversing the table in ascending alphabetical order; index
B, descending. If two SELECT FOR UPDATE statements concurrently execute on this
table--one with an ascending order execution path and one in descending order--
the two processes will deadlock at the point where they meet. If Session A
locks alpha, bravo, charlie, and delta, while Session B locks hotel, golf,
foxtrot, and echo, then neither process can proceed. A needs to lock echo, and
B needs to lock delta, but one cannot continue until the other releases its
locks.
This execution path can be encouraged using hints. Executing queries similar to these on larger tables will generate the "collision" as described above.
-- Session A
select /*+ index_asc (customer) */
from customer
where gender = 'M'
for update;
-- Session B
select /*+ index_desc (customer) */
from customer
where gender = 'M'
for update;
Oracle will recognize that both sessions are in a stand-off, and it will roll
back the work performed by one of the two sessions to break the deadlock.
My question pivots on whether or not, in this situation, the deadlock gets
reported back to the application executing the queries as an ORA-00060. If
these are the ONLY queries executed during these sessions, I would think that
Oracle would rollback the locking performed in one of the SELECT FOR UPDATE
statements. If I understand correctly,
(1) Oracle silently rolls back and replays work performed by UPDATE statements
when a deadlock situation occurs within the scope of the update statement,
and
(2) A SELECT FOR UPDATE statement causes Oracle, at the point in time the cursor
is opened, to lock all rows matching the WHERE clause.
If this is the case, then should I expect Oracle to produce an ORA-00060
deadlock detection error for two SELECT FOR UPDATE statements?
I would think that, for deadlock situations completely within Oracle's control,
this should be perceived to the application invoking the SELECT FOR UPDATE
statements as regular blocking. Since the query execution plans are the sole
reason for this deadlock situation, I think that Oracle would handle the
situation gracefully (like it does for UPDATE, as referenced in (1)).
Notice, from the trace file below, that the waits appear to be from row locking,
and not from an artificial deadlock (e.g. ITL contention).
Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production
With the Partitioning option
DEADLOCK DETECTED
Current SQL statement for this session:
SELECT XXX FROM YYY WHERE ZZZ LIKE 'AAA%' FOR UPDATE
----- PL/SQL Call Stack -----
object line object
handle number name
58a1f8f18 4 anonymous block
58a1f8f18 11 anonymous block
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-002f004b-000412cf 37 26 X 26 44 X
TX-002e0044-000638b7 26 44 X 37 26 X
session 26: DID 0001-0025-00000002 session 44: DID 0001-001A-00000002
session 44: DID 0001-001A-00000002 session 26: DID 0001-0025-00000002
Rows waited on:
Session 44: obj - rowid = 0000CE31 - AAANCFAApAAAAGBAAX
Session 26: obj - rowid = 0000CE33 - AAANCHAArAAAAOmAAM
Thanks for your insight,
- Curtis
(1) "Oracle will silently roll back your update and restart it"
http://tkyte.blogspot.com/2005/08/something-different-part-i-of-iii.html
(2) "All rows are locked when you open the cursor, not as they are fetched."
http://download-east.oracle.com/docs/cd/A87860_01/doc/appdev.817/a77069/05_ora.htm#2170
Message was edited by:
Curtis Light

Thanks for your response. In my example, I used the indexes to force a pair of query execution plans to "collide" somewhere in the table in question by having one query traverse the table via index in an ascending order, and another in descending. This is an artificial scenario for reproducible illustrative purposes, but similar collisions could legitimately occur in real world scenarios (e.g. a full table scan and an index range scan with lookup by ROWID).
So, with that said, I think it would be unreasonable for Oracle to report the collision as a ORA-00060 every time it occurs because:
(1) The UPDATE statement handles this situation automatically, and
(2) An ORA-00060 results in a 100+KB trace file being written out, only rational for truly erroneous situations.
I agree that, when the application misbehaves and locks rows out of order in separate SQL statements, then Oracle should raise an ORA-00060, as the deadlock is outside of its control. But in this case, the problem occurs with just two individual SQL statements, each within its own transaction.

DBMS_LOCK vs Select for update locking

Hi,
In one of our database packages, we are using the dbms_lock (that package is used to generate unique numbers) instead of select for update locking.
I want to ask what is more suitable here. Our application is oracle forms and oracle db on oracle app server.
Are there any limitations to select for update locking?
What are the conditions favourable to use DBMS_LOCK?
Regards,

DBMS_LOCK is extremely efficient. Try it. Put a call to obtain/free a lock in a loop and see how long it takes to loop a few thousand times (don't SLEEP in the loop, just obtain and free the lock). If you are having performance issues with DBMS_LOCK or your select it is probably because whatever it is that gets the lock (whichever way you get it) is taking a certain amount of time to finish.
I too, am curious as to what "issues" you had. In either case, a lock for consistent read will be different than a lock for update (as it should be) in terms of how it impacts other users.

LOCK TABLE vs select for update

Hello All,
if the requirement is to lock an entire huge table to prevent any users from performing any update statement, which statement has more performance gain and why: LOCK TABLE or select fro update nowait?
is there any overhead of using LOCK TABLE statement?
Thanks,

The reason I said to revoke update privilege is because I do not understand the requirement. Why do you want to prevent users from updating the table? I am assuming that users should never be allowed to update the table. In that case locking the table and select for update would be no good. If you want to stop users from updating while some one else is updating, why? All the lock table or select for update will do is cause their session to wait (hang) until the locking process commits or rolls back. This could generate a few (sic) complaints that the user application is slow/freezing.
If you can state the business problem, perhaps we can offer a solution.

Clarification on SELECT for UPDATE

HI All,
I am doing a SELECT FOR UPDATE using NOWAIT as well as SKIPLOCKED option. I have question regarding the general behavior.
Suppose let say , I have two tables (table1 and table 2 ).
TABLE 1
header_id NUMBER,
service_id NUMBER
TABLE 2
header_id NUMBER,
line_id NUMBER,
status VARCHAR2
And I run the following query
SELECT t2.header_id, t2.line_id
FROM table1 t1, table2 t2
WHERE t1.header_id = t2.header_id
AND t1.service_id = 1
AND t2.status = 'SUCCESS'
FOR UPDATE OF t2.status NOWAIT SKIP LOCKED;
Questions
1) Does adding both the NOWAIT and SKIP LOCKED in the sql help or just SKIP LOCKED would do fine.
2) Lets say this SQL is executed when there are no rows with status as 'SUCCESS' in table2. Would this cause any performance impact. Like for example since its joining with table1 with table 2 based on the header id .Would it lock any rows on table1?
( My understanding was that it would not lock any row until it finds out any row with status as 'SUCCESS' but getting some conflicting answers)
Thanks,
Vj

AKVK wrote:
( My understanding was that it would not lock any row until it finds out any row with status as 'SUCCESS' but getting some conflicting answers)THis would be my understanding too.
To be sure make a test.
Do the select for update so that it does not lock any rows.
Then check the data dictionary select * from v$lock; to see for your session if there are any locks.

SELECT FOR UPDATE - does it write to REDO?

Greetings folks,
we have some strange performance issues with a recent application update. This is custom in-house application. Every morning since the deploy we get a spike in load, especially to log sync / redo archive. We capture activity surrounding the load, and found many "select for update" statements.
Im digging through metalink and docs looking to confirm "write or no write" to the redo log files. comments appreciated.

sb92075 wrote:
SELECT does not generate REDO
DML generates REDO.It is possible for a SELECT to generate redo due to the effects of delayed block cleanout. A small test case:
Session 1:
CREATE TABLE T10 AS
SELECT
ROWNUM RN
FROM
DUAL
CONNECT BY
LEVEL<=1000;
UPDATE
T10
SET
RN=RN;
UPDATE
T10
SET
RN=RN;
UPDATE
T10
SET
RN=RN;
Session 2:
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH BUFFER_CACHE;
Session 1:
COMMIT;
Session 2:
SET AUTOTRACE ON STATISTICS
SELECT
FROM
T10;
1000 rows selected.
Statistics
          0 recursive calls
          0 db block gets
         73 consistent gets
          3 physical reads
        188 redo size
      11104 bytes sent via SQL*Net to client
       1060 bytes received via SQL*Net from client
         68 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
       1000 rows processedNote that the above may be performed in a single session rather than using two sessions. Essentially, the flush of the buffer cache causes the dirty blocks (containing uncommitted changes) to be written to disk, and the blocks are "cleaned up" during the next SELECT which accesses the blocks.
A much better explanation:
http://jonathanlewis.wordpress.com/2009/06/16/clean-it-up/
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Difference in select for update of - in Oracle Database 10g and 11g

Hi, I found out that Oracle Database 10g and 11g treat the following PL/SQL block differently (I am using scott schema for convenience):
DECLARE
  v_ename bonus.ename%TYPE;
BEGIN
  SELECT b.ename
    INTO v_ename
    FROM bonus b
    JOIN emp e ON b.ename = e.ename
    JOIN dept d ON d.deptno = e.deptno
   WHERE b.ename = 'Scott'
     FOR UPDATE OF b.ename;
END;
/While in 10g (10.2) this code ends successfully (well NO_DATA_FOUND exception is raised but that is expected), in 11g (11.2) it raises exception "column ambiguously defined". And that is definitely not expected. It seems like it does not take into account table alias because I found out that when I change the column in FOR UPDATE OF e.empno (also does not work) to e.mgr (which is unique) it starts working. So is this some error in 11g? Any thoughts?
Edited by: Libor Nenadál on 29.4.2010 21:46
It seems that my question was answered here - http://stackoverflow.com/questions/2736426/difference-in-select-for-update-of-in-oracle-database-10g-and-11g

The behaviour seems like it really is a bug and can be avoided using non-ANSI syntax. (It makes me wonder why Oracle maintains two query languages while dumb me thinks that this is just a preprocessor matter and query engine could be the same).

Can I use a select and update statement in a single jsp file?

I want to update the BUY table everytime I would add a SELL transaction.....I want to minus the stocks that I sold to those that Ive bought before.....
note: I used a seperate table in BUY and SELL transaction
After I Have added a transaction, I want to update the buy table. This is my problem, can I used both SELECT and UPDATE statement at the same time in a single jsp file for example like this:
select * from test, test1;
update test
set total_shares=total_shares-Stotal;
where stock_code=Scode AND name_broker=Sbroker;
Can i have both of these statements in the same jsp file in oder to update the buy table?
Or can anyone suggest how can process that update?THANKS!
--------------------

Can i have both of these statements in the same jsp file in oder to update the buy table?Yes. But wouldn't it have been easier just to try it?

Rogue implicit SELECT FOR UPDATE statement in forms 9i 9.0.4.0.19

all,
out of 200 production forms, one form occasionally and incorrectly "selects for update" an entire 3 million row table, during an update transaction. this creates 100+ archive logs.
we cannot repeat the event via testing. but the rogue select statement has been captured from SGA and is listed below. its plain to see that somehow the where clause is truncated to a W, and is then used as a table alias, resulting in the entire table being locked.
has anyone seen anything like this?
SELECT ROWID,DISTRIBUTION_PARTY,DISTRIBUTION_PARTY_NAME,CORRESPOND_SEQ_NUM,DISTRIBUTION_SEQ_NUM,VENDOR_NUM,DEPENDENT_SEQ_NUM,INTERNAL_ATTORNEY_USER_NAME,MAIL_LOC,ORIGINAL_FLAG
FROM CLAIM_DISTRIBUTION_DATA W
FOR UPDATE OF DISTRIBUTION_PARTY NOWAIT

Find out where this select statement is issued from first of all. Is it in your code or is it issued implicitely by Forms? Since it has rowid I assume it is an implicit Forms call.
Do you use on-update triggers any where in this form? on-lock?

Performance of using a Select For Update vs a correlated subquery

Similar Messages

Maybe you are looking for