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.

Similar Messages

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

  • When does select for update release locks

    Hello all,
    Does anyone know when Oracle realeases the row locks when a
    select for update is issued?
    Does Oracle realase the row lock at the time when an actual update statement is
    issued for the locked row, or does it wait until a commit statment is executed?
    So for example, can I lock several rows with a select for update clause, and then
    issue update statements as many times as I want on each locked row without
    having to worry about the lock being released until I issue a commit statement.
    Thanks,
    David

    yes.
    The lock is released only when your transaction ends. A transaction can end because of:
    1). Commit.
    2). Rollback.
    3). client disconnects.
    etc. etc...

  • Is SELECT FOR UPDATE lock ever released?

    Hi,
    Does any one know whether the lock acquired by SELECT FOR UPDATE will ever be released if user session ends without commit or rollback(e.g. crashed)? If it does, is there a default parameter to control the maximum wait time for Oracle to release the lock automatically?
    Thanks,
    JM

    Your select statement won't be committed if the db crashes. That is a DML (data manipulation language)statement. In your scenario everything is rolled back upto the last commit or savepoint. For DDL (data definition Language) for the same situation you would get an implicit commit.
    Hope this helps.

  • 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;

  • 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

  • Database select for update locks ADF

    Hi,
    When a user has initiated an update session in an adf application and locking is optimistic it will acquire a lock on table row using select for update no wait; . But when the user closes a tab the session would not be terminated. Now i know as HTTP is a stateless protocol, we can wait for the timeout and then the lock will be released using a session listener implementation. But if the user instead tries to log in again in a new tab and tries to edit the same record he will receive a message stating that another user already holds a lock on the record which is correct, but is misleading.
    So can we rely on javascript for these scenarios that as soon as the user closes the tab the session should be terminated.
    Here's a snippet
    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/dojo/1.4/dojo/dojo.xd.js" ></script>
    <script type="text/javascript">
    var unLoad = function() {
        dojo.io.script.get({
        url:'http://127.0.0.1:7101/myapp/adfAuthentication?logout=true',
        timeout:15000,
      dojo.addOnWindowUnload(unLoad);
    </script>I know this might not work always as it depends on the fact that request might / might not be processed by the server.
    Are there any alternate solutions and also reducing the session timeout is ruled out in my scenario.

    Ramandeep,
    So are there other alternatives or solutionsAlternatives or solutions to what, exactly? As Jobinesh has told you, as long as you use optimistic locking, ADF doesn't acquire database locks except in the context of a transaction that is going to be completed in the current HTTP request. You could obviously force ADF to deviate from this if you called "postChanges" during an HTTP request and leave the transaction hanging, but that would just be wrong in an optimistic locking scenario - the solution would be "don't do that."
    John

  • 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!

  • Oracle select for update: not releasing lock

    My JDBC code uses "select for update" to modify record in Oracle database. I tried to simulate network connection down situation.
    After my JDBC code locked on a record using "select for update", I unplugged the network cable. I then tried to run the same code on another computer, but it could not accquire the lock, because the previous lock was not released. I tried sqlplus to lock the record, but failed also. The lock has been there for at least an hour now. I guess it may finally be released, but is there a way for oracle to release the lock as soon as the connection is down? Not know if it is a JDBC setting or oracle setting.

    Dear Friend,
    What you are trying to do is not correct way of checking the concurrency and transaction.
    The reason is as listed below.
    01.Always remember http is a stateless protocol and removing the connection or just closing the browser will never be informed to the database or to the application server thus the transaction monitor (TM)or processor will never release the lock as it will deem that the actor is manipulating the data.
    02.As per locking goes every database is having a �TM� and the default isolation level setting is different like oracle uses serializable DB2udb 7.0 or db2/As400 uses repeatable read. You can change this setting by editing the default setting in the database but be very sure before touching it.
    03.     You can also transpose this with your Application server setting for that piece of code or Globally but again be very sure about it as it will change the entire gamete.
    04.     For releasing lock you have to manually do it or you can change the settings of App server or the Database to release the connection after some wait time.
    Regards,
    Ruchir

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

  • Select for update returns no rows even though there is no locking thread

    I'm using Ibatis library over oracle sql for my query. The select for update statement returns no rows. This happens intermittently. When this was happening last time, I executed the select statement on sqldeveloper (but without the 'for update') and got rows. This situation is not easily reproducible so I've not yet been able to ascertain whether rows are returned on sqldeveloper with the 'for update' clause. But I know for sure that there was no other thread locking the rows. How could this be happening?

    The select for update statement returns no rowsWhy do you think that a select for update will always return rows?
    the for update clause if there not to garantee the presence of rows but to lock the row when it is present
    sql> select * from t;
             A          B C
             1          1 step1
             2          2 step2
             3          3 step3Then session 1 issues the following select
    SELECT     *
          FROM t
         WHERE a = 1
    FOR UPDATE NOWAIT;If session 2 issues the same select before session 1 commits or rolls back
    SELECT     *
          FROM t
         WHERE a = 1
    FOR UPDATE NOWAIT;It will get the following error
    ERROR at line 1:
    ORA-00054: resource busy and acquire with NOWAIT specifiedBut if session 2 issue such a kind of select
    sql> SELECT     *
      2        FROM t
      3       WHERE a = 99
      4  FOR UPDATE NOWAIT;
    no rows selectedYou see then that a select for update can return no rows
    Best Regards
    Mohamed Houri

  • 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?

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

  • Audit "SELECT FOR UPDATE" statement

    Hi all
    My database is 10.2.0.3 and I enabled audit_trail to DB value already.
    My purpose I want to audit "SELECT FOR UPDATE" statement on the table and I tried to enable audit "SELECT" on the table that have many records in dba_audit_trail because "SELECT" statement that include in this audit and then I tried to enable audit "LOCK TABLE" on the table that doesn't have any records n dba_audit_trail.
    So my question is How to enable audit for collecting only "SELECT FOR UPDATE" statement? or anyone have any idea for this.
    Regards,
    Hiko

    taohiko wrote:
    Hi all
    My database is 10.2.0.3 and I enabled audit_trail to DB value already.
    My purpose I want to audit "SELECT FOR UPDATE" statement on the table and I tried to enable audit "SELECT" on the table that have many records in dba_audit_trail because "SELECT" statement that include in this audit and then I tried to enable audit "LOCK TABLE" on the table that doesn't have any records n dba_audit_trail.
    So my question is How to enable audit for collecting only "SELECT FOR UPDATE" statement? or anyone have any idea for this.
    A consideration on top of the comments made by Justin:
    You have an unfortunate version of the database for auditing: when you enable audit on 10.2.0.3 (or.2 or .1) the redo pattern changes - normally you will see a redo change vector for each row updated, but in these versions you will see two records, a "lock row" followed up "update row piece"; which means your volume of redo may increase significantly.
    I wrote a note about it some time ago: http://jonathanlewis.wordpress.com/2011/05/27/audit-ouch/ and one of the comments includes the bug number ( 5166745 ), reporting fixed in 10.2.0.4 and 11.1.0.6
    Regards
    Jonathan Lewis
    This is bug

  • "SELECT FOR UPDATE" genrating large redo

    Hi,
    Is there any obvious reason why a "SELECT FOR UPDATE" would cause massive amount of redo to be generated?
    Derek

    1. "SELECT FOR UPDATE" itself should modify block to record row level lock information. This can cause redo data. See following:
    -- Create test table
    SQL> create table for_update_test(id int);
    Table created.
    SQL> insert into for_update_test values(1);
    1 row created.
    SQL> commit;
    Commit complete.
    -- Get DBA
    SQL> select dbms_rowid.rowid_relative_fno(rowid) as fno,
    2 dbms_rowid.rowid_block_number(rowid) as blk_no
    3 from for_update_test;
    FNO BLK_NO
    4 41980
    -- Execute "Select for Update..."
    SQL> connect user/password;
    SQL> select * from for_update_test for update;
    ID
    1
    -- Get Transaction ID
    SQL> select xidusn, xidslot, xidsqn from v$transaction
    where ses_addr = (select saddr from v$session where sid =
    (select sid from v$mystat where rownum = 1));
    SQL> /
    XIDUSN XIDSLOT XIDSQN
    2 24 24009
    -- Dump corresponding block to identify which has been changed
    SQL> alter system dump datafile 4 block 41980;
    Block header dump: 0x0100a3fc
    Object id on Block? Y
    seg/obj: 0x1013b csc: 0x7df.1847891a itc: 2 flg: E typ: 1 - DATA
    brn: 0 bdba: 0x100a3f9 ver: 0x01 opc: 0
    inc: 0 exflg: 0
    Itl Xid Uba Flag Lck Scn/Fsc
    0x01 0x0004.023.00004719 0x00800b41.1359.02 C--- 0 scn 0x07df.184788fe
    0x02 0x0002.018.00005dc9 0x00800c54.0eef.33 ---- 1 fsc 0x0000.00000000
    data_block_dump,data header at 0x6682464
    ===============
    tsiz: 0x1f98
    hsiz: 0x14
    pbl: 0x06682464
    bdba: 0x0100a3fc
    76543210
    flag=--------
    ntab=1
    nrow=1
    frre=-1
    fsbo=0x14
    fseo=0x1f92
    avsp=0x1f7b
    tosp=0x1f7b
    0xe:pti[0] nrow=1 offs=0
    0x12:pri[0] offs=0x1f92
    block_row_dump:
    tab 0, row 0, @0x1f92
    tl: 6 fb: H-FL lb: 0x2 cc: 1
    col 0: [ 2] c1 02
    end_of_block_dump
    End dump data blocks tsn: 4 file#: 4 minblk 41980 maxblk 41980
    Here you can see that the row's lock byte is "2" and the corresponding ITL entry shows that the lock owner is the session that executed "Select for update...".
    So, "Select for update" does really update block and generate redo for that change.
    2. Note that even "Select " statement can generate redo data. This is caused by "delayed block cleanout". Google it for more information.

Maybe you are looking for