Re: Checkpoint not complete

From: Mark D Powell <Mark.Powell_at_eds.com>
Date: Tue, 15 Sep 2009 06:55:12 -0700 (PDT)
Message-ID: <f7deff8f-d65b-43f9-8ee3-3ce0a2970197_at_v2g2000vbb.googlegroups.com>



On Sep 14, 12:26 pm, joel garry <joel-ga..._at_home.com> wrote:
> On Sep 14, 6:30 am, Michael <mbulch..._at_gmail.com> wrote:
>
> > I am receiving the following message in my alert log and can find no
> > documentation explaining what this error means or how to correct it.
>
> > Thanks,
> > Michael
>
> The answers vary somewhat by version.  In general it is not a fatal
> error as long as it isn't compounding until things die, but it
> indicates a misconfiguration of some sort, and likely a performance
> problem.  In older versions, you might need to configure a checkpoint
> process.
>
> So, what version/OS version are you on, and how often are you getting
> the error?  Are users complaining?  How have you configured your log
> buffer size?  How big are your redo logs and how often are they
> switching?
>
> jg
> --
> _at_home.com is bogus.
> Marketing, feh.http://www3.signonsandiego.com/stories/2009/sep/14/pc-makers-turn-sim...

A "checkpoint not complete" message in the alert log pretty much has always been an indication that the online redo logs are sized too small for the amount of redo being generated so that another log switch takes place before the checkpoint of the previous switch could be completed.

Take a look at the alert log or use v$log_history to determine the time between switches. In the absence of Data Guard I aim for 24 - 48 switches per 24 hours. That is one switch every 30 - 60 minutes on average. If you use Data Guard and you log ship then you generally want smaller redo logs and will aim for a higher switch total but even so you need to make sure the online redo logs are not badly undersized.

Too many log switches too close together so that multiple checkpoint not complete messages occur can result in Oracle stopping current activity so that it completes a check point.

HTH -- Mark D Powell -- Received on Tue Sep 15 2009 - 08:55:12 CDT

Original text of this message