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

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 Wed Jan 31 2001 - 10:56:58 CST