Re: Redo and Archive Log Question

Hi Chuck

Comments embedded.

"Chuck" <ccarson_at_echeeba.com> wrote in message news:3E6846E0.7040708_at_echeeba.com...
>
> We are trying to add some more redundancy to a very busy OLTP database
> and I have this question.
>
> I currently have 4 dedicated logging disks as follows:
>
> disk 1 = control01.ctl, redo1a.log
> disk 2 = control02.ctl, redo2a.log
> disk 3 = control03.ctl, redo1b.log
> disk 4 = redo2b.log
> disk 5 = archive_dest_1
>
> These 5 'disks' are all RAID 0+1 volume groups on an IBM SAN. (18Gb 10k
> rpm) I want to add another logging disk which will be on another SAN
> Switch/RAID Controller, in order to protect against failures in our
> Brocade Switch or IBM FastT controller. (We have two independent SAN's)
>
> disk 6 = redo3.log, archive_dest_2
>
> Disk 6 is a larger, slower disk (70 Gb 10k rpm) that will also have more
> I/O contention than disks 1 - 5. (due to redo and archive on the same
disk)
>
>
> My questions are:
>
> 1) If I have 3 copies of each online log file (as configured above) but
> one of the copies is on a slower disk (disk 6), will the slower disk be
> the 'weakest link' so to speak. OR, can the ARCH process start archiving
> the first full online log written within the group even though the
> third member may be lagging behind due to poor I/O?

Yes, you will have a "weak link" requiring the ARCH process to wait.

>
> 2) Same thing as question 1, but applied to the archive process.

If I understand your question, it will depend on whether you're destinations are mandatory or optional.

>
> 3) Can I have a third group with only one member even though the first
> two log groups have two each?

Yes you can, but I would question the logic in doing so. Don't forget Murphy's Law. The group with just the one member will be the one that will cause you grief.

>
> I hope this makes sense, it has been a long day.
>

Has it ever.

I would recommend using the new disk 6 as *just* the second archive dest and use your disks 1-4 as the disks for your new redo log members, keeping the online log members as you currently have such that no two members are on the same disk and such that the lgwr and arch processes do not contend at the same time (eg. group 3 on disk 1 and 3, group 4 on disk 2 and 4 and so on). Just keep to the same pattern and add as many new groups as you require to avoid archive/checkpoint delay issues.

This way, all groups have 2 members on separate disks, there is no contention by lgwr/arch trying to write to the same disk and no contention between lgwr writing and arch reading from the same disk (providing the archiving is completed in sufficient time).

Make sense ?

Good luck (and good night :)

Richard Received on Fri Mar 07 2003 - 07:53:00 CST