In my previous post, I looked at how a typical OLTP workload may be affected by various controller cache configurations. And the conclusion was that giving too much cache (say all 512MB) to reads hurt the OLTP performance. The primary reason was that the writes from the OLTP workloads were starved of cache. Now, let's take a look at how the ...

In my previous post on the performance impact of controller cache configurations, I presented some empirical results showing the performance impact of configuring the controller cache to various read/write settings on large sequential I/Os.   Why did I single out large sequential I/Os? That's because large sequential I/Os are heavily used ...

In the next several blog posts, I’ll share with you some empirical results concerning the performance impact of configuring the read/write cache of a disk controller.   In the comments on Joe Chang’s blog at this site on Storage Performance for SQL Server, some statements were made concerning the performance impact of read cache in a disk ...

In my two previous posts on the performance impact of frequent manual checkpoints and the I/O behavior of frequent manual checkpoints, I demonstrated that frequently issuing manual checkpoints can be bad for performance and why it's bad from the storage perspective. If you were led to believe that manual checkpoints were always bad, that wasn't ...

In my previous blog post on the performance impact of frequent manual checkpoints, I highlighted the performance peril of going overboard with manual checkpoints, and I suggested that a major contributing factor was the failure of frequent manual checkpoints to take advantage of the throughput potential of the underlying storage. But I didn't ...

SQL Server 2005 supports placing read-only filegroups or read-only databases on NTFS compression. In other words, you can compress the database files in a read-only filegroup or a read-only database. This can be a very useful feature if saving disk storage is of high priority. But what are the performance implications of using this SQL Server ...

Recently, when I was doing some I/O performance tests on an I/O path, I found that 8K random reads (and writes) significantly and consistently outperformed 8K sequential reads (and writes) in terms of I/O throughput (megabytes per second). I was puzzled. With a traditional hard disk that is made up of a stack of magnetic platters held by a ...

I had always thought that: SQL Server backup reads/writes sequentially, and SQL Server backup could fully utilize the throughput of the I/O path But I'm no longer so sure. Recently, I was doing some benchmark work on two I/O paths, and had the following numbers from pure I/O tests with sqlio.exe: Drive E:  ~200MB/sec for both ...

In Windows Server 2003, you can use the Disk Management console to create a striped volume over multiple dynamic disks (well, you can also create a mirrored, a RAID-5 volume, etc). If these disks (or LUNs) are presented from a SAN, most likely you can stripe across the same storage devices--making up these LUNs--inside the SAN to present ...

Just google for Windows disk alignment best practice, and you would find thousands of articles, whitepapers, and posts, all preaching the practice of aligning disk partitions on the 64K boundary. For instance, one of the EMC recommendations prescribes a disk alignment value of 64K for the host file systems when deploying SQL Server 2005. Microsoft ...