Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Perl again

RE: Perl again

From: Martic Zoran <>
Date: Fri, 11 Mar 2005 01:12:42 -0800 (PST)
Message-ID: <>

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.


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
Received on Fri Mar 11 2005 - 04:16:01 CST

Original text of this message