Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: RE: Not 100% clear on archive switching..

RE: RE: Not 100% clear on archive switching..

From: William Beilstein <>
Date: Wed, 27 Dec 2000 12:54:55 -0500
Message-Id: <>

If you have 5 redo logs, ARCH will have copied the 4 not in use. Meaning, = when redo #2 is full and LGWR switches to redo #3, ARCH will immediately = start writing redo #2 out. If you have multiple ARCH processes running, it = still has one redo log being written by one ARCH process. The multiple = ARCH processes just decreases the likelihood that there won't be an = available redo log when it comes time for LGWR to switch to the next log. = We have Oracle Financials running at our site with 3 redo logs of 10 meg = each and never run into any problems. Remember if you are running on non = raid/mirrored disks make sure to setup redo log groups,

>>> Shawn Ferris <> 12/27/00 10:11AM >>> Thanks Doug,

  Let me explain a little further. I have 5 online redo logs. (for now. I suspect I'll probably need more when the system goes live.) log_archive_max_processes is not defined. (default 0) Under high loads and given the right conditions, is it possible that archive log 3 completes before 2 completes? OR, will 1 always complete before 2 starts, and 2 = before
3, etc. Even under parallel ARCH processes. (BTW: I'd never think about killing any Oracle processes from the command line. Well, not on purpose anyway. ;)

  I am building an archived redo copy script. (To another host) It was always my (bad) assumption that (archived redo) 1 will finish before 2 = will
start. UNTIL I started to actually read the docs. ;) (when did log_archive_max_processes and the ability to parallel ARCH appear? I swear = I
didn't make that behavior up. However, I could've been under the influence.=

Too much Oracle has the affect of being a mind altering drug for me on occasion. ;) BTW: This runs constantly.. (~1min) =20
  Anyway, with the above assumption. My script was always: copy everything.= .
Delete all but the last file or any reported to be in use by fuser. In the case that the last archive was complete, it's still protected on another machine. If it wasn't, it'll be recopied later. (I also had a test to = match
sizes. If they were same, no additional copy occurred.) Now I have to re-think this strategy a bit. I want to avoid getting the info from Oracle on what has been archived but I don't really want to keep 10 logs for = every
instance on the same machine. (waste of space) In the light of things, I'd rather add disk than to be uncertain that oracle (ARCH) finished their writes. (Yes, production will likely have more than one instance running = on

  Some people are going to say, why not just leave a days worth on the machine. My answer to that is: I fortify the archive destination on the local oracle server. The repository host is a different story. I fortify this area as best as I can.. Then I fortify it again. Much cheaper to = spend
a lot on one machine than to do it on every oracle server we have. This scheme gives me the longest possible time before the archiver hangs in = case
of multiple failures. If the repository(s) goes down, I still have a = fairly
large buffer on the local machine. (That buffer wouldn't be nearly as = large
if I kept a days worth of archived redo on it. It's an OLTP system and may support on the upwards of a couple thousand users, 24x7)

Thanks for the help everyone.. I'm pretty sure I'm correct in my reasoning,=

but wanted to confirm.

SMF 8)
> -----Original Message-----
> From: []=20
> Sent: Wednesday, December 27, 2000 7:17 AM
> To: Shawn Ferris; Multiple recipients of list ORACLE-L
> Subject: Re:RE: Not 100% clear on archive switching..


> Shawn,

> Let me see if I can explain this in a clear way & the way=20
> I understand it.=20
> Now I work mainly with HP-UX, but I believe the process is=20
> the same on all
> platforms.

> LGWR writes to the online redo log files in a sequential=20
> manner, log #1
> followed by log #2 and so forth. (I always like at least 3=20
> online log files.)

> When LGWR has filled an online redo log it signals for a=20
> checkpoint, along
> with any other checkpoint settings in the init.ora file, and=20
> a "log switch". If
> the database is in "archivelog" mode this log switch causes=20
> ARCH to 'copy' the
> online redo log to the archive log destination. In the=20
> process it creates a file
> name in the archive destination that is whatever you put as=20
> the archive log
> format + a sequence number. When it finishes copying the=20
> online redo log it
> updates the files status in dba_log_files, or more likely the=20
> underlying V$
> table which is actually stored in the control file and it=20
> becomes available for
> LGWR to reuse which means that the data therein is=20
> overwritten, not that the
> file is erased & re-created or even resized, although I've=20
> got some questions on
> that score too. Most of my archive redo logs are 10M in=20
> size. But every so
> often I see one that is less than 10M.

> If the database has only the required 2 online redo logs=20
> and/or it's so busy
> that ARCH is getting close to 0 CPU time, or the archive log=20
> destination fills
> up, LGWR will continue filling online redo logs in sequence=20
> until there are no
> more available entries in dba_log_files. At this point in=20
> time the database
> ceases all activity (you end up with the ORA-00257 error=20
> message when logging on
> or trying any kind of statement) until al least one log file=20
> is released by
> ARCH. Thereafter things can get a little sporatic for a bit=20
> until ARCH catches
> up.

> Hope this helps. BTW: Do not, like an associate did, do=20
> a kill -9 on ARCH.=20
> It will die, the database will continue to run for a little=20
> bit, and you'll end
> up with one heck of a mess.

> Dick Goulet

> ____________________Reply Separator____________________
> Subject: RE: Not 100% clear on archive switching..
> Author: Shawn Ferris <>
> Date: 12/26/2000 3:40 PM

> > It seems to me that Oracle switches redo log from the full=20
> to the empty
> for=20
> > archiving purpose.=20
> =20
> Well, the log may or may not be empty but you get the idea.=20
> I'm pretty sure
> it doesn't actually clear the file, it just overwrites it=20
> when available.
> (archived in archivelog mode)
> =20
> > Now the background process "ARCH" is in charge with the archiving
> > process. Would you explain more?

> =20
> Yes.. I'm not asking about online redo, I want to clarify my=20
> understanding
> of the archiving process and the order in which redo is=20
> archived to disk
> depending on the value of log_archive_max_processes.
> =20
> > And again I might not be completely right, but=20
> > LOG_ARCHIVE_MAX_PROCESSES is targetting le number
> > of processes, not redo logs.

> Yes.. log_archive_max_processes determines how many ARCH=20
> processes can run
> in parallel. Each of which works on an single redo log to=20
> archive. (at least
> that is what I'm verifying.)

> Shawn M Ferris
> Oracle DBA - Time Warner Telecom=20

> =20
> --=20
> Please see the official ORACLE-L FAQ:
> --=20
> Author: Shawn Ferris

> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
Please see the official ORACLE-L FAQ: --=20
Author: Shawn Ferris
Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
To REMOVE yourself from this mailing list, send an E-Mail message to: (note EXACT spelling of 'ListGuru') and in Received on Wed Dec 27 2000 - 11:54:55 CST

Original text of this message