I just benchmarked a query against an Oracle database using three
different access techniques (OLDDB, ADO.NET and ODBC) and I found that
ADO.NET fared worse than all of them - almost twice as long as OLEDB!

Surely something is wrong here. I was under the impression that ADO.NET
was supposed to improve retrieval times, not slow it down! The results
are as follows - it is an average of five executions of the same query.
Code is included in case someone wants to tell me what I'm doing wrong.
The query itself is a fairly long select query that I can't post here
due to its proprietary nature - the actual query shouldn't affect these
results, anyway.

Please, someone, what's going on?

-----------------------------------------------------------
OLEDB: 1.21 Seconds
-----------------------------------------------------------

public String execute_query (String query, DataGridView data_grid)
{
Int32 rowcount = 0;
OleDbCommand command = new OleDbCommand (query, connection);
DataTable data_table = new DataTable ();
OleDbDataAdapter data_reader = new OleDbDataAdapter ();
try {
data_reader.SelectCommand = command;
data_reader.Fill (data_table);
data_grid.DataSource = data_table;
rowcount = data_table.Rows.Count;
} catch (Exception e) {
MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
} finally {
data_table.Dispose ();
data_reader.Dispose ();
command.Dispose ();
}// try..catch..finally
return "Rows returned: " + rowcount.ToString ();
}// execute_query;

-----------------------------------------------------------
ODBC: 1.274 Seconds
-----------------------------------------------------------

public String execute_query (String query) {
Int32 rowcount = 0;
OdbcCommand command = new OdbcCommand (query, connection);
DataTable data_table = new DataTable ();
OdbcDataAdapter data_reader = new OdbcDataAdapter ();
try {
data_reader.SelectCommand = command;
data_reader.Fill (data_table);
rowcount = data_table.Rows.Count;
} catch (Exception e) {
MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
} finally {
data_table.Dispose ();
data_reader.Dispose ();
command.Dispose ();
}// try..catch..finally
return "Rows returned: " + rowcount.ToString ();
}// execute_query;

-----------------------------------------------------------
ADO.NET: 2.056 Seconds
-----------------------------------------------------------

public String execute_query (String query) {
Int32 rowcount = 0;
OracleCommand command = new OracleCommand (query, connection);
DataTable data_table = new DataTable ();
OracleDataAdapter data_reader = new OracleDataAdapter ();
try {
data_reader.SelectCommand = command;
data_reader.Fill (data_table);
rowcount = data_table.Rows.Count;
} catch (Exception e) {
MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
} finally {
data_table.Dispose ();
data_reader.Dispose ();
command.Dispose ();
}// try..catch..finally
return "Rows returned: " + rowcount.ToString ();
}// execute_query;

RE: ADO.NET the fastest? My foot! by KerryMoorman

KerryMoorman
Tue Oct 03 13:05:02 CDT 2006

Rex the Strange,

All of your code examples are using ADO.Net.

If Select query execution speed is your primary concern, you should pick a
provider accordingly.

Kerry Moorman


"Rex the Strange" wrote:

> I just benchmarked a query against an Oracle database using three
> different access techniques (OLDDB, ADO.NET and ODBC) and I found that
> ADO.NET fared worse than all of them - almost twice as long as OLEDB!
>
> Surely something is wrong here. I was under the impression that ADO.NET
> was supposed to improve retrieval times, not slow it down! The results
> are as follows - it is an average of five executions of the same query.
> Code is included in case someone wants to tell me what I'm doing wrong.
> The query itself is a fairly long select query that I can't post here
> due to its proprietary nature - the actual query shouldn't affect these
> results, anyway.
>
> Please, someone, what's going on?
>
> -----------------------------------------------------------
> OLEDB: 1.21 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query, DataGridView data_grid)
> {
> Int32 rowcount = 0;
> OleDbCommand command = new OleDbCommand (query, connection);
> DataTable data_table = new DataTable ();
> OleDbDataAdapter data_reader = new OleDbDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> data_grid.DataSource = data_table;
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>
> -----------------------------------------------------------
> ODBC: 1.274 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query) {
> Int32 rowcount = 0;
> OdbcCommand command = new OdbcCommand (query, connection);
> DataTable data_table = new DataTable ();
> OdbcDataAdapter data_reader = new OdbcDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>
> -----------------------------------------------------------
> ADO.NET: 2.056 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query) {
> Int32 rowcount = 0;
> OracleCommand command = new OracleCommand (query, connection);
> DataTable data_table = new DataTable ();
> OracleDataAdapter data_reader = new OracleDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>
>

Re: ADO.NET the fastest? My foot! by Miha

Miha
Tue Oct 03 15:19:02 CDT 2006

Hi,

Your benchmark is really not accurate at all.
I mean you deduce that ado.net is slow from three examples??? And even don't
bother to check which operation is slow/fast?
Did you repeat the methods in a loop? No? Ever heard of JIT? etc...

--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/

"Rex the Strange" <roger.main@widgetinc.com> wrote in message
news:1159894516.413433.247900@b28g2000cwb.googlegroups.com...
>I just benchmarked a query against an Oracle database using three
> different access techniques (OLDDB, ADO.NET and ODBC) and I found that
> ADO.NET fared worse than all of them - almost twice as long as OLEDB!
>
> Surely something is wrong here. I was under the impression that ADO.NET
> was supposed to improve retrieval times, not slow it down! The results
> are as follows - it is an average of five executions of the same query.
> Code is included in case someone wants to tell me what I'm doing wrong.
> The query itself is a fairly long select query that I can't post here
> due to its proprietary nature - the actual query shouldn't affect these
> results, anyway.
>
> Please, someone, what's going on?
>
> -----------------------------------------------------------
> OLEDB: 1.21 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query, DataGridView data_grid)
> {
> Int32 rowcount = 0;
> OleDbCommand command = new OleDbCommand (query, connection);
> DataTable data_table = new DataTable ();
> OleDbDataAdapter data_reader = new OleDbDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> data_grid.DataSource = data_table;
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>
> -----------------------------------------------------------
> ODBC: 1.274 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query) {
> Int32 rowcount = 0;
> OdbcCommand command = new OdbcCommand (query, connection);
> DataTable data_table = new DataTable ();
> OdbcDataAdapter data_reader = new OdbcDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>
> -----------------------------------------------------------
> ADO.NET: 2.056 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query) {
> Int32 rowcount = 0;
> OracleCommand command = new OracleCommand (query, connection);
> DataTable data_table = new DataTable ();
> OracleDataAdapter data_reader = new OracleDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>



Re: ADO.NET the fastest? My foot! by Rex

Rex
Tue Oct 03 16:56:24 CDT 2006


> Did you repeat the methods in a loop? No? Ever heard of JIT? etc...

Yeah, I did (loop). I just didn't post that part here.

So enlighten me. How can I make this faster?


Re: ADO.NET the fastest? My foot! by Rex

Rex
Tue Oct 03 17:00:17 CDT 2006


Kerry Moorman wrote:

> All of your code examples are using ADO.Net.
>
> If Select query execution speed is your primary concern, you should pick a
> provider accordingly.
>
> Kerry Moorman

Well that would explain part of it. Can you elaborate on what you mean
by:

"pick a provider accordingly."

I have to use Oracle - I have no choice in the matter on that count.

rts.


Re: ADO.NET the fastest? My foot! by Chris

Chris
Tue Oct 03 17:00:47 CDT 2006

Your test is a bit flawed.

First off, all of your methods are using ADO.Net. You're using a wide
variety of data providers, but they're all ADO.Net Data Providers.

You're never using the actual Oracle provided drivers for ADO.NET, so you
don't have a good baseline to start from. The Microsoft provider for Oracle
shouldn't be considered the ideal way to conenct to the Oracle Database.
Sure, it's good enough for many things, but I would be willing to bet it's
not nearly as tuned as (for example) the Sql Client provider for Sql Server.

You're not factoring in database connection times (are you using pooled
connections?), what's chached and what's not in the database, and a number
of other items.

I would love to see your test done in a more rigorous way. To do this,
you'll need to be a bit more methodical though.

I have, personally, been involved in a number of "What database to we buy,
and how do we connect to it?" decisions for very large applications. I've
had excellent success with SqlClient connecting to Sql Server, and the
Oracle Provider(from Oracle, not Microsoft), connecting to Oracle.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise
http://www.coversant.net/blogs/cmullins


"Rex the Strange" <roger.main@widgetinc.com> wrote in message
news:1159894516.413433.247900@b28g2000cwb.googlegroups.com...
>I just benchmarked a query against an Oracle database using three
> different access techniques (OLDDB, ADO.NET and ODBC) and I found that
> ADO.NET fared worse than all of them - almost twice as long as OLEDB!
>
> Surely something is wrong here. I was under the impression that ADO.NET
> was supposed to improve retrieval times, not slow it down! The results
> are as follows - it is an average of five executions of the same query.
> Code is included in case someone wants to tell me what I'm doing wrong.
> The query itself is a fairly long select query that I can't post here
> due to its proprietary nature - the actual query shouldn't affect these
> results, anyway.
>
> Please, someone, what's going on?
>
> -----------------------------------------------------------
> OLEDB: 1.21 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query, DataGridView data_grid)
> {
> Int32 rowcount = 0;
> OleDbCommand command = new OleDbCommand (query, connection);
> DataTable data_table = new DataTable ();
> OleDbDataAdapter data_reader = new OleDbDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> data_grid.DataSource = data_table;
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>
> -----------------------------------------------------------
> ODBC: 1.274 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query) {
> Int32 rowcount = 0;
> OdbcCommand command = new OdbcCommand (query, connection);
> DataTable data_table = new DataTable ();
> OdbcDataAdapter data_reader = new OdbcDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>
> -----------------------------------------------------------
> ADO.NET: 2.056 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query) {
> Int32 rowcount = 0;
> OracleCommand command = new OracleCommand (query, connection);
> DataTable data_table = new DataTable ();
> OracleDataAdapter data_reader = new OracleDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>



Database speed issues by Rex

Rex
Tue Oct 03 17:21:25 CDT 2006

Chris Mullins wrote:
> Your test is a bit flawed.
>
> First off, all of your methods are using ADO.Net. You're using a wide
> variety of data providers, but they're all ADO.Net Data Providers.
>
> You're never using the actual Oracle provided drivers for ADO.NET, so you
> don't have a good baseline to start from. The Microsoft provider for Oracle
> shouldn't be considered the ideal way to conenct to the Oracle Database.
> Sure, it's good enough for many things, but I would be willing to bet it's
> not nearly as tuned as (for example) the Sql Client provider for Sql Server.
>
> You're not factoring in database connection times (are you using pooled
> connections?), what's chached and what's not in the database, and a number
> of other items.
>
> I would love to see your test done in a more rigorous way. To do this,
> you'll need to be a bit more methodical though.
>
> I have, personally, been involved in a number of "What database to we buy,
> and how do we connect to it?" decisions for very large applications. I've
> had excellent success with SqlClient connecting to Sql Server, and the
> Oracle Provider(from Oracle, not Microsoft), connecting to Oracle.

OK. I'll cry uncle at this point. It seems that all I've managed to
demonstrate is that certain providers are faster than others. Allow me
to rephrase the question:

What do people think is the fastest way to connect to an Oracle
database?

rts.


Re: Database speed issues by William

William
Tue Oct 03 20:31:06 CDT 2006

There are at least three different "native" managed providers for Oracle.
Those sold by Microsoft, Oracle itself and DataDirect. Each has its
advantages and issues. In addition, you can also use generic (what I call
"OSFA") providers like ODBC and OLE DB that expose less native functionality
but can actually be faster in some cases.
As I discuss in my books, it's not how fast you ask the question--execute
the query. It's how long it takes the server to answer the question that
governs performance. Most performance tests I've seen don't measure anything
very well--and no, I didn't look at yours. The performance you seek might be
gained by better indexes, smarter queries, properly handling server-side
compiled code and a dozen dozen other factors.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
Between now and Nov. 6th 2006 you can sign up for a substantial discount.
Look for the "Early Bird" discount checkbox on the registration form...

"Rex the Strange" <roger.main@widgetinc.com> wrote in message
news:1159914085.621484.273940@e3g2000cwe.googlegroups.com...
> Chris Mullins wrote:
>> Your test is a bit flawed.
>>
>> First off, all of your methods are using ADO.Net. You're using a wide
>> variety of data providers, but they're all ADO.Net Data Providers.
>>
>> You're never using the actual Oracle provided drivers for ADO.NET, so you
>> don't have a good baseline to start from. The Microsoft provider for
>> Oracle
>> shouldn't be considered the ideal way to conenct to the Oracle Database.
>> Sure, it's good enough for many things, but I would be willing to bet
>> it's
>> not nearly as tuned as (for example) the Sql Client provider for Sql
>> Server.
>>
>> You're not factoring in database connection times (are you using pooled
>> connections?), what's chached and what's not in the database, and a
>> number
>> of other items.
>>
>> I would love to see your test done in a more rigorous way. To do this,
>> you'll need to be a bit more methodical though.
>>
>> I have, personally, been involved in a number of "What database to we
>> buy,
>> and how do we connect to it?" decisions for very large applications. I've
>> had excellent success with SqlClient connecting to Sql Server, and the
>> Oracle Provider(from Oracle, not Microsoft), connecting to Oracle.
>
> OK. I'll cry uncle at this point. It seems that all I've managed to
> demonstrate is that certain providers are faster than others. Allow me
> to rephrase the question:
>
> What do people think is the fastest way to connect to an Oracle
> database?
>
> rts.
>



Re: ADO.NET the fastest? My foot! by Miha

Miha
Wed Oct 04 03:59:16 CDT 2006

You might start by searching for bottleneck using a profiler.
Or simply compare various providers performance (as you did, but with
different parameters, etc) if performance is only thing that matters for
you.

--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/

"Rex the Strange" <roger.main@widgetinc.com> wrote in message
news:1159912584.062565.297850@k70g2000cwa.googlegroups.com...
>
>> Did you repeat the methods in a loop? No? Ever heard of JIT? etc...
>
> Yeah, I did (loop). I just didn't post that part here.
>
> So enlighten me. How can I make this faster?
>



Re: Database speed issues by MrSmersh

MrSmersh
Wed Oct 04 06:25:02 CDT 2006

I'll go with Oracle.
Take care that are also subtle differences in behavior between these
providers.

"William (Bill) Vaughn" wrote:

> There are at least three different "native" managed providers for Oracle.
> Those sold by Microsoft, Oracle itself and DataDirect. Each has its
> advantages and issues. In addition, you can also use generic (what I call
> "OSFA") providers like ODBC and OLE DB that expose less native functionality
> but can actually be faster in some cases.
> As I discuss in my books, it's not how fast you ask the question--execute
> the query. It's how long it takes the server to answer the question that
> governs performance. Most performance tests I've seen don't measure anything
> very well--and no, I didn't look at yours. The performance you seek might be
> gained by better indexes, smarter queries, properly handling server-side
> compiled code and a dozen dozen other factors.
>
> --
> ____________________________________
> William (Bill) Vaughn
> Author, Mentor, Consultant
> Microsoft MVP
> INETA Speaker
> www.betav.com/blog/billva
> www.betav.com
> Please reply only to the newsgroup so that others can benefit.
> This posting is provided "AS IS" with no warranties, and confers no rights.
> __________________________________
> Visit www.hitchhikerguides.net to get more information on my latest book:
> Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
> Between now and Nov. 6th 2006 you can sign up for a substantial discount.
> Look for the "Early Bird" discount checkbox on the registration form...
>
> "Rex the Strange" <roger.main@widgetinc.com> wrote in message
> news:1159914085.621484.273940@e3g2000cwe.googlegroups.com...
> > Chris Mullins wrote:
> >> Your test is a bit flawed.
> >>
> >> First off, all of your methods are using ADO.Net. You're using a wide
> >> variety of data providers, but they're all ADO.Net Data Providers.
> >>
> >> You're never using the actual Oracle provided drivers for ADO.NET, so you
> >> don't have a good baseline to start from. The Microsoft provider for
> >> Oracle
> >> shouldn't be considered the ideal way to conenct to the Oracle Database.
> >> Sure, it's good enough for many things, but I would be willing to bet
> >> it's
> >> not nearly as tuned as (for example) the Sql Client provider for Sql
> >> Server.
> >>
> >> You're not factoring in database connection times (are you using pooled
> >> connections?), what's chached and what's not in the database, and a
> >> number
> >> of other items.
> >>
> >> I would love to see your test done in a more rigorous way. To do this,
> >> you'll need to be a bit more methodical though.
> >>
> >> I have, personally, been involved in a number of "What database to we
> >> buy,
> >> and how do we connect to it?" decisions for very large applications. I've
> >> had excellent success with SqlClient connecting to Sql Server, and the
> >> Oracle Provider(from Oracle, not Microsoft), connecting to Oracle.
> >
> > OK. I'll cry uncle at this point. It seems that all I've managed to
> > demonstrate is that certain providers are faster than others. Allow me
> > to rephrase the question:
> >
> > What do people think is the fastest way to connect to an Oracle
> > database?
> >
> > rts.
> >
>
>
>

Re: Database speed issues by Rex

Rex
Wed Oct 04 11:02:54 CDT 2006

OSFA?


William (Bill) Vaughn wrote:
> There are at least three different "native" managed providers for Oracle.
> Those sold by Microsoft, Oracle itself and DataDirect. Each has its
> advantages and issues. In addition, you can also use generic (what I call
> "OSFA") providers like ODBC and OLE DB that expose less native functionality
> but can actually be faster in some cases.
> As I discuss in my books, it's not how fast you ask the question--execute
> the query. It's how long it takes the server to answer the question that
> governs performance. Most performance tests I've seen don't measure anything
> very well--and no, I didn't look at yours. The performance you seek might be
> gained by better indexes, smarter queries, properly handling server-side
> compiled code and a dozen dozen other factors.
>
> --
> ____________________________________
> William (Bill) Vaughn
> Author, Mentor, Consultant
> Microsoft MVP
> INETA Speaker
> www.betav.com/blog/billva
> www.betav.com
> Please reply only to the newsgroup so that others can benefit.
> This posting is provided "AS IS" with no warranties, and confers no rights.
> __________________________________
> Visit www.hitchhikerguides.net to get more information on my latest book:
> Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
> Between now and Nov. 6th 2006 you can sign up for a substantial discount.
> Look for the "Early Bird" discount checkbox on the registration form...
>
> "Rex the Strange" <roger.main@widgetinc.com> wrote in message
> news:1159914085.621484.273940@e3g2000cwe.googlegroups.com...
> > Chris Mullins wrote:
> >> Your test is a bit flawed.
> >>
> >> First off, all of your methods are using ADO.Net. You're using a wide
> >> variety of data providers, but they're all ADO.Net Data Providers.
> >>
> >> You're never using the actual Oracle provided drivers for ADO.NET, so you
> >> don't have a good baseline to start from. The Microsoft provider for
> >> Oracle
> >> shouldn't be considered the ideal way to conenct to the Oracle Database.
> >> Sure, it's good enough for many things, but I would be willing to bet
> >> it's
> >> not nearly as tuned as (for example) the Sql Client provider for Sql
> >> Server.
> >>
> >> You're not factoring in database connection times (are you using pooled
> >> connections?), what's chached and what's not in the database, and a
> >> number
> >> of other items.
> >>
> >> I would love to see your test done in a more rigorous way. To do this,
> >> you'll need to be a bit more methodical though.
> >>
> >> I have, personally, been involved in a number of "What database to we
> >> buy,
> >> and how do we connect to it?" decisions for very large applications. I've
> >> had excellent success with SqlClient connecting to Sql Server, and the
> >> Oracle Provider(from Oracle, not Microsoft), connecting to Oracle.
> >
> > OK. I'll cry uncle at this point. It seems that all I've managed to
> > demonstrate is that certain providers are faster than others. Allow me
> > to rephrase the question:
> >
> > What do people think is the fastest way to connect to an Oracle
> > database?
> >
> > rts.
> >


Re: Database speed issues by Chris

Chris
Wed Oct 04 12:26:23 CDT 2006

"Rex the Strange" <roger.main@widgetinc.com> wrote in message
>
> What do people think is the fastest way to connect to an Oracle
> database?

To be honest, in most cases it doesn't really matter. In almost all
real-world usage, your performance is going to be governed by how fast your
database can perform your queries. The issue of network lag time, and
database performance is going to be signifigantly more than the difference
in performance between providers.

If you're doing advanced Oracle stuff, I would go with the provider written
by Oracle. The drawback to this is that it requries (if I remember right) a
200+ meg installation on the machine. If all you have is a web server
hitting a database, this is plausable. If you're building a WinForms app
that's running on a few hundred workstations this isn't much of an answer.

Like all performance tuning, I wouldn't worry about it until you run into
performance problems. Go with whatever gets the job done and don't worry
about it unless you actually run into performance problems.

When/If you do hit performance problems, then take a methodical approach to
solving them. Use metrics and profilers - including a database profiler.

In the data layer for our IM Server, we use the Microsoft Provider for
Oracle. This simplifies the install, gives a good feature set, and has
worked fine. We don't do anything advanced though, as we also have data
layers for Postgres, MySQL, SQL 2000, SQL 2005, and a few others and they
all need to be interchangable based on a check-box during the installation
process.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise
http://www.coversant.net/blogs/cmullins



Re: Database speed issues by William

William
Wed Oct 04 17:14:00 CDT 2006

OSFA::One Size Fits All--a generic interface designed to access a wide
variety of engines.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
Between now and Nov. 6th 2006 you can sign up for a substantial discount.
Look for the "Early Bird" discount checkbox on the registration form...

"Rex the Strange" <roger.main@widgetinc.com> wrote in message
news:1159977774.373458.228550@k70g2000cwa.googlegroups.com...
> OSFA?
>
>
> William (Bill) Vaughn wrote:
>> There are at least three different "native" managed providers for Oracle.
>> Those sold by Microsoft, Oracle itself and DataDirect. Each has its
>> advantages and issues. In addition, you can also use generic (what I call
>> "OSFA") providers like ODBC and OLE DB that expose less native
>> functionality
>> but can actually be faster in some cases.
>> As I discuss in my books, it's not how fast you ask the question--execute
>> the query. It's how long it takes the server to answer the question that
>> governs performance. Most performance tests I've seen don't measure
>> anything
>> very well--and no, I didn't look at yours. The performance you seek might
>> be
>> gained by better indexes, smarter queries, properly handling server-side
>> compiled code and a dozen dozen other factors.
>>
>> --
>> ____________________________________
>> William (Bill) Vaughn
>> Author, Mentor, Consultant
>> Microsoft MVP
>> INETA Speaker
>> www.betav.com/blog/billva
>> www.betav.com
>> Please reply only to the newsgroup so that others can benefit.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> __________________________________
>> Visit www.hitchhikerguides.net to get more information on my latest book:
>> Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
>> Between now and Nov. 6th 2006 you can sign up for a substantial discount.
>> Look for the "Early Bird" discount checkbox on the registration form...
>>
>> "Rex the Strange" <roger.main@widgetinc.com> wrote in message
>> news:1159914085.621484.273940@e3g2000cwe.googlegroups.com...
>> > Chris Mullins wrote:
>> >> Your test is a bit flawed.
>> >>
>> >> First off, all of your methods are using ADO.Net. You're using a wide
>> >> variety of data providers, but they're all ADO.Net Data Providers.
>> >>
>> >> You're never using the actual Oracle provided drivers for ADO.NET, so
>> >> you
>> >> don't have a good baseline to start from. The Microsoft provider for
>> >> Oracle
>> >> shouldn't be considered the ideal way to conenct to the Oracle
>> >> Database.
>> >> Sure, it's good enough for many things, but I would be willing to bet
>> >> it's
>> >> not nearly as tuned as (for example) the Sql Client provider for Sql
>> >> Server.
>> >>
>> >> You're not factoring in database connection times (are you using
>> >> pooled
>> >> connections?), what's chached and what's not in the database, and a
>> >> number
>> >> of other items.
>> >>
>> >> I would love to see your test done in a more rigorous way. To do this,
>> >> you'll need to be a bit more methodical though.
>> >>
>> >> I have, personally, been involved in a number of "What database to we
>> >> buy,
>> >> and how do we connect to it?" decisions for very large applications.
>> >> I've
>> >> had excellent success with SqlClient connecting to Sql Server, and the
>> >> Oracle Provider(from Oracle, not Microsoft), connecting to Oracle.
>> >
>> > OK. I'll cry uncle at this point. It seems that all I've managed to
>> > demonstrate is that certain providers are faster than others. Allow me
>> > to rephrase the question:
>> >
>> > What do people think is the fastest way to connect to an Oracle
>> > database?
>> >
>> > rts.
>> >
>



Re: ADO.NET the fastest? My foot! by Cor

Cor
Wed Oct 04 22:42:05 CDT 2006

Rex,

I thought that there are some videos on Google as benchmark between a
Ferrari and a Fiat.

It seems that the are at the end almost finishing at the same moment.

Just what I thought reading your message.

Cor

"Rex the Strange" <roger.main@widgetinc.com> schreef in bericht
news:1159894516.413433.247900@b28g2000cwb.googlegroups.com...
>I just benchmarked a query against an Oracle database using three
> different access techniques (OLDDB, ADO.NET and ODBC) and I found that
> ADO.NET fared worse than all of them - almost twice as long as OLEDB!
>
> Surely something is wrong here. I was under the impression that ADO.NET
> was supposed to improve retrieval times, not slow it down! The results
> are as follows - it is an average of five executions of the same query.
> Code is included in case someone wants to tell me what I'm doing wrong.
> The query itself is a fairly long select query that I can't post here
> due to its proprietary nature - the actual query shouldn't affect these
> results, anyway.
>
> Please, someone, what's going on?
>
> -----------------------------------------------------------
> OLEDB: 1.21 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query, DataGridView data_grid)
> {
> Int32 rowcount = 0;
> OleDbCommand command = new OleDbCommand (query, connection);
> DataTable data_table = new DataTable ();
> OleDbDataAdapter data_reader = new OleDbDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> data_grid.DataSource = data_table;
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>
> -----------------------------------------------------------
> ODBC: 1.274 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query) {
> Int32 rowcount = 0;
> OdbcCommand command = new OdbcCommand (query, connection);
> DataTable data_table = new DataTable ();
> OdbcDataAdapter data_reader = new OdbcDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>
> -----------------------------------------------------------
> ADO.NET: 2.056 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query) {
> Int32 rowcount = 0;
> OracleCommand command = new OracleCommand (query, connection);
> DataTable data_table = new DataTable ();
> OracleDataAdapter data_reader = new OracleDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>



Re: ADO.NET the fastest? My foot! by deepak

deepak
Wed Oct 04 23:31:57 CDT 2006

Hi Rex,
Could u tell me how many number of Records are u fetching.


Rex the Strange wrote:
> I just benchmarked a query against an Oracle database using three
> different access techniques (OLDDB, ADO.NET and ODBC) and I found that
> ADO.NET fared worse than all of them - almost twice as long as OLEDB!
>
> Surely something is wrong here. I was under the impression that ADO.NET
> was supposed to improve retrieval times, not slow it down! The results
> are as follows - it is an average of five executions of the same query.
> Code is included in case someone wants to tell me what I'm doing wrong.
> The query itself is a fairly long select query that I can't post here
> due to its proprietary nature - the actual query shouldn't affect these
> results, anyway.
>
> Please, someone, what's going on?
>
> -----------------------------------------------------------
> OLEDB: 1.21 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query, DataGridView data_grid)
> {
> Int32 rowcount = 0;
> OleDbCommand command = new OleDbCommand (query, connection);
> DataTable data_table = new DataTable ();
> OleDbDataAdapter data_reader = new OleDbDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> data_grid.DataSource = data_table;
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>
> -----------------------------------------------------------
> ODBC: 1.274 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query) {
> Int32 rowcount = 0;
> OdbcCommand command = new OdbcCommand (query, connection);
> DataTable data_table = new DataTable ();
> OdbcDataAdapter data_reader = new OdbcDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;
>
> -----------------------------------------------------------
> ADO.NET: 2.056 Seconds
> -----------------------------------------------------------
>
> public String execute_query (String query) {
> Int32 rowcount = 0;
> OracleCommand command = new OracleCommand (query, connection);
> DataTable data_table = new DataTable ();
> OracleDataAdapter data_reader = new OracleDataAdapter ();
> try {
> data_reader.SelectCommand = command;
> data_reader.Fill (data_table);
> rowcount = data_table.Rows.Count;
> } catch (Exception e) {
> MessageBox.Show ("Failed" + Environment.NewLine + e.Message);
> } finally {
> data_table.Dispose ();
> data_reader.Dispose ();
> command.Dispose ();
> }// try..catch..finally
> return "Rows returned: " + rowcount.ToString ();
> }// execute_query;


Re: Database speed issues by Frans

Frans
Thu Oct 05 03:02:56 CDT 2006

William (Bill) Vaughn wrote:

> There are at least three different "native" managed providers for
> Oracle. Those sold by Microsoft, Oracle itself and DataDirect. Each
> has its advantages and issues.

I wouldn't call Microsoft's or Oracle's 'native managed' providers ;).
Both are thin wrappers around the OCI, the oracle client interface
which does all the work, where ODP.NET is more powerful than MS's for
obvious reasons. The only fully native managed providers are the one
from DataDirect and the one from CoreLab, where the one from CoreLab is
way cheaper than the DataDirect one.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Re: ADO.NET the fastest? My foot! by Rex

Rex
Thu Oct 05 09:33:20 CDT 2006


deepak.programming@gmail.com wrote:
> Hi Rex,
> Could u tell me how many number of Records are u fetching.
>

Nah. I'm bored with this thread. I screwed up. Give me a break. And
besides, I'm past this part of my project.

rts.


Re: Database speed issues by William

William
Thu Oct 05 12:01:55 CDT 2006

Ah, you're right. But the one-time cost of getting a deadly serious provider
(like the DataDirect version) makes a lot of sense to me. You get what you
pay for.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
Between now and Nov. 6th 2006 you can sign up for a substantial discount.
Look for the "Early Bird" discount checkbox on the registration form...

"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
news:xn0es3uca40hdk001@news.microsoft.com...
> William (Bill) Vaughn wrote:
>
>> There are at least three different "native" managed providers for
>> Oracle. Those sold by Microsoft, Oracle itself and DataDirect. Each
>> has its advantages and issues.
>
> I wouldn't call Microsoft's or Oracle's 'native managed' providers ;).
> Both are thin wrappers around the OCI, the oracle client interface
> which does all the work, where ODP.NET is more powerful than MS's for
> obvious reasons. The only fully native managed providers are the one
> from DataDirect and the one from CoreLab, where the one from CoreLab is
> way cheaper than the DataDirect one.
>
> FB
>
> --
> ------------------------------------------------------------------------
> Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
> LLBLGen Pro website: http://www.llblgen.com
> My .NET blog: http://weblogs.asp.net/fbouma
> Microsoft MVP (C#)
> ------------------------------------------------------------------------