It's good you are asking questions and wanting to learn about this.
It's a bit of a pet topic for me and as a result my DASD guy has a hit
out on me :-). My comments would be:
- Don't use raid-5 anywhere for any reason. DASD is so darn cheap and
time is so so expensive. Go RAID 0+1 all the way and your life will be
the better for it. I have been talked in (read, forced) to using
different raid levels and I and the clients have always regretted it.
- Archive log writes are large sequential writes. I have seen where this
was so slow all the online logs backed up waiting for a log to be
archived. Of course, this would point out that log switches are occuring
too frequently and you need take some steps here but now I'm forced to
add online redo log because my archive disk is so slow.
- Think about how your physical disk is laid out. I have seen people
say well my onlines are raid 0+1 and my archives logs are RAID 5 and
guess what... They end up both being stripped across the same underlying
physical drives. bad bad bad plan
- All of this becomes less and less an issue depending on the size of
your DB. I have many DBs where everything (online, archive log,
exports, source, etc...) is on one RAID 0+1 array and responce time off
the disks is great. Also I don't need to worry about placing thing on
seperate volumes and drives. Of course these are smallish dbs. Less than
100 GB onlines and only about 5-10 GB of redo per day.
- As you get into larger DBs or move transaction activity... now you
need to think about multiple volumes, but still, 2-3 RAID 0+1 arrays
will rock. At 2:00 in the morning when you are doing a recovery or
import/export you'll think back and realize what a good idea this was.
- Lastly - About redo. Think about not using multiple redo log members
in your redo groups. It is my opinion that this was done before raid was
available and with mirroring, this is not only not necessary, but a
waste since now 2x the amount of redo is written. However, another
school of thought is that with 2 log writes there is less a chnage of
corruption and perhaps transaction activity can be split across the
members. I'm not buying this right now, but if my db was a credit card
processing or ATM back end, I could be talked in to going with multiple
members.
Good luck and I hope this helped.....
--
Doug Coan
Oracle Certified Professional DBA
Sent via Deja.com
http://www.deja.com/
Received on Fri Jan 05 2001 - 11:57:14 CST
