Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: different ways of archiving current redo log

Re: different ways of archiving current redo log

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Wed, 24 Mar 2004 16:04:36 +1100
Message-ID: <406116e5$0$3956$afc38c87@news.optusnet.com.au>

"Prem K Mehrotra" <premmehrotra_at_hotmail.com> wrote in message > HJR:
> Thanks, Regrading question 2, even though your automatic archiving is
disabled,
> manual archiving can still be done. When you say precious liitle
difference,
> do you mean there is no difference between 2 and 1. You response on 1 is
> similar to my thinking but Syad's response seems to say that
> alter system switch logfile
> may archive the log as well as switch. This where I get confused, there is
> no gurantee that archiving has been completed with
> alter system switch log file.

OK, I see where you're coming from now.

When I said there was precious little difference between 'alter system switch logfile' and 'alter system archive log current', what I meant was that there is NO difference in the behaviour regarding what gets archived, and whether there is a log switch. There is a difference, of course, which is that in the switch logfile case it is ARCn doing the archiving, and in the 'archive log current' case it is your server process doing the deed.

Given that 'archive log current' ties up your server process until such time as the archive has been produced, then it is a fair bet that the archive has actually been produced by the time that your SQL> prompt returns. It is also fair to say that 'switch logfile' only has to make one small change to the controlfile, and the SQL> prompt will therefore return far quicker than ARCn could have archived the log.

So yes, 'archive log current' is rather more reliable than 'switch logfile' in that regard.

However, it's not *that* reliable. The "guarantee" you seek only arises because you don't get your prompt back until the archive of the current log has taken place. There's nothing to stop another session firing up, however, and starting to issue SQL commands... and there's no guarantees for that session at all as to what the state of play is regarding the successful completion of the archive, except for querying from v$archived_log.

Does that make it any clearer now?

Regards
HJR Received on Tue Mar 23 2004 - 23:04:36 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US