Re: intermittent commit on insert ?

"Niall Litchfield" <niall.litchfield_at_dial.pipex.com> wrote in message news:3cfd30be$0$8506$cc9e4d1f_at_news.dial.pipex.com...
> "Chuck" <chuckhNOSPAM_at_softhome.net> wrote in message
> news:adj4tq$116qbh$1_at_ID-85580.news.dfncis.de...
> > Why would smaller commits increase the log volume? You're still
inserting
> > the same amount of data into the table. The miniscule amount of log
space
> to
> > hold the commit records isn't even worth mentioning.
>
> No-one said it would change the log volume. Redo isn't the issue here.
Undo
> is.
>

Actually Sy did.

"Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in message news:7utpfuooqromk8krj1dd3nj0b73a8go8ga_at_4ax.com...
> And, oh yes, just to inform you : every transaction has overhead.
> Limiting the number of rows committed, will increase the overhead,
> will increase the redolog volume etc.

Switching back to current article...

"Niall Litchfield" <niall.litchfield_at_dial.pipex.com> wrote in message news:3cfd30be$0$8506$cc9e4d1f_at_news.dial.pipex.com...
>The point is that the rollback system will suffer under artificially high
>numbers of transactions. You commit at the end of a transaction and the
>DBA's job (pain that it is) is to size rollback segments appropriately.

In an ideal world and in text books that would be possible - but so would having one CPU for each process, and terabytes of real memory so no tasks ever swap out. In the real world rollback segments fill up, disk size is limited, and sometimes you have to commit more frequently than you want to. I would not want to be in the position of having to explain to my boss why I'm tying up gigabytes of space for a rollback segment that gets used once in a blue moon. Received on Wed Jun 05 2002 - 09:53:42 CDT