| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Perl again
Thanks Ron,
Just answering a few of your comments.
> > When you are using bulk DML in C or Perl or
> whatever
> > you get errors back then deal with them properly.
>
> Yes, but then you need to write your own error
> handlers and/or logging facilities. Granted this is
> not rocket science, but it is something else you
> would need to write.
You need to write the code for SQL*Loader too. What
are you going to do with error and discard files?
How customers are going to fix errors and reprocess
them?
I like SQL*Loader, easy to use it, good for certain
things, but too simple to be the piece of nicely
integrated environment.
> > Why do you think you cannot beat SQL*Loader speed?
>
> Try it for yourself.
>
> Test 1 - SQL*Loader direct load logging and
> nologging (make sure that the process feeding your
> sqlldr process has I/O buffering turned off).
> Test 2 - Pro*C/Perl/whatever direct load logging and
> nologging (pick different array sizes).
I did not try it, because I am using SQL*Loader in
non-programatical environments.
I just questioned that maybe SQL*Loader code is maybe
not perfect :)
OCI has direct path load API's, but I did not go that
far because our mad environments are huge volume OLTP,
mostly "real-time" processing, no way to do locking
with direct path load. Also there are always a few
very big tables. We are using the biggest HW on the
market. Without bulk DML we will need not 64-CPU
machines but 200-CPU machines (I did not say RAC - am
not Oracle sales :)
> > At the end it is based on C OCI, is not it?
>
> Yes, but I believe the methods for direct load are
> different. SQL*Loader uses a different API for
> direct loads than the "normal" OCI libraries.
You have the direct path API in OCI too.
Because do not need direct path API (sometimes too
restrictive in OLTP) I did not test it from some OCI
code.
We agreed about how Oracle SW is perfect :)
At the end again saying that integration between multiple different products without nice API's between them are just disaster. That is why OCI, even with their ugly API calls are just used so often. Just look that almost all development tools using OCI layer, most complex apps too, ...
I would be happy if you can solve all Oracle problems
with high-OLTP/OLAP applications with just simple
binds. I know that some companies are not even on the
level of using prepared/preparsed SQL and binds, but
that is mostly because they never had high-volume
applications at the first place.
We are from time to time hitting the limits of one box
server because we need sometimes more then 64/108
CPU's. Ugly but real.
Regards,
Zoran
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Mar 11 2005 - 04:16:01 CST
 |
 |