Disk performance issues - Best candidates for a move?

  • On the top of my head I can only come up with one op that is 100% write (or almost anyways), and that's an INSERT statement. (in the database data file that is, not the log) Come to think of if, if there indexes present, then there might be some reads involded in the maintenance of those.

    Updates and Deletes for example, or a clustered index rebuild, and even more stuff isn't just writes, they need to do a lot of reads as well as part of their operations. And here's where 'the big picture' comes into play.

    So at the end of the day, many times a raid5 performs 'overall' just as well, or even better than a raid10 when it comes to those things that we percieve as 'just writes', simply because under the hood, it's not 'just writes', there's a lot of reads involved as well.

    Naturally, everyone's mileage will vary, and for sure, raid5 *is* twice as slow as for example raid10 to commit one i/o to disk.

    But that's not the entire truth. If the 'read-part' of something (update or delete for example) outhweighs the write-penatly, then a raid5 array will be more performant than a raid10 for that op.

    Though it's to be noted that the number of spindles in each array does play a big part in this. It's more a question of how many spindles than which raidlevel 'in general'.

    If we move to SANs, then all bets are off. In that world there's a whole new ballgame going on.

    (as noted earlier)

    Anyways, my point is just to point out that raid5 may have more virtues than we ususally think. 😉

    -- edit --

    Oh , saw the 'report/tempdb' reference...

    For the sake of argument, I'm referring to R5 for the data array.. not tempdb, which should in such a case be placed on a RAID1 or RAID10 array if needed.

    /Kenneth

Viewing post 16 (of 15 total)

You must be logged in to reply to this topic. Login to reply