That's good analysis for single block reads. Then we are left with the case of multiblock reads and there the issue will boil down to the =66ollowing factors neglecting cache: 1. Is the block size of the mb read sufficiently close to the stripe size so that the number of blocks being read crosses 2 or more stripe boundaries. In that case for that single mb read you could involve more than 2 physical disks in the read. 2. The read advantage then is concentrated in a hopefully small number of database motivated reads (if you are doing tons of mb reads, maybe dw environment you could "maximize" the raid 5 adevantage) and file systems ops on unix where you want to copy or move multi GB's of data. Overall, it might be possible, after extensively analysing your system to gain some read speed advantages using raid 5. You just have to make sure you don't get the write penalty in production. This also assumes you find some spiritual benefit to obsessing on your disk configuration. On the whole I find confining raid 5 to application servers and other boxes that don't do many writes to be about the only place raid 5 really makes sense. Allan -----Original Message----- =46rom: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Cary Millsap Sent: Wednesday, August 25, 2004 4:20 PM To: oracle-l@xxxxxxxxxxxxx Subject: RE: Raid5 Vs Raid0+1 -- Raw Vs Solaris 9 Concurrent Direct IO UFS =3F A single-block read from a RAID level 5 array will visit only one block =3D on the array (unless something weird's going on like a block split across devices, or there's a partial outage going on). A single-block read from a RAID level 1 array will also visit only one =3D block (unless there's a block split issue), but the advantage of RAID level 1 =3D is that a good controller can fetch the block from the less busy of two =3D disks storing equally valid copies of the block. There is no "read advantage" of level 5 over level 1. In fact, it's =3D quite the contrary. First, because of what I said above. Second, because a =3D RAID level 5 array has inherently greater load to manage than a RAID level 1 array. If an application generates R 1-block reads/sec, and W 1-block writes/sec, then the two architectures would compare this way: - Level 1: would have to process (R + W) I/O requests per second - Level 5: would have to process (R + 4W) I/O requests per second So, for example, if write calls comprise 50% of your I/O call workload =3D (that is, W=3D3DR), then this is your situation: - Level 1: load is 2R I/O requests per second - Level 5: load is 5R I/O requests per second That is, the RAID level 5 system will have to process 2.5x more I/Os per second than the RAID level 1 system. How could the RAID-5 system keep =3D up=3F Either with a /lot/ of cache ($$$, and Tim's right; any amount of cache =3D can be overwhelmed by a high enough sustained I/O rate), or by buying a =3D /lot/ more disks. ...By the time you buy all that stuff, your whole economic motivation =3D =66or buying RAID level 5 ("it's cheaper, because you don't have to buy as =3D many disks...") is out the window. RAID level 5 is /not/ cheaper, because you /do/ have to buy as many =3D disks. And cache. And controller software. ...BAARF. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com * Nullius in verba * Upcoming events: - Performance Diagnosis 101: 9/14 San Francisco, 10/5 Charlotte, 10/26 Toronto - SQL Optimization 101: 8/16 Minneapolis, 9/20 Hartford, 10/18 New =3D Orleans - Hotsos Symposium 2005: March 6-10 Dallas - Visit www.hotsos.com for schedule details... -----Original Message----- =46rom: oracle-l-bounce@xxxxxxxxxxxxx =3D [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Nelson, Allan Sent: Wednesday, August 25, 2004 3:14 PM To: oracle-l@xxxxxxxxxxxxx Subject: RE: Raid5 Vs Raid0+1 -- Raw Vs Solaris 9 Concurrent Direct IO =3D UFS Raid 5 does get good read performance because for reads more disks get in on the action. 3 in his example vs essentially 2 for the raid 0+1 stuff. Allan ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ =46AQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ___________________________________________________________________________= ___ This email is intended solely for the person or entity to which it is = addressed and may contain confidential and/or privileged information. = Copying, forwarding or distributing this message by persons or entities = other than the addressee is prohibited. If you have received this email in = error, please contact the sender immediately and delete the material from = any computer. This email may have been monitored for policy compliance. = [021216] ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------