Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««678910»»»

RAID and Its impact on your SQL performance Expand / Collapse
Author
Message
Posted Monday, May 7, 2012 10:46 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, May 29, 2014 12:39 PM
Points: 110, Visits: 495
sqlquery-101401 (5/7/2012)
Thanks , Yes i have couple of servers on SAN , what other utilities you refer?


I have never administred a SAN\NAS so i've always had to go to our IT Team or the Systems Engineers to obtain this data.



GAJ


Gregory A Jackson MBA, CSM
Post #1295992
Posted Thursday, November 22, 2012 2:01 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 8:42 AM
Points: 1,635, Visits: 5,592
I'm a little confused. Surely the Disk Transfers/second counter in Performance Monitor will already be limited by the hard disk subsystem you have installed, so you can't use it to determine if you need to upgrade or not?
Post #1387760
Posted Thursday, November 22, 2012 2:57 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, August 29, 2014 8:36 AM
Points: 142, Visits: 460
Steve Jones - SSC Editor (5/1/2012)
yazalpizar_ (5/1/2012)
With the proliferation of SSD disk and its costs going down, some RAID levels with low write performances are no longer so low. Put an SSD in your life. I've done it, both home, laptop and work. Is the best money can buy right now in order to increase performance several degrees. We are planning to do it also on our local servers, first on the test server and then on the main one if evertyhing is ok.


Make sure you have good backups and be careful here. When SSDs die, they die ,and you may or may not get good notice.

A quick read: http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html


Very good article that one on CodingHorror. Sorry for not replying, was no aware of the thread and it has grown a lot with useful information. I indeed have backups of everything on external hard drive. At the office we finally didn't change the HD on the servers, is not a priority for our manager for now.

PS: failed the MCITP sql server 2008 exam yesterday... need to work harder on it
Post #1387795
Posted Thursday, November 22, 2012 8:20 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, May 29, 2014 9:35 PM
Points: 6, Visits: 22
Great Article - very helpful. Especially calculating the IOPS.
Post #1387919
Posted Thursday, November 22, 2012 4:04 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Sunday, August 24, 2014 6:50 PM
Points: 401, Visits: 556
Good article and some excellent comments

Not much in here on RAID 50, which is rapidly becoming one of my favourite RAID levels for Data and Backups

Logs and Tempdb are definitely destined for RAID 10 (1+0, not 0+1 as has been pointed out), but RAID50 gets around a lot of the write penalty associated with RAID5 by spreading the writes out across multiple arrays.

As an example, if you have a 5 disk RAID5 array which can handle 100 IOPS, then striping this with an identical RAID5 array gives you 200 IOPS (in a perfect world, realistically probably only 190!).

One area which isn't discussed in here, and can have an enormous impact on RAID performance is stripe size. Ensuring that your stripe sizes are multiples of each other as you stack the RAID levels is crucial to maintaining performance. Ensuring that the OS disk cluster size is a multiple will also help things along nicely.
Post #1387994
Posted Thursday, November 22, 2012 6:42 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, May 29, 2014 12:39 PM
Points: 110, Visits: 495
Excellent info....

thanks


GAJ


Gregory A Jackson MBA, CSM
Post #1388001
Posted Thursday, November 22, 2012 11:51 PM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, August 26, 2014 11:49 PM
Points: 833, Visits: 1,365
It appears that this article has been changed (or at least republished). Perry Whittle's comment should have been taken into consideration, the difference between RAID 1+0 and 0+1 is indeed not academic. RAID 1+0 is a stripe of mirrors, if one disk fails, that mirror has only one disk left, but all the other mirrors may still lose a disk each, and your RAID array is still available. RAID 0+1 is a mirror of stripes, if one disk fails, that whole stripe is available, and you're left with a singe stripe. If one of the disks in this stripe fails, your RAID array is not available anymore.

As far as I understand it, the physical storage of RAID 1+0 and 0+1 are identical, the difference lays in how these data are used logically (or internally if you wish) by the RAID controller.




Ole Kristian Velstadbråten Bangås - Virinco - Facebook - Twitter

Concatenating Row Values in Transact-SQL
Post #1388054
Posted Friday, November 23, 2012 1:19 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Yesterday @ 2:27 PM
Points: 464, Visits: 371
btd (5/1/2012)
I do agree a well put together document BUT I wish we could get away from the interpretation of RAID. 'inexpensive discs'... The 'I' certainly did not mean inexpensive discs when RAID first came out way back when...'Independent' ... why does the computer world keep changing things when it does not need to, we have plenty of change without it...... and as for 'tables' instead of files.........



My personal recollection is that the "I" did stand for inexpensive. Prior to the days of cheap, large, fast, hard disks one of the key metrics was MTBF (Mean Time Between Failures). In those days a lot of the data was stored "off-line" on tape. When a job ran the operator would mount the tape and the data would be transfered to disk as working storage (sort of a cache).
Disk drive failures on early main frame and mini computers were fairly common. Disks with high MTBF were very expensive. Early RAID configurations used the relatively inexepensive Winchester architecture drives to construct fault-tolerant solutions without breaking the bank on expensive high MTBF drives. At a time when CPU cycles were measured in milliseconds, the added disk write penalties did not seem so bad.

Post #1388246
Posted Friday, November 23, 2012 5:11 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, May 29, 2014 12:39 PM
Points: 110, Visits: 495
T.C.
I'm not sure I understand your question completely.....care to rephrase or expand?


GAJ


Gregory A Jackson MBA, CSM
Post #1388262
Posted Saturday, November 24, 2012 3:09 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 11:35 PM
Points: 6,318, Visits: 13,624
The differences between RAID 1+0 and 0+1 are not academic. Let's just review that again, not academic!!!

If you do decide to deploy a 0+1 array for your mission critical data and you're unlucky enough to encounter a drive failure in each array you'll realise just how important the differences are.

As you're sitting there typing your resume you'll have time to reflect on the storage decision you made


-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs"
Post #1388294
« Prev Topic | Next Topic »

Add to briefcase «««678910»»»

Permissions Expand / Collapse