Re: CHECKPOINTS

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 Thu Mar 02 2000 - 00:00:00 CST