Re: Oracle Err: Can not allocate log, archive required

I'm almost certain that it's perfectly OK to any of this from the MOUNT stage -the problem you had was that you started only with two groups, and if there's one cast-iron rule that Oracle has, it's that you can't ever have LESS than 2 redo log groups.

Hence, any drop commands upfront would have been trying to take you below two groups, and that wouldn't be allowed. Add in the new groups, then the old ones become superfluous to requirements, and can be dropped any time you fancy!

The other problem you encountered (and dealt with beautifully, if I read your script correctly) is that you can never drop the current group (hence your forced log switches, making the next group 'current'; and you can't drop an 'active' group (ie, one that is being checkpointed and/or archived) -if, in your script, you'd typed the 'drop logfile group 1' command just a fraction of a second after doing the 'switch logfile' command, it would probably have failed, because the status would still have been 'ACTIVE' (probably -but you'd have to type faster than I can manage!!).

Regards
HJR <alexberi_at_my-deja.com> wrote in message news:959g4k$juh$1_at_nnrp1.deja.com...
>
>
> Thanks Sybrand, David and others,
> I had only two redo log files with size 1M.
> Now I created 2 groups of two, size 5M and is okay.
>
> But I couldn't first delete the old two groups of one
> redo log file each. First I created the new groups
> with and after that deleted the old groups.
>
> This was what I needed to do:
>
> alter database add logfile group 3 (<filename spec>,....) size 5M;
> alter database add logfile group 4 (<filename spec>,....) size 5M;
>
> alter system switch logfile;
> alter database drop logfile group 1;
> alter system switch logfile;
> alter system checkpoint;
> alter database drop logfile group 2;
>
> I suppose is not possible to do this with database not open (just
> mounted, for example).
>
> Thanks all.
>
> In article <957qem$806$1_at_nnrp1.deja.com>,
> hailey_kyle_at_my-deja.com wrote:
> >
> >
> > There is a case I ran into recently where the archiver would stop,
> > but its when you have a standby database. It doesn't sound like you'd
> > be using a standby database, but its an interesting case and I've
 meant
> > to post it as a warning to other. There is a bug, 1355687, where if
 the
> > standby db dies in the middle of an archive, even though it is
> > optional, the main db archiver will hang.
> > Interesting stuff to check is to see what the archiver is waiting
> > for in v$session_wait. In our case it was waiting for 'file identify'.
> > I wasn't here when it happened but captured it in monitoring scripts.
> > The file identify wait's P2 field is called "file name". It is
 actually
> > a pointer to the memory address in the archiver process where the name
> > of the file it is trying to identify. On NT I'm not sure what you'd
 do,
> > but on LINUX its easy to attach a debugger like gdb to the arc process
> > and print that memory location and see what file it is waiting on.
> >
> > In your case, during the hang, I'd look at CPU and disk io. Is
> > anything running, is there disk IO, is the archiver process active or
> > idle? In the case of an idle archiver during a hang, try checking out
> > what the archive process is waiting for. Look at v$session_wait for
 SID
> > = arc's SID.
> > In the case of blasting through the redo logs faster than the
> > archiver, I wouldn't expect the archive wait to be very long. The
> > archivers work is easier than the log writers.
> >
> > Things you can do. Try
> > SQL> archive log all
> > what happens?
> >
> > For more info and tracing you can try:
> > SQL> alter system set LOG_ARCHIVE_TRACE=127;
> > SQL> alter session set events 'immediate trace name systemstate
> > level 10'
> > SQL> oradebug setorapid <pid of archiver>
> > SQL> oradebug unlimit
> > SQL> oradebug dump errorstack 3
> > to trace the database and archiver.
> >
> > Best
> > Kyle
> >
> > PS On the managed standby, more dangers, if the standby database has
 an
> > Oracle 600 it will bring the primary database down ! (fixed in 8.1.7
> > bug 956434)
> >
> > In article <9574g3$jfl$1_at_nnrp1.deja.com>,
> > alexberi_at_my-deja.com wrote:
> > >
> > >
> > > I have configured an Oracle NT database 8.0.5 to work in archieve
 mode
> > > and set automatic archieving of logs, but I receive the message:
> > >
> > > "Can not allocate log, archive required"
> > >
> > > There is plenty of room on the drive where the archive files are
> > > created, and I have about 100 archieved logs there.
> > >
> > > Can anyone tell me where is the problem?
> > >
> > > Thanks, Alex.
> > >
> > > Sent via Deja.com
> > > http://www.deja.com/
> > >
> >
> > Sent via Deja.com
> > http://www.deja.com/
> >
>
>
> Sent via Deja.com
> http://www.deja.com/
Received on Thu Feb 01 2001 - 02:35:33 CST