ODBC vs Pro*c or OCI
TurkBear
In general, ODBC is unwise for any high performance work...It is an added layer
that will slow down the transaction...
OCI and ProC access SqlNet or the Oracle APIs directly and will be much
faster...
Furkan Khan <kh...@home.com> wrote:
>Folks, I am building a very high performance
>distributed application for the internet. I have a
>minimum requirement of at least 400 transaction/s (profiled on
>low end solaris box).
>
>What are the pros and cons of using ODBC vs pro*c or OCI ?
>I am interested in performance issues/experiences using
>ODBC. How is connection pooling in Oracle ODBC driver ?
>Are there any gotchas with ODBC for high performance
>solutions ?
>
>Can I use Oracle Advanced Queuing with Oracle ODBC ??
>
>Any ideas, suggestions appreciated. I can be mailed directly
>also.
>
>Thanks in advance.
>
>Regards.
>Furkan Khan
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
Furkan Khan
Bo Lorentsen
> Folks, I am building a very high performance
> distributed application for the internet. I have a
> minimum requirement of at least 400 transaction/s (profiled on
> low end solaris box).
This can be achieved by using the OCI library, but it look like Oracle
have an error in there client code, if you plan to use dynamic date and
"host arrays" (DynamicBind). I have made a JDBC/ODBC like interface for
OCI and C++, and this interface have gained over 1000/s while inserting
rather small records, but its not stable during the Oracle error (wild
pointer), hope this will be fixed in the near future (I have send this
error to Oracle id DK, but only time will show have fast this will be
fixed).
> What are the pros and cons of using ODBC vs pro*c or OCI ?
I have been told that OBDC is rather slow. Pro*C is ok, but not for
dynamic data and statements, and OCI is not pretty, but it CAN be fast !
/BL
--
Bo Lorentsen
Software Engineer
Belle Systems
E-mail: b...@bellesystems.com
Tel.: +45 5944 2500
Sergei Kuchin
http://home.sprynet.com/~skuchin/otl_1pg.htm -- via OCI7 and OCI8
http://home.sprynet.com/~skuchin/otlodbc.htm -- via ODBC
ODBC by itself is not slow if the driver supports bulk operations.
Sergei
David Sisk
The OCI will definitely give you the absolute best performance and it's
portable to any supported platform, but the API is a bit ugly. Pro*C is
easier to code and is also portable to any supported platform, but doesn't
provide as good performance, although it should still be quite good. ODBC
will give you the highest amount of flexibility, the largest number of
layers, the slowest performance, and the largest number's of potential
problems.
If performance is what you're after, you can't go wrong with the OCI.
That's what ERP systems like SAP use.
Regards,
--
David C. Sisk
The Unofficial ORACLE on NT site
http://www.ipass.net/~davesisk/oont.htm
Furkan Khan wrote in message <37938010...@home.com>...
>Folks, I am building a very high performance
>distributed application for the internet. I have a
>minimum requirement of at least 400 transaction/s (profiled on
>low end solaris box).
>
>What are the pros and cons of using ODBC vs pro*c or OCI ?
winghead
provide you with the code that will be the easiest to maintain because
it's syntax matches with Oracle's syntax when using SQL*Plus. I have
seen only snippets of OCI code. I'm sure it will provide the best
performance, but it is very complex. Through SQL tuning and a good
schema design, you should be able to meet your performance objective
since it seems you will be running it on a UNIX platform.
Best of Luck!
HAP
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All that is visible must grow beyond itself
and extend into the realm of the invisible.
-- Dumont, the tower guardian, _TRON_
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
winghead
prema...@my-deja.com
We are using 8.1.5 Oracle ODBC driver and just today we noticed a
problem. We have a multi-threaded NT application where each thread
basically opens a connection to the database and calls a stored
procedure.
We noticed that all these threads are getting serialized on
SQLExecDirect() call. Is Oracle ODBC multi-threaded? We were
wondering if we have to set some connection attributes.
OCI documentation claims (though we have not tried it yet) that it
supports multi-threading and Oracle ODBC is supposed to have been
implemented using OCI.
Could you please shed some light on the matter? We are eager to know
what is the solution to the problem.
Any help would be really appreciated.
Thanks a lot for your time.
regards,
premal
mumbai,
india
In article <37938010...@home.com>,
kh...@home.com wrote:
> Folks, I am building a very high performance
> distributed application for the internet. I have a
> minimum requirement of at least 400 transaction/s (profiled on
> low end solaris box).
>
> What are the pros and cons of using ODBC vs pro*c or OCI ?
> I am interested in performance issues/experiences using
> ODBC. How is connection pooling in Oracle ODBC driver ?
> Are there any gotchas with ODBC for high performance
> solutions ?
>
> Can I use Oracle Advanced Queuing with Oracle ODBC ??
>
> Any ideas, suggestions appreciated. I can be mailed directly
> also.
>
> Thanks in advance.
>
> Regards.
> Furkan Khan
>
>
Johan Wegener
[snip]
>OCI documentation claims (though we have not tried it yet) that it
>supports multi-threading and Oracle ODBC is supposed to have been
>implemented using OCI.
>
>Could you please shed some light on the matter? We are eager to know
>what is the solution to the problem.
The Oracle ODBC driver - the one provided by Oracle, not a third-party driver - has not necessarily been implemented using pure OCI. Oracle developers usually implement system software using a low-level "Oracle API". Utterly undocumented to outsiders, this API is reportedly called the "Oracle Programming Interface (OPI)".
As OCI and Pro*C both calls the OPI layer, I doubt that there is much of a performance lead of one over the other.
As to your problem, this is what I found in my 8.0.5 Oracle ODBC documentation:
Oracle8 ODBC Setup Dialog Box->Application Options->Enable Thread Safety:
"thread safety can be disabled for a data source. If thread safety is not required, disabling this option eliminates the overhead of using thread safety. By default, thread safety is enabled."
Regards,
Johan
argo...@my-deja.com
Between OCI, and ProC, I would definetly go with ProC.
ProC has a small learning curve.
OCI has a huge learning curve. And then, you
get your quirky programmers who like to do
things their own strange ways, making maintenance
far more difficult.
ProC (.pc) precompiles everything to its OCI (.c)
equivilent, so I would fail to see any performance
benefits from OCI. Both are executable files
off of the Unix system.
Argosy
P Seely
>HI,
>
>Between OCI, and ProC, I would definetly go with ProC.
>
>ProC has a small learning curve.
>
>OCI has a huge learning curve. And then, you
>get your quirky programmers who like to do
>things their own strange ways, making maintenance
>far more difficult.
>
>ProC (.pc) precompiles everything to its OCI (.c)
>equivilent, so I would fail to see any performance
>benefits from OCI. Both are executable files
>off of the Unix system.
>
>Argosy
>
You're a little misinformed about the difference between Pro*C and
OCI. Here's an excerpt from the Pro*C/C++ precompiler FAQ, which can
be found on the Oracle Technet (http://technet.oracle.com):
Question:
Does Pro*C/C++ generate calls to the Oracle Call Interface (OCI)?
Answer:
No. Pro*C/C++ generates data structures, and calls to its runtime
library: SQLLIB (libsql.a in UNIX). SQLLIB, in turn, calls the UPI to
communicate with the database.
Question:
Then why not just code using SQLLIB calls, and not use Pro*C/C++?
Answer:
SQLLIB is not externally documented, is unsupported, and might change
from release to release. Also, Pro*C/C++ is an ANSI/ISO
compliant product, that follows the standard requirements for embedded
SQL.
If you need to do low-level coding, use the OCI. It is supported, and
is guaranteed to stay compatible from release to release. Also, Oracle
is committed to supporting the OCI.
You can also mix OCI and Pro*C.
Fuzzy
>Folks, I am building a very high performance
>distributed application for the internet. I have a
>minimum requirement of at least 400 transaction/s (profiled on
>low end solaris box).
>
>What are the pros and cons of using ODBC vs pro*c or OCI ?
>I am interested in performance issues/experiences using
>ODBC. How is connection pooling in Oracle ODBC driver ?
>Are there any gotchas with ODBC for high performance
>solutions ?
Lots of replies about slow ODBC. ODBC can be as fast as the OCI if
a) You have a good DB design
b) You have well structured queries
c) Your programmers know what they're doing.
Intersolv had some nice tests two years ago showing ODBC to be FASTER
than OCI for inserts and deletes (though YMMV). ODBC means you aren't
tied to Oracle's proprietary technology.
Pro*C has the usual proprietary gotcha's, but seems to perform nicely
on the sites I've seen it.
Ciao
Fuzzy
:-)
Norris
In comp.databases.oracle.misc Fuzzy <gra...@nospam.student.canberra.edu.au> wrote:
: Ciao
: Fuzzy
: :-)
--
===================================
http://www.washington.edu/pine/faq/
Fuzzy
>What is YMMV?
"Your Mileage May Vary"
Ciao
Fuzzy
:-)