VPD problem: select for update on join tables with policy on ref table

In our application we use VPD. Now we ran into an issue. I will try to explain with EMP and DEPT table.
EMP table has no VPD attached.
DEPT table has VPD policy that forbids all updates, but allows select. (Policy returns '1=2' for statement type update.
This query returns no rows:
select * from emp join dept using (department_id) for update. This makes sense, because I'm going to update both the tables.
However:
select * from emp join dept using (department_id) for update of employee_id also returns no rows. THIS IS WRONG. I'm not going to update dept table.
Any experience with this. Is this a known limitation ?

I can see all the rows, because there is no select policy.
However the point is, that VPD should allow me to update the emp table, because there is no update policy.
With the 'for update of employee_id' clause, VPD should recognize that I'm not going to update the dept table, but only the emp table. But VPD does not recognize this, but applies the update policy of dept to the statement, making the statement to update no rows.
(Reason behind my question is ADF Business Components, where you have ViewObjects with Referenced Entities. ADF BC generates this type of statement and now we run into this VDP limitation)

Similar Messages

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.

Select for update problem

i am having a query
SELECT (max_no + 1) FROM eat_last_no
FOR UPDATE
when i execute this i am getting an exception
java.sq.Exception : Not in transaction.
what all could be the reason for this
thanks in advance

sorry for my information that the for update locks the table
what i ment to say was that it locks the selected row
but still what is the reason that i am getting execption
java.sql.SqlException : Not In transaction

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

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

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

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.

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?

Clarification on SELECT for UPDATE

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

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

[Forms6]Select for update before update and commit

Hi,
In the KEY-COMMIT forms trigger
My code finds the primary keys of the rows to be updated,
then there is "select ...where "these keys".. for update nowait"
then there is a commit
(There also is a pragma exception init -54 "Resource Busy")
At runtime I get an error:
"Cannot insert rows here".
Maybe I should lock these rows before triggering the Key-commit?
--> message edited
Oops, I just reproduced the code in Forms 10,
I select for update from emp where empno=7839 then update King's sal then commit_form;
and everything works fine.
So I have to locate where this error message comes from.
--< End of edit
Many thanks for your help.
Edited by: JeanParis on Dec 23, 2009 10:31 PM

Hi,
The issue is solved on my Developer 2000 10 installed on Windows XP.
At work on Forms 6 I have hidden the warning with a :system.message_level.
What I'm searching now is a script to check the locks in the situation where
I don't have access to the catblock.sql script because I'm not DBA on the database. (but I can see DBA_LOCKS).
The problem starts because on the master block there is an item that can ben changed
from 'CREAT' to 'VALID', and in the When Validate Item trigger on that item I cannot issue a go_block( 'xxx' ).
I have to go to the 'xxx' block in order to start a first record - next loop to gather values and update a table accordingly.
Many thanks for your care.
JBM.

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

"All of the Playlists Selected for Updating No Longer Exist"

My family has 2 ipod shuffles. After purchasing a Nano recently, I inserted the cd that came with it. Apparently the existing iTunes software was removed and reinstalled. At any rate, the library still shows all the original songs, but when the Nano is plugged in, iTunes immediately gives a prompt stating "Songs on the iPod *** cannot be updated because all of the playlists selected for updating no longer exist." The library is there, the playlists that were there are there, and I can play the songs on my cpu. Is there anything I can do besides completely uninstalling everything and starting over?
iPod Nano Windows XP Pro

This user tip should help you sort out your missing playlist problem: Hudgie - iPod cannot sync because one or more playlists are missing

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?

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.

Create transaction for update a custom table

Hi,
I have a custom table Z****. What are all the steps to create a transaction for updating my custom table? I don't want to use SM30 anymore.
Thank you.

Create a Table maintainence through the maintainence generator.
Open table in SE11, goto utilities => table maintainence generator.
Once the generator is created,
In the same screen of generator - Goto Environment => Transaction Code
Select Transaction Code with Parameter.
In the default values - Enter the Transaction as SM30 . Select skip first screen.
In default values at the bottom
Add
screen field = VIEWNAME and value = Ztable name.
screen field =UPDATE and value = 'X'.
Edited by: Pranu Pranu on May 19, 2010 2:36 PM

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

VPD problem: select for update on join tables with policy on ref table

Similar Messages

Maybe you are looking for