Most newer servers and RAID controllers support the 66 MHz, 64-bit PCI standard. This gives 520+ Mbytes per second of transfer rate for the PCI bus, enough to support 13 10K RPM disks transferring full tilt. Since his configuration only includes 6 transferring spindles (redundant and parity disks don't count in this calculation), and he'll never use all those spindles at once, a single 66 MHz, 64-bit PCI bus should work fine.
-----Original Message----- From: Katz, Gordon J. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 06, 2002 7:53 AM To: NT 2000 Discussions Subject: RE: SQL Server and RAID Levels I hope you server has 3 or more PCI buses. You will have contention on the bus for the data on that is being spread across the controllers, slowing your server down... -----Original Message----- From: Anthony L. Sollars [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 9:05 PM To: NT 2000 Discussions Cc: Anthony L. Sollars Subject: RE: SQL Server and RAID Levels IT does we are runnning 3 dual channel RAID cards, most of the disk are on a subsystem. I too shudder at RAID0 but they kept beating into me that the data on this RAID0 is not vital data, but will be moved here during data prep and it requires a lot of i/o activity to the performance gain outweighs the risks of losing a few hours work. WE shall see, for now the indexes will be stored on a redundant array, so if the disk does fail the SQL server doesn't go down. -TOny -----Original Message----- From: Andrew Baker [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 6:00 PM To: NT 2000 Discussions Cc: '[EMAIL PROTECTED]' Subject: RE: SQL Server and RAID Levels I still shudder when I see RAID0, since a failure of your Indexes will have a negative impact on the rest of the server... Overall, it's a better config than the original... Good luck with the install. (make sure your RAID controller has 4 channels!) ============================================================== ASB - http://www.ultratech-llc.com/KB/?File=~MoreInfo.TXT ============================================================== Automation Leads To Relaxation... -----Original Message----- From: Anthony L. Sollars [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 8:35 PM To: NT 2000 Discussions Subject: RE: SQL Server and RAID Levels Wow thanks for all the great information guys, I just got out of a 3 hour meeting discussing all the relevent information I gathered today. I took your reccomendations to light and completed it with my own research to come up with the following configuration. 2x18gig SCSI RAID1 - OS 2x73gig SCSI RAID1 - LOGS & TempDb 4x73gig SCSI RAID0 - DataPrep for Data warehousing & indexes(No redundancy is required, performance is the key issue here) 3x73gig SCSI RAID5 - Critical Data where redundancy is required Thanks all -TOny -----Original Message----- From: Byron Kennedy [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 2:48 PM To: NT 2000 Discussions Subject: RE: SQL Server and RAID Levels here is what i sent to a friend i was having this discussion with. ultimately, vendors like compaq supply a spec sheet on the i/o time per controller in various configs. I'd like to get that info for ours. look forward to talking about this more - very interesting. cheers-byron -----Original Message----- From: Byron Kennedy [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 12:53 PM To: NT 2000 Discussions Subject: RE: SQL Server and RAID Levels Because when writing to a RAID 5 array (in general), both the target disk stripe and the target parity stripe must be read(2) and the parity calculated, and then both stripes written out(2). As you say, this performance hit can be vastly improved through the use of write caching, though the disks still have to do the writes (short-term vs. long term performance). Agree with your points though. Tony, as other have advised, use RAID 1 for the logs. the i/o to the transaction logs are almost 100% sequential writes - no perf issues. you don't want to loose these in a RAID 0 because 1 drives drops. if nothing else use cheaper disks for the logs. good luck.byron -----Original Message----- From: Wes Sent: Monday, February 04, 2002 12:30 PM To: NT 2000 Discussions Subject: RE: SQL Server and RAID Levels How does RAID 5 need 4 i/o's per disk? RAID 5 is slower because it must calculate a parity bit before writing the data to disk. If you have enough cache so that the OS thinks it is written before it is really done then that negates the performance hit of RAID 5. All controllers we use have 128MB cache and some large SAN systems may have GB's of cache. RAID 5 is optimal for reads. The more spindles the better by the way. If you can afford it RAID 10 or 1+0 combines the benefits of RAID 1 and 0. I would never recommend using RAID 0 for anything on a server. Even if it is just a dev box you still have to consider lost labor hours while people can't work. Benchmarking is the only way to tell if you absolutely must have the optimal cost and performance solution. We use RAID 5 for all large configurations. RAID 1 only for the OS and transaction logs. -----Original Message----- From: Byron Kennedy [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 2:21 PM To: NT 2000 Discussions Subject: RE: SQL Server and RAID Levels not exactly: RAID 5 is the most costly on writes as it requires 4 physical i/o per disk per write (remember parity is distributed across all drives). RAID 1 requires 2 physical i/o per disk, per write. RAID 0 requires 1 physical i/o per disk per write. RAID 10 (0+1) requires 2 physical i/o per disk, per write. byron -----Original Message----- From: Szlucha, Chris [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 12:06 PM To: NT 2000 Discussions Subject: RE: SQL Server and RAID Levels Forgive me if I'm wrong, but Ed wasn't saying to use both RAID 0 and RAID 1, but rather what is sometimes called RAID 10, or more properly RAID 0+1. It is a mirrored RAID setup. Speed and redundancy, but it's the most costly of the bunch. And your statement about it being faster on RAID 0 or 1 is incorrect. RAID 5 is faster, as the write job is split up across the drives and each drive writes it's own piece of data at the same time as the others. -Chris ------ You are subscribed as [EMAIL PROTECTED] Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe send a blank email to [EMAIL PROTECTED] ------ You are subscribed as [EMAIL PROTECTED] Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe send a blank email to [EMAIL PROTECTED] ------ You are subscribed as [EMAIL PROTECTED] Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe send a blank email to [EMAIL PROTECTED] ------ You are subscribed as [email protected] Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe send a blank email to [EMAIL PROTECTED]
