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

Similar Messages

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?

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.

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.

SELECT FOR UPDATE via KODO queries

I want to do the following in a transaction:
1) SELECT * from Foo where type='x' FOR UPDATE
2) UPDATE Foo set sequence='22' where type='x'
3) commit
The issue: is there any way to force KODO to add the 'for update' in a find query.
Thanks

Please try kodo.LockManager configuration property.
-pessimistic: This is an alias for the kodo.jdbc.kernel.PessimisticLockManager , which uses SELECT FOR UPDATE statements (or the database's equivalent) to lock the database rows corresponding to locked objects. This lock manager does not distinguish between read locks and write locks; all locks are write locks.
Also please make sure you have following setting
kodo.jdbc.DBDictionary: SupportsSelectForUpdate=true
Please check kodo doc section 9.4.4.
JPA looks like
<property name="kodo.LockManager" value="pessimistic(VersionCheckOnReadLock=true,VersionUpdateOnWriteLock=true)"/>
JDO looks like
kodo.LockManager: pessimistic(VersionCheckOnReadLock=true,VersionUpdateOnWriteLock=true)
Thanks,
Yun

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.
;)

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

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

ODBC 10.2 client makes SELECT FOR UPDATE run slower

Hi all,
I'm facing a strange problem with Oracle OBDC: I got an application which needs to connect to an Oracle DB via odbc.
Server is a 10.2.0.1; if I connect using ODBC driver installed by Oracle 8 client everything is ok but if I use ODBC driver installed by Oracle 10 client or Oracle XE client SELECT FOR UPDATE statements become really slower.
My application always does the same statement:
SELECT list_of_fields
FROM table
WHERE primary_key =
AND ...
FOR UPDATE;
If I use the Oracle 8 ODBC, this select is almost immediate; but if I use Oracle 10 ODBC it tooks ~4 seconds.
The statement is identical, so the access plan must be the same.
The ODBC configuration is identical too; tnsnames.ora entries are the same.
So, why the 10x clients are slower?
thanks for every answer
andrea
Message was edited by:
user585511
Message was edited by:
user585511

Which cursor library are you using? The ODBC Driver Manager's cursor library strips off the FOR UPDATE silently (see Appendix F of the ODBC Programmer's Reference). Depending on what version of the "Oracle 8 client" you were using, there may not have been an ODBC driver cursor library, so you may have been forced to use the driver manager's. Potentially, the slowdown is that you're now actually locking the rows now and may be running some contention issues.
It would be worthwhile to trace the sessions and see what the difference in waits is.
Justin

Any parameter is required to set "select for Update"

Hi all,
For using "Select for Update" statement, is any parameter is required to set at the database level.
Thanks in advance,

Hi,
I did't get any problem. but before implementing that I searching for any overheads.
I had read that some transaction isolation level should be required to use "select for update".
I did't catch it clearly.
Can u explain briefly if you know/any body know.

'Missing select' error for update statement using WITH clause

Hi,
I am getting the below error for update statement using WITH clause
SQL Error: ORA-00928: missing SELECT keyword
UPDATE A
set A.col1 = 'val1'
     where
A.col2 IN (
WITH D AS
SELECT col2 FROM
(SELECT col2, MIN(datecol) col3 FROM DS
WHERE <conditions>
    GROUP BY PATIENT) D2
WHERE
<conditions on A.col4 and D2.col3>

Hi,
The format of a query using WITH is:
WITH d AS
    SELECT ... -- sub_query
SELECT ...   -- main query
You don't have a main query. The keyword FROM has to come immediately after the right ')' that ends the last WITH clause sub-query.
That explains the problem based on what you posted. I can't tell if the real problem is in the conditions that you didn't post.
I hope this answers your question.
If not, post a complete test script that people can run to re-create the problem and test their ideas. Include a little sample data (CREATE TABLE and INSERT statements, relevant columns only) for all the tables involved, and the results you want from that data.
In the case of a DML operation (such as UPDATE) the sample data should show what the tables are like before the DML, and the results will be the contents of the changed table(s) after the DML.
Explain, using specific examples, how you get those results from that data.
Always say what version of Oracle you're using (e.g. 11.2.0.2.0).
See the forum FAQ: https://forums.oracle.com/message/9362002

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?

LOB: Select for update

I keep getting this error with some pretty standard CLOB code to update data:
HELLLP!!!
SQLException: ORA-01002: fetch out of sequence
java.sql.SQLException: ORA-01002: fetch out of sequence
Here's the code:
CLOB lob_loc = null;
String buf = new String ("CLOB text buffer test");
Connection myConn=
DriverManager.getConnection("jdbc:oracle:thin:@172.16.11.32:1521:ORCL","outerforce","outerforce");
Statement stmt = myConn.createStatement();
System.out.println("BEFORE SELECT FOR UPDATE........");
ResultSet myResultSet = stmt.executeQuery("SELECT data FROM clobtest WHERE assign_no=7 FOR UPDATE");
System.out.println("SELECT DONE FOR UPDATE........");
if (myResultSet.next())
lob_loc = ((OracleResultSet)myResultSet).getCLOB (1);
OracleCallableStatement cstmt = (OracleCallableStatement)
myConn.prepareCall ("BEGIN DBMS_LOB.OPEN(?, DBMS_LOB.LOB_READWRITE); END;");
cstmt.setCLOB(1, lob_loc);
cstmt.execute();
/* if (myResultSet != null){
while (myResultSet.next()) {
System.out.println(myResultSet.getString("assign_no"));
long pos = 0; // This is the offset within the CLOB where the data is to be written
long length = 0; // This is the size of the buffer to be written.
// This loop writes the buffer three times consecutively:
//for (int i = 0; i < 3; i++)
// Fill the buffer with some data to be written:
length = buf.length();
//pos += length;
// This is an Oracle-specific method:
//lob_loc.plsql_write(pos, buf.toCharArray());
lob_loc.putString(pos, buf);
//}

Sorry Email reply was incorrect
send to:
[email protected]
null

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?

Audit "SELECT FOR UPDATE" statement

Similar Messages

Maybe you are looking for