1:05:17 Webinar
A Practical Deep Dive into I/O for T-SQL Performance Tuners
Join me for an in-depth, advanced but essential “what you need to know” exploration of SQL Server I/O.
This webinar first aired on 19 May 2026
The first 5 minute(s) of our recorded Webinars are open; however, if you are enjoying them, we’ll ask for a little information to finish watching.
Click to View Transcript
Is mssqltips.com webcast Practical Deep Dive into I/O for the T-SQL Performance Tuner. I bet that is you. Today's session will be presented by Andy Yun and, sponsored by Everpure. I'm Jeremy Catlin from mssqltips.com, and I welcome you to today's event. Andy, he's a long-time friend of MSSQLTips from doing, webcasts for many years, and he
has a ton of content, as always, and that's no different for today's session. So please buckle up, get ready. If you have any questions along the way, please post them in the questions portion of the GoTo Webinar controls, and we'll answer as many as possible during the tail end of today's event. So Andy, please take it from here and help
educate the community. Thank you so much for having me, and, thank you everyone for taking the time to join me today for a practical deep dive into I/O for the T-SQL Performance Tuner. If you haven't heard, you know, eh, if you haven't seen me present before, I am a, field solutions architect with Pure Storage, now known as EverPure.
I still refer to it just as Pure, as, many of us will, for the time being. But, you know, the-- my background though to understand is that, you know, I've been a hardcore SQL Server guy. I've been a SQL Server DBA and a DB developer. And, you know, I used to be based out of the Chicago area. I come to you now from Boston.
And the most important thing on this slide, of course, is my contact information at the bottom. You'll see my email address, my GitHub, my blog, all of which contain supporting material for this particular presentation as well. All of this information will be available to you at the end of this presentation as well,
so don't feel the need to take screenshots or anything just yet. This is my amazing spouse, Deborah Melkin, who is another community member who also speaks and presents. And then this is our dog, Sebastian, who may or may not be making cameo appearances throughout this particular presentation.
So let's just imagine it's a nice quiet Monday morning. I'm out here in the Boston area, so we have these awesome cannolis out here. That's one of the things that Boston is very well known for, so I'm about to enjoy one for breakfast. It's nice and quiet up until, oh, seriously, Sebastian, what's going on?
We get paged. We get that alert, right? We all know this pain of being, getting those emails and, "Hey, all hands on deck. We got a problem." All right, so let's crack open the, SQL Server error log, and in this case, we are seeing the dreaded, I/O request taking longer than fifteen seconds error message all throughout our error logs.
Oh, great. Now what? Is the big question. And frankly, there have been some points in my career, earlier in my career, that I've seen this, I've experienced this, and I literally had it, "Uh, I don't know what to do now. Oh, no, this is..." 'Cause, yeah, it, it's one of those things where, yeah, I/O's taking
longer than fifteen seconds, but where do I start? Where do I go? It's n- and it's one of those things that, that can be very, very intimidating because the realm of I/O is very, very expansive. There's a lot of different things that fall underneath that umbrella. And that's the goal of this particular presentation is to give you a quick whirlwind
tour of those different elements. So we're gonna be diving into I/O, and this is gonna be a bit of a deep dive, but I'm gonna try and keep things in a very practical sense as well. You see I chose each of these words very carefully as part of the context of this title. Now, one thing that I, have here as well is this is for the T-SQL Performance Tuner,
but I did not say T-SQL developer. And you might be wondering why I didn't do that if I'm being very, very, very intentional about my titling and my word choice here. And you might say to yourself that, "Well, you know, I'm primarily a T-SQL developer, and frankly, I was for the vast majority of the first half, two-thirds of my career.
I slung code for a living. So why should I care about the hardware stack? I just write code." Well, this is where Deborah comes in, 'cause that's what she has been doing for the vast majority of her career, and her answers are actually answers that I think are v-very applicable to many of us as well and why this all matters, why at least
having a working understanding of the hardware stack and all of the different things beyond just our code come into play. And it plays into why specifically I'm using the term that I did before because this is kind of the career progression that I took myself. I was originally a T-SQL developer.
That's what I specialized in, for the good, you know, portion of my-- earlier portion of my career, and I got really good at it. But then I became more of a T-SQL performance tuner. I learned about execution plans. I learned about the ins and outs of the query optimizer and things of that nature, right?
But now I've progressed to what I like to call the SQL Server Performance Tuner. It's a much more holistic approach. It all, of course, starts with our code, but it kinda goes up and out in a more broader sense of what is going on with the SQL Server ecosystem. And my hope is that this presentation today is geared towards what I call the T-SQL
Performance Tuner, m- I'd like to say Andy five, eight years ago, and help you then take that first step to upskilling to yet even that next tier of being a more holistic SQL Server Performance Tuner. Okay? Some other things I just want to be very clear is that you don't have to know everything, i- but it's good to at least have this familiarity in order to or i-if nothing else,
just to have the ability to say, "Hey, yeah, I remember Andy talked about that in that session a couple of months back," or something like that. "I should go check that out again," the next time you run into something like this, right? So don't feel the need that you have to memorize and know all of this inside and out. And if you've never been to one of my sessions before, you know that I'm notorious for
building seventy-five, eighty-minute sessions and jamming them into sixty minutes. Today is no exception. Thankfully, this is being recorded. So yes, this will be a fast-moving session. but again, you can always go back and check out the recording.And one final thing of note,
today's session is a sponsored session by my, the company that I work for, Pure Storage, AKA EverPure. This is not a vendor session, however. so there'll be, points here and there where I may make a mention around something that EverPure does, and there will be a brief sort of focused commercial towards the end that'll
only last about two, three minutes. but otherwise, this is totally not a vendor session. I very much specifically have built it this way just because I've sat in many vendor sessions where the it was just all vendor fluff and marketing and nothing of meat and value.
This is the complete opposite. There's, of course, mentions of EverPure, but this is meat and, potatoes, the good stuff for all of us, no matter what, we use. Okay. With that, let's jump into foundations first. So it all starts off with a T-SQL query.
If no one was running queries, then our SQL Servers wouldn't be doing anything. That query gets passed into the query optimizer. Of course, there are entire, you know, multi-hour presentations just deep diving into the nuts and bolts of the query optimizer. The fundamental output of the query optimizer is an execution plan, okay?
So the key to understand here, though, is that T-SQL is what's known as a declarative language. You are Your code is saying, "What do you want?" But you are not giving explicit instructions. Yes, there's a side, tangent or exceptions using things like query hints and stuff.
We're not talking about that type of thing. But from, from a holistic perspective, T-SQL is declarative. Just tell me what you want, and the query optimizer is gonna figure out how to get it for you in the form of that execution plan. And I like analogies, so, you know, it might be thinking about how, like, for example, I'm
the cook in the family, so I might give Deborah a, a menu for dinner tonight. But, you know, and this is the, you know, dish that we're gonna be looking forward to. Yes, we're both fans of Top Chef. But in the end, Deborah's not gonna be s- standing next to me in the kitchen giving me explicit instructions as far as how to go about cooking this meal and, you know, doing
this or doing that with the onions or with the broccoli or, you know, with the sauce that I'm making, you know, giving me the exact measurements. That's not her job here. She's just asking, "Hey, Andy, I want you to make this awesome dish for dinner tonight. Will you please do that?" Yeah, cool.
Absolutely, I will. But it's now up to me to come up with that final execution plan to come up with the output. And just like our exec- or, you know, just like what I was doing as far as cooking, our execution plan dictates access methods as far as how we're actually gonna be retrieving our underlying data, whether it be a clustered
index scan or an index seek or something of that nature. These are the underlying access methods that the storage engine will then utilize to retrieve our data. So with one of these, let's talk about what the storage engine does with the execution plan. I now, for example, I'm gonna do a clustered index scan against a recipes table, and now
we're gonna go to the buffer manager. The buffer manager is the entity within the storage engine that controls and manages what data pages are resident in the buffer pool, AKA RAM. What pages are, accessible or available right now in memory? Are any of the recipe data pages available to me in the buffer pool?
If the answer is yes, cool. Let's read those data pages, and away we go, and those are considered to be logical read operations. However, if the data page is not in the buffer pool at this time, we must fetch that data page from disk.
That discrete operation is known as a physical read. But then after the physical read, we must reread that data page again and e- once it is inside the buffer pool, and that is what's known as a logical read as well. So whenever you are using, say, s- set statistics IO on, you'll see both physical reads and logical reads.
They, your physical reads will always be a subset or equal to your logical reads. A different way of thinking about it, that kinda helps me really to understand this, and that's why I thought I'd share this with you, is that a physical read is a read from disk. A logical read, let's not overload the word read here, but instead think of it as the scanning or processing of the respective data page inside the buffer pool as opposed to
reading the data page from disk, okay? And that's just, again, how I kinda like to think about it. Maybe that'll help you keep the two of them straight just because read this, read that, the, the dual uses of read can sometimes confuse folks. It did, confuse me earlier on in my career.
Okay. So who is actually dispatching the IO request down to your underlying storage? SQL Server, while it has its own operating system, in this case will still utilize Windows to then dispatch the IO request. So Windows then, will utilize the CPU, and then of course that IO request goes over the
PCI bus, the physical bus inside the computer, to then, you know, process that data page inside of RAM, assuming that the data page resides in the buffer pool. And if it does not, then Windows will once again utilize CPU cycles to go over to the PCI bus to go retrieve your data from local disk, assuming that this is a local disk scenario and this is just a SQL Server on a single bare metal localized machine.
So let's talk about the underlying physical pathways, between a host, or server and the underlying disk, and this is in the case of direct attached storage. We're gonna go over what's called the PCI bus. that is the bus lanes on your motherboard. Now, on the other hand, you may have a SAN like, oh, hey, look, a Pure Storage FlashArray.
So many of us in our organizations do use SANs these days. direct attached storage for production SQL Servers is really not all that common. SANs are absolutely far, far more common, i- in the industry today. So with-Uh, to communicate with a SAN, a server will connect through an HBA adapter. In this context today I'm using HBA adapter in a more generic term, because it could be
Ethernet, it could be fiber channel cards. so HBA, by the way, stands for host bus adapter. Just like we have a PCI bus, now we have a host bus adapter. but that adapter can again take multiple forms. You may have heard of, fiber channel for example, which is a dedicated, storage fabric
for, for SANs. Otherwise, of course, we all know about Ethernet and, networking. That's another way of getting out to a SAN. And then storage fabric, I'm also using that term generically here of all just to represent all of the different hardware that might reside between the server's host bus adapter,
which is again, a physical card inside the physical, server, and then everything in between. I'm gonna use, networking as an example. It'll be your switches, your routers, your Ethernet cables i- in this example. Or if you have fiber channel, it'll be the respective fiber channel, switches and cabling and so on and so forth.
That all will wind up back out at your SAN. And of course, many of us don't have bare metal SQL Servers these days. We virtualize our s- SQL Servers. So understand that a virtual machine will have virtualized adapters, usually SCSI adapters, for varying reasons, that will then connect to a virtual host.
That virtual host is your bare metal machine. And then that virtual host has the same physical connections of an HBA adapter that physically goes over a storage fabric to then get out to the flash array. But you see now that there's additional layers of complexity in the physical pathway from getting from that machine, that SQL Server, all the way out to my storage and back.
So remember, if nothing else, the reading and writing from disk, there are many different layers to this stack. And, access from memory will always be faster just because there's far fewer steps that we have to go through. If I just have to go to my PCI bus and then straight to memory, that's one of the reasons why it's fundamentally faster, and of course,
in addition to the nature of RAM as opposed to, say, spinning disk. But again, if nothing else, it's just shorter hops. I will say real fast, if you happen to have any questions along the way, I forgot to mention this early on, please throw them into the questions tab. I am monitoring that over here.
I will most likely only take questions towards the end, but if something of pertinent comes up, I will answer it on the fly. But I am keeping an eye on it, so, feel free to, pepper me with questions or heckle me in the questions, pane if you want to for fun as well. I got a thick skin, let's have a little bit of fun.
So back to the story. Yes, Sebastian, we are back. Error 833, I/O requests have been taking longer than 15 seconds to complete. So that means that SQL Server has issued a read or a write to and from disk, and that of course it is taking longer than 15 seconds to complete. But we need to dissect this just a little bit further.
How is this, error message even being tracked? First of all, it means that i- there could be a- any type of I/O outstanding, whether it be a read I/O and/or write I/O, that has been outstanding for longer than the duration of 15 seconds. But here's a key nuance.
This is not polled at all times or directly in real time. It is only recorded every five seconds, and then recorded in the error log every five minutes. Why Wha- what- what's up, Sebastian? Well, why yes, there are some coverage gaps here.
So don't necessarily be reliant on an error 833 because it's reported every five minutes. It could have happened four minutes ago and then resolved itself. or you could actually have I/O that's long running that could last between the two polling periods of once every five seconds. So if, you know, I had, you know, at second zero, if my I/O issue started at, you know,
0.5 but then concluded at 4.0, and then we record again or poll again at, second five, we have no idea about it 'cause we're only polling every five seconds. So in some regards, error 833 is not as reliable or as granular, as you might think it is. And it's just that any I/O has been pending for longer than 15 seconds, but it might
resolve itself at s- the 16-second mark for all you know. But still, it is a symptom of something. So before you really dig in or freak out about, you know, your storage subsystem, you need to start asking questions. A great question is, has this always been happening?
Is this something that's systemic or is this something that's cyclical? Since when? For how long? Is this a, a long multi-hour I/O storm? Is it just a brief blip for 30 seconds or a minute or something like that, right? So these are You, you need to construct the timeline of the event or sequence of events.
And then once you've, constructed the timeline and know the timeframe that you're investigating, we now need to be mindful of and start investigating not just the storage, but the entirety of your stack, y- your entirety I/O pathway. And it's critical as you start doing that, 'cause most of the time we're DBAs, we're not the s- we're not the storage admins, we're not the networking admins, we're not the v-
virtualization admins. So we need to go to our colleagues to also say, "Hey, what's going on here? What's going on there? Did you see anything during this period of time or that period of time?" Because SQL Server saw these errors in the error log. Oh, that's a great reminder, Sebastian. Yeah.
So this is a reminder to tell a story, a tale from the trenches. This is something that actually happened to one of my customers who recently upgraded, or at the time they had upgraded, and, brought in something called FlashBlade. FlashBlade is a scale-out, a scale-out piece of hardware for us that excels at throughputIt's a really awesome piece of hardware.
but in either case, they were having performance issues with it, and they were really, you know, puzzled by it. So of course, there was an escalation that was put together and, you know, on the customer side, we brought in the database admin, the Windows admin, the virtualization admin, and the storage admin. Now, one key detail about this entire scenario
as I got brought in on the Pure side is this: not only did they bring in the FlashBlade, but they also upgraded their entire storage fabric. They b- brought in a brand-new storage fabric to, you know, work with this brand-new piece of, shiny hardware. And in this case, they switched from Fibre Channel to iSCSI and Ethernet in this
particular case. Well, wait a minute. Ethernet, that's networking, and no, no one talked to the networking team here. So what had happened is this. The FlashBlade itself, from a networking perspective, had what's called, top-of-rack switches.
That's what these two green bars, represent, and there's two of them for redundancy purposes. Well, the networking team, basically had one go down. They were doing some shenanigans as they were just kinda testing all this stuff and setting it all up, not fully realizing or appreciating that the FlashBlade was in production now, and
one of them went down. But it's like, oh, the other one's, up, it's for redundancy, but they hadn't properly wired up all the redundancy such that with one top-of-rack switch down, throughput was cut in half. But they just kinda kept it to themselves. They weren't used to also sharing this out with everyone else, and the storage folks and
the database folks and whatnot weren't used to talking to the network team because previously it was just the storage team's, problem because it was prior all Fibre Channel, and the storage team used to manage the Fibre Channel. But now that there's, Ethernet in the mix, they needed to involve the networking team. So now this became a, a, you know, one of those things of communication, and that's
really all it amounted to. So that's the moral of that little story, is make sure that you have all the correct people in the room. All right. So we wanna start talking about troubleshooting then. You know, so within the SQL Server, realm, we're gonna start with IO wait stats.
We always wanna take a look at what the wait types are. It's not the end-all be-all, but it's a great place to start, and it's one of the places that I generally prefer to start from a troubleshooting perspective. But then I'll also, of course, look at the IO related SQL Server DMVs and look at things like what does latency look like.
But then I'll also check PerfMon as well and check out what PerfMon's latency is gonna be like. Well, Andy, why should I check, you know, latency on the SQL Server level and the Windows level? Aren't they one in the same? Maybe, maybe not because here's one specific, more advanced scenario that's not as common,
but unfortunately is somewhat common or uncommon as the case may be, and you'll see why. So if SQL Server is reporting really high latency, but Windows performance counters do not report high latency, then you have an immediate culprit of something called a filter driver. A what? Yeah, I don't know.
Before I learned about this, Sebastian, I didn't even know what filter drivers were, but you know what I do know what, is out there that sometimes interferes with, SQL Servers inadvertently? Antivirus, corporate spyware, and other s- corporate security, I should say, and software of that nature. Things that, you know, corporate security will
install on all servers all across the board no matter what that inspect, data packets as they are going in and out of the server for whatever purpose, like antivirus purposes or whatever the case may be. Those are manifested as something called the filter driver inside of Windows. So these can be an interesting, nefarious, performance killer from an IO perspective, and
yes, unfortunately I do see this, being an issue more often than they really should be, even though we should have the proper exceptions in place and so on and so forth. oftentimes that still doesn't happen. So this particular little command, ftlmc instances in Windows, will actually show you the list of per, of filter drivers that are active.
There's always some filter drivers that are active, but this is an example of a bare bones, virtual machine on my laptop, that just happens to have SQL Server on it as opposed to my laptop itself that's running a whole bunch of other stuff. You see that there's many, many more filter drivers here in play. So you can just, if nothing else, get a sense of what this is.
This is a very advanced topic. There's one of the resource slides at the end that has a bunch of, resources to really dig deep into this particular thing. But I just wanted to mention this because there are cases where things like antivirus and corporate security software have injected needless latency and IO to our SQL Server
workloads, and this is one of the ways to dig into that. So going beyond just filter drivers, let's talk about the pipelines and whether we are actually saturating our underlying storage. So in this case, you know, I have a simplistic, environment here where my server is connected, to a really nice, Pure Storage or EverPure FlashArray.
And we are, are trying to drive about eight gigabytes worth of traffic back and forth from an IO perspective, and the FlashArray itself, you know, can easily, you know, ingest and, feed up well over 30 gigabytes in this, simplistic case. I'm just using round simple numbers. These are not the actual product spec numbers.
I kind of forgot to look those up for this. so these are just r- my random prior generic numbers by the way. So don't take this as a, "Oh, the FlashArray can only do that." But in either case. But, you know, the, the point is, is that you have a high-end storage array that can take a whole heck of a lot more than the IO that you are trying to drive from your SQL Server.
I expect to be able to drive eight gigabytes per second from my SQL Server, but why am I not, able to achieve that? This is where you need to start investigating the specific model numbers and underlying drivers and the physical hardware in the storage fabric that you are going through. In this simplistic example, while my HVA was capable of eight gigabytes per second,
somewhere in my storage fabric I found an old switch that somehow for whatever reason IO was now being routed to that old switch instead of this other switch that it should have been going to, and that throttled me at four gigabytes per second. This is a simplistic example, but this is based upon things that have really happened to my customers out there where, again, people aren't talking to each other, or no one's
actually crawled through the data center and, oh, IO was taking a different path than we fully expected, or that piece of hardware for some reason, is throttling down. There's all sorts of different reasons why this might happen, but this is something-to look into and why it's important to look at every single layer of the stack and ask questions about every single layer of the stack.
Now, coming back to SQL Server, of course, you know, our, it very rarely are we just running one single query. We are running many queries. We have a, we have to take a look at things from that workload perspective. So of course, we all know that CPU and RAM are a limited commodity.
One thing to understand and be mindful of is that CPU is what orchestrates IO. The more CPU I have, the, the, the more powerful it is, the, the faster it is from a, you know, like operations, megahertz and whatnot, the more IO that I can drive. So if I free up more CPU, I can actually drive more CPU utilization by driving more IO. So those two are very much tied together.
So if my CPU is being burned down by calculation and computative, a, you know, sort of operations as opposed to driving IO, that may actually wind up burning, or throttling your underlying IO. Or, you know, is your CPU actually being fully throttled or not? That may also be indicative of whether, where your IO bottleneck may be manifesting.
Memory grants is also one of those things to be mindful of from a query perspective, 'cause then of course, why, y- you know, memory grants that wind up spilling over means I now have to do things like writing out to tempdb and therefore causing more IO. So that's one of those other common things that I will typically look at from a high level, just because I wanna look for inadvertent spills to tempdb.
A lot of folks, a lot of workloads that I look at of, across my customers, you know, they thrash tempdb a lot because they don't have tuned queries, and they wind up spilling over to tempdb a lot more often than they fully expect to. So it's really critical to monitor, to, to monitor your stack, but you would be surprised at how many times I've talked to database teams and they don't really know how to query
their queries and to monitor their queries. How do you know what was happening at 5:00 in the morning when you hopefully were not awake and staring at your SQL Servers? Very rarely are we staring at our SQL Servers 24/7. The response I'll oftentimes get is, "Well, I can't afford a monitoring tool." And yes, I
used to work for a monitoring company. You might, some of you might know that I used to work for SentryOne. and you know, those products can be somewhat expensive. But here's the thing, it's 2026, and in today's day and age, there's some really cool free offerings that are out there.
One of the ones that I really like that's relatively new on the market is by Eric Darling. Hopefully, you know who he is, a master, performance tuner, a SQL Server performance tuner, as I would like to say. And, in the last, what, five, six months, he's put out an amazing free performance,
monitoring, solution. Go check this out right now if you're a shop that say, "I can't monitor everything." Or maybe you do have a third-party monitoring tool, but you only have enough licenses to monitor prod, but you're still responsible for non-prod environments. Go get Eric's tool, deploy that out in your non-prod environments.
a- and, you know, just get more visibility into what is actually running, on your servers. 'Cause without that knowledge, you really got nothing. All right, maybe it's not the actual workload. Maybe the workload is operating within spec, within norm, and something else is really going on. This is where, again, just like we did with a
few of the examples earlier, you really need to spend time analyzing the IO path to really try and figure out what is going on with, that error 833 that's being reported. Now, if you go read about it on, the Microsoft documentation page, they have a really in-depth page about, error 833. and the term IO path is mentioned 11 times.
It's again, all about the pathway. I, I've been beating this down, you know, into your heads, earlier, and I'm gonna keep beating that. It's all about making sure we're looking at every single element in the pathway and what is each pathway capable of. You not only wanna look at things like throughput, you also wanna look at IOPS as
well, and you wanna see if you can capture and monitor this as well. Sometimes this is more of a challenge. There are some, APMs, application, performance monitoring tools that are out there that are really, really good at seeing things end to end. Other times, you're just gonna have to go into the monitoring for just the fiber channel
switches and the monitoring for this and the monitoring for that to try and piece everything together. It can be very challenging. So here's a different, story here. So we had a backups, scenario, with a customer where they were not getting the performance that they were expecting or they were hoping for.
So what they were doing is that they were reading their data from FlashArray, so that's a SQL Server, in the middle, and then they were writing out backups over SMB to our FlashBlade. So FlashArray is really, really good at, you know, low latency, high-end performance workloads. FlashBlade is really good at high throughput
workloads, especially being a backup target, for example. So the backup throughput they were getting was about three gigabytes per second, but our FlashBlade is capable of consuming and ingesting a whole heck of a lot more than that. Again, those are not exact product numbers, just, you know, numbers for example here. But the, the point of the FlashBlade is that, yeah, it can ingest a whole
heck of a lot of data. So three, gigabytes should be absolutely nothing. And the FlashArray can feed up 30 gigabytes in this particular example here. Again, fake numbers. But nonetheless, why is the FlashBlade, why are we not pushing the FlashBlade to its
particular limit? Why is my backup throughput only about three gigabytes per second? This is again, where we have to look at the underlying hardware. In this case, we found out that HBA adapter was throttling things, but it was not only throttle, it was throttling things from a different perspective.
Physically inside the server, there was something called a, on a PCI slot where normally a card will live, there was something called a riser slot, and that riser slot actually had two HBA adapters plugged into it. But what that riser slot does is that it cuts the, the throughput capability, or the bandwidth I should say, that's available to it in half.Again, something that we would've
never discovered until we started literally digging through the manuals and having someone, you know, look physically inside that physical server inside the data center. But sometimes you have to go to these extremes in order to try and figure out why am I bottlenecking, where-- what's going on here? Why am I not getting all of the throughput that I fully expect to be getting?
All right. So now we've upgraded everything, right? And we have FlashArray. So this should be really awesome, right? But once again, Monday morning, you know, I, I've spent money on, this really awesome Pure hardware and I've heard from many other people that it's plug it in, you know, go fast.
That's the easy button, right? So why am I not getting really awesome performance? What's going on here? So to explain that anecdote, I'm gonna introduce you to this concept called queuing, and queuing is universal in the realm of I/O.
So a queue contains I/O requests to be processed, okay? And then the term queue length is the number of I/Os currently being processed, or as I also kinda like to think of it, you know, I/O that's actively being serviced, where w- you-you're standing at the counter, you know, like someone is getting your order and actually, you know, processing it for you.
Like you just ordered, your lunch and, you know, someone's going to get your burger and your fries. And the queue depth limit is the maximum number of I/Os that can be processed simultaneously. So going back to that silly, fast food, example, there's four cashiers, so your queue depth limit is four in this simplistic example.
So usually you'll just hear it as queue depth, but I like to a-tack on the word limit in my brain to help me better understand and remember the nuance of queue depth versus queue length. So what I found confusing, first of all, is that a queue is a line. So here's another ana-analogy for us all.
We have a gas station here that has four fuel pumps. So what is my current queue length? I have one car that's at the fuel pump that's ga- currently, pumping gas right now. Queue length is one, 'cause there's only one automobile. There's one I/O being serviced at this point.
Two more cars show up, no problem. we still have a queue depth limit of four. A fourth vehicle shows up, all four of them are now pumping gas right now. Well, what happens if more vehicles show up? In this case, we've hit our queue depth limit.
So in this case, those cars can't just sit there and wait. They are rejected. They are told, "You can't wait here. You need to go back home and then come back later." And what our I/O essentially does is that essentially it's rejected from the source, told to the host, and then the host has to resend that I/O once again.
And it can bounce back and forth. And this can be a bit of a challenge and a bit of a problem. So as, storage fabrics and such, you know, evolved over time, 'cause this is an old, old, old problem, right? We've introduced queue depth limits at other layers of the stack that basically kinda act like traffic lights here.
So let's pretend I have an HBA here that's my traffic light, and it has a queue depth limit of three. But our to- our destination, our destination storage has a queue depth limit of four, but I can never fully saturate that because my HBA is gonna throttle in, in this case. But in the case of a single-lane highway or a single road that's feeding into the gas
station, that's absolutely okay. But if I had five lanes feeding into the gas station, just like I might have five servers feeding into a SAN, right? That queue depth is helping to, not overcome the gas station itself. So we actually want lower, queue depths, you know, earlier in the stack to not overwhelm
our underlying destination, okay? So now if someone c- you know, leaves here, you kinda see the behavior of what I was just, verbally describing, okay? So think of it as traffic signals that buffer the flow of I/O intentionally to help not overwhelm lousy legacy storage.
But here's the thing. A lot of these different queue depth limits were set in like drivers and HBAs way back in the stone ages of computing, and have not been necessarily updated to handle or accommodate really, really high-end storage that's now available to us today. So we, we can relate to this.
Things like cost social for parallelism is one of those defaults that was set back in the stone ages inside a SQL Server, but we could probably make it a default adjustment today if we really wanted to, and you know, there are many recommendations around doing so. So let's pretend that we've upgraded our underlying storage and now we got 24 fuel pumps here, but my HBA only has a queue depth limit of three.
I'm now going to throttle over here, and I can't do anything about it. I will never be able to saturate my underlying storage at the end. So this is one case where I've had to educate a lot of customers about queue depth settings because frankly, in the-- with old legacy storage, it was never really much of a problem. But once you have really, really high-end storage, you wanna crank up those queue depth
limits because your final destination can absolutely handle much, much more traffic, so you don't need to throttle that traffic further up the stack anymore, okay? This is a very real, very practical thing. And I've had to give this, kinda tutorial to many folks, you know, many customers over the years, especially in the realm of VMware.
Because with VMware, the default SCSI adapter for a virtual machine is the LSI adapter. And oftentimes people would only have one and has a really low default queue depth setting. The best practices as defined by, VMware for SQL Server and database workloads and other high-end workloads is to switch to using paravirtual SCSI adapters, which have a much higher queue depth limit default value.
And to use multiple ones of these as well. That means I have four lanes rather opposed to just one lane, traffic. And you wanna try and distribute your volumes or your drives across those different, those different virtual, SCSI adapters. And then you also need to look at the underlying HBA, queue depth limits on the
drivers themselves. So you need to look at your physical drivers. So you've gotta find out what the vendor is for your HBA adapter and then see if you need to adjust queue depth settings there as well.Now you might be wondering, well, I've seen this queue length thing in Windows.
Is that something I really need to care about, average disk queue length and such? Well, you really only need to care about it depending on what your underlying latency value is in Windows. Because do I really care if queue length is really, really high if my latency is super low? Because if I have a high queue length, that just means that SQL Server is firing a whole
bunch of IO really, really fast. But if my latency is really low, that also means that the IO is being serviced and returned lightning fast as well. That's a good thing in most cases, right? I want my IO as fast as I possibly can.
So queue length can be misleading. That's one of the reasons why I really tried to define everything beforehand. And also understand that SQL Server, when it issues IO, in most cases does so asynchronously. It does so in a fire and forget method.
So your disk queue length may start climbing really, really high from Windows' perspective, but that's by design and that's okay. And as long as latency is low or within acceptable realms for your workload, I don't care. But if latency is high, okay, we have a problem.
SQL Server is firing a bunch of IOs and they're not being serviced fast enough. Latency is king in this particular scenario. All right, let's jump back to the error 833. So what was root cause? The root cause can be a lot of different things, unfortunately.
That's the problem with the error 833 is that it's very, very, very broad. And all of these different elements or these possible root causes, you know, as you kind of read through them, should potentially jive with the different, you know, breakdowns of IO, the IO pathway, the IO lifecycle that we've been going through for the past 30, 40 minutes. And all of this is material that's, you know, taken straight from the Microsoft page.
So unfortunately, root cause could be any number of things that fall under this particular umbrella, which is one of the reasons why it makes it so challenging to try and troubleshoot this. This flowchart is also on one of the Microsoft pages, and it'll actually also take you through the process. And what's kind of funny is that our narrative
today has actually loosely followed this particular flowchart as well. So it's really just all about a logical process of an elimination. And that's what this flowchart is about. And hopefully you kind of get a sense of that as I was going through a number of different elements in this particular narrative.
All right, so let's talk tooling. Frankly, you know, we all should know about performance, perfmon counters, DMV queries, things like SP who is active. And frankly, these are the boring ones. These are things that are tried and true and have been talked about a lot.
I am not going to talk about them today. You can use Google. You can look at some of my other presentations. There's more resources about that today. Instead, I'm going to touch upon a few other more interesting tools. A stored procedure called SP Pressure Detector.
If you haven't checked this out, it's an amazing tool. Yes, by Eric Darling once again, who's been doing a whole bunch of really awesome work around performance tooling. There's something called Resource Monitor. It's a little bit more esoteric.
It's not as practical from a day-to-day perspective, but it can show you some interesting things. I'll show you a quick demo of that. And this is not to be confused with the Management Studio Activity Monitor. Resource Monitor instead is buried inside of Windows Task Manager. And then because this is an EverPure presentation, one of the other cool things
that we bring to the table, amongst many things, is something called VM Analytics. And I'm going to show you a brief example of this. And this is what's possible in the realm of Pures. We have this free tool called VM Analytics that gives you an end-to-end visibility from virtual disk all the way down to the array and all of the different elements in between.
You see reading from left to right, I see the virtual disk, the virtual machine, the host that the virtual machine resides on, then the underlying data store, the array volume, and then the array itself. So I'm very clearly able to see whether I choose to slice and dice by bandwidth, read or write, or latency read or write, or IOPS, or any number of other different units where
there might be a bottleneck in this particular stack. So in this simplistic example, I'm just looking at read bandwidth. I'm looking at my MUT servers. And I see that this is where all of my different IO pathways are going. I can see which underlying Windows disk is driving it.
And I can also see, for example, if latency was really high in the virtual machine but not on the host, that tells me I need to look at and troubleshoot something on the Windows layer or something in between the VM and the host. Like, you know, am I bottlenecking with the virtual SCSI adapters, right? Am I using the old LSI adapter rather than paravirtual SCSI?
Or from the host to the data store. That oftentimes is a host HVA queue depth issue when you see this type of behavior on our hardware. Like you've just, you're a new customer, you brought in our hardware, why am I now bottlenecking? Well, you never upgraded your HVA queue depth settings because you used to have older,
slower, crappier storage, right? So now that you have awesome storage, you can crank up those queue depth settings on the host level of your ESXi clusters, for example. So tools like this are invaluable to be able to troubleshoot this. And again, one of the cool things that Pure brings to the table in
addition to underlying storage. So we do have some quick demo now. This is going to be fairly short and compact because this is, of course, a compressed presentation. So the first thing I'm just going to do is just show you some quick examples of SP
Pressure Detector. This is just some setup here to make sure that batch mode memory grant feedback was not active. So utilizing SP Pressure Detector here, all I'm doing is just using the help function here. And you see that there's a whole bunch of different parameters, a lot of different ways that you can use this particular tool.
So this is insanely, insanely powerful and really allows you to dig into things around memory and disk pressure and so on and so forth, right? It's really, really, really cool. I strongly encourage you to check it out.So what I'm gonna do is I'm gonna check all, I'm gonna do a minimum disk latency of one millisecond, because this is just my local
laptop after all. And I'm gonna look at a CPU utilization of, ten seconds here. Oops. Wrong hotkey there. And now we can see some of the different output here. So I'm l- you know, I'm seeing my SQL Server wait types over the last couple of hours.
You know, I ran a little bit of workload like an hour or so ago. Average waits, average, latency per wait, and the, and the breakdown there. And then I also see a breakdown of my SQL Server data files on the file information, latency information, and so on and so forth. So I can see a wide variety of different information here about what's going on from an
IO perspective. So this is really cool. And so, you know, as you go through this code, and I encourage you to go through this code yourself, it's all published on GitHub, here's a quick cheat sheet for you. I'm just gonna do one quick, simple example.
So this is a bunch of code that makes Sebastian sad. It's just some workload code. So I've run that, and then I'm gonna take a quick look at this just to see what some of the other results and the output happens to be. Oh, yeah, by the way, if t- as I scroll further down, I forgot to do that earlier,
there's other pieces of information even going further down about TempDB, about, you know, the different performance counters that are manifest within SQL Server as well. So you remember that you can get access to a lot of that other underlying information. so I could actually see, you know, where, actually it was against the cookbook demo database in this case, where some of this information had, changed or where I had seen
some different IO, stalling and stuff like that. Now, one other thing that I really like to, use is the sample seconds here. So, let's see if I do, if I do this, that's gonna keep running. So now while this is running, I take a sample at second one and at second five.
This is very similar to the sp_whoisactive functionality. Hopefully, you're using that, delay function in there as well. So that way I can see the underlying deltas. The deltas won't be reported for every single, every single metric, but it will be reported for many of the different metrics.
So now this way I can get a better sense of Here we go. Like, for example, looking at the, you know, the Windows counters, for example, the first counter value, the second counter value, the total difference, total difference per second. Here's my sample, time period right here. So if I happen to be in the midst of a performance troubleshooting issue right now,
this is a great way to say, "You know what? I'm gonna take a ten-second sample, see what's going on, and try and get a better sense of, you know, what's going on from the IO perspective." So this is a really, really powerful tool. There's so much to really dig deep into. So again, this is just a very brief demo just to kinda introduce it.
The second thing I wanna show you is Resource Monitor. So I'm gonna jump into my virtual machine here. So first of all, in order to get at this, underneath here I happen to have Task Manager open, okay? So once I pop open Task Manager, and I go to the Performance tab, how many people in here have actually bothered tapping on this
particular button? I will confess, I didn't really discover this until about four or five years ago when, my colleague and good friend Anthony Nocentino actually shared this with me. I'm like, "What? This is a thing? I've never looked at this before." And this can give me some really cool information about what's actually going on inside of SQL Server.
Let me fire up my workload once again. So, so I gotta, bop back over to, this. I'm gonna do this as my workload, which is I'm just gonna run a backup multiple times, which will immediately drive, IO workload, and then I'm gonna jump back here. And then zoom in. Okay.
So I have preselected the Disk tab here, but you see that I can go to all the, all sorts of different tabs, and I've preselected the SQLServer, process right now. Because I'm zoomed in, everything is paused. But you can see that I'm actually, you know, I've sorted by read bytes per second, so we're actually doing some underlying work, and then I can actually see the different files that
are being operated against. Did the backup not kick off, or did I have an error underneath it? I should be seeing some other stuff here. One moment. Oh, did I Am I running the wrong backup here? I may have goofed that one.
We'll run this backup . How about that? That's better. Apologies about that. I put it in script one but not script two. Of course, I had made some changes. So now that I actually see that there's read activity going against, this sandbox database
that I'm backing, executing a backup from. So I see a bunch of read activity here. So this is pretty cool, and I see write activity out to my backup file, and I see the corresponding write activity here. So this is another really cool way to kinda dig in to see what's going on with the SQL
Server process and what underlying physical files is it interacting with at any given point in time. So again, depending on how you're troubleshooting, what you're troubleshooting, if you're actively looking at something, this may be really, really powerful to see, what might g- be going on. I also like using this for backup troubleshooting as well if I'm not getting the
backup throughput that I'm seeing. "Hey, what's going on here from the actual read and the write perspective, for, my backup operation?" All right. So that concludes the brief demo. If nothing else, you know, those are just a handful of different tools, but really the
most powerful tool in your arsenal is the question, and I cannot stress that enough. So this is a different Reddit story anecdote that I'm gonna share with you. I'm somewhat active on the SQL Server subreddit. and this particular, case, someone had asked, you know, that they're trying to load a whole bunch of data, twenty million datasets without overloading, you know, overloading it,
overloading what. And they mentioned that they were using, bulk insert drop and reloads, and that, quote, "Statements are overwhelming the resources and slowing the API down," the API of whatever their application happened to be. There was not a lot of information in here. So a bunch of people started answering and saying, "Oh, it could be this, it could be
this, could be," you know, or, you know, "Take a look at this, take a look at that," blah, blah, blah, blah. They all started spewing possible solutions, butNo one stopped to ask a question. Frankly, I'm the one who stopped to ask a question. Overwhelming the resources, what do you mean by that?
Help me understand what you mean by overwhelming the resources. So how are you bottlenecking is the question I ask. Give me the discrete symptoms. So the answer was essentially this, "Oh, we're in Azure SQL." Oh, okay. That's a huge, key, detail right there, Azure SQL.
And then the main bottleneck is on log I/O. Log I/O you say? Well, Azure SQL Database works a bit differently when it comes to log I/O. So what are you using in Azure SQL DB? You know, what level of service do you happen to have?
"Oh, we're doing Azure SQL DB Gen5 one vCore." One vCore, really? Remember, first of all, I said, CPU is, dispatches I/O. So, if I only have one vCore, that's gonna limit me from an I/O perspective. But even more interestingly is this specific nuance, and this is, at least, true at the time of the write- this writing.
A Gen5, Azure SQL DB has a, oops, has a defined maximum log rate of four and a half megabytes per second. So even if CPU is not, you know, being completely tapped out, you have a You're capped on your max log rate as well. So I'm like, full stop.
Before you look at any of the other possible solutions anyone else told you, upsize that Azure, SQL DB. "By the way, is this your production DB?" "Yeah, it is." "Seriously, that's your prod DB?" Obviously, it was a tiny app, and it was more of a prototype prod application, but yeah. That's one of those things of, "Sorry, just throw more vCores at it and, call it a day,
and you'll get more log, log throughput." All right, so we have about nine minutes left, about, nine minutes worth of content as well. So yes, it's almost time for Sebastian's walk. So to summarize this presentation, we've explored I/O pathways, and hopefully now you have a much better appreciation of everything in between.
We've talked a little about CPU and RAM contention, and I've shared some interesting anecdotes, about throughput bottlenecks as well, and why you need to be very mindful of that. And also, if nothing else, I hope you take away a better understanding of queuing, especially if you're virtualized.
That's something you definitely want to look into. And again, there are resource slides at the end of this presentation. There's like four of them all available up on my GitHub, so you can really dig deep into all of this. But sometimes people just kinda want a easy button.
Like, you know, Sebastian, will hang out at the bottom of the stairs here, and he won't come up until you go down and carry him up the stairs, and frankly, some organizations are like that. So wouldn't it be really awesome if your environment was literally forty times faster? Yes, this is the commercial bit.
It's only be a few minutes. So, you know, Pure of course, brings to the table some really, really, really powerful hardware and this forty x faster is actually not marketing fluff or anything else like that. This was a true outcome with a true customer workload. A very high-end, financial customer of ours that used to have their SQL Servers on direct
attached storage. They switched over to our FlashArray//X line, which is the top-tier, low latency, high through, high-end transactional workload, type offering, and they literally saw a forty x improvement with their SQL Server workloads. They were using several, different high-end, workloads that were bottlenecking.
Forty x performance improvement. That was an amazing business outcome. The point of this slide, though, is that, you know, I've talked about the XL line, but we have a number of different products that fulfill whatever your need happens to be from a workload perspective, 'cause not everyone is a high-end trans-transactional workload.
Some people have just, you know, general transactional workloads. Some people are more analytical workloads, more data warehousing, reporting, and analytics and analysis. so you might need something that's more throughput-heavy rather than, more of a throughput horsepower-heavy and powerhouse rather than a latency powerhouse.
So just understand that we offer a wide variety of different products to fill and meet whatever s- whatever workload it is that, you need. And the other thing that Pure really brings to the table is this. We are not just a bunch of disks, or in this case, flash storage. We are software-defined storage, and we bring a whole slew of collection of software
capabilities to the table that, especially for us DBAs, will empower us to bring operational outcomes to make our lives easier. Top-tier performance, for example, our performance is consistent across the board. Some storage vendors out there will have arrays that have a caching layer, but if you fill up that cache and you overwhelm that cache, your performance is gonna tank.
Our underlying architecture is not the case. We will always give you consistent performance all across the board. One of the other things that I talk to customers about on an almost daily basis is storage array level snapshots. Yes, many of us have had bad experiences with snapshots in the past on legacy storage, but
because of our architecture underneath the covers and a whole other bunch of nuances that I can, dig deeper into, storage array level snapshots are a very powerful tool for things like non-prod, you know, like non-prod database refreshes. we oftentimes have to take a backup and restore it for QA, staging, and dev and whatnot. Wouldn't it be really awesome just to use a, a
storage array snapshot and do that work instead? Also, SQL Server 2022 introduced T-SQL snapshot backup. Yes, I used the word snapshot and backup in the same sentence. But this enables you to now take s- application consistent snapshots as a form of a backup operation.
It's a variation of the backup database command. and actually be able to now truly back up a database in conjunction with a storage array level snapshot in literally a matter of seconds. so that database could be thirty, forty, fifty terabytes, I don't care. I've now f- done a full backup on it, or in this case, a T-SQL snapshot backup.
Anthony Nocentino and Bob Ward did an amazing, presentation together where they talk about this capability, 'cause this is not just a Pure capability, this is Pure in conjunction with what Microsoft has done behind the scenes. But this is, this is a seriously powerful outcome. Many of my customers are making use now of T-SQL snapshot backups-Because, you know, we
now live in the era where I have a big behemoth database that, you know, if it's twenty, thirty, forty terabytes in size, good luck trying to back that up in one night, you know, using a f- old, traditional method. And, you know, s- application consistent snapshots prior to twenty twenty-two required the VSS framework, which many of us have had bad experiences with it.
and that's why twenty twenty-two is a game changer. No more VSS, so you get truly reliant, application consistent snapshot, snapshot backups, so. And there's a number of other different capabilities that we bring to the table as well. But understand that, you know, Pure is not
just fast for you, but we bring you all sorts of other cool things, such as the snapshot capabilities that I talked about, because we are software-defined storage. All right. So just to kinda wrap things up, remember that performance tuners, you don't need deep expertise in everything, but having a familiarity should be that end goal, such that you can refer back to materials like this
particular presentation and all of the different resources that I gave to you. But in the end, sometimes you just gotta bite the bullet and pay the technical debt and just rewrite that terrible code. This is a trilogy, by the way. So this is the, this particular presentation is a culmination, or part three of two other
presentations that I've done over the years. so check these out. I, I believe I've done both of these for MS SQL Tips, so you can just look for my name on MS SQL Tips and, go searching, under the webinar archive there. otherwise there are four pages worth of resources here.
there's a lot of deep dive stuff here. Bob Dorr, who is, one of the other one of the two Bobs. Y- most of us have known of Bob Ward, but if you've done any internal stuff, you'll also know of Bob Dorr, who's infamous, at SQL Server, or, or with SQL Server at Microsoft. and he's done a lot of amazing deep work and, published a lot of deep work around that.
some more resources about the, you know, error issues, talking a bit about if you wanna utilize things like, Resource Monitor or SP Pressure Detector as well. And then here's the final page on, filter driver resources as well. Again, all of this is available up on my GitHub. I'll be uploading an, an updated version of this particular presentation.
and wow, I managed to clock in at fifty-eight minutes, so fantastic. but at this point I'm gonna take questions, and I'm glancing over at the, chat here. Jeremy, thank you. All right, so question number one. "For large LOB/BLOB data, how do we improve, improve performance?" That's a really tough question. Oh, yes, and by the way, while I'm answering
these questions, if you could, take a moment just to quickly answer, the poll here that, you know, that's been thrown up. That's a really difficult question because the thing is LOB/BLOB requires extra IO. I talk about this in another particular presentation of mine. So if possible, nowadays with what's available to us, I would strongly encourage you to look
into, is it possible to actually rip that LOB or BLOB data out of the database and put it somewhere else? Things like data virtualization are absolutely a thing. If you look up my name and, mitigating database bloat in your databases, that's, one of the other presentations I've done recently-ish about data virtualization, which was introduced in twenty twenty-two, that it
now allows you to extract, data and throw them into Parquet files, which then can the- then be parked into, S3 object storage. And depending on the scenario and use case and the nature of this LOB data, may actually be a really good solution for that. Or if that LOB or BLOB data is binary information, absolutely rip that out and park
that, in like a data lake, for example. "How does indexing play into IO performance?" Great question. I have an entire presentation about that. Indexing absolutely plays into IO performance, but I cannot answer that in the next ten seconds.
"How do you find the IO performance of each of your devices and drivers? Is that information anywhere within Windows or just in documentation?" Typically speaking, like for my actual devices and the drivers, it will be in the underlying product documentation. So for example, in some of the anecdotes that I shared, like, yes, we went out to each of
the different vendor websites and actually pulled documentation from them to say like, "Okay, this HBA is capable of doing this. With this particular driver, we're on this particular version. Oh, there was a firmware upgrade to this driver." I've had that scenario where, oh, there's a firmware upgrade to this driver, and now it's capable of doing X, Y, or Z now.
So, yeah, so frankly, you're oftentimes gonna have to do that deep homework. Or now we have AI tools that may be able to do it for us, so. All right. "So what Windows Performance Monitor/System Monitor counters do you recommend monitoring? Can you give us some hints?" Go to the resources slide.
There have been multiple presentations about that. I cover a lot of that material in, the prior to, presentations as well, which is one of the reasons why I didn't touch upon it here. Again, this session is essentially a trilogy. "How do you configure SQL Server storage for OLTP versus analytics?" So
th- I'm trying to figure out how to best answer that quest- 'cause of course there's nuances to it, like whether you're virtualized, whether you're on a SAN, whether you're bare metal, what your underlying storage is. But the point is, is that regardless of whether you're OLTP or anal- or, you know, O- O-OLAP or O- whatever, regardless of whether it is, you want to think about your IO
pathways and are you maximizing the IO pathways?For example, with a VMware virtual machine, if you happen to have one SCSI adapter, that only gives you one I/O pathway for all of your underlying I/O for that virtual machine. If I happen to now have four, SC- PVSCSI adapters, for example, now I can take the virtual disk drives inside of Windows.
Maybe I have a data f- drive, a log drive, temp DB, and then everything else, and I might distribute my workload round robin-ish across those four PVSCSI adapters. Or maybe I have that massive data warehouse where I have multiple data files. I might carve those out into multiple data, disks, virtual disks, such that then I can assign each one of those to an individual SCSI ad- SCSI adapter on their virtual machine to
try and once again distribute the I/O amongst my different pathways, for example. So that's one example of how I might answer that question. Jeremy, are there any other questions? I believe I've hit all five. Yep. Thank you so much. Just wanna let everyone
know we do have a poll up right now. There again, are you interested in learning more about EverPure solutions? So if you're interested in perhaps a personal demo or meeting, with some of the folks at EverPure to kinda work through your exact scenario, please register for that. if you're interested in more technical information, there again, I know Andy kinda
just touched the tip of the iceberg with what Pure has to offer. there again, they have even more f- even more functionality related to things like ransomware. there again, performance is huge. operations, there's support for both the cloud, and on-prem.
So if you're interested in that, please respond to that. If you're interested in proof of concept, please respond to that as well. So we're gonna keep the poll up for about another minute or so. If you could please respond, that would be great. I also pushed out two different, URLs, so you can definitely go check those out.
one's related to SQL Server 2025, and the other is more about database infrastructure. so please check out those URLs. We'll include those in the post-session emails as well. And then if you actually are in the GoToWebinar controls, there's a PDF there to check out, and you can actually download that right now.
That's actually a white paper from, Pure Storage to, there again, kinda get some, firsthand technical information directly from Pure. So if everyone could please respond to the poll now. We're gonna go ahead and close the poll in about 10 seconds and wrap up. I know we're a few minutes over, but Andy did cover a ton of information.
Also wanna make sure everyone knows that today's session is being recorded, and we'll be sending a follow-up email after today's session, if you could che-check out the archive, there again on MS SQL Tips. So I'm gonna go ahead and end the poll right now, Andy. any final words for today?
if nothing else, I just wanna say thank you again, everyone, for, spending, the last hour or so with me. Please keep in touch. I've shared, a couple of the places I hang out these days, you know, in the SQL Slack community and then on, you know, on the Reddit, SQL Server, subreddit over there. Of course, there's my contact information.
And don't forget my GitHub if nothing else. my GitHub will have, you know, all of the, resources that you need. and for all of my presentations, will be up there. So if nothing else, thank you again so much. It's been a pleasure, and I hope to, see you all again soon.
Absolutely. Thank you so much, Andy. You definitely have an open invitation to come back any point in time in the future. You're getting a lot of thumbs up, claps, hearts, so thank you guys for all the love for Andy. once again, this is Jeremy Kadlec.
Have a great day, and please tell a friend about msqltips.com. Thank you. Cheers. Thank you very much, everyone.
Andy Yun
Consulting Field Solutions Architect, Everpure
You’re a T-SQL performance tuner and know that I/O is a critical factor in overall query performance. But you’re also not intimately familiar with the lifecycle of I/O in SQL Server, particularly on the hardware layer. Maybe you’ve struggled trying to determine if an I/O bottleneck originates in the code or within the hardware stack?
Join me for an in-depth, advanced but essential “what you need to know” exploration of SQL Server I/O. We will demystify the relationship and lifecycle of I/O starting from an execution plan operator, to the storage engine, through your physical server, and out to your underlying storage subsystem. Then we will apply this knowledge to example use cases.
When you leave, your new knowledge will help you properly triage the origins and root cause of your I/O related performance issues.
We Also Recommend...
Personalize for Me
My Updates
No updates at this time.