InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comFri, 24 May 2013 17:55:51 GMT20http://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxHi Wesley,Thank you for the info! I understand that it has been a while since you wrote this article but I hope you could answer my questions.My company just bought ioDrive 2.0 and I've been playing with it. You wrote:"... Also, having to convert all my databases from a 512 byte block to a 4KB block is a road block. There is no other way to do this other than copy all the data to a new database that is created on the new 4KB sector size. ..." Does it mean that a simple restore should do the job? The backup is taken on a drive that is formatted with 512 byte sectors. If I format ioDrive 2.0 to 4K sectors and restore the backup on it, it should be just fine, right?Thanks,DenisMon, 08 Oct 2012 12:44:28 GMTDenisThttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxI also have 2 production SQL servers on HP DL385 G7's that run arrays of Intel 160GB drives in RAID 10. I'm using the built-in 410i controller, with 512MB BBWC, and they just fly. Even during maintenance, reporting time, etc, Disks are never more than 5% busy, and IO's complete in less than 1-2ms. I cannot bog them down. I bought consumer drives (but intel, due to good reputation with raid cards), and planned on replacing them as they failed, as the price was about 10% of FusionIO, but I haven't had a single failure of any kind yet. I've been running them hard in production for 2 years, and monitoring the writes to the drives with HP's management tools, and haven't had a single one blink yet.Sometimes it's a heck of a lot cheaper to use multiply redundant cheap drives than enterprise SSD's.Fri, 09 Mar 2012 11:13:01 GMTaaronk-1026045http://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]Wesley Brown (3/9/2012)[/b][hr]...I agree that the article could have a better title. Other than the title, was there anything else wrong with the article?-wes[/quote]I would have to disagree with the statement "Using SQLIO, or any benchmark tool, to get the maximum performance numbers from your system isn't that helpful...". I find using an extensive SQLIO test set, on a variety of IO outstanding values, for a variety of IO block sizes to be very valuable. Note that I recommend 10-20 minute tests of each block size, and I'd also recommend using up as much RAM as possible on the target serverFirst, it gives you an idea of what the maximum performance you can expect in each condition is, and how they relate to each other.Second, it lets you test various configurations (RAID levels, # of drives, stripe size settings, FusionIO options, etc.) and see how they affect each individual IO case. This gives you more information for tuning each particular system.Third, this technique highlights bugs, limitations, edge cases, and oddities in your particular setup. I once saw a system experience an unusually and inexplicably low write rate on certain cases, regardless of the spindle configuration or whether they were solid state or spinning platter drives. More "holistic" techniques would show consolidated numbers, and with those alone you would have a very difficult time figuring out that only one or two specific IO cases have abnormal results.Fri, 09 Mar 2012 08:52:36 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxRay Laubert,If you have multiple log files on a single drive that effectively makes it random I/O and a good candidate for solid state. If, however you have dedicated spindles to a single log drive performance is quite good since it is all sequential I/O.Fri, 09 Mar 2012 07:20:29 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxryabel,When this article was written FusionIO was pretty much the main player in the enterprise space. I have covered several of the topics you are looking for on my blog as well [url=http://sqlserverio.com/2010/06/14/the-fundamentals-of-storage-systems-introduction/]SQLServerIO Fundamentals of Storage Systems[/url].I agree that the article could have a better title. Other than the title, was there anything else wrong with the article?-wesFri, 09 Mar 2012 07:17:50 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxI could see using SSD for log files rather than data storage. I would have also increased the RAM in the systems since SQL is RAM intensive. The combination should give the best performance as well as reducing the total cost.Most of the performance issues I have found are related to poor file distribution, log and data on same drive etc. While data writes don't suffer as much, the TLOG operations do and that really has a negative effect on the performance. Using a fast access drive for TLOGs should really help with the overall performance.Fri, 09 Mar 2012 07:09:43 GMTRay Lauberthttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxIMO this article should be titled: Fusion IO and SQL Server.It is not helpful in regards to the the biggest issues Solid State drives have. I would have liked more details on longevity of the drives, a real test of SLC vs MLC, TRIM support for RAID (sofware OR hardware).Editing the article didn't make it actual. Come on SQLServerCentral / Red Gate, why did this make it to today's mailing?! You guys are better than that.Fri, 09 Mar 2012 06:28:47 GMTDaVinci007http://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxBlast from the past eh?Fri, 09 Mar 2012 03:05:48 GMTRichBhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]brett.hawton (4/9/2010)[/b][hr]Great article!Just some personal observations:1. On larger queries SQL Server [b]read-ahead [/b]kicks in and it reads 512KB blocks at a time. In my observations disks are much better at long sequential reads like this. Yes they still dont get close to matching the performance of SSD's but their performance does improve markedly due to the fact that all modern disks use [i]sector skewing [/i]allowing the head to move (during a sequential read) from one track to the next without incurring any significant latency (the sectors are offset such that the time it takes the head to move 1 track it finds the next sector directly under the head).Brett HawtonIdera Product Architect[/quote]Your statement presumes that data is on disk in a sequential manner. I have never had a client that did anything to be rigorous about making sure their data was sequentially laid out on disk. There are many things that play into this where you can go wrong, everything from file growth increments through SQL Server settings (such as startup flag to allow 2MB allocation size) to data loading methodologies (think Fast Track here) to index maintenance. I would venture to say that less than 5% of all data on SQL Server is sequentially laid out on physical media. Some clients do actually have index maintenance set up (although usually incorrectly), and that is about it. SSDs completely eliminate the need for this...Wed, 14 Apr 2010 09:54:31 GMTTheSQLGuruhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]Paul White NZ (4/11/2010)[/b][hr][quote][b]Wesley Brown (4/9/2010)[/b][hr]If you are using Standard Edition like I am you don't get the full benefit of SQL Servers read-ahead feature.[/quote]Well that is true to some extent - but SQL Server still tries to issue large I/O requests wherever it can, (for scatter/gather as well as sequential operations).For read-ahead, each large read request might be as small as 32 pages (256KB) or as large as 128 pages (1MB) on Standard Edition. Enterprise Edition raises the limit to 1,024 pages (8MB). Read-ahead is used extensively for data and index access - and even on some RID/KEY lookups and loop join operations - look for the WITH (UN)ORDERED PREFETCH iterator tag in the query plan.Many other operations in SQL Server generate large I/O too: log file initialization (512KB), bulk insert (multiples of 128KB), backup (1MB), restore (64KB), DBCC (varies)...I'm not trying to be smart, or contradict you here (far from it) but large I/Os are pretty common in SQL Server, and it would have been nice to see some test results at those sizes, just to give the spinning magnets a fair go :-)Enjoyed the article very much thanks!Paul[/quote]Hey Paul!No, you aren't being "smart" at all! I gave a little one liner and you expounded on that. I agree 100% if you can do sequential reads spinning disks still have a lot to offer. The root of the problem is most people ether don't or can't separate IO patterns on their disks arrays. Moving to SSD's negates some of that handicap. The other part of my short statement was to say not everyone runs Enterprise Edition of SQL Server, I should have been clearer.Thanks again!Sun, 11 Apr 2010 20:25:07 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]Wesley Brown (4/9/2010)[/b][hr]If you are using Standard Edition like I am you don't get the full benefit of SQL Servers read-ahead feature.[/quote]Well that is true to some extent - but SQL Server still tries to issue large I/O requests wherever it can, (for scatter/gather as well as sequential operations).For read-ahead, each large read request might be as small as 32 pages (256KB) or as large as 128 pages (1MB) on Standard Edition. Enterprise Edition raises the limit to 1,024 pages (8MB). Read-ahead is used extensively for data and index access - and even on some RID/KEY lookups and loop join operations - look for the WITH (UN)ORDERED PREFETCH iterator tag in the query plan.Many other operations in SQL Server generate large I/O too: log file initialization (512KB), bulk insert (multiples of 128KB), backup (1MB), restore (64KB), DBCC (varies)...I'm not trying to be smart, or contradict you here (far from it) but large I/Os are pretty common in SQL Server, and it would have been nice to see some test results at those sizes, just to give the spinning magnets a fair go :-)Enjoyed the article very much thanks!PaulSun, 11 Apr 2010 11:20:23 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxHi Wes,Certainly on Idera's SQLSafe backup and restore product we switched to async IO a while back now. We also added (and patented) using a [b]PID Controller [/b](http://en.wikipedia.org/wiki/PID_controller) in our IntelliCompress technology whereby it uses a feedback loop to select precisely the correct compression ratio to be used several times a second during a backup/log offload. What this serves to do is always select [b]precisely the right compression ratio[/b] based on server use, server speed and IO reads and writes. Typically on backup type products, one has to select a fixed compression ratio to be used but each of your servers runs at a different speed and has varying loads during the day (during each instant actually) so [b]whatever fixed compression ratio you select is pretty much always wrong[/b]. Fixed compression ratio's are so pre-recession :)Feedback loops never make this mistake and have proven so superior in balancing out varying opposing factors (such as variable available processor power, effective IO read speed, effective IO write speed) that in a number of applications they have been outlawed due to their superior results (Formula 1 launch control being a particularly good example of its superior results). Brett HawtonIdera Product ArchitectFri, 09 Apr 2010 19:40:53 GMTbrett.hawtonhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]brett.hawton (4/9/2010)[/b][hr]Great article!Just some personal observations:1. On larger queries SQL Server [b]read-ahead [/b]kicks in and it reads 512KB blocks at a time. In my observations disks are much better at long sequential reads like this. Yes they still dont get close to matching the performance of SSD's but their performance does improve markedly due to the fact that all modern disks use [i]sector skewing [/i]allowing the head to move (during a sequential read) from one track to the next without incurring any significant latency (the sectors are offset such that the time it takes the head to move 1 track it finds the next sector directly under the head).2. One of the most critical values to [b]OLTP throughput [/b]is the speed at which [b]log writes can be completed[/b] as typically until they are reported as complete the transaction commit is not reported back to the database/application. The average size of log writes is very much determined by the site. If a site is running small "bank account" type updates then perhaps the average size of the log write could be as small as 512 bytes. Obviously larger transactions will write larger transaction log blocks (in 512 increments). Now the interesting point is that the [b]max log write is is not 64KB[/b] as is written in many articles (but if you use ProcMon you will see [b]61,440 bytes [/b]being written (120X512bytes) as the max size. Some SSD's dont like 61,440 byte sized writes much (some SAN's dont like it much either actually).In testing therefore one should use something like FileMon or ProcMon to check the average size of log writes and use that in testing and then also test the speed of 61,440 byte writes as well as 512KB reads in addition to the "standard" sizes Wes has tested above. Brett HawtonIdera Product Architect[/quote]great reply Brett,If you are using Standard Edition like I am you don't get the full benefit of SQL Servers read-ahead feature. If you are running more than one database per set of disks you don't get the advantage of track-to-track reads ether. If you can configure your disk arrays, isolate IO patterns then you can take advantage of what disk drives do well, long sequential reads. At this point you are at the mercy of the RAID HBA you are using and if it has enough bandwidth to sustain what the disks are putting out. Basically,if your disk configuration isn't optimal swapping to SSD will fix most of it. On the log side, you are right about seeing the 61,440 write but it should still be a sector align write. The log file will be written in increments of sector as small as a single sector and as large as it needs to be. If you sector align your partition it shouldn't be an issue. Lastly, SQLIO won't do a 512 byte test the smallest it will go is 1k, which for log simulation is kind of a bummer. I actually use ProcMon quite a bit to see exactly what is happening underneath the covers. That's where you will see SQL Server using async overlapped IO, which Idera still doesn't do for all its IO operations, you could get a little bit of a bump by doing so, especially multi-threaded to a single backup file.Thanks!WesFri, 09 Apr 2010 18:28:02 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxGreat article!Just some personal observations:1. On larger queries SQL Server [b]read-ahead [/b]kicks in and it reads 512KB blocks at a time. In my observations disks are much better at long sequential reads like this. Yes they still dont get close to matching the performance of SSD's but their performance does improve markedly due to the fact that all modern disks use [i]sector skewing [/i]allowing the head to move (during a sequential read) from one track to the next without incurring any significant latency (the sectors are offset such that the time it takes the head to move 1 track it finds the next sector directly under the head).2. One of the most critical values to [b]OLTP throughput [/b]is the speed at which [b]log writes can be completed[/b] as typically until they are reported as complete the transaction commit is not reported back to the database/application. The average size of log writes is very much determined by the site. If a site is running small "bank account" type updates then perhaps the average size of the log write could be as small as 512 bytes. Obviously larger transactions will write larger transaction log blocks (in 512 increments). Now the interesting point is that the [b]max log write is is not 64KB[/b] as is written in many articles (but if you use ProcMon you will see [b]61,440 bytes [/b]being written (120X512bytes) as the max size. Some SSD's dont like 61,440 byte sized writes much (some SAN's dont like it much either actually).In testing therefore one should use something like FileMon or ProcMon to check the average size of log writes and use that in testing and then also test the speed of 61,440 byte writes as well as 512KB reads in addition to the "standard" sizes Wes has tested above. Brett HawtonIdera Product ArchitectFri, 09 Apr 2010 17:20:11 GMTbrett.hawtonhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]magarity kerns (4/8/2010)[/b][hr]Has anyone here tried SQL Server on something like the ram drives from Texas Memory Systems? They aren't persistent when the machine is off like SSD's but they're supposed to be even faster.[/quote]Hi magarity, YES I have..! read all about it on my blog! once you have worked with them... ;-)[url=www.henkvandervalk.com ]www.henkvandervalk.com [/url]Fri, 09 Apr 2010 11:32:44 GMTH. vandervalkhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxGet a quote for 5TB on the dsi3600 or a comparable TSM RAM-SAN. 8 Fusion-IO 640 Duo's get you 5.1TB of raw space. will retail at 124k. another 10k for chassis if you need them will get you 5~ GB/Sec throughput and 800k~ IO/sec. I doubt TSM or DSI can touch that for the price.Fri, 09 Apr 2010 10:46:21 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxreply to ian-707364:"A solid state SAN won't come close - maximum bandwidth per slot is 4Gbps (500MB/s). Plus you have the added latency from the fabric switches, etc. But the real SAN-SSD killer is cost - it's too prohibitive for a dedicated IO subsystem. " Ian, this isn't true.. per DSI or RAMSAN unit you can connect up to 8 fibers to each ! == 250000 random 8 KB IOs (actually mine delivers to 257000 ...) and 3100MByte/sec on 64 KB Random IOs... What's in a number :-)Fri, 09 Apr 2010 10:31:11 GMTH. vandervalkhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxBesides these entry level plug-in SSD cards, for IO demanding SQL Production environments I would recommend products like the DSI3600 units; (http://www.dynamicsolutions.com/dsi3600)- Up to 5TB storage capacity, - 3Gigabyte/sec bandwidth and up to 250.000 IOPS each! You can connect them to regular 4Gbit HBA ports with up to 8 fibers each using the Windows MPIO for multipath if you want. I blogged on the test results of this high End SQL SSD device already some months ago : http://henkvandervalk.com/dsi-3500-ramsan-500-solid-state-storage-to-the-testand what's even more fun... how to increase SQL bulk Insert speed, SQL table scan speed & SQL backup speed ! Regards,HenkFri, 09 Apr 2010 10:28:44 GMTH. vandervalkhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxHi Kim, free performance tip: long time ago I discovered that when you FORMAT your -In Memory- RAMDRIVE to 64 KB NTFS instead of using the default 4KB blocksize (run chkdsk to check!) before placing tempdb on it, the throughput triples ;-)Fri, 09 Apr 2010 10:14:21 GMTH. vandervalkhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]ian-707364 (4/9/2010)[/b][hr]This is the reply I received from my contact at Fusion IO[i]"The sector size can be changed between 512(default) and 4k (4096) (not 8k). I think this is only supported in Win 2008 as when I tried it in 2003 Windows would not recognise the drives.It is currently a registry change and a manual low level format however in the next driver version it is going to be part of the standard GUI. Formatting to 4096 is better for SQL. However some application still cannot work with the larger sizes.This also means the file system format has to be at least 4k however you could formation to 8,16,32 or 64k. The low level format at 4k is mainly beneficial for memory usage and may give some performance gains but it would be configuration dependant."[/i][/quote]In the 1.2.7 driver there is a registry setting to change the sector size. In the 2.0 driver it is in the GUI. Last time I looked you could go to 8k but NTFS and windows doesn't support it. Some Linux file systems do though. The registry change is just to cut down on memory usage by forcing a larger minimum write size.Fri, 09 Apr 2010 07:43:48 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxThis is the reply I received from my contact at Fusion IO[i]"The sector size can be changed between 512(default) and 4k (4096) (not 8k). I think this is only supported in Win 2008 as when I tried it in 2003 Windows would not recognise the drives.It is currently a registry change and a manual low level format however in the next driver version it is going to be part of the standard GUI. Formatting to 4096 is better for SQL. However some application still cannot work with the larger sizes.This also means the file system format has to be at least 4k however you could formation to 8,16,32 or 64k. The low level format at 4k is mainly beneficial for memory usage and may give some performance gains but it would be configuration dependant."[/i]Fri, 09 Apr 2010 01:22:00 GMTiposnerhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxpersonally if I was going to do it again, I would get ocz summit 128gb drives times 5 and do a raid 5. Don't forget how important a good raid controller. The ocz summits have 128mb cache and built in gc. I have found it to be reliable in my desktop and performance always stays up. With 500gb over 5 drives I'd be happy. I think the speed of the ssds combined with a smart raid controller make raid 5 a great option for databases that are even write heavy. If you only let the cache be used for writes, you should keep quite a bit of throughput while maximizing your investment in the ssds.Thu, 08 Apr 2010 22:31:20 GMTnewjcbhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote]With the INTEL drives did you have the same memory overhead as what is described by Wes in this article?I'm trying to determine the scope of this additional memory requirement. In otherwords is it an issue for all SSD's or is it for only SSD's using a PCI configuration or is it only specific to the Fusion DUO card.[/quote]No you won't. The memory issue is specific to the Fusion-IO.Thu, 08 Apr 2010 22:03:02 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]Kevin Martin (4/8/2010)[/b][hr]Nicely done, Wes! Quite informative.Kevin Martin[/quote]Thanks Kevin!Thu, 08 Apr 2010 22:01:21 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]newjcb (4/8/2010)[/b][hr]I actually use 4 Intel 160GB X25M in a Raid 10 for our production Sql Server. They simply fly. I haven't seen a wait time on a read or write greater than 2ms. I wanted to just Raid0, but I couldn't bring myself to do this on a Production server. To decide a replacement schedule for the SSDs I:Amount of space I could use (space): 320GB (4x160GB / 2 for Mirror)Average amount of writes per day (writeRate): 32GB writes/DayAverage life expectancy of an MLC chip (life): 1000 writes ( I like to be conservative, other documentation shows 10,000 writes)To figure out how long they will last: (life x space) / writeRateThis means ( 1,000 x 320GB ) / 32GB = 10,000 days or about 27 yearsHowever, since technology is always changing, I plan on replacing one drive every 9 Months. The next drives I get will have Garbage Collection like the Vertex or Summit Series. Trim is not Raid Supported, and after about half a year, my drives are going to start to slow down when writing because Intel doesn't go and clean up deleted sectors until they need to be written again which causes a 3x penalty on writes.[/quote]With the INTEL drives did you have the same memory overhead as what is described by Wes in this article?I'm trying to determine the scope of this additional memory requirement. In otherwords is it an issue for all SSD's or is it for only SSD's using a PCI configuration or is it only specific to the Fusion DUO card.Thu, 08 Apr 2010 19:41:49 GMTgspraguehttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxNicely done, Wes! Quite informative.Kevin MartinThu, 08 Apr 2010 19:14:26 GMTKevin Martinhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxI actually use 4 Intel 160GB X25M in a Raid 10 for our production Sql Server. They simply fly. I haven't seen a wait time on a read or write greater than 2ms. I wanted to just Raid0, but I couldn't bring myself to do this on a Production server. To decide a replacement schedule for the SSDs I:Amount of space I could use (space): 320GB (4x160GB / 2 for Mirror)Average amount of writes per day (writeRate): 32GB writes/DayAverage life expectancy of an MLC chip (life): 1000 writes ( I like to be conservative, other documentation shows 10,000 writes)To figure out how long they will last: (life x space) / writeRateThis means ( 1,000 x 320GB ) / 32GB = 10,000 days or about 27 yearsHowever, since technology is always changing, I plan on replacing one drive every 9 Months. The next drives I get will have Garbage Collection like the Vertex or Summit Series. Trim is not Raid Supported, and after about half a year, my drives are going to start to slow down when writing because Intel doesn't go and clean up deleted sectors until they need to be written again which causes a 3x penalty on writes.Thu, 08 Apr 2010 16:32:42 GMTnewjcbhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxHas anyone tested the INTEL X-25M SATA 160G 2.5" Internal SSD drives with SQL Server?Thu, 08 Apr 2010 14:36:08 GMTgspraguehttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]johnzabroski (4/8/2010)[/b][hr]Just to be clear, does that mean you will post a benchmark confirming the 10x increase reported by the vendor? I can understand if the vendor has license restrictions on the beta driver prohibiting benchmarking during the beta testing period, and what not... I just want a clear description of the exact status of this order of magnitude performance increase.[/quote]I will be posting a follow up. This is a 10x decrease in memory usage not in speed up. When we get closer to the RTM I'm sure Fusion-IO will be fine with me updating the article to reflect the new firmware/driver changes.Thu, 08 Apr 2010 13:03:53 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxJust to be clear, does that mean you will post a benchmark confirming the 10x increase reported by the vendor? I can understand if the vendor has license restrictions on the beta driver prohibiting benchmarking during the beta testing period, and what not... I just want a clear description of the exact status of this order of magnitude performance increase.Thu, 08 Apr 2010 13:00:55 GMTjohnzabroskihttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]johnzabroski (4/8/2010)[/b][hr][quote]That strategy is working out well and giving us some head room to plan for our next round of servers where we can properly plan and size them with Fusion-IO in mind. Also, they have also announced an updated driver 1.3 that is due out soon. It reduces the memory consumption by as much as 10 fold over the current driver. With that and a 4KB block size memory pressure should be a thing of the past for them.[/quote]What is your source for "it reduces the memory consumption by as much as 10 fold over the current driver"? Are you trusting the vendor to deliver? Or have you beta-tested the driver to confirm their statements are true?[/quote]I'm currently testing a beta version now.Thu, 08 Apr 2010 12:57:36 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote]That strategy is working out well and giving us some head room to plan for our next round of servers where we can properly plan and size them with Fusion-IO in mind. Also, they have also announced an updated driver 1.3 that is due out soon. It reduces the memory consumption by as much as 10 fold over the current driver. With that and a 4KB block size memory pressure should be a thing of the past for them.[/quote]What is your source for "it reduces the memory consumption by as much as 10 fold over the current driver"? Are you trusting the vendor to deliver? Or have you beta-tested the driver to confirm their statements are true?Thu, 08 Apr 2010 12:55:07 GMTjohnzabroskihttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxNice article. Thanks for sharing.Thu, 08 Apr 2010 11:07:52 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]magarity kerns (4/8/2010)[/b][hr]Has anyone here tried SQL Server on something like the ram drives from Texas Memory Systems? They aren't persistent when the machine is off like SSD's but they're supposed to be even faster.[/quote]Yep. They are crazy fast with huge IO numbers 400k or more random IO's a second. They are persisted to internal disks when the TSM disk is off and have battery backups built into the unit. They are also crazy expensive. TSM also has a PCIe card out but I've never seen it or read any real reviews on it.Thu, 08 Apr 2010 09:54:28 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]ian-707364 (4/8/2010)[/b][hr]I've sent an email to my contact at Fusion IO - hopefully we'll get some definitive answers on sector size in relation to their cards[/quote]The definitive answer is 512 bytes to 8096 bytes user configurable in the 2.0 driver which isn't out yet. MLC native is 4k. Windows supports up to a 4096 sector. http://support.microsoft.com/kb/926930 for SQL Server supported sector sizes.Thu, 08 Apr 2010 09:51:34 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxHas anyone here tried SQL Server on something like the ram drives from Texas Memory Systems? They aren't persistent when the machine is off like SSD's but they're supposed to be even faster.Thu, 08 Apr 2010 09:50:20 GMTmagarity kernshttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxI've sent an email to my contact at Fusion IO - hopefully we'll get some definitive answers on sector size in relation to their cardsThu, 08 Apr 2010 09:33:21 GMTiposnerhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxthxthe reason i've used dynamic disks for SQL is to expand the array. every year larger hard drives come out and instead of buying a new MSA70, you can just buy larger hard drives, replace them one by one or add to an existing array if you have empty bays and then expand the logical drive. On Windows you would need to create a new drive, or if you have a dynamic disk you can just expand the existing volumeThu, 08 Apr 2010 09:20:16 GMTalen teplitskyhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspx[quote][b]ian-707364 (4/8/2010)[/b][hr]I was talking about the cluster size for formatting. However, as I understand it, currently most drives physical cluster size are 512 bytes with some new drives at 4096 supported in the latest version of Windows.Surely the Fusion IO cluster size refers to the raw IO block size to be written to SSD as an atomic unit? For SQL Server this should be 8192. Or am I missing something?[/quote]Drives have sectors, file system have clusters. So, most drives have a 512 byte sector. Newer drives, some SAN's and the Fusion-IO have a 4096 byte sector option. That is the smallest unit that can be written to the drive. If you have a small file say 1024 bytes it will still take up a 4096 byte sector or two 512 byte sectors depending on the sector size. You are confusing sectors with file system cluster sizes. This has nothing to do with atomic writes to disk though. SQL Server can do a write as small as a sector or as large as the whole disk if need be. Atomic writes are handled by the OS and SQL Server.Alen,GPT partitions are aligned via offsets If you want to align a GPT disk you need to start at an offset of 129MB the GPT disk will automatically round to the nearest sector and don't support the align= for that reason. There are some structures that come with GPT that use the 129MB you reserved in the offset space. Thu, 08 Apr 2010 09:01:11 GMTWesley Brownhttp://www.sqlservercentral.com/Forums/Topic899232-195-1.aspxFirstly, as an aside, you don't have to worry about the offset with Windows Server 2008 and Windows 7 onwards - basic disks on these versions default to a 1MB offset, so unless your stripe size is bigger than 1MB, there'll be no problem.Coming back to diskpart in previous versions, neither GPT nor Dynamic disks support the "ALIGN =" for custom offsets. That's why you should use Basic disks for SQL Server Data/Logs/BackupThu, 08 Apr 2010 08:56:15 GMTiposner