Very slow OracleDataReader.Read or HasRows ???

Question

Hi,
I’m experiencing huge performance delays when calling Read on OracleDataReader …. It takes for ages ….. I waited for 2 minutes then stopped the execution in my .NET application…
If I run the same SQL statement in Toad for Oracle it returns in less than a second ….. Why ???
The only difference is that in .NET I call ExecuteReader to fetch rows while using parameters …. In Toad I just execute generated SQL statement as seen below.
I’m using System.Data.OracleClient.dll from .NET framework 2.0 …. Tried 3.5 , same result.
SQL:
SELECT TITLE,SUBTITLE,AUTHOR,ART_DATE,MEDIA_CODE,FULLTEXT,ID,STARTTIME,ON_PAGE,COORDINATES,COOR_TEXT,THUMBS_NR,CATEGORY,SHOW,CREATE_DATE,GENRE,USER_LAST,DURATION FROM MS_ARTICLE WHERE CREATE_DATE >= TO_DATE('10.12.2008 09:38:16','dd.MM.yyyy HH24:MI:SS') AND (MEDIA_COUNTRY = 'SLOVENIJA' AND INSTR(CHAR_14, ' METRONET',1,1)>0 )
Execution plan is:
Plan
SELECT STATEMENT ALL_ROWS Cost: 4 Bytes: 550 Cardinality: 1
     2 TABLE ACCESS BY INDEX ROWID TABLE PRESCLIP.MS_ARTICLE Cost: 4 Bytes: 550 Cardinality: 1
          1 INDEX RANGE SCAN INDEX PRESCLIP.MS_ARTICLE_CREATE_DATE_INDEX Cost: 3 Cardinality: 1
Any ideas why ?

Answer 1

Its tough to make a guess with the limited information available at this point.
Are you sure you're executing the exact same query in SQLNavigator? Same bind variables/types/etc?
To troubleshoot further, I'd enable SQLNet tracing (level 16) with Timestamps enabled, and see if you can pick out a 60 second gap in the timestamps. For example, here's an excerpt from a sqlnet trace.:
(1124) [28-JAN-2009 10:33:18:428] nttrd: entry
(1124) [28-JAN-2009 10:33:45:787] nttrd: socket 436 had bytes read=14
(1124) [28-JAN-2009 10:33:45:787] nttrd: exit
In the above trace, we can see we entered the oracle client network receive function (nttrd:entry) at 10:33:18:428, and it was 27 seconds before 14 bytes were read on the socket and the network call completed (nttrd: exit). It was waiting for info from the socket read for 27 seconds. In that case, that would generally point to a database side issue.
Matching client and server sqlnet traces should give you a more complete picture.
You may want to open a SR with Oracle support to get the traces looked at.
Hope it helps,
Greg