Oracle query is slow (or fails) from .NET app but is fast from SQL Developer

Question

We use ODP.NET to perform queries on Oracle databases, and normally it works fine. There is a particular database, and a particular view in that database, though, that we just can't complete a query on from .NET. For example:

SELECT some_varchar_field FROM the_view WHERE ROWNUM < 5;

If I execute this query from within Oracle SQL developer, it finishes in less than a second. If I do an identical query from our .NET application using ODP.NET, it hangs and eventually produces an "ORA-03135: connection lost contact" error. I think that limiting it to just a few rows eliminates the possibility that it is as FetchSize issue.

There are other queries I can execute successfully, but they are slower from our program than from SQL Developer. Again, I realize SQL Developer only gets data for the first 50 rows initially, but I think the ROWNUM condition takes that out of the equation.

What might be different about the connection or command that Oracle SQL Developer is using vs the one our application is using that would cause a difference in speed?

Unfortunately, I do not have access to the server (other than to run Oracle queries against it).

Thank you.

UPDATE: I have tried the same query with Microsoft's Oracle provider and it executes very quickly. Unfortunately, that provider is deprecated so this is not a long term solution.

Answer 1

It had nothing to do with the ODP.NET provider. The problem was that the library we use to create connections for us (which, of course, is not used by Oracle SQL Developer, and which I did not use when I tried the Microsoft provider) was always executing the following statements before doing anything:

ALTER SESSION SET NLS_COMP = LINGUISTIC
ALTER SESSION SET NLS_SORT = BINARY_CI

These make Oracle case-insensitive. But, they also render all conventional indexes useless. Because we were querying from a View, it had ordering built in. And because we don't own the database, we can't make the indexes linguistic to fix the performance problem.

Providing a way to not execute those statements in this (rare) scenario fixed the problem.

Answer 2

Immediate thoughts are

1. CLOB, BLOB or LONG/LONG RAW which requires a lot of bandwidth for just a few rows.
2. Invalid data (eg there are ways to get an invalid date into a date field, which may confuse some clients)
3. "the_table" isn't actually a table but a view or something with a complex derivation or has a VPD/RLS/FGAC security policy on it.
4. Exotic datatype (Spatial or User Defined).

Suggestions

1. Explicitly list the columns (eg SELECT a,b,c FROM the_table WHERE ROWNUM < 5). Add columns one by one until it stops working. That assumes there is at least one 'simple' column in the table.
2. Check the session in v$session to see what the wait EVENT is. Either the DB server is burning CPU for this SQL, or it is waiting for something (possibly the client).
3. Check the SQL in v$sql. Is there one or more child cursors. is there one or more PLAN_HASH_VALUEs. Different child cursors can use different plans. Without a WHERE clause other than ROWNUM, this is pretty unlikely.

Answer 3

A view adds a different magnitude of complexity. A "SELECT column FROM table WHERE rownum < 5" has probably just a single explain plan, picking data from a single local object.

For a view you should start by getting the view text SELECT TEXT FROM ALL_VIEWS WHERE VIEW_NAME = ...

There's a lot that can be different between an ODP.NET and an SQL Developer session. I'd think about NLS parameters (such as date formats) and character set settings.

If you can locate the SQL in v$sql, you can do a DBMS_XPLAN.DISPLAY_CURSOR(sql_id) to look at the different plans and see if you can identify the problem.

Answer 4

On a project I was working on at my former employer, we were using odp.net to talk to a large retailing system database and we'd get connection lost errors.

It took a lot of effort to prove, but it ended up being a corrupt index inside the Oracle database that was only being hit by our query. The DBA's eventually traced it to a coredump of the process that run on the Sun box when our query was being executed. We didn't use any sort of query hinting etc, but when we ran the same query in Toad, it didn't hit this particular index. strange??<<