Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 7183 invoked from network); 13 Sep 2007 08:07:38 -0500 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by 69.64.49.119 with SMTP; 13 Sep 2007 08:07:27 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id B4B2074267E; Thu, 13 Sep 2007 08:28:31 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03719-08-4; Thu, 13 Sep 2007 08:28:31 -0400 (EDT) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7B1CA74267F; Thu, 13 Sep 2007 08:28:30 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 13 Sep 2007 07:43:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id C1D30742498 for ; Thu, 13 Sep 2007 07:43:30 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23159-02-2 for ; Thu, 13 Sep 2007 07:43:30 -0400 (EDT) Received: from castafiore.sivsa.com (correo.sivsa.com [212.145.138.162]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 019B1741F93 for ; Thu, 13 Sep 2007 07:43:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by castafiore.sivsa.com (Postfix) with ESMTP id D3B4F29C084; Thu, 13 Sep 2007 14:22:11 +0200 (CEST) Received: from castafiore.sivsa.com ([127.0.0.1]) by localhost (castafiore.sivsa.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rOrPXvRW5452; Thu, 13 Sep 2007 14:22:03 +0200 (CEST) Received: from LIMENS.sivsa.int (limens [10.174.123.154]) by castafiore.sivsa.com (Postfix) with ESMTP id 28E5E29C05A; Thu, 13 Sep 2007 14:22:03 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F600.B0E47A23" Subject: RE: v$session_longops hash join operation oddity Date: Thu, 13 Sep 2007 14:22:02 +0200 Message-ID: <607D6181D9919041BE792D70EF2AEC48242D51@LIMENS.sivsa.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v$session_longops hash join operation oddity From: "Alvaro Jose Fernandez" To: "Stefan Knecht" Cc: "oracle-l" X-archive-position: 1508 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: alvaro.fernandez@sivsa.com Precedence: normal Reply-to: alvaro.fernandez@sivsa.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l X-Virus-Scanned: Debian amavisd-new at localhost.localdomain ------_=_NextPart_001_01C7F600.B0E47A23 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Stefan, =20 Cannot imagine, if the number of rows returned for the hash join is the expected, what is wrong, unless an internal bug.=20 =20 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). =20 conn / as sysdba; exec dbms_system.set_ev(,,10104,10,'') ; /* sid, serial of the session doing the query */ commit; . . . exec dbms_system.set_ev((,,10104,0,'') ; <=3D=3D deactivate event when=20 commit; =20 =20 >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 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 .=20 =20 alvaro ------_=_NextPart_001_01C7F600.B0E47A23 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

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,’’) ; = <=3D=3D 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@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

------_=_NextPart_001_01C7F600.B0E47A23-- -- http://www.freelists.org/webpage/oracle-l