Re: CHECKPOINTS

Argh...

Sometimes it pays to keep one's fingers away from the keyboard when one is tired.

No, I don't have any idea where ENABLE_CHECKPOINT_PROCESS came from.

Sigh...

    / Bob

"Bob Beilstein" <rjbeilstein_at_earthlink.net> wrote in message news:FWFv4.37$M83.2733_at_newsread2.prod.itd.earthlink.net...
> Hi, Steve
>
> Thank you for pointing out the fact that ENABLE_CHECKPOINT_PROCESS will
 not
> "fix" Mario's problem. I agree. I should have made it more clear that
 this
> suggestion was just something in addition to more substantive action to
> improve I/O performance.
>
> I was well aware that the CKPT process only frees up the LGWR somewhat,
 and
> that Mario's problem probably lies in the DBWR I/O realm.
>
> On the other hand, enabling the CKPT process does, in my experience, help
> some (which is, I assume, why Oracle 8 made it a standard feature rather
> than an option). On occasion, "some" is enough to push the problem off
 (on
> rare occasion, enough to actually "cure" it).
>
> Craig's paper includes information about I/O and so forth -- so I was just
> adding a couple of cents worth about something in the "can't hurt, might
> help" category.
>
> I certainly would not expect turning on ENABLE_CHECKPOINT_PROCESS to have
> any dramatic effect on its own.
>
> Thanks again.
>
> / Bob
>
> "Steve Adams" <steve.adams_at_ixora.com.au> wrote in message
> news:38bdee81.39787591_at_news.eagles.bbs.net.au...
> > Hi Bob,
> >
> > The checkpoint process is only responsible for the writes to the
> > datafile headers, not the data block writes.
> > Enabling it would not help Mario at all.
> >
> > Regards,
> > Steve Adams
> > http://www.ixora.com.au/
> > http://www.oreilly.com/catalog/orinternals/
> > http://www.christianity.net.au/
> >
> >
> > On Thu, 02 Mar 2000 03:57:10 GMT, "Bob Beilstein"
> > <rjbeilstein_at_earthlink.net> wrote:
> >
> > >In addition to Craig Shallhamer's excellent suggestions, you want to
 make
> > >sure that you have:
> > >
> > >CHECKPOINT_PROCESS=TRUE
> > >
> > >set in your init.ora. This will start a separate process devoted to
 doing
> > >checkpoint I/O.
> > >
> > >In my experience, it can make the difference between getting the log
 files
> > >emptied before you roll back to them, and not.
> > >
> > >You also didn't mention how big your logfiles are. We've found that
 for
 a
> > >lot of databases, increasing the size of the logfiles (we often use
 64MB
 or
> > >larger for big databases) can also help. Your mileage may vary.
> > >
> > >
> > >
> > >"Mario" <mtechera_at_yahoo.com> wrote in message
> > >news:89k4d5$di0$1_at_news.online.de...
> > >>
> > >> We have a problem with redo log switching
> > >> when running large jobs. All groups fill up
> > >> and remain active even though they
> > >> are archived - presumably this is because
> > >> checkpointing is going on.
> > >>
> > >> Finally when the
> > >> last log group fills and wants to switch back to
> > >> the first group it cannot do so, because
> > >> the first group is still active. At this point the system
> > >> slows to a crawl and even trivial queries require minutes
> > >> for a response.
> > >>
> > >> We have
> > >> increased the number of redo log groups
> > >> (almost doubling the space available),
> > >> and have also increased the initialization
> > >> parameter db_block_checkpoint_batch
> > >> so as to allow for faster checkpointing.
> > >> Yet the problem persists.
> > >>
> > >> Does anyone have any pointers for us?
> > >>
> > >> Is there any good documentation on how the checkpoint
> > >> process works and why it takes so long?
> > >>
> > >> Our System
> > >> Oracle V7.3.4, RS/6000, 2CPUs, 1.3 GB Memory, AIX
> > >>
> > >> Thanks in advance,
> > >> Mario
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> >
>
>
Received on Fri Mar 03 2000 - 00:00:00 CST