RE: high cpu on query

I'm too busy to even read your whole situation in depth (in the middle of a restore), but in general, high cpu use is usually a sign of a lot of buffer gets, which is usually a sign of indexes and nested loops being used where perhaps a full table scan and hash join or sort-merge join would be more appropriate. This is a typical problem I see when explain plans are shared inappropriately due to bind variable peeking - search Metalink for "query using bind variables is suddenly slow" for more info - I don't have the note number on hand. Good chance you got a plan using "MERGE JOIN - CARTESIAN" with a "BUFFER SORT" because the plan was optimized based on estimated cardinality of 1 with the peeked bind variables, then later the same query was executed with different bind variables selecting much more than 1 row.

Regards,
Brandon

Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.

--
http://www.freelists.org/webpage/oracle-l