<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: SQL SERVER &#8211; NTFS File System Performance for SQL Server</title>
	<atom:link href="http://blog.sqlauthority.com/2012/07/06/sql-server-ntfs-file-system-performance-for-sql-server/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.sqlauthority.com/2012/07/06/sql-server-ntfs-file-system-performance-for-sql-server/</link>
	<description>Personal Notes of Pinal Dave</description>
	<lastBuildDate>Sat, 25 May 2013 01:31:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Ayman El-Ghazali</title>
		<link>http://blog.sqlauthority.com/2012/07/06/sql-server-ntfs-file-system-performance-for-sql-server/#comment-310452</link>
		<dc:creator><![CDATA[Ayman El-Ghazali]]></dc:creator>
		<pubDate>Sat, 07 Jul 2012 02:49:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.sqlauthority.com/?p=19707#comment-310452</guid>
		<description><![CDATA[SSDs work best with Random seeks not sequential. Since database reads are random, then it would probably improve performance; plus SSDs are generally faster than regular magnetic disk.  For Log files, that is a hard question to answer.  SSDs are faster, but log files are sequential and so are regular HDD. I can&#039;t provide any data to say which would be better in that case.

One thing to keep in mind with SSDs is that when they fail, your data is GONE! There is no recovery like there is with Magnetic disk.  So make sure you use some sort of RAID architecture with SSD;RAID 5 or 6 would be pretty good since it is more affordable for drives which cost a fortune. 

I would disagree a bit with the 15% empty space on the drive that you mentioned.  It depends on the disk size; 15% of 1TB is different than 15% of 100GB. Larger drives can be a little slower, but they tend to keep data closer to the inner part of the disk platter which could improve performance.  The reason for that is that there is high density of space on the drive, so the inner part of a 1TB drive could potentially hold the entire 80GB DBs.  However, on a smaller drive it would be distributed further across the platter so the head would have to move a lot more for read seeks. 

It definitely needs a bit more research.]]></description>
		<content:encoded><![CDATA[<p>SSDs work best with Random seeks not sequential. Since database reads are random, then it would probably improve performance; plus SSDs are generally faster than regular magnetic disk.  For Log files, that is a hard question to answer.  SSDs are faster, but log files are sequential and so are regular HDD. I can&#8217;t provide any data to say which would be better in that case.</p>
<p>One thing to keep in mind with SSDs is that when they fail, your data is GONE! There is no recovery like there is with Magnetic disk.  So make sure you use some sort of RAID architecture with SSD;RAID 5 or 6 would be pretty good since it is more affordable for drives which cost a fortune. </p>
<p>I would disagree a bit with the 15% empty space on the drive that you mentioned.  It depends on the disk size; 15% of 1TB is different than 15% of 100GB. Larger drives can be a little slower, but they tend to keep data closer to the inner part of the disk platter which could improve performance.  The reason for that is that there is high density of space on the drive, so the inner part of a 1TB drive could potentially hold the entire 80GB DBs.  However, on a smaller drive it would be distributed further across the platter so the head would have to move a lot more for read seeks. </p>
<p>It definitely needs a bit more research.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Luiz Mercante</title>
		<link>http://blog.sqlauthority.com/2012/07/06/sql-server-ntfs-file-system-performance-for-sql-server/#comment-310351</link>
		<dc:creator><![CDATA[Luiz Mercante]]></dc:creator>
		<pubDate>Fri, 06 Jul 2012 21:32:21 +0000</pubDate>
		<guid isPermaLink="false">http://blog.sqlauthority.com/?p=19707#comment-310351</guid>
		<description><![CDATA[Really interesting article. I would like to understand, if data files are huge even using 8KB pages, i think it is util use 64KB blocks because it reduces the quantity of pointers in partition index and fragmentation in disk level. If anybody have considerations about that, i really apreciate.]]></description>
		<content:encoded><![CDATA[<p>Really interesting article. I would like to understand, if data files are huge even using 8KB pages, i think it is util use 64KB blocks because it reduces the quantity of pointers in partition index and fragmentation in disk level. If anybody have considerations about that, i really apreciate.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Terrapin</title>
		<link>http://blog.sqlauthority.com/2012/07/06/sql-server-ntfs-file-system-performance-for-sql-server/#comment-309991</link>
		<dc:creator><![CDATA[Joe Terrapin]]></dc:creator>
		<pubDate>Fri, 06 Jul 2012 03:13:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.sqlauthority.com/?p=19707#comment-309991</guid>
		<description><![CDATA[thanks dave. much appreciated :-)]]></description>
		<content:encoded><![CDATA[<p>thanks dave. much appreciated :-)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
