InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 22 May 2013 06:15:45 GMT20http://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxNice article.Mon, 24 Dec 2012 11:54:23 GMTNeha05http://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxthis article is just being republished.....sounds like I need to update it and publish again....amazing what you learn from others eh?GAJSat, 24 Nov 2012 17:22:45 GMTGregoryAJacksonhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxRaid 1+0 and 0+1 isn't even identical in performance, 1+0 performs better when the array is degraded.Sat, 24 Nov 2012 08:51:55 GMTokbangashttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]Perry Whittle (11/24/2012)[/b][hr]The differences between RAID 1+0 and 0+1 are [u][b]not[/b][/u] academic. Let's just review that again, [u][b]not[/b][/u] 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 ;-)[/quote]+1Sat, 24 Nov 2012 08:43:29 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxThe differences between RAID 1+0 and 0+1 are [u][b]not[/b][/u] academic. Let's just review that again, [u][b]not[/b][/u] 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 ;-)Sat, 24 Nov 2012 03:09:59 GMTPerry Whittlehttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxT.C.I'm not sure I understand your question completely.....care to rephrase or expand?GAJFri, 23 Nov 2012 17:11:55 GMTGregoryAJacksonhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]btd (5/1/2012)[/b][hr]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.........[/quote]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 [i][b]relatively[/b][/i] 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.Fri, 23 Nov 2012 13:19:23 GMTRay Herringhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxIt 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.Thu, 22 Nov 2012 23:51:54 GMTokbangashttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxExcellent info....thanksGAJThu, 22 Nov 2012 18:42:49 GMTGregoryAJacksonhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxGood article and some excellent commentsNot much in here on RAID 50, which is rapidly becoming one of my favourite RAID levels for Data and BackupsLogs 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.Thu, 22 Nov 2012 16:04:50 GMTToby Harmanhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxGreat Article - very helpful. Especially calculating the IOPS.Thu, 22 Nov 2012 08:20:32 GMTBrian Souderhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]Steve Jones - SSC Editor (5/1/2012)[/b][hr][quote][b]yazalpizar_ (5/1/2012)[/b][hr]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.[/quote]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: [url]http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html[/url][/quote]:-D 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... :sick: need to work harder on itThu, 22 Nov 2012 02:57:35 GMTyazalpizar_http://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxI'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? :ermm:Thu, 22 Nov 2012 02:01:05 GMTpaul.knibbshttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]sqlquery-101401 (5/7/2012)[/b][hr]Thanks , Yes i have couple of servers on SAN , what other utilities you refer?[/quote]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.GAJMon, 07 May 2012 10:46:09 GMTGregoryAJacksonhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxThanks , Yes i have couple of servers on SAN , what other utilities you refer?Mon, 07 May 2012 10:33:46 GMTsqlquery-101401http://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]sqlquery-101401 (5/7/2012)[/b][hr]what is the best way to get the production IOPs requirement , we have ETL that runs for an hour and trying to get new H/w , what is the best way to know the IOPs requirement with current production load, will disk transfer/s will suffice or any better way?[/quote]that is what I used.If your in a SAN\NAS environment there will be additional utilities that capture this info as well.GAJMon, 07 May 2012 10:13:51 GMTGregoryAJacksonhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxwhat is the best way to get the production IOPs requirement , we have ETL that runs for an hour and trying to get new H/w , what is the best way to know the IOPs requirement with current production load, will disk transfer/s will suffice or any better way?Mon, 07 May 2012 10:07:25 GMTsqlquery-101401http://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]GregoryAJackson (5/4/2012)[/b][hr]Typically the RAID Controller will have an administrative software application or control panel.[/quote]Ultimately it's the BIOS on the RAID controller that handles the array(s), for vendor specific you may have a management interface without rebooting and entering the BIOSSat, 05 May 2012 01:15:28 GMTPerry Whittlehttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxTypically the RAID Controller will have an administrative software application or control panel.this is where you can see the RAID config settings and make modifications if necessaryGAJFri, 04 May 2012 19:26:20 GMTGregoryAJacksonhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxHow can i check my disks RAID status? I mean , how can i become confirm that my disks are on RAID 10?Fri, 04 May 2012 06:26:39 GMTjahid786http://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]GregoryAJackson (5/2/2012)[/b][hr]Hi do you think it would be a big performance loss to store tempDB data and Logs on the same Raid?in our BI(OLAP) enviroment , we use1. RAID 10 for Data1 and Log22. RAID 10 for Data2 and Log13. RAID 10 for TempDB Data and LogsYou will benefit from seperating TempDB and Logs.Budget is always an issue so you gotta pick your battles. But in a perfect World, Id absolutely seperate them.GAJ[/quote]HiJust to be sure you get me right:3rd RAID ist only for TempDB Logs.This RAID is build of 10x 15k 600GB 3,5" Hdds.Would you go with this config, or would you recommend to build 2 Raids out of the 10 available HDDs?Thu, 03 May 2012 02:52:53 GMTmrpellepellehttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]rbarbati (5/2/2012)[/b][hr]This is a nice article, but possibly a bit dated and not really considering higher-end enterprise-scale subsystems that are available and more common these days, where RAID is not only obsolete, but not even a configuration option on the subsystem. Higher end arrays are now 'wide-striping' (as one term) across the entire array and are managed by the subsystem HW/FW/SW itself. Configuration is limited more to logical units and volumes. So although the discussion is valid for a more traditional physical server, I beleive more consideration needs to be placed on newer generation virtual compute modules with high-end disk subsystems. Also when reaching multi-terabyte/pedabyte scales, spindle counts are not much of a factor really either, each spindle possibly (typically) being a terabyte drive in itself. These systems are tuned and configured so differently than, say a local disk array, that I feel it warrants mention.[/quote]I suspect one of us needs to study "wide striping" in greater depth. As far as I'm aware based on a cursory inspection of the literature, "wide striping" is commonly using the very normal, standard RAID levels this article and discussion references, but with more drives. I.e. instead of a minimum 2+1 RAID 5 array, or even a normal 4+1 or 5+1 RAID 5 array, it's implementing an N+1 array, where N is "large". It's got all the normal features of a RAID 5 with many disks in the set; it averages out performance, it's got the write penalty, and it is resilient to only 1 drive failure at a time. When you put multiple workloads on the array, you get all the same features: when both Workload A and Workload B run at the same time, they compete for resources (and if everyone runs really big, long operations the first day of the quarter, perhaps they all take a lot longer), but when only one workload is active, it gets all the performance.Reference: [url=http://www.storagerap.com/2010/03/calculating-the-output-of-wide-striping.html]http://www.storagerap.com/2010/03/calculating-the-output-of-wide-striping.html[/url]Reference: [url=http://gestaltit.com/all/tech/storage/chris/enterprise-computing-the-wide-striping-debate/]http://gestaltit.com/all/tech/storage/chris/enterprise-computing-the-wide-striping-debate/[/url]Wed, 02 May 2012 14:05:19 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxThis is a nice article, but possibly a bit dated and not really considering higher-end enterprise-scale subsystems that are available and more common these days, where RAID is not only obsolete, but not even a configuration option on the subsystem. Higher end arrays are now 'wide-striping' (as one term) across the entire array and are managed by the subsystem HW/FW/SW itself. Configuration is limited more to logical units and volumes. So although the discussion is valid for a more traditional physical server, I beleive more consideration needs to be placed on newer generation virtual compute modules with high-end disk subsystems. Also when reaching multi-terabyte/pedabyte scales, spindle counts are not much of a factor really either, each spindle possibly (typically) being a terabyte drive in itself. These systems are tuned and configured so differently than, say a local disk array, that I feel it warrants mention.I'm finding many of the articles I recieve from SSCC are not considering true enterprise and large scale systems, focusing more on simpler stand-alone systems and may be misleading to newer adminstrators who might be working in enterprise level environements.I'd love to start seeing more write-ups targeting higher profile systems, as that is where the leading edge of technology lives and where the real sticky intracacies tart getting interesting.The RAID topics are great above, dont get me wrong, but it's just reminiscent of a era past.But that's just one humble adminstrators opinion of course... it's always good to see folks writing and sharing knowledge of any kind, so keep up the work !Wed, 02 May 2012 13:03:24 GMTrbarbatihttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]tony.turner (5/2/2012)[/b][hr]Sounds suspiciously like your hosting company has been listening to their EMC salesperson. EMC apparently is strongly in favour of RAID 5 for SSD, thus the loss of a single disk in the array. The EMC claim is that RAID 5 on SSD has a minimal write latency effect. Not convinced from measurements in practice[/quote]My own tests of locally attached 6 drive (enterprise) SATA SSD's vs. 10 drive 15k FC SAN disks shows that the 6 disk local SATA RAID 5 is always faster; even for 8KB random writes the 6 SSD RAID 5 is near triple the performance of the 10 disk RAID 10, though for 64KB random writes it's only about a third better. For most other categories the SSD RAID 5 is very much faster, though I was limited to 4Gbps throughput on the SAN in my tests, which is an artificial throughput ceiling.SQLIO, at least, also shows average and max latencies to be much better for the local SSD's than for the SAN.Wed, 02 May 2012 10:37:00 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxHi do you think it would be a big performance loss to store tempDB data and Logs on the same Raid?in our BI(OLAP) enviroment , we use1. RAID 10 for Data1 and Log22. RAID 10 for Data2 and Log13. RAID 10 for TempDB Data and LogsYou will benefit from seperating TempDB and Logs.Budget is always an issue so you gotta pick your battles. But in a perfect World, Id absolutely seperate them.GAJWed, 02 May 2012 10:31:01 GMTGregoryAJacksonhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]Cois (5/2/2012)[/b][hr]I would store it on the logs RAID.[/quote]Hi do you think it would be a big performance loss to store tempDB data and Logs on the same Raid?in our BI(OLAP) enviroment , we use1. RAID 10 for Data1 and Log22. RAID 10 for Data2 and Log13. RAID 10 for TempDB Data and LogsWed, 02 May 2012 09:58:52 GMTmrpellepellehttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]piotrka (5/2/2012)[/b][hr]Thanks Nadrek for your response. It was my understanding that RAID 10 is superior over RAID 5 on writes. However; using the same number of hard drives, RAID 5 has an advantage over RAID 10 on random reads.[/quote]Please see my post on the first page, with the table. Read that carefully, though you can focus only on one set of IOs Outstanding (perhaps 8 or 16).On my particular setup, RAID10 appears to have an advantage over RAID5 and RAID50 only on 8KB and 64KB random writes. Note that RAID10 does not retain that advantage on sequential writes, however, and has no other advantages except for the possibility of losing more drives... if they're all on the same side of the array. Murphy's law says they won't be as often as you want them to be, so I don't find that to be a telling argument, personally - RAID50 can lose one drive on each RAID5 set also, and RAID6 can lose any two drives.Wed, 02 May 2012 09:51:35 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxThanks Nadrek for your response. It was my understanding that RAID 10 is superior over RAID 5 on writes. However; using the same number of hard drives, RAID 5 has an advantage over RAID 10 on random reads.Wed, 02 May 2012 09:43:10 GMTpiotrkahttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]tony.turner (5/2/2012)[/b][hr]Sounds suspiciously like your hosting company has been listening to their EMC salesperson. EMC apparently is strongly in favour of RAID 5 for SSD, thus the loss of a single disk in the array. The EMC claim is that RAID 5 on SSD has a minimal write latency effect. Not convinced from measurements in practice[/quote]Actually, if you're running enough disks, at least on spindle drives EMC's RAID 50 implementation can have significantly better performance than their RAID 5; look for the 15000 RPM drives in the table in my post above.Wed, 02 May 2012 08:41:29 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]piotrka (5/1/2012)[/b][hr]Gregory, great articleBut I have a question about read performance for RAID 5 and RAID 10. In your table you showed that RAID 5 scores Good and RAID 10 scores Excellent for read. On the other hand, Kendal Van Dyke in his tests http://www.kendalvandyke.com/2009/02/disk-performance-hands-on-part-5-raid.html, shows that RAID 5 always outperforms RAID 10. I know that Kendal’s article is 3 years old but could you please tell me why you score RAID 10 higher than RAID 5 on read performance?[/quote]If you look at my table of actual test results above, you'll note that on my test setup (running on an EMC SAN for the spindles, with each test run 10 times as long, and using up a larger portion of available disk capacity, but running less files at a time) RAID 10 has a significant advantage for both 8KB and 64KB random writes (the only random writes tested), and is either similar or worse performance in every other category.Note that there can be differences in how RAID 10's are implemented; it's technically possible for a RAID 10 array (or a RAID 1) to read data from both halves of the mirror set at once, which can affect performance.Wed, 02 May 2012 08:38:55 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]gert.j.kruger (5/2/2012)[/b][hr]For SSD Raid 1+0 configuration I have been advised by our hosting company that the total storage space is different than for traditional drives. My understanding is that storage space on "traditional" Raid 1+0 would be half the total size of the disks in the array (ie there are 6 x 150GB disks in the array, the total storage space is 3 x 150GB = 450GB). However, I have been advised that on SSD one "loses" only one of the drives (ie if there are 6 x 150GB disks in the array, the total storage capacity would be 5 x 150GB = 750 GB). Is this correct, and if so, why is it different?[/quote]That can't be correct for a given raid level. Perhaps they are assuming that the performance and extra space reserved inside an SSD means they can run RAID 5 instead?Wed, 02 May 2012 08:16:57 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]Steve Jones - SSC Editor (5/1/2012)[/b][hr][quote][b]jfogel (5/1/2012)[/b][hr]I don't see ever getting on board with having a production database running on a VM. Of course, things change but I cringe at the thought of this.[/quote]You're missing out. Modern hypervisors have a tiny percentage of penalty. Even a 1vm/1physical machine makes sense in many cases, especially for DR.There are lots of SQL Servers in most environments that run fine on VMs. Not necessarily the most loaded, but any that are averaging < 50% CPU with rare peaks, should be virtualized. The SQLServerCentral servers (clustered) are both virtualized. I have friends at various companies, including a large media company with the vast majority of their SQL Servers on VMs. There are a few heavily used ones on physical hosts, but it's rare.[/quote]In addition to low CPU, be very careful to compare the disk and RAID configurations between the original host and the VM, and ask about current VM disk sharing and future VM disk sharing. Also check with the VM expert about reserved CPU capacity, reserved IO capacity if on shared physical disks, dedicated NICs vs. shared NICs, and very importantly, reserved memory vs. memory ballooning.It sounds like a lot, but the bottom line is that some VM's are more equal than others; if you want more predictable performance, particularly peak performance, then it needs to be planned for. When this is done, we've also had very good results virtualizing our smaller database instances.Wed, 02 May 2012 08:16:15 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]gert.j.kruger (5/2/2012)[/b][hr]For SSD Raid 1+0 configuration I have been advised by our hosting company that the total storage space is different than for traditional drives. My understanding is that storage space on "traditional" Raid 1+0 would be half the total size of the disks in the array (ie there are 6 x 150GB disks in the array, the total storage space is 3 x 150GB = 450GB). However, I have been advised that on SSD one "loses" only one of the drives (ie if there are 6 x 150GB disks in the array, the total storage capacity would be 5 x 150GB = 750 GB). Is this correct, and if so, why is it different?[/quote]SSD's have zero capacity calculation differences for each RAID level. Their differences lie solely in sequential performance (better), random performance (much better), cost (much higher per bay, much higher per GB, not so much higher per performance, with a much higher performance ceiling in a given physical enclosure), and capacity (much lower maximum capacity).What your "hosting company" is almost certainly doing is comparing a spindle drive RAID 10 against an SSD RAID 5.Wed, 02 May 2012 08:11:16 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspx[quote][b]gert.j.kruger (5/2/2012)[/b][hr]However, I have been advised that on SSD one "loses" only one of the drives (ie if there are 6 x 150GB disks in the array, the total storage capacity would be 5 x 150GB = 750 GB). Is this correct, and if so, why is it different?[/quote]Sounds suspiciously like your hosting company has been listening to their EMC salesperson. EMC apparently is strongly in favour of RAID 5 for SSD, thus the loss of a single disk in the array. The EMC claim is that RAID 5 on SSD has a minimal write latency effect. Not convinced from measurements in practiceThere are SAN configuration "restrictions" that make it complex or inefficient to configure some of the logical volumes as RAID 5, some as RAID 10For the record, I have successfully run the standard Windows Logical Volume Manager (LVM) to implement striped volumes (RAID 0), mirrored volumes (RAID 1), striped with parity (RAID 5), and spanned volumes over SSDs. Using UEFI boot it is quite feasible to implement booting off a logically mirrored pair of PCIe-attached SSDsWed, 02 May 2012 08:07:33 GMTtony.turnerhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxHere's a good article that explains the fault tolerance difference between RAID10 and RAID01 - as also mentioned by another reader. http://www.thegeekstuff.com/2011/10/raid10-vs-raid01/Wed, 02 May 2012 07:40:48 GMTbruce.kulighttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxgert, That sounds wrong, I doubt SSD's would be treat any differently to traditional drives when putting them in a raid array. If im wrong I'd love to know why SSD's are different.Wed, 02 May 2012 07:23:11 GMTJason-299789http://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxFor SSD Raid 1+0 configuration I have been advised by our hosting company that the total storage space is different than for traditional drives. My understanding is that storage space on "traditional" Raid 1+0 would be half the total size of the disks in the array (ie there are 6 x 150GB disks in the array, the total storage space is 3 x 150GB = 450GB). However, I have been advised that on SSD one "loses" only one of the drives (ie if there are 6 x 150GB disks in the array, the total storage capacity would be 5 x 150GB = 750 GB). Is this correct, and if so, why is it different?Wed, 02 May 2012 05:29:32 GMTgert.j.krugerhttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxVery useful information, and working and OLAP Db's I've often considered read performance to be of higher importance than write performance.The reason for this is that you are generally write loading the disks out of standard operating hours when infrastrucutre is relatively unused, so the consideration of disk writes is a a lower priority. Conseqently I generally like to set up data/index drives to be Raid 5, with system Db's and Logs on raid Raid 1+0.I wondered if this thinking was still relevant in regards to the article, or do I need to consider a complete rethink.Wed, 02 May 2012 02:52:06 GMTJason-299789http://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxIf your lazy write can clear the write buffer quick enough to make space for new incomming write requests, then that would be fine. But if new write requests come in at a rate that is faster than the lazy writer can clear the write buffer, then you will be in trouble. So if you have a high volume or large write request queue you would require a higher performance write.Wed, 02 May 2012 02:52:06 GMTCoishttp://www.sqlservercentral.com/Forums/Topic1292935-143-1.aspxI understand the concept of requiring fast write response for SQL log writes. However, what is the performance case for fast data writes; provided you have enough buffers does the lazy writer really require fast writes? Also, what is the performance case for fast backup writes, provided you can finish a backup before you need to start the next one?Wed, 02 May 2012 02:45:47 GMTtony.turner