| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: RE: Not 100% clear on archive switching..
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 <Shawn.Ferris_at_twtelecom.com> 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
it.)
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: dgoulet_at_vicr.com [mailto:dgoulet_at_vicr.com]=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..
>=20 >=20
>=20> I understand it.=20
> Let me see if I can explain this in a clear way & the way=20
>=20> manner, log #1
> LGWR writes to the online redo log files in a sequential=20
>=20> checkpoint, along
> When LGWR has filled an online redo log it signals for a=20
>=20> and/or it's so busy
> If the database has only the required 2 online redo logs=20
>=20> a kill -9 on ARCH.=20
> Hope this helps. BTW: Do not, like an associate did, do=20
>=20 >=20
>=20> Subject: RE: Not 100% clear on archive switching..
> ____________________Reply Separator____________________
>=20
>=20
>=20
>=20
>=20
>=20> To REMOVE yourself from this mailing list, send an E-Mail message
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
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: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in Received on Wed Dec 27 2000 - 11:54:55 CST
 |
 |