Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Run Oracle without transactions?

Re: Run Oracle without transactions?

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Thu, 8 Jul 1999 08:53:19 +0100
Message-ID: <931421115.27533.1.nnrp-06.9e984b29@news.demon.co.uk>


I suspect that there is no cheap fix for your problem, too many black-boxes with the
potential for complicated twiddly bits.

You ought to have an option to commit
one object at a time within your loading front-end. This will save the massive
rollback, though it could drive the redo log wastage (hence I/O) up quite a bit. (If there isn't an option to commit for each object, there should be).

You could look at the option for producing a second loader, using common code to
generate flat files corresponding to the relational tables that would be loaded, and then use a fast loader to pump the flat files into the database.

To get an insight into what the black boxes are doing, you could send a sql_trace call to the process that gets the data into the database - it might give you some clues on a least expensive strategy.

--

Jonathan Lewis
Yet another Oracle-related web site: www.jlcomp.demon.co.uk

Anita Krishnamurthy wrote in message <37840543.F914E81F_at_cls.uob.com.sg>...
>We are using Oracle 8.
>
>Ours' is an object oriented system, and we are trying to load objects into
>the database. We have another utitlity which does the mapping for us, from
>objects to relational database(which means we do not have control over
which
>tables a single object maps to, or where the data is stored). This layer
uses
>SQL statements, and we have to go through this layer. And for the same
reason
>that we are loading objects, we cannot define a logical commit point, since
>we do not know at which point the object references are resolved
completely. Received on Thu Jul 08 1999 - 02:53:19 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US