Harddisc perfomance tipps

  • Hey there,

    i am planing a new database server for our company...but i am not sure how i should split my 11 discs on this server...i thought about this

    2 discs in raid 1 for system + programfiles

    3 discs in raid 5 for database files (mdf)

    3 discs in raid 5 for log files (ldf)

    3 discs in raid 5 for temp db

    So ok, the perfomance is even on all discs, the databases are most time in read access and there is not so hard write stuff on most of the databases which will run on this db server, this is why raid 5 instead of 10 (cost/advantage 😉 ). I dont think there will be more than ~15 Databases. Databases will be mirrored to a second system, too.

    or should i go like this

    2 discs in raid 1 for system + programfiles

    3 discs in raid 5 for database files (mdf)

    2 discs in raid 1 for log files (ldf)

    4 discs in raid 10 for tempdb or 2 raid 1

    or

    2 discs in raid 1 for system + programfiles

    4 discs in raid 10 for database files (mdf+temp)

    4 discs in raid 10 for log files (ldf)

    Planned discs are ssd harddisks if this change something...

    What do you think is the optimal configuration for a system like this?

  • How many IO channels do you have?

    What kind of database are you expecting to run (OLTP/OLAP/hybrid)?

    How many transactions per second?

    How critical is your data ... how many seconds/minutes/hours can you afford to lose if you need to go to backups?

    How critical is your uptime?

    └> bt



    Forum Etiquette: How to post data/code on a forum to get the best help[/url]

  • bteraberry (4/22/2010)


    How many IO channels do you have?

    What kind of database are you expecting to run (OLTP/OLAP/hybrid)?

    How many transactions per second?

    How critical is your data ... how many seconds/minutes/hours can you afford to lose if you need to go to backups?

    How critical is your uptime?

    Do you mean the raid controller? 4 or 8

    OLTP, later maybe hybrid

    trans/sec:

    Max ~1200 (absolute)

    Average ~200 (workours)

    Data: The less we loose, the better it is 😉

    Disaster recovery -> back to last night

    Uptime: Very Critical

  • or should i run all on a large array (raid 50)?

    no one can give a hint on this? someone must have an opinion on this 🙂

  • OK, here are my opinions:

    I like to keep things as simple as possible, so I would probably do it like this:

    2 discs raid 1 for system+programs+paging

    2 discs raid 1 for ldf

    7 discs raid 5 for mdf

    If there is very heavy write traffic on tempdb, you might want to dedicate one or more disks in raid0 to tempdb only.

    For example like this:

    2 discs raid 1 for system+programs+paging

    2 discs raid 1 for ldf

    2 discs raid 0 for tempdb mdf

    5 discs raid 5 for mdf

    Some important things to consider are:

    ldf files

    For maximum performance these files should always be on a dedicated raid 1 or raid 10 volume. You only need raid 10 if the data does not fit on one disc.

    If you can accept some data loss you could keep your ldf-files on a non redundant volume (raid0). In this case you will have to restore to the last transaction backup if you get a disc crash on the ldf volume.

    mdf-files

    These files can be put on either raid 0, raid 10, or raid 5.

    raid 5: slow writes, fast reads, low cost

    raid 10: fast writes, fast reads, high cost

    raid 0: fast writes, fast reads, lowest cost, much longer recovery times from a disc crash.

    The more disks you use, the faster it is. (Except writes to raid5 which are always at the speed of a single disk)

    The reason raid0 is slower to recover from a disc crash is that you need to replace the disk and then restore from backup.

    tempdb files

    tempdb does not need redundancy. For maximum performance and low cost you can put it on a raid0 volume. Note that unless you have very heavy traffic in tempdb it is probably better to use all disks for the mdf-files.

    Additional notes

    If your uptime is very critical you might want to use a failover cluster or a mirrored database. (Very expensive)

    /SG

Viewing 5 posts - 1 through 4 (of 4 total)

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