SQLServerCentral / Editorials / SQLServerCentral.com / RAID 5 and SQL Server / Latest Posts

RE: RAID 5 and SQL Server

coldsteel2112 — Thu, 07 Apr 2011 09:02:17 GMT

[quote][b]peter-757102 (4/7/2011)[/b][hr][quote][b]coldsteel2112 (4/6/2011)[/b][hr][quote][b]peter-757102 (1/10/2011)[/b][hr]At my company we had two times now a disk in a RAID 5 broke and the array could not restore itself and had to use backups to continue working on another server. An identical issue with RAID 10, never cause any issues or significant downtime.[/quote]I noticed this post and had to respond. In a properly configured RAID 5, a single disk failure would not cause a failure of the array. And even if there was a failure of the writing of the data to the replaced disk, no one would have known it because the array would have kept chugging along like nothing happened.So, I'm wondering if your aversion to RAID 5 is simply based on misunderstanding? What you've described cannot happen in the real world.[/quote][b]Theory and practice are two entierliy different things.[/b]The RAID controller choked early during the repairs and never recovered, we had to send the disks to a specialised company to retrieve the data!And te time during repairs of a raid 5, is VERY risky for the validity of your data. At that point there is NO redundance and the disks themself cannot be read on their own either, so ANYTHING that can go wrong will cause data loss or corruption.And with todays big disks, the chance of something like that that happening is simply to large.To even considder using raid 5 today on large spinning disks is IMHO just on that basis alone a bad idea!Now, for SSD's there might by an exception as they are so fast and more reliable, rebuilding can be fast too.But even then, I strongly prefer the much simpler and transparent method of mirroring![/quote]So if the controller failed, then no matter what flavor of RAID you were running, you still would have had the same issue. Any disks in a failed array would still need a rebuild by the controller once the new disk was installed. So to blame RAID 5 on your issue is a bit unfounded.Not saying that RAID 5 is better or worse, but I've been using for the past 15 years on hundreds of servers (internally) and have never once seen one disk fail, along with another immediately after. Not saying that could never happen, just telling you my experience. As long as you have a spare configured and the controller set to high priority on the rebuild, you mitigate the length of time the array is in a vulnerable state.Now, with all that said, I agree :-P I would much prefer RAID10 or if I have the capacity, RAID 50. Both posses a greater amount of fault tolerance then 5. So unless there is a space issue (only allowed 4 drives for instance) and you need the most out the capacity of those 4 drives (4 - 500gb drives: RAID 5: 1862GB vs. RAID 10: 931GB), there is no real reason to choose RAID 5.So, like all things in life, its about how much money are you willing to throw at it. ;-)

RE: RAID 5 and SQL Server

peter-757102 — Thu, 07 Apr 2011 05:56:54 GMT

[quote][b]coldsteel2112 (4/6/2011)[/b][hr][quote][b]peter-757102 (1/10/2011)[/b][hr]At my company we had two times now a disk in a RAID 5 broke and the array could not restore itself and had to use backups to continue working on another server. An identical issue with RAID 10, never cause any issues or significant downtime.[/quote]I noticed this post and had to respond. In a properly configured RAID 5, a single disk failure would not cause a failure of the array. And even if there was a failure of the writing of the data to the replaced disk, no one would have known it because the array would have kept chugging along like nothing happened.So, I'm wondering if your aversion to RAID 5 is simply based on misunderstanding? What you've described cannot happen in the real world.[/quote][b]Theory and practice are two entierliy different things.[/b]The RAID controller choked early during the repairs and never recovered, we had to send the disks to a specialised company to retrieve the data!And te time during repairs of a raid 5, is VERY risky for the validity of your data. At that point there is NO redundance and the disks themself cannot be read on their own either, so ANYTHING that can go wrong will cause data loss or corruption.And with todays big disks, the chance of something like that that happening is simply to large.To even considder using raid 5 today on large spinning disks is IMHO just on that basis alone a bad idea!Now, for SSD's there might by an exception as they are so fast and more reliable, rebuilding can be fast too.But even then, I strongly prefer the much simpler and transparent method of mirroring!

RE: RAID 5 and SQL Server

coldsteel2112 — Wed, 06 Apr 2011 14:28:55 GMT

[quote][b]peter-757102 (1/10/2011)[/b][hr]At my company we had two times now a disk in a RAID 5 broke and the array could not restore itself and had to use backups to continue working on another server. An identical issue with RAID 10, never cause any issues or significant downtime.[/quote]I noticed this post and had to respond. In a properly configured RAID 5, a single disk failure would not cause a failure of the array. And even if there was a failure of the writing of the data to the replaced disk, no one would have known it because the array would have kept chugging along like nothing happened.So, I'm wondering if your aversion to RAID 5 is simply based on misunderstanding? What you've described cannot happen in the real world.

RE: RAID 5 and SQL Server

sjimmo — Thu, 13 Jan 2011 09:17:16 GMT

Having read all of the posts to this point, I find it interesting the arguments for/against one RAID vs another.In my opinion and experinece the RAID rule of thumb has been data segments went on RAID 5 and T-Logs on RAID 1 or if able 10. In the case of SAN's, there was a lot more creativity but essentially the same.That being said, I feel that one should also consider the type of database, whether OLAP or OLTP as well as the size and number of users.In the case of OLTP you can place the data segment(s) on RAID 5, which will allow better read capabilities for those who are doing some reporting while the write protion (T-Log) is on RAID 10. This RAID is overall better for writing data. Then, as all know when a chackpoint occurs the data is written to the database files without much of an impact to the data-entry side.In larger or even busier databases, it may be of benefit to partition the database itself into seperate files placing these files onto and appropriate RAID array. ie Indexes for a certain table to a seperate file group on a seperate RIAD 5 array while the data for that table may be on it's own RAID 5 array.I personally like RAID 10 for my T-Logs as this array is actually more conducive to faster writing speeds.On larger databases, I also try to ensure that at least my RAID 5 and 10 is on a seperate channel on the controller, if not on seperate controllers all together.I also make sure that I have my tempdb on yet another RAID10 array in order to ensure that there is no contention there as well as on seperate controllers (most of my tempdb's ate approximately 100GB + and heavily used). I have found in several cases a need to partition these into seperate files as well and mve them to seperate drives.I also have a few small databases all on RAID 10.So I guess I would say that it isn't as simple as saying RAID 1 or 5 or 10 or 50 or ...Now IO extremes, such as reducing reports from 30 hrs to minutes - I suspect that there is a lot more there than a simple move of 1 database or database file.

RE: RAID 5 and SQL Server

SQLRNNR — Thu, 13 Jan 2011 08:41:41 GMT

The popularity, I think, of RAID is derived from installation types around the world and the people that are setting up these new databases. Mom and Pop shops may not have the money to buy RAID 10 and RAID 5 may be pressing their budget but it is the best option for them. It also depends on type of database and volume of transactions as to whether it is an appropriate choice. Not every database needs to be on RAID 10 - it just doesn't make sense for the cost versus transaction volume in many cases.

RE: RAID 5 and SQL Server

richj-826679 — Mon, 10 Jan 2011 10:32:55 GMT

I may get my official membership in BAARF revoked, but in Oracle SQL tests in spring '09 with a then-new midrange IBM POWER6 server and DS-series SANs connected by dual 4GB FC HBAs, I saw no discernable IO performance difference in read or write between RAID-5 and RAID-10 setups, even under unrealistically stressed conditions (tests were throttled solely by CPUs ability to generate enough IO). I forget the exact array sizes for each, but the SAN caching was truly effective in nullifying the write performance penalty. I should also mention that we have an SVC frontending the SANs, although I'm not sure how that would affect IO performance for the testing, unless it's cache is additively effective (when it's not shuffling volumes around).One other knock on R5 is the array rebuilding performance hit after a lost drive is replaced. We've lost multiple drives since then (guessing due to thermal stress after AC failure), albeit no more than one at a time in any array, and I've seen zero performance effect by either failure or replacement, at least on our production Oracle box.When relaying this to my former boss who is BAARFier than I am, he said that they came to the same damnable conclusion. I guess technology really does change. :-)That being said, there is ZERO chance I'll approve of a standalone RAID-3/4/5/6/etc config for critical production systems. It's just the BAARF in me...

RE: RAID 5 and SQL Server

David Fulton-388478 — Mon, 10 Jan 2011 08:45:29 GMT

I have worked with medium to large databases in SQL Server and Oracle for some time and have seen just about any combination of disks you can imagine for them. When our financial system went from RAID 5 to RAID 10, the disk queues shank 40% and IO improved more than imaginable. We got to be heroes once the move was finished. At the time it was an IO intensive 50GB database with about 800 users.Our POS system, which is Microsoft front to back, was crippled by an oversized RAID 5 array. We switched it to a RAID 10 array and did nothing else. The fix got reports from a 30 hour run to a six minute run. When we redistributed the files to improve the IOPS things got even better. Nothing changed but the disk configuration. The system works now like it should.As hardware has gotten better the gap has narrowed some. The question you have to ask is, "How important is my data?" I want our people to get their data instantly every time. I don't want anyone to have to wait for information they need to make our organization work.

RE: RAID 5 and SQL Server

tony.turner — Mon, 10 Jan 2011 07:59:55 GMT

In debating RAID 5 against RAID 10 performance for SQL we need, in my view, to distinguish between read and write performanceFor read performance:SQL read page requests (except for SQL read-ahead) are generally un-overlapped; your request waits until the read is satisfied and your request can continue, you need to retrieve the top index level before you retrieve the next index level, before you retrieve the leaf index level, before you retrieve the data row. In effect, poor read performance mushrooms. In partial mitigation of this, metadata and non-leaf index pages have a relatively higher hit rate than index leaf and data pages, they tend to stay buffer or cache resident longerRaid 10 may satisfy read requests faster than RAID 5; a competent RAID 10 implementation will allow access to the first available mirror copy. In effect, path contention can be halved by RAID 10, or it can be seen as doubling the effective device bandwidth. In a multi-user SQL environment this can be very significant. In some SAN environments path contention (rather than device contention) may be the major bottleneck, and the benefit of RAID 10 above RAID 5 may not be seen because of this constraintA large device cache may, or may not, be an advantage to read performance. In most of the cached devices I have worked with recently, including SANs, the SQL buffer pool has been significantly larger than the device cache. In effect, any SQL buffer miss is almost by definition also a device cache miss (both use similar ageing algorithms). In my (biased) view additional RAM allocated to SQL buffer pools, rather than a larger device cache, is far more effective until the device cache is multiple times larger than the SQL buffer pool. A SQL buffer hit may be more like 10000 times faster than a physical read, a device cache hit may be less than a 100 times faster than a physical read under load (depending on implementation and path contention)For write performance:Data page write requests are effectively overlapped. I can find no specific reason why writing of dirty data pages during checkpoint should delay transaction processing, except if the flushing of pages is sufficiently slow as to affect the free page replenishment algorithm. In effect, if data page write is sufficiently slow, it may cause free list stalls, with all the negative performance implications thereof. To the SQL heavies: if I have missed some aspects of data page write, please let me knowLog page write requests are not overlapped; an implicit or explicit transaction is not complete until the log pages reflecting that request are confirmed as written. The effect of poor write performance should not be cumulative, as it is in read performance; log write may require multiple physical writes, but they can be viewed essentially as either a single request, or multiple independent requests RAID 5 page writes require cache hits (not buffer hits) on the page to be written, and the parity page, and possibly all the pages in the parity set (there are some implementations that verify the parity before write). In mitigation, the page(s) can be retrieved in parallel, but the physical write is delayed by the retrieval process. It is likely that SQL log page writes have a very low cache hit rate (log writes into empty pages rather than previously used pages), the retrieval of the parity page, and possibly parity set, is what delays the physical write. The same delay of physical write is not true for RAID 10 implementationsRAID 5 page writes require the page and the parity page to be physically written. In some implementations the writes are not strictly in parallel; recovery from failed writes requires a particular sequence of writes. Essentially the same is true for RAID 10 implementations In all SQL-supported implementations the modified page and parity page (where applicable) must be stored in non-volatile cache before the write can be posted as complete; regardless of where they were retrieved from. In almost all implementations I have come across the non-volatile cache is significantly smaller than the volatile cache. In most implementations the size of the non-volatile cache is not readily increased. I have yet to meet the non-volatile cache that is not frequently (constantly ?) overrun under load, thus delaying write completion until space is available in the non-volatile cache. In effect, for SQL, write buffering reduces the write time, but in practice it is still significantly dependent on the physical write time of the underlying pagesWhat distinguishes RAID 5 write from RAID 10 write is that generally two entries are required in the non-volatile cache for RAID 5 as against a single entry for RAID 10, thus effectively doubling the size of the non-volatile cache, and thus reducing contention for space in that non-volatile cache. The non-volatile cache is in almost all RAID implementations a severely constrained resource. In addition, RAID 5 SQL log write time is significantly delayed by the retrieval of the parity page, which for SQL log is seldom a device cache hit almost regardless of the device cache size. This may significantly compound the contention for non-volatile cache space Thus, in my view, a large SQL buffer pool, a RAID 10 implementation, and as large a non-volatile cache as I can get are very desirable In my view SSDs do not change this equation, except that physical write rates to SSDs are significantly greater than to traditional disks. However PCIe-attached SSDs can be seen as a very large but relatively slow non-volatile device cache, which can benefit both read and write

RE: RAID 5 and SQL Server

Steve Reich — Mon, 10 Jan 2011 07:37:55 GMT

I always prefer to consider facts rather than rely completely on theory. Some years back I conducted a test of SAN RAID 5 disk arrays vs. RAID 10 arrays, for various sizes and combinations or read and write activity. I found that as disk size increased, the performance of the RAID 5 arrays caught up to the RAID 10 arrays, and by the team I reached 512Gb sized disks, the RAID 5 array was actually faster. Unfortunately I no longer have the results, but in any case your mileage may vary depending on what hardware you are using. If you have a SAN and you have the flexibility to try both options, I would suggest that you try a direct comparison by using the SQLIO benchmark tool and also try timing some simple SQL server operations (e.g. backup).

RE: RAID 5 and SQL Server

kevincox — Mon, 10 Jan 2011 07:01:52 GMT

Since I work with the largest SQL Server implementations in the world, it is essential that RAID 5 is removed from the picture, even for read mostly databases. I am a huge proponent of the "kill RAID 5 for databases" movement. RAID 10 is still the best general recommendation for databases, with RAID 1 being a good recommendation for some data warehouses ( see the [url=http://msdn.microsoft.com/en-us/library/dd459178.aspx]Fast Track Implementation Guide[/url]). Those DBAs implementing RAID 1 tend to be more advanced and know their application well enough to balance the disk IO over multiple database files and multiple LUNS themselves. One thing that most people miss is that many of the newer disk controllers/HBAs will do dual reads off the mirror. So even read mostly databases will get a big benefit from implementing RAID 10. Check your cards to see if they have this capability, even in the SANs. An interesting side note is that the lower cost SANs were among the first to include these type of cards.As far as SSDs go, they are the great equalizer in the random vs sequential IO discussion and really have nothing to do with RAID 5 vs RAID 1/10. You still pay the write penalty with RAID 5. Having said this, you can probably get some relief if you are having IO waits in a RAID 5 implementation with SSD just because it is faster. But at some point if you grow big enough you will end up killing RAID 5 anyway.And the discussion about disk caching helping RAID 5, what you are really saying is that it is helping up to a point. In the large systems I work with, write caching is practically worthless and is generally turned off because the volume of writes will overrun the cache and the system ends up waiting to get its turn to write to the cache. This holds true for any RAID implementation.In reality, SSD + write caching will help in the small to mid size RAID 5 implementations. But if you know you are going to experience significant growth over the next few months/years, go ahead and start moving to a mirrored RAID solution.I would like to close with the statement that those using RAID 5 don't get the right to complain their DBMS doesn't scale.Kevin Cox - SQL CAT

RE: RAID 5 and SQL Server

andreas.goretzky — Mon, 10 Jan 2011 06:54:31 GMT

Penalties in writing on RAID: during the nineties an issue on server hardware, 2011 an issue on gamer PC.In former times it was the calculation and the limited processing speed of hardware raid controllers leading in reduced data transfer rates. E.g. Adaptec AAA2400 has 4x UDMA 33 channels and supports natively Raid5. In stripeset mode on 4 discs the controller writes about 126 MB/sec, that's the limit for PCI 32 bit 33 Mhz. In Raid 5 mode the CPU on the controller (Intel I960) gets really hot, and it writes with about 30 MB/sec. This penalty is more or less gone, at least if customers don't buy their servers at Walmart having an ICH10R built in.Current quality hardware is able to calculate redundancy in realtime. Having 4 disks a simple exor algorithm can be used, but ICH10R is much faster running on odd disk numbers. That is cheap scrap, and an admin will die in hell when he uses ICH10R for productional use.I can also understand the Oracle guys living with a dozen independant disks in their system, but forgetting that this is fault multiplying and not fault tolerating. Both strategies (Raid and indiv. disks) are able for offline recovery if hardware fails, and Raid5 on cheap hardware is nearly intolerable.In general I would talk about reliability and not about "I like / I dislike Raid". Enterprise storage has to be reliable, this is a fact. It has no flaws during a rebuild and just works.Spending 100.000 $ for an enterprise SAN doesn't leave gaps, is fast enough so we're discussing about small companies and 1000$-5000$ entry class servers, barely worth being called servers.Anyway, a good Raid controller should NOT show any kind of penalties nowadays, nor even or odd disk number affinities.In principle raid 5 with n+1 layout can die easily if a disk fails and during the rebuild the next disk fails. Raid 5 n+2 could be a better (and more expensive) solution, but concerning smaller systems having only 4 disks there are 2 idle disks in Raid 5 but also in Raid 10 setup. Raid 10 will die later in this config, but the risk of failing disks is highly increased by just buying a bulk of disks from the same producitonal date.

RE: RAID 5 and SQL Server

johnr_johnson — Mon, 10 Jan 2011 06:05:26 GMT

We asked our centralized IT server support organization about using an SSD but they will not support them for the time being.

RE: RAID 5 and SQL Server

grahamc — Mon, 10 Jan 2011 03:31:00 GMT

At a previous company where we used internal server disks, instead of SANs, we used an interesting mix of RAIDs for the different drives. And as usual the answer is "it depends"...For our systems that were massively critical and performance orientated, we used RAID10. For our backup, archive and reporting systems we used RAID5. Now I am onto SANs and hardly get to see/touch/change anything on them. It was said earlier though, SQL was (is) a cost effective solution for databases, when compared to Oracle and the hardware seems to fall inline with that. Would be interesting to Oracle and SQL next to each other on the same hardware doing the same tasks :hehe:

RE: RAID 5 and SQL Server

peter-757102 — Mon, 10 Jan 2011 01:53:23 GMT

I think RAID 5 must be burried.It was once introduced when magnetic disks where still very expensive and capacity limited, while at the same time there was a need for redundancy. Nowadays, disks are cheap and BIG. So big even that when a raid array is repairing there is a sizable chance of an random error occurring and all data will be lost.Add to that the complexity of a the system and with it the sensitivity to errors and larger downtimes. And you will conclude that RAID5 is expensive and unreliable compared to other solutions such as RAID 10.And really most database servers are fairly small and do not have fully time dedicated admins. This is especially true for such an accesible product as SQL Server. Why Microsoft claims that RAID 5 is popular with its customers is beyond me. They must be polling the large customers maybe, not the hundreds of thousands smaller ones.At my company we had two times now a disk in a RAID 5 broke and the array could not restore itself and had to use backups to continue working on another server. An identical issue with RAID 10, never cause any issues or significant downtime.Is there really ANY reason to go for RAID 5 today? I think not.As for the previously mentioned speed argument...think also about the limited use of a SSD to compensate the use of slower but larger magnetic disks. They are quickly becoming afordable and the performance shatters that of spinning media!

RE: RAID 5 and SQL Server

johnr_johnson — Sun, 09 Jan 2011 16:32:40 GMT

I recently spec'd two new Dell PowerEdge R710 servers for a small data warehouse. One for Analysis Services and the other for SQL Server. The choices for storage were constrained by capacity, performance and direct attach storage disk connections. I ended up choosing RAID 5 for both because I had to meet performance and storage requirements but was limited by 8 DAS connections. The AS system has an 8 x 146GB 15k rpm drive array and the SQL Server system has an 8 x 600GB 10k rpm drive array. Choosing a RAID 10 array could have been accomplished if I were willing to use slower disks to regain the capacity lost due to RAID 10 versus RAID 5. I'm convinced that RAID 10 is the right choice but can't escape practical realities.

RE: RAID 5 and SQL Server

S. Kusen — Sun, 09 Jan 2011 14:43:41 GMT

As you mention, the SAN companies have combated the the issue with larger caches, and to my knowledge, my company solely uses RAID 5 in all SAN arrays. We differentiate tier 1 with tier 2 and tier 3 with the size of cache on the arrays and the RPM's of the disk. We consider our tier 1 to be EMC Symmetrix with 15k disks and the larger write cache. We have XP HP Arrays that have mixed disks.Ultimately, from a DBA team perspective, for better or worse, our SAN configuration is a black hole because there are so many different arrays and brands in play (EMC Sym/ Clariion, NetApp, etc). We haven't seen very many problems with RAID 5 and that is what our SAN admins continually tell us is how they carve up the arrays.They pre-provision the arrays when they are built, so it's difficult for us to even request a RAID 10 LUN from them because they simply "don't do it".Best regards,Steve

RE: RAID 5 and SQL Server

SQL_ME_RICH — Sun, 09 Jan 2011 09:34:26 GMT

I'm going with RAID 5 for Filegroups / .NDF's, and something smaller for the OS and installed instance / .MDF. The .LDF will be on yet another disk that is controlled of the mainboard - probably (most likely some form of EIDE or SATA if available to my spec).This is a great discussion and is giving me cause for thought on going with RAID 10 on the main array if I can manage it this late in the game for my current project.

RE: RAID 5 and SQL Server

Ivan Arjentinski — Sun, 09 Jan 2011 06:18:34 GMT

Depending on the load, I would add also separate disk/array for the tempdb. RAID5 for backups is totally ok, but I think an important question is whether RAID5 is usable for the main DB storage? Perhaps maybe the same question can be asked for the log?!?Another question that pops in my head is whether SSDs will change the game and if yes - how? Perhaps their speed will lead to simpler disk designs?

RE: RAID 5 and SQL Server

Minvalla — Sun, 09 Jan 2011 01:28:11 GMT

I think of the disk design more by raid channels matching purpose and separating loads across them. An oltp system I built for a large indie record label a few years ago had 7 channels:Raid 1 - operating system and apps, main swapfileRaid 10 - Sql dataRaid 10 - Sql IndexRaid 1 - LoggingRaid 5 - Backups to disk- plus 2 for the application data / reports etc both Raid 10Also if specific tables in the database get a hammering they can be partitioned out onto other raid channels.

RE: RAID 5 and SQL Server

Ivan Argentinski — Sun, 09 Jan 2011 00:33:04 GMT

I'm used to using RAID 10 almost always for DB setups. But I think that RAID 5 will gain significance once again when SSD disks begin to be more widely used for DB.There are several reasons to prefer RAID 5 in such setups:- SSDs are generally fast enough, even on writes, to compensate for the parity- SSDs are expensive per GB (currently - around $2/GB for MLC) and having more usable GB is goodCurrently I'm considering how to advice a customer for their new DB server and I'm debating with myself :w00t: whether to advocate for RAID 5 or even 6.It will be most interesting for me to see the opinion of the other members on this.

RE: RAID 5 and SQL Server

Evil Kraig F — Sat, 08 Jan 2011 23:40:32 GMT

The write penalty for RAID 5 is painful, there is little argument there. However, unless you're dealing with incredibly high transactions, the write-cache built into most sans these days alleviates a lot of your pressure.RAID 5 has become more and more viable as different companies have worked out ways to reduce the parity pain. It's also still popular for reporting systems.In general, I'd agree. There's a cost tradeoff for RAID in SANs, and the fact that rarely does a system get a purely dedicated spindleset in a SAN means you're not really working from a hardware optimization standpoint *anyway*.However, when you start dealing with huge systems that you do need hardware optimizations, you're looking at a significant cost. Enterprise Disks aren't cheap, no matter if they're *cheaper*. This isn't cheap. A combination of RAID5 for less transient data and RAID 01 (my preference, a striped series of mirrors, it has more stability) for the high volume data (filegroups are your friend...) is workable. I've seen workarounds from multiple RAID5 setups which where then AGAIN RAID5'd (don't ask) to any other number of ways to try to deal with RAID5 issues.In the end, it's cost vs. throughput. There is a price for everything. SQL Server is a mid-cost product, and thus, a lot of times we end up with mid-cost solutions for all but the largest endeavours. We've learned to cope.

RE: RAID 5 and SQL Server

SQL_ME_RICH — Sat, 08 Jan 2011 18:56:51 GMT

Hi Tony - The timing of this article is both funny, and informative. I am literally in the process right now of finishing up the design of a new database for my company. We went with similar hardware to a previously configuration of theirs (Dell PowerEdge R710). I beefed it out to spec on the 6-drive bay version (wasn't bad given that there wasn't suppose to be a budget for this project). I loaded it with 6-146gb drives, RAID 5 with a 12mb cache controller, and 8gb of RAM (wanted to start with 16, but cut it back due to going with only the 6-bay drive config).Now - I had not even heard of this kind of venomous talk about RAID 5 and Databases before. My background has been in I.T. for over 20 years, and RAID 5 was always a very popular and steady platform, for the most part. I'm only newly born to SQL Server (since about 2004 as more of an application analyst), and this is my first titled role as a DBA, but I have to tell you - I would not have gone above RAID 5 for many reasons (not the least of which is the trade off of disk space and the cost for it), but to know that there was all this disparity (no pun intended) over the manner in which the controller writes to the disk is nearly laughable if not questionable. I have never heard of such things being that bad in the past, but then again - I wasn't big on Oracle! ;-)I'll let you know how my first endeavor goes. It's an OLTP system that is being readied for role out next week!Best wishes to you, and keep the articles coming!Rich YargerSt. Louis Park, MNSQL Server DBA

RAID 5 and SQL Server

Tony Davis — Sat, 08 Jan 2011 11:45:48 GMT

Comments posted to this topic are about the item [B]RAID 5 and SQL Server[/B]