Interesting that Oracle EBS does not use declared foreign keys. It would seem that this is not a desirable practice from a data integrity point of view.

The whole Oracle EBS, has no a single foreign key. All is handled with app logic.

And the best of all … have seen EBS with 1000 connections with no few locking events-amazing and maybe the best point where to go when you want to build enterprise app for thousand of concurrent connections.

Thanks for posting the link to your test case. It has been a couple of months since you posted the comment: “… function based index will not protect us”. If I remember correctly, I considered testing your statement, but instead decided that your comment was addressing the situation where the foreign key column was enclosed in a function within the index definition. I did wonder a bit what would happen if the function based index were a composite index.

It is true that a bitmap index will not protect against TM enqueues on the child table. And how would it be the case when we know that bitmap indexes themselves generate deadlocks situation in an OLTP application. However, I was not completely true to say that Function based indexes do not protect against this kind of TM enqueue. They in fact do; they just need to start with the Foreign key column (or columns in case of a composite key). A very simple example can be found here
http://hourim.wordpress.com/2012/01/19/bitmap-indexes-and-foreign-key/
Best Regards

Thank you for the extensive comment post.

The AskTom thread you linked to is very interesting, and very long. The following is a list of some of the items mentioned in that thread:
* The original version of Tom Kyte’s foreign key indexing script
* Problems with multi-column foreign keys and NULL values in one of the columns
* Problems with CURSOR_SHARING = SIMILAR or FORCE: ORA-01467: sort key too long (another one to add to the list in the article http://hoopercharles.wordpress.com/2011/07/03/the-cursor_sharing-parameter-is-a-silver-bullet-what-is-wrong-with-this-quote/ )
* Oracle Forms by default updates all columns, including primary key columns (this is mentioned in a couple of books, as I recall)
* First hint of table locking change due to unindexed foreign key columns in 11g in July 2009 (that was the same month when Randolf Geist and I wrote the section in the OakTable book about the locking change – we tripped over it by accident)
* Tom Kyte’s blog article about unindexed foreign keys and his script: http://tkyte.blogspot.com/2009/10/httpasktomoraclecomtkyteunindex.html
* Mohamed Houri’s script:
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:292016138754#3002983200346796154

I also found your post “Unindexed foreign key Share lock without delete/update on the parent” which was added “February 10, 2011 – 10am Central time zone”
I probably misunderstood Tom Kyte’s follow up comment to you considering what he later stated about the bug. It seemed that he was stating that you need to index the foreign key columns in the grand-child table. You then mentioned Metalink (MOS) Bug 12313173, which currently has a status of “32 – Not a Bug. To Filer”. Interesting situation – do you see the same results on 10g and 11g?

—

Setting event 10704 – I had not heard of that before (or I simply forgot). A web search helped me determine the purpose of that event:
http://www.juliandyke.com/Diagnostics/Events/EventReference.html#10704

Thank you for the reminder that bitmap indexes and function based indexes will not protect against TM enqueues on the child table – that suggests that the script should also verify that the index is in fact a b*tree index and not a bitmap index.

If you have your script posted somewhere, please provide a link to the script. Or, if you would like, please post the script here. If you post the script here, please use a <pre> tag before the script and a </pre> tag after the script to retain the spacing in the script (or use one of the other common code tags).