O/S partition

  • Hello....I have 1200 GB drive space RAID 5.

    Can anyone recommand the size for best practice to create these partitions.?

    C = O/S (Size ??)

    E = SQL Server (Size ??)

    F = Log file (Size ??)

    Thanks a lot.

    TJ

  • Can you go to RAID 1?

    Other than that, you need to get the data size and growth to get the database and log size.

    If it's one array, not sure you get a benefit from different drives. Why not leave it as one size. That way you don't have one to small and another too large.

  • I agree. What's the point of partitioning into multiple drives? It won't buy you any performance or data recovery advantages...may even give you a performance hit.

    If there are 4 disks in the RAID5, can you make 2 RAID1 arrays out of it?

    The Redneck DBA

  • Hi SSChampion, may be not.

    We run out of space issues for setup replication.

    The initial plans was to add additional 3 x 250 GB.

    Now, Networkers wanted to upgrade to RAID 5.

  • Hello SSC-Enthusiastic,

    Can you explain on make 2 RAID1 Arrays.?

    Thanks,

    TJ

  • And once again I am struck by the reminder NEVER to let a Network Admin or Sys Admin near my database disks!

    Databases always want LOTS of physical disks.

    Log files should be kept on different physical disks from databases (and never joined together in an array!)

    So you seem to have the right idea - You want 3 discrete drive (OS, db and log). These should be on different physical disks.

    OS should be RAID1 (ideally so that the pagefile stays quick)

    db could be RAID5 if the writes are sufficiently low

    log should be RAID1

    Go through your databases and do the sizing from that (in Enterprise Manager choose View - Taskpad when pointing to a database)

    Once that basic structure is in place, you can start to get creative with more disks (putting tempdb on its own drive etc)

    Enjoy!

  • yet another post which talks about raid 5 - unless your database is read only don't use raid 5 , and to consider placing a transaction log on a raid 5 is almost beyond belief - unless you never plan to change the data or never add new data, or the databas eis just for one user.

    I can actually see quite good resaons for partitioning an array, if that's how you have to carve your disks, and to be fair that's exactly what a SAN does, which is why so many SAN's have poor performance of course, but logical partitioning can be useful - it's less a problem than raid 5

    [font="Comic Sans MS"]The GrumpyOldDBA[/font]
    www.grumpyolddba.co.uk
    http://sqlblogcasts.com/blogs/grumpyolddba/

  • We've put our data (not logs) on raid 10 (1+0, actually). It's better performance than raid 5, although it certainly costs more. However, disks these days are cheap enough that we decided it was worth it. Of course, it really can depend on what you're doing with your database. We needed the best Write performance and Read performance concurrently. But if you only need very good Write performance or very good Read performance, but don't really have to have both, maybe raid 5 or raid 1 would be the best for you.

  • "Hello....I have 1200 GB drive space RAID 5"

    Can you provide a break down of the equipment? How many HD's is there only one RAID controller? How many channels on controller(s)? What are the rest of the motherboard specs (provide model information so I can understand what you have)? I can make lot's of suggestions but without enough info I am just talking.

  • Hi

    For your setup I would be inclined to have a 50GB o/s Partition and leave the rest as one large partition for SQL Server.

    The partitions will not improve performance but will stop any unexpected Database growth using up all the disk space and crashing the server.

    Also you should consider aligning IO with storage track boundaries, the following link is for exchange but is applicable for SQL.

    http://technet.microsoft.com/en-us/library/aa995867.aspx

    I Hope this Helps


    Kindest Regards,

    Brandon

  • As per gist of other postings, RAID 5 is not recommended as the way to go for SQL databases. Partitioning of the RAID will certainly not improve performance, though may make it easier to do housekeeping.

    Refer to this recent article on sql-server-performance http://www.sql-server-performance.com/articles/audit/2005_audit_hardware_checklist_p3.aspx

    Only thing they recommend RAID 5 for is backup files.

  • Thank you for your all helps.

    Your advise and input are very valuable!!!!

    Best regards,

    TJ

  • never understood why anyone would recommend raid 5 for a backup which is a write intensive operation so raid 5 would be the absolute worst choice ( well actually raid 6 would be worse )

    I don't understand what this "issue" is with disks and servers, the average home PC probably comes with a terabyte these days ( probably in two disks for sure ) and we post about 50Gb partitions and bang for buck using raid 5, we all use dual core procs now and we're probably moving to quad core, servers usually have lots of memory now and we have 64 bit systesms - and here we are talking about disks as if they were on the protected list or there was a world shortage of them. Back in the days of sql server 6 I used upwards of 40 odd disks for production servers, not really a difficult move is it guys - microsoft have been writing about using dedicated arrays ( that means not shared ) for o/s, binaries, logs, data and backups for as long as I remember - it's one area we seem to be regressing upon and I can think of my work at a large corporate where we were arguing about allocation an extra 50GB of disk space to a production server - probably cost less than the marketing manager's daily lunch bill!!

    sorry, rant over - one of those days!!

    [font="Comic Sans MS"]The GrumpyOldDBA[/font]
    www.grumpyolddba.co.uk
    http://sqlblogcasts.com/blogs/grumpyolddba/

  • Just out of curiosity, how many drives make up your 1200GB of RAID 5 space?

    Is anyone else out there running into concerns with these monster arrays composed primarily of 400+ GB drives? I've heard of and now seen rebuilds on these huge arrays take upwards of a week (during which time you're completely vulnerable to losing the array).

    Thoughts?

  • I have almost always used R5 for servers, however I've usually been on a budget. Many smaller companies, gov't, etc. struggled with the cost of disk. Usually when we get a server, we go for most memory first, then disk.

    However I agree. These days disk is soooo cheap, it doesn't make sense to run R5. We ran it early on here, but over the last couple years we've upgraded to a couple R1 arrays and even rebuilt the arrray from R5 to R1.

Viewing 15 posts - 1 through 14 (of 14 total)

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