As I was sitting in Bob Ward’s Inside SQL Server I/O presentation, something interesting caught my eye on a slide that noted that ReFS is now supported for SQL Server 2014. I’d run into problems with 2012 so I’d just given up but this looks promising. I am neither a filesystem aficionado, nor a dilettante but I know that there are some interesting features of ReFS at which Windows server admins are looking to see if it’s viable.
Previously, I examined a couple of features that were potential blockers for 2014/ReFS adoption: DBCC CHECKDB and In-Memory OLTP support.
So with it established that these issues have been addressed and that SQL Server 2014 does support ReFS, should we consider it as a viable option? Let’s see from a FIO benchmark perspective.
As I was sitting in Bob Ward’s Inside SQL Server I/O presentation, something interesting caught my eye on a particular slide.
It looks like ReFS is now supported for SQL Server 2014. I’d run into problems with 2012 so I’d just given up but this looks promising. I am neither a filesystem aficionado, nor a dilettante but I know that there are some interesting features of ReFS at which Windows server admins are looking to see if it’s viable.
There are a few known gotchas with ReFS that I’m going to (hopefully) test, along with performance characteristics. Performance will be addressed in a separate post because I’ve already got the numbers and the post will be a bit deeper and less along the lines of “work/no-work.”
Recently I’ve been tasked with testing storage for a hardware purchase for a new, large SQL Server implementation. I’ve not gotten everything “down pat” as far as SQL Server IO methods, but I figured I’d take on the challenge of getting better.
In the Star Wars universe, the nerf was an adaptable, hairy, slow, grumpy animal that was important for its meat. In SQL Server, the Statistic is a flexible, hairy, (sometimes) slow, grumpy blob that is important in query compilation. The similarities don’t end there, though. Both nerfs and statistics can get unwieldy if not managed properly.
I recently wanted to explore potential candidates for data compression in our environment. I found a few ways to go about doing this, most notably this TechNet article that steps through strategy and planning. This was helpful, but I wanted to come up with a repeatable process. Since we have partitioned tables, I also wanted to examine candidates for compression at the partition level for each index.
As users and business activities generate data that is stored in SQL Server, the possibility for data skew increases. For the purposes of this conversation, data skew can be generally characterized as significant variance in frequencies of values in a column. Admittedly, the significance of the variance depends on factors such as data size and/or the informed subjectivity of the analyst. To illustrate, I’ll use some data from a recent SQL Saturday (#297) presentation I did on backup throughput analysis.
It’s been a while, primarily because I’ve been looking into a different blogging platform with actual Markdown support, and on a different host. It’s definitely better looking and undoubtedly easier to use from a publishing perspective. I may still end up self-hosting and just buying a domain name. However, I digress …
We’ve been having some issues with blocking on a pre-prod implementation recently. That’s not really a huge cause for alarm since blocking comes with the territory, but this has been excessive and was having some noticeable performance impact. I wanted to put together a query that would help us find the blocking chain (this was before we put the environment in the list of servers monitored by SQLSentry). Recursive CTEs really came in handy. The first iteration looked something like this:
I’ve uploaded my deck and scripts for my upcoming presentation. It’s in the “Presentation” page.
In order to create the sample “Stack Exchange” databases, you can use the Gist here .
I’ve noticed some range and scale issues so I took out the explicit schema creation (for now). For right now it just selects into a table, dropping the table if it already exists.
Back in October I had the opportunity to attend Jonathan Kehayias’ “SQL Server Archaeology” presentation. I’d been trying to wrap my brain around Extended Events for a while, but his presentation got me motivated to dive into the system_health Event Session.
I had the good fortune of attending Kimberly Tripp’s data skew presentation at the PASS Summit 2013 in Charlotte, NC back in October. In this presentation she revealed some code that she’d developed to help analyze skew in your data and make suggestions for filtered stats. This inspired me to take a look at statistics in some of my servers.