|
|
Posted by rcamarda on 08/20/06 12:04
Boa:
I cant speak of what happens when an index disaapears because of a
drive failure.
However, I steer away from raid-5 as the have overhead for writes.
Worse, when a drive fails, it has to do N reads in order to reconstruct
the missing data. The more drives you have, the more reads it has to
do. (I has to read the data strip from each drive and read the checksum
to reconstruct the data from the missing drive).
I said all that to say you should see better performance from you raid
10 or 1 drive arrays.
Also, if you have more than one controller in the system to put logs
vs. data on the different controlers.
I've had two logical drives on a single controller what was an array.
In that situation I cant see splitting logs and data to get better
performance; they are using the same physical drives.
HTH
boa wrote:
> I'm currently planning disk layouts and use for a new version of our
> database. The current version has all data and indexes in the default
> filegroup, placed on one big raid-5 array(6 drives) along with the
> transaction log. Performance is not the best, as you may imagine...
>
> Next week we will add another 14 drives and organize them in different
> combos of raid-10 and raid-1, and then create several filegroups and
> place tables and index data on separate physical drives.
>
> Most of the database will be placed on a raid-10 array, and some parts
> (tables/indexes/translog) will have their own raid-1 drives.
>
> I've been playing with the rather incorrect idea of using raid-0 instead
> of raid-1 on one or two of the new disk arrays we're adding and then
> place (some) indexes on those drives.
>
> The theory is that even if one drive fails, the db will stay up and it
> will be easy to recreate the indexes when the disk has been replaced.
> (We will have one hot spare available)
>
> Does anyone know how well sqlserver 2005 handles disk loss in such a
> configuration?
>
> Any other comments? ;-)
>
> boa
Navigation:
[Reply to this message]
|