This is in addition to Mark's advice, which is correct, but if you are just
running a "query" as your question states you don't have to worry about
commits as you are not altering/updating data, basically you are only
reading the data.
<markp7832_at_my-deja.com> wrote in message news:89midm$32r$1_at_nnrp1.deja.com...
> In article <89mf2v$53$1_at_nnrp1.deja.com>,
> victre_at_my-deja.com wrote:
> > How long does it take Oracle 8.0.5 to execute a commit? I want to
> > avoid running out of resources required to run a large query by using
> > commits every n records but also want to minimizing the execution time
> > of the query by not doing more commits than necessary.
> >
> Oracle 8 uses the same fast commit logic it used with ver 7, namely, on
> a commit Oracle flushes the redo log buffer to disk, but allows the
> database writer to get around to writing the changed data whenever it
> gets around to it (lazy writes). Because a commit requires writing to
> the redo log it is relatively expensive so you are correct in that you
> do not want to over commit, but I think you want to base your commit
> frequency based on the likelihood that another session will want to
> update one of the rows your process updated and how long it is
> acceptable for them to wait. That and the total number of bytes worth
> of rollback you want to limit a transaction to using.
>
> --
> Mark D. Powell -- The only advice that counts is the advice that
> you follow so follow your own advice --
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Received on Thu Mar 02 2000 - 00:00:00 CST
