Re: Thread 1 cannot allocate new log

Size will not cure this problem.

You are cycling around your groups too quickly. If you increase the size of the logs, then yes, you will slow down the rate at which you checkpoint. But each checkpoint will (other things being equal) also have more work to do. Expect the two effects to cancel out to a small or negligible overall benefit.

The cure is more redo log groups. That way, you can be switching onto logs 4, 5, 6, 7 and so on, whilst the checkpoint completes on Log 1. Hopefully, by the time you get up to log 8 or 9, Log 1 will have been dealt with, and you'll be able to switch back into it without a problem.

HJR

--
=============================!!=============================
The views expressed are my own only, and definitely NOT those of Oracle
Corporation
=============================!!=============================


"Anne Williamson" <annew_at_mac.com> wrote in message
news:3B1D6833.FF203B8A_at_mac.com...


> Thanks Murali and Vinayak. I'll increase the size of the redo logs and

> try again. This is why I have a test database!

>

> Cheers

> Anne

>

> OracleMS wrote:

> >

> > Hi Anne,

> >

> > This means that checkpoints are occuring too often. During

> > checkpoints, all data in the buffer cache is flushed to disk, and the

> > headers of the datafiles and controlfiles are updated. This aids us

> > during recovery. Checkpoints also cause a substantial overhead if you

> > have a lot of datafiles. Checkpoints are controlled by the init.ora

> > parameters LOG_CHECKPOINT_INTERVAL (will cause checkpoint after this

> > many OS blocks are written) and LOG_CHECKPOINT_TIMEOUT (will cause

> > checkpoint after this many seconds). They also HAVE to occur at every

> > redo log switch. In your case, if your redo logs are too small and

> > there is a lot of activity in the database, the logs switch very fast

> > and consequently cause checkpoints to occur. Before one checkpoint can

> > complete, another log switch occurs, triggering another checkpoint,

> > and so on. With this message, Oracle is telling you that since the

> > logs are switching so fast, it could not complete the checkpoint that

> > had started at the previous log switch. So the solution to this is to

> > increase the size of your redo logs and have a minimum of three groups

> > so that redo logs will not switch so fast.

> >

> > Hope that helps.

> >

> > Murali

> >

> > Anne Williamson <annew_at_mac.com> wrote in message

 news:<3B1C4BC6.A8B58763_at_mac.com>...


> > > Yesterday I was doing a schema update on my test database, using

 scripts


> > > supplied by the third party who supplies the end-user application.

> > > Looking at the alert log I noticed a number of messages like this:

> > >

> > > Thread 1 cannot allocate new log, sequence 1609

> > > Checkpoint not complete

> > >

> > > There is no Oracle error message reported. I couldn't find anything

> > > about it in the Oracle error messages manual. The scripts all seemed

 to


> > > complete happily.

> > >

> > > Does anyone know what is causing these messages? How do I stop them?

> > > What is the result of these incomplete checkpoints?

> > >

> > > Digital Unix 4.0F, Oracle 8.0.5.1.1

> > >

> > > Many thanks in advance

>

>

> --

> Anne Williamson

> Melbourne, Australia