RE: v$session_longops hash join operation oddity

Hi Stefan,  

Cannot imagine, if the number of rows returned for the hash join is the expected, what is wrong, unless an internal bug.  

I would try - if the join is still active - to start a trace via 10104 event (hash operation trace) to see the details (best is start the trace before executing

the query, of course/maybe a after logon trigger, etc. would be of use here).  

conn / as sysdba;

exec dbms_system.set_ev(<sid>,<serial>,10104,10,'') ; /* sid, serial of the session doing the query */

commit;

.

.

.

exec dbms_system.set_ev((<sid>,<serial>,10104,0,'') ; <== deactivate event when

commit;    

>Hi Alvaro
>The plan looks OK -- it's what we'd expect it to be ( I can't show it
unless I edit all the table names out first, and it's 140 lines long)
>Stefan

On 9/13/07, Alvaro Jose Fernandez <alvaro.fernandez_at_sivsa.com> wrote:

May be a bug, or bad constructed query which fires a bug.

Or simply a bad written query - or very bad filters. Check the current plan for this hash value, now , if you can .  

alvaro

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