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

Similar Messages

  • Ta OC41 - in PRD modification allowed even though the system is locked

    Hello SAP gurus,
    I stumbled upon a strange behaviour in our test and productive system.
    In the test system transaction OC41 (Change View "Currency Exchange Rates": Overview) shows a popup window saying client xxx has status not modifiable.
    So the unlocking with scc4 or se06 poped up in my head.
    However when I looked up this example in our productive system, I've found out that I have the possibility for the exchange rates edit even though the system is locked!
    Test system is set like this:
    SCC4:
    Client role: Test
    No Change Allowed
    No Changes to Repository and cross-client Customizing objs
    Protection level 0: No restriction
    eCATT and CATT Only Allowed for 'Trusted RFC'
    No restrictions set
    SE06
    Global Setting: Modifiable
    Productive system is set like this:
    SCC4:
    Client role: Productive
    No Change Allowed
    No Changes to Repository and cross-client Customizing objs
    Protection level 0: No restriction
    eCATT and CATT Not Allowed
    No restrictions set
    SE06
    Global Setting: Not Modifiable
    So how come I can change the exchange rates in productive system and not on the test system?
    Thanks for help in advance.
    Regards
    - Stefan

    Hi Venkata,
    Congratulations for your first (and well earned) points!
    Really if you change the client as productive in scc4, you can also then change the currency rates in oc41.
    To all above, thanks for telling me to keep on searching, I've found some info and e.g. a note 356483, that might help me in the future.

  • A word skips to next line even though there's room

    I'm currently typing bylaws for an organization. Occasionally, even though there's plenty of room for another word or two on a line, it automatically skips to the next line. I'm finally getting used to Pages thanks to this forum, but this problem is really frustrating me. Thanks.

    It would have helped if I had actually included the screenshot.

  • Select for update that doesn't return any rows

    Are there any odd side-effects that may occur if a select for update that returns no results is never committed? I wouldn't think there are, but I'm not sure if there would be some kind of overhead or unforeseen consequences. This isn't a terribly important question, but it's come up in some coding I've done and I've not been able to find any documentation addressing it.

    A select for update only locks rows that meet the predicate specified in the where clause. So, if the query returns no rows, no rows are locked.
    session1> SELECT * FROM t;
            ID DESCR
             1 Un
             5 One
             2 THIS IS WA
    session1> SELECT * FROM t
      2  WHERE id = 11 FOR UPDATE;
    no rows selectedA second session can update rows in the table
    session2> UPDATE t
      2  SET descr = 'One'
      3  WHERE id = 1;
    1 row updated.John
    Edited by: John Spencer on Jan 7, 2009 1:36 PM
    I just realized that, although you can do updates on the table after the select fo update that returns no rows, you cannot do DDL operations liike a truncate. Unless the session that does the select for update either ends the transaction (i.e. commit or rollback) or ends the session DDL operations will fail.

  • Strange behavior of select for update

    I observed a strange behavior of "select .. for update" statement in binary xml table. Here is the piece of code:
    create table xmltab of XMLType XMLTYPE store as binary xml;
    Table created.
    insert into xmltab values('<x><y>y1</y><z>z1</z></x>');
    1 row created.
    select x.object_value
    from xmltab x
    where extractValue(x.object_value,'/x/y')='y1' and
    extractValue(x.object_value,'/x/z')='z1' ;
    OBJECT_VALUE
    <x>
      <y>y1</y>
      <z>z1</z>
    </x>
    The following query doesn't return any row!!
    select x.object_value
    from xmltab x
    where extractValue(x.object_value,'/x/y')='y1' and
    extractValue(x.object_value,'/x/z')='z1' for update;
    no rows selected
    select x.object_value
    from xmltab x
    where extractValue(x.object_value,'/x/y')='b1' for update;
    OBJECT_VALUE
    <x>
      <y>b1</y>
      <z>z1</z>
    </x>
    select x.object_value
    from xmltab x
    where extractValue(x.object_value,'/x/z')='z1' for update;
    OBJECT_VALUE
    <x>
      <y>b1</y>
      <z>z1</z>
    </x>
    The following one returns correct result !!
    select x.object_value, extractValue(x.object_value,'/x/y'), extractValue(x.object_value,'/x/z')
    from xmltab x
    where extractValue(x.object_value,'/x/y')='b1' and
    extractValue(x.object_value,'/x/z')='z1' ;
    OBJECT_VALUE
    EXTRACTVALUE(X.OBJECT_VALUE,'/x/y')
    EXTRACTVALUE(X.OBJECT_VALUE,'/x/z')
    <x>
      <y>b1</y>
      <z>z1</z>
    </x>
    b1
    c1
    I get expected result for all the cases if the table is created in the following way
    create table xmltab of XMLType;
    Can anyone tell me why does select for update behaves in this strange way for binary xml table?

    Sorry for copy paste problem. b1 should be replaced with y1 and c1 with z1.
    Here is the correct code.
    create table xmltab of XMLType XMLTYPE store as binary xml;
    Table created.
    insert into xmltab values('<x><y>y1</y><z>z1</z></x>');
    1 row created.
    select x.object_value
    from xmltab x
    where extractValue(x.object_value,'/x/y')='y1' and
    extractValue(x.object_value,'/x/z')='z1' ;
    OBJECT_VALUE
    <x>
      <y>y1</y>
      <z>z1</z>
    </x>
    The following query doesn't return any row!!
    select x.object_value
    from xmltab x
    where extractValue(x.object_value,'/x/y')='y1' and
    extractValue(x.object_value,'/x/z')='z1' for update;
    no rows selected
    select x.object_value
    from xmltab x
    where extractValue(x.object_value,'/x/y')='y1' for update;
    OBJECT_VALUE
    <x>
      <y>y1</y>
      <z>z1</z>
    </x>
    select x.object_value
    from xmltab x
    where extractValue(x.object_value,'/x/z')='z1' for update;
    OBJECT_VALUE
    <x>
      <y>y1</y>
      <z>z1</z>
    </x>
    The following one returns correct result !!
    select x.object_value, extractValue(x.object_value,'/x/y'), extractValue(x.object_value,'/x/z')
    from xmltab x
    where extractValue(x.object_value,'/x/y')='y1' and
    extractValue(x.object_value,'/x/z')='z1' ;
    OBJECT_VALUE
    EXTRACTVALUE(X.OBJECT_VALUE,'/x/y')
    EXTRACTVALUE(X.OBJECT_VALUE,'/x/z')
    <x>
      <y>y1</y>
      <z>z1</z>
    </x>
    y1
    z1
    I get expected result for all the cases if the table is created in the following way
    create table xmltab of XMLType;
    Can anyone tell me why does select for update behaves in this strange way for binary xml table?

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

  • 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

  • Select for update gives wrong results. Is it a bug?

    Hi,
    Select for update gives wrong results. Is it a bug?
    CREATE TABLE TaxIds
    TaxId NUMBER(6) NOT NULL,
    LocationId NUMBER(3) NOT NULL,
    Status NUMBER(1)
    PARTITION BY LIST (LocationId)
    PARTITION P111 VALUES (111),
    PARTITION P222 VALUES (222),
    PARTITION P333 VALUES (333)
    ALTER TABLE TaxIds ADD ( CONSTRAINT PK_TaxIds PRIMARY KEY (TaxId));
    CREATE INDEX NI_TaxIdsStatus ON TaxIds ( NVL(Status,0) ) LOCAL;
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100101, 111, NULL);
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100102, 111, NULL);
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100103, 111, NULL);
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100104, 111, NULL);
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200101, 222, NULL);
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200102, 222, NULL);
    Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200103, 222, NULL);
    --Session_1 return TAXID=100101
    select TAXID from TAXIDS where LOCATIONID=111 and NVL(STATUS,0)=0 AND rownum=1 for update
    --Session_2 waits commit
    select TAXID from TAXIDS where LOCATIONID=111 and NVL(STATUS,0)=0 AND rownum=1 for update
    --Session_1
    update TAXIDS set STATUS=1 Where TaxId=100101;
    commit;
    --Session_2 return 100101 opps!?
    --Session_1 return TAXID=100102
    select TAXID, STATUS from TAXIDS where LOCATIONID=111 and NVL(STATUS,0)=0 AND rownum=1 for update
    --Session_2 waits commit
    select TAXID, STATUS from TAXIDS where LOCATIONID=111 and NVL(STATUS,0)=0 AND rownum=1 for update
    --Session_1
    update TAXIDS set STATUS=1 Where TaxId=100102;
    commit;
    --Session_2 return 100103                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    This is a bug. Got to be a bug.
    This should be nothing to do with indeterminate results from ROWNUM, and nothing to do with read consistency at the point of statement start time in session2., surely.
    Session 2 should never return 100101 once the lock from session 1 is released.
    The SELECT FOR UPDATE should restart and 100101 should not be selected as it does not meet the criteria of the select.
    A statement restart should ensure this.
    A number of demos highlight this.
    Firstly, recall the original observation in the original test case.
    Setup
    SQL> DROP TABLE taxids;
    Table dropped.
    SQL> 
    SQL> CREATE TABLE TaxIds
      2  (TaxId NUMBER(6) NOT NULL,
      3   LocationId NUMBER(3) NOT NULL,
      4   Status NUMBER(1))
      5  PARTITION BY LIST (LocationId)
      6  (PARTITION P111 VALUES (111),
      7   PARTITION P222 VALUES (222),
      8   PARTITION P333 VALUES (333));
    Table created.
    SQL>
    SQL> ALTER TABLE TaxIds ADD ( CONSTRAINT PK_TaxIds PRIMARY KEY (TaxId));
    Table altered.
    SQL>
    SQL> CREATE INDEX NI_TaxIdsStatus ON TaxIds ( NVL(Status,0) ) LOCAL;
    Index created.
    SQL>
    SQL>
    SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100101, 111, NULL);
    1 row created.
    SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100102, 111, NULL);
    1 row created.
    SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100103, 111, NULL);
    1 row created.
    SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (100104, 111, NULL);
    1 row created.
    SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200101, 222, NULL);
    1 row created.
    SQL> Insert into TAXIDS (TAXID, LOCATIONID, STATUS) Values (200102, 222, NULL);
    1 row created.
    SQL> commit;
    Commit complete.
    SQL> Original observation:
    Session1>SELECT taxid
      2  FROM   taxids
      3  WHERE  locationid    = 111
      4  AND    NVL(STATUS,0) = 0
      5  AND    ROWNUM        = 1
      6  FOR UPDATE;
         TAXID
        100101
    Session1>
    --> Session 2 with same statement hangs until
    Session1>BEGIN
      2   UPDATE taxids SET status=1 WHERE taxid=100101;
      3   COMMIT;
      4  END;
      5  /
    PL/SQL procedure successfully completed.
    Session1>
    --> At which point, Session 2 returns
    Session2>SELECT taxid
      2  FROM   taxids
      3  WHERE  locationid    = 111
      4  AND    NVL(STATUS,0) = 0
      5  AND    ROWNUM        = 1
      6  FOR UPDATE;
         TAXID
        100101
    Session2>There's no way that session 2 should have returned 100101. That is the point of FOR UPDATE. It completely reintroduces the lost UPDATE scenario.
    Secondly, what happens if we drop the index.
    Let's reset the data and drop the index:
    Session1>UPDATE taxids SET status=0 where taxid=100101;
    1 row updated.
    Session1>commit;
    Commit complete.
    Session1>drop index NI_TaxIdsStatus;
    Index dropped.
    Session1>Then try again:
    Session1>SELECT taxid
      2  FROM   taxids
      3  WHERE  locationid    = 111
      4  AND    NVL(STATUS,0) = 0
      5  AND    ROWNUM        = 1
      6  FOR UPDATE;
         TAXID
        100101
    Session1>
    --> Session 2 hangs again until
    Session1>BEGIN
      2   UPDATE taxids SET status=1 WHERE taxid=100101;
      3   COMMIT;
      4  END;
      5  /
    PL/SQL procedure successfully completed.
    Session1>
    --> At which point in session 2:
    Session2>SELECT taxid
      2  FROM   taxids
      3  WHERE  locationid    = 111
      4  AND    NVL(STATUS,0) = 0
      5  AND    ROWNUM        = 1
      6  FOR UPDATE;
         TAXID
        100102
    Session2>Proves nothing, Non-deterministic ROWNUM you say.
    Then let's reset, recreate the index and explicity ask then for row 100101.
    It should give the same result as the ROWNUM query without any doubts over the ROWNUM, etc.
    If the original behaviour was correct, session 2 should also be able to get 100101:
    Session1>SELECT taxid
      2  FROM   taxids
      3  WHERE  locationid    = 111
      4  AND    NVL(STATUS,0) = 0
      5  AND    taxid         = 100101
      6  FOR UPDATE;
         TAXID
        100101
    Session1>
    --> same statement hangs in session 2 until
    Session1>BEGIN
      2   UPDATE taxids SET status=1 WHERE taxid=100101;
      3   COMMIT;
      4  END;
      5  /
    PL/SQL procedure successfully completed.
    Session1>
    --> so session 2 stops being blocked and:
    Session2>SELECT taxid
      2  FROM   taxids
      3  WHERE  locationid    = 111
      4  AND    NVL(STATUS,0) = 0
      5  AND    taxid         = 100101
      6  FOR UPDATE;
    no rows selected
    Session2>Of course, this is how it should happen, surely?
    Just to double check, let's reintroduce ROWNUM but force the order by to show it's not about read consistency at the start of the statement - restart should prevent it.
    (reset, then)
    Session1> select t.taxid
      2   from
      3    (select taxid, rowid rd
      4      from   taxids
      5      where  locationid = 111
      6      and    nvl(status,0) = 0
      7      order by taxid) x
      8   ,  taxids t
      9   where t.rowid = x.rd
    10   and   rownum = 1
    11   for update of t.status;
         TAXID
        100101
    Session1>
    --> Yes, session 2 hangs until...
    Session1>BEGIN
      2   UPDATE taxids SET status=1 WHERE taxid=100101;
      3   COMMIT;
      4  END;
      5  /
    PL/SQL procedure successfully completed.
    Session1>
    --> and then
    Session2> select t.taxid
      2   from
      3    (select taxid, rowid rd
      4      from   taxids
      5      where  locationid = 111
      6      and    nvl(status,0) = 0
      7      order by taxid) x
      8   ,  taxids t
      9   where t.rowid = x.rd
    10   and   rownum = 1
    11   for update of t.status;
         TAXID
        100102
    Session2>Session 2 should never be allowed to get 100101 once the lock is released.
    This is a bug.
    The worrying thing is that I can reproduce in 9.2.0.8 and 11.2.0.2.

  • 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

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

  • HT6208 Cannot download the latest update 7.1.1 even though plugged in and on wifi keeps saying error help!!!!!

    Cannot download the latest update 7.1.1 even though plugged in and on wifi keeps saying error help!!!!!

    I am not getting an errr #. It just says that there are purchases on my ipod, not in my itunes. I transfer all of my ipod purchases into itunes. Then I try an download the new version of my ipod 7.1.1. It still says there are purchases on my ipod touch. So I just hit continue because their are not purchases on my ipod, that aren't in itunes. It extracts the software, and backs up ipod. Then itunes just closes. When I reopen it I get the same message A new iPod software version (7.1.1) is available for the iPod “My" iPodl”. Would you like to update your iPod now? My imac has recently been restored to as new, I have the newest ipod touch, and my version of itunes is also the newest version. The only thing that I can assume is that the problem, is another untested & bad update, from Capn Cook.

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

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

  • Pros and  cons  of  select  for  update  clause

    hi,
    Can anybody explain what are the
    pros and cons of select for update clause
    11.2.0.1

    As commented, there are no pros versus cons in this case.
    What is important is to understand conceptually what this do and why it would be use.
    Conceptually, a select for update reads and locks row(s). It is known as pessimistic locking.
    Why would you want to do that? Well, you have a fat client (Delphi for example) and multiple users. When userA updates an invoice, you want that invoice row(s) locked and prevent others from making updates at the same time. Without locking, multiple users updating the same invoice will result in existing updated data being overwritten by old data that also has been updated. A situation called lost updates.
    For web based clients that are stateless, pessimistic locking does not work - as the clients do not have state and pessimistic locking requires state. Which means an alternative method to select for update needs to be used to prevent lost updates. This method is called optimistic locking.
    So it is not about pros versus cons. It is about understanding how the feature/technique/approach works and when to use it.. and when it is not suited to use it. All problems are not nails. All solutions are not the large hammer for driving in nails.

  • In addition to my home page, every time I start Firefox a tab opens with notifacation of an updated addon. Why does this tab continue to appear even though there is no updated version of the addon?

    In addition to my home page, every time I start Firefox a tab opens with notification of an updated addon. Why does this tab continue to appear even though there is no updated version of the addon?

    See these articles for some suggestions:
    *https://support.mozilla.com/kb/Firefox+has+just+updated+tab+shows+each+time+you+start+Firefox
    *https://support.mozilla.com/kb/How+to+set+the+home+page - Firefox supports multiple home pages separated by '|' symbols
    *http://kb.mozillazine.org/Preferences_not_saved

Maybe you are looking for

  • How to combine +two fields without submitting page (via AJAX/HTMLDB_Get)?

    Hi all, After my last contribution "Request for Scott Spendolini" I was able to create the scripts to update fields in forms without having to refresh the page. Thanks again to Scott, Carl and the others who helped me solving my problem. I have anoth

  • Can i use the same itunes acct on 2 computers?

    i set up the original itunes acct on my desktop,and also want to run the same acct on my laptop,for moblity reasons.

  • 2nd Gen not supported on os x 10.2.8?!!

    Sorry guys, I'm new to this forum and I've managed to post this twice already in the wrong forums. D'oh!! : I have a powerbook G4, mac os x 10.2.8, and a big headache. I've just been bought a 2nd gen ipod nano one as an early xmas present, only to fi

  • Objects in a tablespace or datafile ???

    How do we find out what objects ( tables, indexes etc ) are there in a particular tablespace ? Is there a way to find which object is in a particular datafile if the tablespace has more than one datafile ?

  • Flash Drive not mounting, shows up in sys. prof. and USB Prober

    I have a 4Gig Flash Drive that doesn't mount. It shows up in both SYstem Profiler and USB Prober. Is there any way to "fix" it? I don't need to recover any files - I just want to be able to use it. It used to work, maybe a year ago. Havn't touched it