Re: Frequent Checkpointing ...

Oracle recognised the problem this could cause some time back, and changed the meaning of the log_checkpoint_timeout and log_checkpoint_interval accordingly.

There is a note on the FAQ (see URL below) about this, but in outline, you now specify how long a buffer can remain dirty before it is written to disc. This allows you to keep DBWR working steadily rather than switching from idle to flat-out at the end of each log file.

The mechanism also underpins the 'MTTR' strategy - you set the maximum number of seconds that a recovery should take, and Oracle adjusts these parameters dynamically to ensure that the buffer is kept sufficiently clean to make your target possible.

--
Regards

Jonathan Lewis
http://www.jlcomp.demon.co.uk

  The educated person is not the person
  who can answer the questions, but the
  person who can question the answers -- T. Schick Jr


One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html

____Finland__September 22nd - 24th
____Norway___September 25th - 26th
____UK_______December (UKOUG conference)

Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____USA__October
____UK___November


The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html


"Domenic G." <domenicg_at_hotmail.com> wrote in message
news:c7e08a19.0309180734.2e09803d_at_posting.google.com...


> I was just reading the INDEX/TABLE separation thread -- how about

the


> checkpoint myth?  From my experience, it is better to checkpoint

> frequently and keep those disks busy at an even rate vs. delaying

> checkpoints for 20 minutes and then all of a sudden you've got a

> workload surge to disk.  To me that never made sense.  Checkpoint

> frequently, every few minutes -- keep the checkpoint workload even

and


> steady.

>

> Domenic.