title: Why do best practices tell you to disable caching on the log drive of SQL Server on an Azure VM
body: <p>According to this article and several others I've found:
  <a href="https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-sql-performance/" rel="nofollow">Performance best practices for SQL Server</a></p>
  
  <p>It is considered a best practice to disable caching on premium storage disks for the SQL Server Log disks.  However, I can't find anywhere that explains why.</p>
  
  <p>Does anyone have some insight?</p>
  
  <p>Let me add that the reason I see disabling read-only cache on the log drive as an issue is because it makes you have to set up two separate Storage Pools inside the VM, which makes upgrading/downgrading VM's inside Azure more problematic and considerably less performant.  </p>
  
  <p>For example, say you start with a DS V13 which has a 16 drive limit, but about 6 of those drives can be maxed before you're throttled (25000 IOPs).  Since best practices says read-only cache for data and no cache for logs, you give 8 of those drives to the data and 8 to the log.</p>
  
  <p>Now, the server needs to be upgraded, so you upgrade it to a DS V14.  Now you can max out 12 drives before being throttled (50000 IOPs).  However, your data drive's Storage Spaces column size is only 8, which is throttled to 40000 IOPs.  So you're not using the IO's full potential.</p>
  
  <p>However, if you can start with a DS V13 and assign all 16 of those drives to a single Storage Pool then put both the log and data on it.  You can upgrade/downgrade all the way up to a DS V15 without any concern for not using up your full IOP's potential.</p>
  
  <p>Another way to put it is: If you create a single Storage Pool for all 16 drives, you have considerably more flexibility in upgrading/downgrading the VM.  If you have to create two Storage Pools, you do not.</p>