Re: what is the different?

When using multiple threads of redo, you'll find another subtle difference:

ARCHIVE LOG CURRENT will cause each thread's current log to be archived where SWITCH LOGFILE will only affect the current thread ( the instance from which it is called ).

I've found that when doing an ARCHIVE LOG CURRENT, I do not regain control until the operation is complete. This is probably due to the fact that it's my *server process* doing the work, rather than ARCH.

So... In that case, I wouldn't think a script would need to wait a few minutes, as the wait would have already occurred.

-Kevin

"Howard J. Rogers" <howardjr_at_www.com> wrote in message news:3b14ec1d_at_news.iprimus.com.au...
> Not entirely certain what benefits you get using the one approach over the
> other, given that even the "new" syntax won't produce an instantaneous
> archive file, so you'd still have to wait for a bit before it being safe
 to
> copy the archives.
>
> Anyway: as far as I see it, Niall's right. Switch logfile can be done to
> any database (and will trigger a checkpoint); archive log current will
 only
> work on databases in archivelog mode. The subtler difference is that on a
> database in archivelog mode, with the Archiver proces enabled, 'switch
> logfile' will cause ARCH to do the archiving, but 'archive log current'
 will
> cause your *server process* to do the archiving.
>
> So if the latter always produces an error, but the former does not, I'd
> suspect that ARCH had hung, or hadn't been enabled in the first place (ie,
> LOG_ARCHIVE_START or its 8i variants hasn't been set in the init.ora).
>
> I usually get an error message when it's the other way round when the
> archive destination that ARCH is about to use (the default, or
> LOG_ARCHIVE_DEST is specified incorrectly) is one to which I don't have
> permissions (or which doesn't exist). 'Archive log current to <other
> destination>' will then correctly work, since I get to pick a directory to
> which I *do* have permissions.
>
> Regards
> HJR
> --
> =============================!!=============================
> The views expressed are my own only, and definitely NOT those of Oracle
> Corporation
> =============================!!=============================
>
>
> "Spencer" <spencerp_at_swbell.net> wrote in message
> news:P0eQ6.438$My3.106492_at_nnrp3.sbc.net...
> > in our hot backup scripts, we use the "archive log current" syntax to
> > ensure that the current log file is archived. prior to the introduction
> > of this syntax, the script used the "switch logfile", and then waited
 for
> > several minutes to give ARCH enough time to archive the log file,
> > before continuing.
> >
> > one place we use the the
> > "Niall Litchfield" <niall.litchfield_at_dial.pipex.com> wrote in message
> > news:3b114c75$0$15030$cc9e4d1f_at_news.dial.pipex.com...
> > > alter system switch logfile switches between current online redo logs.
 It
> > > (should) always work.
> > >
> > > alter system archive log current will archive the (current) redo log.
 It
> > > thus requires all of the prerequisites for archiving redo logs.
> > >
> > > Most likely causes for the second command to fail
> > >
> > > 1. you are not in archivelog mode
> > > 2. you have run out of space in your archive log destination.
> > >
> > > The error message in the alert log will tell you what the problem is.
> > >
> > > IMO you should also not usually need to issue the second command since
> > > oracle will quite happily archive redo logs for you automatically.
> > >
> > >
> > > --
> > >
> > > Niall Litchfield
> > > Oracle DBA
> > > Audit Commission UK
> > > "Cheong" <leslie_hk_at_hotmail.com> wrote in message
> > > news:3b113326_at_newsgate.imsbiz.com...
> > > > Can anyone tell me what is the different of the following two
 commands
> > > >
> > > > alter system archive log current
> > > > alter system switch logfile
> > > >
> > > > and why the first command always produce and error a message fail to
 arhive
> > > > log ... in alert log file.
> > > >
> > > > Thanks in advance
> > > >
> > > > Antony
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>
Received on Wed May 30 2001 - 11:30:42 CDT