OracleCommands With Parameters not being prepared

Question

Hi!
We have a complex issue.
Client (actually originally we had the issue in the appserver, but we also reproduced in a win box): Win, ODP.Net unmanaged 2.112.3.0
Server: Oracle 10.2.0.4.0-64b running on AIX.
The simptomps: symple select running for long time. Same select take seconds in SqlDeveloper.
The query is of the form:
"select * from <Phisical Table> where field1=:0 and field2 between :1 and :2"
there are indices defined, that are being used when we call from SqlDeveloper, however, when we call from .net, using the following pseudocode:
DbCommand liacmd = liaFactory.CreateCommand();
DbParameter lioParameter1 = liacmd.CreateParameter();
lioParameter1.ParameterName = ":0";
lioParameter1.Value = "70100100347";
liacmd.Parameters.Add(lioParameter1);
DbParameter lioParameter2 = liacmd.CreateParameter();
lioParameter2.ParameterName = ":1";
lioParameter2.Value = "20130101000000";
liacmd.Parameters.Add(lioParameter2);
lioParameter2 = liacmd.CreateParameter();
lioParameter2.ParameterName = ":2";
lioParameter2.Value = "20131017000000";
liacmd.Parameters.Add(lioParameter2);
DbDataReader liareader = liacmd.ExecuteReader();
With the unmanaged .net provider, the ExecuteReader takes around 3 minutes, the Read() 15 minutes!
If i switch to the OleDb provider, the Execute+Read takes less than a second in total.
We have the ODP.Net trace level 63, it taking long time in actions like:
     TIME:2013/10/18-08:38:58:186 TID: b54  (ENTRY) OpsGetAvailPhysMemory()
     TIME:2013/10/18-08:38:58:186 TID: b54  (EXIT)  OpsGetAvailPhysMemory(): returnValue=0 Line=1068
However with the old ODP.Net unmanaged 2.111.6.20 the time was spent in...
     TIME:2013/10/18-08:01:07:453 TID: c80  (ENTRY) OpsSqlExecuteReader(): (1c0f38)=0
     TIME:2013/10/18-08:09:57:013 TID: c80  (ENTRY) OpsMetAddRef(): (1c3668)=0
Any ideas on how to debug this mess (in the production db)?
thanks
daniel

Answer 1

Hi Alex,
Thanks, answering the questions:
Does this problem only occur on one machine (i.e. production, not on test machines)?
     > when it happens, it happens everywhere (production/test machines, but allways when accesing the production 10g db).
     > Today the problem is not happening, so i cannot test, waiting until the next occurrence so I can continue testing alternatives.
Does this behavior occur with other queries? If so, what do all those queries have in common?
     > Other queries behave ok, is just this particular simple query. It is weird, I have to recheck, but apparently even changing the parameter value will make the query work in some occasions.
What if the parameters are replaced by literal values?
     > Good advice, will try that the next we experience the problem.
So now we are just waiting for the next time the problem appears, to be able to try more options.
thanks!
df