InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 21 May 2013 11:46:31 GMT20http://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspx[quote][b]Perry Whittle (1/12/2012)[/b][hr]@Steve Jones that is, unfortunately a disadvantage of the RAID5. Array rebuild times for R5 and R10 are also a consideration, with lower rebuild times R10 is often the favourite.[/quote]That's why you need a spare in the rack.And if you do that, why not go with R10 then and slightly bigger drives? I've gambled on R5 in the past, but with today's capacities of drives, not sure I would anymore.Side note: we started with R5 here in 2001, but when we purchased larger servers in 2005, we just went with multiple R1 arrays for protection since we were putting a spare drive in a 6 slot server, we just did 3 R1 arrays.Thu, 12 Jan 2012 08:25:57 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspx@SQLRNNR exactly, although if you were to lose half the drives performance would suck in a big way. Your data is still intact though.@Steve Jones that is, unfortunately a disadvantage of the RAID5. Array rebuild times for R5 and R10 are also a consideration, with lower rebuild times R10 is often the favourite.Thu, 12 Jan 2012 00:16:21 GMTPerry Whittlehttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspxRaid 5 has performed great for me in many applications. Many apps where we weren't pushing the envelope on IOPS, and we had much of the needed data in RAM.The issue with R5 is that you need a spare handy when one fails because the degradation of performance, and risk, go up dramatically.Wed, 11 Jan 2012 18:24:43 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspx[quote][b]Perry Whittle (1/11/2012)[/b][hr]The big advantage of Raid 10 is you can lose up to half the disks as long as no mirrored pair fail and the array will still operate, albeit with reduced performance.[/quote]Biggest part of the reason I would go with RAID10 if possible - protection.Wed, 11 Jan 2012 17:41:20 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspxThe big advantage of Raid 10 is you can lose up to half the disks as long as no mirrored pair fail and the array will still operate, albeit with reduced performance.Wed, 11 Jan 2012 17:10:43 GMTPerry Whittlehttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspxI really don't like the questions about "best" practices for storage from MS. There is seldom enough information presented to properly answer those questions.Sure, RAID10 offers better protection. RAID5 is cheaper. In discussions with EMC consultants as well as SQLIO sims you can get the same performance from both. If RAID5 is cheaper, you can add more disks and have more space in theory.Case in point - at one client we had double the performance from RAID5 than the RAID10 (write and read were both better in SQLIO). Client could not afford to have RAID10 everywhere nor was there enough drive bays to compensate in favor of the RAID10.If I had to use spinning disk then I would go RAID10 where possible. If I had the money I would use FusionIO not worry about the performance of the chosen array ;).Wed, 11 Jan 2012 17:03:46 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspx[quote][b]Kenneth.Fisher (1/11/2012)[/b][hr]I appreciate ya'lls help with this. RAID has always been a difficult subject for me but I think I'm finally getting it down.Just as an aside, we have the interesting problem of not always knowing where are drives are comming from. In other words, the D drive and the E drive may actually both be on the same RAID array, but no one told us, its just the way it was allocated out.[/quote]Are you planning to use local disks or SAN presented storage?Wed, 11 Jan 2012 16:55:03 GMTPerry Whittlehttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspx[quote][b]Kenneth.Fisher (1/11/2012)[/b][hr]I appreciate ya'lls help with this. RAID has always been a difficult subject for me but I think I'm finally getting it down.Just as an aside, we have the interesting problem of not always knowing where are drives are comming from. In other words, the D drive and the E drive may actually both be on the same RAID array, but no one told us, its just the way it was allocated out.[/quote]Very common in a SAN scenario. You usually have to work closely with the SAN team to get things setup physically the way you need them, but you'll almost always get pushback on this because it's 'wasteful' from their perspective unless you have a definate need and can prove I/O is your stall. It's up to you if it's worth the small war it can turn into, depending on your team. It might even be a friendly war, but you usually end up in one either way. SAN space is expensive a lot of places and it's their job to make sure it's used optimally from their side, too.Wed, 11 Jan 2012 12:53:27 GMTEvil Kraig Fhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspxI appreciate ya'lls help with this. RAID has always been a difficult subject for me but I think I'm finally getting it down.Just as an aside, we have the interesting problem of not always knowing where are drives are comming from. In other words, the D drive and the E drive may actually both be on the same RAID array, but no one told us, its just the way it was allocated out.Wed, 11 Jan 2012 12:43:25 GMTKenneth.Fisherhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspxI think there's a limit whereby you are saturating channels, and it would depend on your workload. I think you want to minimize head movement if you have a busy log since these are sequential writes, and there is some benefit from having those separate.For tempdb and data files, it's more workload dependent, but ultimately I would dislike having things together for risk purposes. I don't want to lose my log and my data (and my backups) if there is a problem with the array.Wed, 11 Jan 2012 10:51:42 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspxNow I did see one comment that said if you can get a big enough RAID 10 (large number of disks) just stick it all in the same place and let the RAID controllers sort it out. I would guess that would in part depend on not just the # of disks but the # of controllers also correct?Wed, 11 Jan 2012 10:48:19 GMTKenneth.Fisherhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspxI'd second Gail's advice. R10 if you can, R1 for logs if you can't. R5 for data if you must, but keep a spare drive around, which in most cases means you should just get 2 spares and go R10 anyway.Wed, 11 Jan 2012 09:44:46 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspx[quote][b]Kenneth.Fisher (1/11/2012)[/b][hr][quote][b]GilaMonster (1/11/2012)[/b][hr]Best is 10 everywhere. If that's too expensive, then 1 or 10 for log and 5 for data (and 10 for TempDB)RAID 5 is terrible for logs because it has a high write overhead. Tran logs are write-heavy, not read-heavy. [/quote]I had thought that RAID 5 had better write performance than RAID 0? Although I have been reading comments in both directions.[/quote]No. RAID 5 has about the worst write performance of the common RAID levels because of the need to compute and then write parity. (though no one would ever consider RAID 0 for a database)RAID 0, a write operation is a single operation. RAID 5 (let's say 4 stripes), a write operation is a write, potentially 1 or 2 reads and then a second write for the parity stripe)There's a good overview of the RAID levels and more in chapter 2 of this: [url]http://www.simple-talk.com/books/sql-books/troubleshooting-sql-server-a-guide-for-the-accidental-dba/[/url]Wed, 11 Jan 2012 09:28:44 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspx[quote][b]GilaMonster (1/11/2012)[/b][hr]Best is 10 everywhere. If that's too expensive, then 1 or 10 for log and 5 for data (and 10 for TempDB)RAID 5 is terrible for logs because it has a high write overhead. Tran logs are write-heavy, not read-heavy. [/quote]I had thought that RAID 5 had better write performance than RAID 0? Although I have been reading comments in both directions.[quote]RAID 0 for TempDB is a risk, if any drive fails then TempDB fails and SQL shuts down. Now sure, there's no important data in there, but TempDB is essential for SQL operation and if it's on RAID 0 and a drive fails, SQL can't be started until either that failed drive is replaced (which could be anything from minutes to weeks) or until someone figures out how to start SQL without TempDB and relocates TempDB to some other drive.[/quote]Excellent point. I hadn't thought of that.Wed, 11 Jan 2012 09:22:52 GMTKenneth.Fisherhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspxStorage Top 10 Best Practices :http://technet.microsoft.com/en-us/library/cc966534.aspxMaybe there are no sensitive data in tempdb but you don't want your instance to shut down !Wed, 11 Jan 2012 09:16:05 GMTazdznhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspxBest is 10 everywhere. If that's too expensive, then 1 or 10 for log and 5 for data (and 10 for TempDB)RAID 5 is terrible for logs because it has a high write overhead. Tran logs are write-heavy, not read-heavy. RAID 0 for TempDB is a risk, if any drive fails then TempDB fails and SQL shuts down. Now sure, there's no important data in there, but TempDB is essential for SQL operation and if it's on RAID 0 and a drive fails, SQL can't be started until either that failed drive is replaced (which could be anything from minutes to weeks) or until someone figures out how to start SQL without TempDB and relocates TempDB to some other drive.Wed, 11 Jan 2012 09:13:43 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1234076-1550-1.aspxI'm starting to study for my Admin MCITP for 2008 and the first thing I have been hitting is the recommendations about what RAID to use for different parts of the server.My understanding so far is that MS recommends a RAID 1 for Log files, and a RAID 5 for database files. I have 2 questions. What do the wise minds of SSC think of the above recommendations? For example wouldn't RAID 5 be better for the log since (from what I read) it provides better performance while still providing redundancy? And would a RAID 0 be good for TEMPDB where you want fast performance but don't really need recoverability?Wed, 11 Jan 2012 09:04:08 GMTKenneth.Fisher