|
|
|
|
Browse by Tags
All Tags » Performance » SAN (RSS)
Showing page 1 of 2 (13 total posts)
-
A contribution for T-SQL Tuesday #004, hosted by the illustrious Mike Walsh!
In the past few weeks I had some correspondence with Kendal Van Dyke leading up to his SQL Saturday presentation on SSDs, and he got me fired up to share a little of my team’s experience with a real implementation. Over the past four months or so, our IT group at work ...
-
As will become apparent from this post, I am no Storage Admin. My apologies for offending the sensibilities of those who know this topic better than I do!
I get asked occasionally about placing SQL Server data on SAN storage, and I've done it with a few systems, and a lot of smart people helping me, so here's a SAN 101 crib sheet for DBAs ...
-
Lately I'm faced with a fairly ambitious data center move, and at the same time with an initiative to consolidate sprawling SQL Servers onto centralized clusters. It's a chunk of work, but these two notions have fit together pretty well: as long as we're moving SQL services and touching everything, it seems to be easier to make the consolidation ...
-
I'd like to pass along a couple of tips for those new to using SAN storage for SQL Server. SAN Storage is quite expensive, and doubly so if your storage doesn't deliver on the performance front. SAN disk arrays are not magic, and sadly they don't just automagically perform well, marketing to the contrary. These are some items I have found helpful ...
-
SQL Server workloads
So far, the discussions in all the previous posts (1, 2, 3, and 4) on the performance impact of file fragmentation on a drive presented from a high-end enterprise-class disk array are related to disk I/O workloads. Ultimately, you want to know how file fragmentation may impact your SQL Server workloads.
In ...
-
Lies, damned lies, and statistics!
If you have read my three previous posts (1, 2, 3), you may walk away with an impression that on a drive presented from a high-end enterprise class disk array, Windows file fragmentation does not have a significant performance impact. And I’ve given you empirical data—oh yeah, statistics—to support that ...
-
256KB Sequential Reads
In my two previous posts (1, 2), I highlighted the fact that while file fragmentation had a huge adverse performance impact on directly attached storage (DAS), it did not have much, if any, impact on the drive presented from a high end enterprise class disk array. That observation was derived from running disk I/O ...
-
1KB Sequential Writes on DAS
There were some questions about the use 1KB sequential writes in my previous post to test the performance impact of file fragmentation on a drive presented from a high end enterprise class disk array.
There were two reasons for testing 1KB sequential writes:
· SQL ...
-
1KB Sequential Writes
It’s well known that disk I/O performance can be severely impacted by fragmentation at the file system level. In other words, when a file is allocated space from many small fragments, its performance can be much worse than when its space is allocated from a single contiguous chunk. The impact is most pronounced with ...
-
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 ...
1
|
|
|
|
|