 




<?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/"
		>
<channel>
	<title>Comments on: Disk Design for vCenter database</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/sql-server/disk-design-for-vcenter-database/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/sql-server/disk-design-for-vcenter-database/</link>
	<description></description>
	<lastBuildDate>Tue, 07 May 2013 13:39:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: Mrdenny</title>
		<link>http://itknowledgeexchange.techtarget.com/sql-server/disk-design-for-vcenter-database/#comment-1533</link>
		<dc:creator>Mrdenny</dc:creator>
		<pubDate>Wed, 23 Nov 2011 17:35:56 +0000</pubDate>
		<guid isPermaLink="false">http://itknowledgeexchange.techtarget.com/sql-server/disk-design-for-vcenter-database/#comment-1533</guid>
		<description><![CDATA[I would still recommend putting them on different LUNs.  You&#039;ll get different IO paths to the SAN so there&#039;s less chance of the HBAs being saturated that way.  Also you&#039;ll get separate IO queues in Windows this way which will help you out if a path starts to have performance issues.

(This is all assuming the native Windows MPIO driver.  If you have EMC&#039;s PowerPath installed this change a little.)]]></description>
		<content:encoded><![CDATA[<p>I would still recommend putting them on different LUNs.  You&#8217;ll get different IO paths to the SAN so there&#8217;s less chance of the HBAs being saturated that way.  Also you&#8217;ll get separate IO queues in Windows this way which will help you out if a path starts to have performance issues.</p>
<p>(This is all assuming the native Windows MPIO driver.  If you have EMC&#8217;s PowerPath installed this change a little.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MattPenner</title>
		<link>http://itknowledgeexchange.techtarget.com/sql-server/disk-design-for-vcenter-database/#comment-1532</link>
		<dc:creator>MattPenner</dc:creator>
		<pubDate>Wed, 23 Nov 2011 08:09:36 +0000</pubDate>
		<guid isPermaLink="false">http://itknowledgeexchange.techtarget.com/sql-server/disk-design-for-vcenter-database/#comment-1532</guid>
		<description><![CDATA[We have a VMware setup connected to our SAN with two RAID arrays one two physical sets of disks. The first is a RAID10 and the second is a RAID6. It sounds like our logs should go on a LUN on the RAID10 array. The blades that the VMs run on boots from the SAN and has no internal storage of its own. 

Is there any performance improvement between having the data files and the TempDB on the same LUN vs separate LUNs if they are both on the same RAID6 array? It seems to me that the SAN would still be optimizing the writes to this same array as best as it could whether they were the same LUN or separate. But then I read a post somewhere that SQL will assign a different I/O thread if the info is on two separate drives and this might increase performance.  Again, this doesn&#039;t sound right since the bottleneck is the I/O, not the O/S handling of the I/O thread. 

Any comments?]]></description>
		<content:encoded><![CDATA[<p>We have a VMware setup connected to our SAN with two RAID arrays one two physical sets of disks. The first is a RAID10 and the second is a RAID6. It sounds like our logs should go on a LUN on the RAID10 array. The blades that the VMs run on boots from the SAN and has no internal storage of its own. </p>
<p>Is there any performance improvement between having the data files and the TempDB on the same LUN vs separate LUNs if they are both on the same RAID6 array? It seems to me that the SAN would still be optimizing the writes to this same array as best as it could whether they were the same LUN or separate. But then I read a post somewhere that SQL will assign a different I/O thread if the info is on two separate drives and this might increase performance.  Again, this doesn&#8217;t sound right since the bottleneck is the I/O, not the O/S handling of the I/O thread. </p>
<p>Any comments?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
