Re: CHECKPOINTS

Hello Craig,

Your analysis: Checkpoint duration has nothing to do with the size or number of the log files, or the rate of redo generation. The amount of work to be done is a function of the number of dirty blocks in cache at the checkpoint SCN and virtually nothing else.

Your commercial: That paper has a number of serious errors. Perhaps the most significant is that you claim that the unit of time is milliseconds when in fact is the centiseconds.

Regards,
Steve Adams

http://www.ixora.com.au/
http://www.oreilly.com/catalog/orinternals/
http://www.christianity.net.au/

On Wed, 01 Mar 2000 15:56:11 -0800, Craig Shallahamer <craig_at_orapub.com> wrote:

>[snip]
>This "hanging" can be a performance killer, but there are a number of
>ways to attack this problem. You can tell if you are having this
>problem by looking at the "alert.log" file and looking for "cannot
>allocate log" or something like that. You can also check the session
>wait tables for log sync and related waits. Besides reducing the redo
>the application generates, you add additional log files and increase
>their size. Basically anything to "slow the clock down." The situation
>can get much more complicated than this, but this is a good start.
>
>The commercial: There are more details about the session wait stuff in a
>paper, Quick Contention Identification Using Oracle's Session Wait Views
>on my web site. I also have an Internet Video Seminar on this topic as
>well. My performance classes also cover this in detail. And, I have
>some tools, for free on my web-site, that collect and report on session
>wait details.
>
>Hope this helps,
>
>Craig.
>
>Craig A. Shallahamer
>President, OraPub, Inc.
>
>craig_at_orapub.com
>http://www.orapub.com
>+1.503.636.0228 (tel)
>+1.413.812.4406 (fax)
>
>[snip]
>
>Mario wrote:
>
>> 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