December 3, 2003 at 11:14 pm
Hi,
This question really alerts me to start learning RAID. Can someone point me out a good newbie tutorial on how to setup RAID for SQL Server.
Thanks for any help
Hendry
December 4, 2003 at 2:07 am
Hi there
A good idea, any search on google will return hundreds of documents to assist you. Also include searches on other DBMS technologies as the rules dont change too much.
Be aware though, this question wasnt practicle and I get a little annoyed with them. It is generally rare that you have so many disks to do what was said in the example, let alone put tableA on one disk array and tableB on another via filgroups due to a join. The 1st issue here is what happens when the dynamic of the table is altered and other joins are made with larger tables? its a strange modelling concept where, if they tables are super huge you may need to undertake such a modelling scheme over raw query perf analysis etc.
The other side of the coin is related to the number of databases you instance (or instances) are hosting on the server and how all of these map to raid-sets. Its important to realise that DBMS are "multi-user" and as multi-user systems its difficult to serialise anything for any period of time. With lots of databases all with their own trans logs for example, then there will come a time where the "single raid-1 or raid-10 set per log file per db" will never work for you physically. Its all a huge trade off.
All im saying here, take time out to really understand your apps and take care with sql tuning, indexing, buffer/prod cache utilisation etc, disk architecture is important, but be very careful how far you go with this low level mapping of datbase objects to physical arrays.
Cheers
Ck
Chris Kempster
Author of "SQL Server 2k for the Oracle DBA"
Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"
December 4, 2003 at 9:48 am
Must admit, while I know & follow the general concept of separating large, often joined tables in files on different physical disks (for improved performance due to physical drive I/O speed limits), I never performed any tests to see the effect. Just worked on creating better queries, indexes, and "summary" tables to improve performance.
And to me RAID is something to kill bugs with.
Data: Easy to spill, hard to clean up!
December 4, 2003 at 11:02 pm
Hi Guys,
Thanks for the suggestions, now I come across an idea to use Disk Partitions instead of RAID. I try to put heavy transaction tables on different Hard disk partition. I imagine this configuration can improve I/O perf. but maybe not as perfect as RAID, at least there's perf. improvement.
Is my thought reasonable? Has anyone practiced it?
Cheers,
Hendry
December 5, 2003 at 2:42 am
Well, with the way most RAID works with more than two disks, the data is split up into "stripes" across all disks in the array, so it doesn't really improve things if you put your data into different partitions as data access will be fairly random across all disks - think about how you can minimise disk head movement.
In fact, splitting tables across disk partitions is more likely to slow your database down, as the disk head will definitely have to move to access data in different filegroups.
For really good explanations of RAID, I use two books:
Kalen Delaney "Inside SQL Server 2000" (considered by many DBAs as an essential book) and
Whalen / Microsoft Press "SQL Server Performance Tuning - Technical Reference"
Hope this helps!
--
Si Chan
Database Administrator
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply