SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


RAID recomendations


RAID recomendations

Author
Message
Kenneth.Fisher
Kenneth.Fisher
SSCarpal Tunnel
SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)

Group: General Forum Members
Points: 4272 Visits: 2031
I'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?

Kenneth Fisher
I strive to live in a world where a chicken can cross the road without being questioned about its motives.
--------------------------------------------------------------------------------
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Link to my Blog Post --> www.SQLStudies.com
GilaMonster
GilaMonster
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86526 Visits: 45242
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.

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.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


azdzn
azdzn
SSCommitted
SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)

Group: General Forum Members
Points: 1698 Visits: 289
Storage Top 10 Best Practices :
http://technet.microsoft.com/en-us/library/cc966534.aspx

Maybe there are no sensitive data in tempdb but you don't want your instance to shut down !



Kenneth.Fisher
Kenneth.Fisher
SSCarpal Tunnel
SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)

Group: General Forum Members
Points: 4272 Visits: 2031
GilaMonster (1/11/2012)
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.

I had thought that RAID 5 had better write performance than RAID 0? Although I have been reading comments in both directions.

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.

Excellent point. I hadn't thought of that.

Kenneth Fisher
I strive to live in a world where a chicken can cross the road without being questioned about its motives.
--------------------------------------------------------------------------------
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Link to my Blog Post --> www.SQLStudies.com
GilaMonster
GilaMonster
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86526 Visits: 45242
Kenneth.Fisher (1/11/2012)
GilaMonster (1/11/2012)
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.

I had thought that RAID 5 had better write performance than RAID 0? Although I have been reading comments in both directions.


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: http://www.simple-talk.com/books/sql-books/troubleshooting-sql-server-a-guide-for-the-accidental-dba/

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


Steve Jones
Steve Jones
SSC Guru
SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)

Group: Administrators
Points: 61815 Visits: 19099
I'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.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Kenneth.Fisher
Kenneth.Fisher
SSCarpal Tunnel
SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)

Group: General Forum Members
Points: 4272 Visits: 2031
Now 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?

Kenneth Fisher
I strive to live in a world where a chicken can cross the road without being questioned about its motives.
--------------------------------------------------------------------------------
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Link to my Blog Post --> www.SQLStudies.com
Steve Jones
Steve Jones
SSC Guru
SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)

Group: Administrators
Points: 61815 Visits: 19099
I 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.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Kenneth.Fisher
Kenneth.Fisher
SSCarpal Tunnel
SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)SSCarpal Tunnel (4.3K reputation)

Group: General Forum Members
Points: 4272 Visits: 2031
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.

Kenneth Fisher
I strive to live in a world where a chicken can cross the road without being questioned about its motives.
--------------------------------------------------------------------------------
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Link to my Blog Post --> www.SQLStudies.com
Evil Kraig F
Evil Kraig F
SSCrazy Eights
SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)

Group: General Forum Members
Points: 8555 Visits: 7660
Kenneth.Fisher (1/11/2012)
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.


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.


- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search