Re: ARCn
Date: Thu, 1 Aug 2013 20:23:37 +0100
Message-ID: <CAFGV9u=AUr3GUibA84Xh-XemCAZUQfidMDtWrvmvE8T8KdxNFQ_at_mail.gmail.com>
Hi
We have 2 members in 2 different disk, and one is faster than the other, so im wondering, if it follows a rule (e.g: always one), i can use fast disk for member 1. The other reason is curiosity :) I know it wont be a big difference really, but i just start thinking/reading about it and i realise i didnt know the answer for sure.
You are completely right about the *one* now that im reading it again, and im agree that the logical way of programing is starting with group1 member 1 and go on, but maybe there is more info/docs about it that i didnt know, and that can confirm the way it does it.
Thanks
On Thu, Aug 1, 2013 at 7:49 PM, Hans Forbrich <fuzzy.graybeard_at_gmail.com>wrote:
> On 01/08/2013 12:12 PM, Ricard Martínez wrote:
> > Hi
> > I have a doubt about the archive process. One redo log group have at
> least
> > 2 members. When the ARCn process reads it to create the archive log, did
> it
> > always reads member 1? or its random?
> Curious why this is important to you. (There are legit reasons, just
> wondering.)
> > Cause here seems that is always member 1:
> >
> http://docs.oracle.com/cd/E11882_01/server.112/e25789/physical.htm#i1006259
> That doc says " the database is in ARCHIVELOG mode, and if automatic
> archiving is enabled, then the archiver process (ARCn) will archive
> *one* of these files. If A_LOG1 is corrupted, then the process can
> archive B_LOG1."
>
> The way I read that comment, "One of these files" does not imply "File 1"
>
> Then again, unless there is an I/O issue, why would it matter which one
> it reads? I personally would program this to say "start by reading
> member one, continue with member one of the next group unless we end up
> switching due to corruption, at which time we switch to member 2 and
> stick with that series unless we are forced to switch again."
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Aug 01 2013 - 21:23:37 CEST