A lot of stored procedures have multiple statements and determining the most costly statement in a given proc is a very common task. After all, you want to focus your time and efforts on fixing the things that cause you the most pain. You simply don't have the time to tune every single statement in every single procedure. So, identifying the most costly statement is vital. Happily, Extended Events are here to help. Finding a Costly Statement Query tuning is initially an act of discovery. Which queries, batches, procedures are inflicting the most pain on us. That pain could be measured a bunch of ways. The three most common, in particular order, are: Frequency with with a given query/batch/procedure is called.Resources used by that query.Length of time that it takes…
I love questions. Most of all, I love questions I can answer. I spotted this question recently: How can I use Profiler to capture execution plans for queries over a certain duration? Oh, that's easy. You don't use Profiler. You use Extended Events. Query_post_execution_showplan Extended events are just better than Profiler. Period. One of many things that is superior is the way in which the events are configured. Take for example query_post_execution_showplan. Here are the fields it captures: This event will capture execution plans plus runtime metrics. It can easily be filtered on any of the fields listed, and you can even add the database_name field if you want. So, to filter by duration is pretty simple: CREATE EVENT SESSION ExecPlansDuration ON SERVER ADD EVENT sqlserver.query_post_execution_showplan (WHERE ([duration] > (1000000)))…
The moment you decide you want to monitor your SQL Server instance for query behavior, you're going to be forced to make a bunch of choices. Further, all these choices lead to problems that you're going to have to deal with. Some of the problems are obvious. For example, you decided to capture all the statements run against the system. That's a lot of data you'll have to be prepared to manage. However, other problems are extremely subtle and can really be a pain. For example, how do you differentiate between a query run by a person in SQL Server Management Studio and the queries that SSMS itself runs against the system? Queries From SSMS Let's say I'm interested in capturing both the batch completed event and the statement completed…
What's the story with AWS RDS and SQL Server deadlocks? I'm approaching AWS RDS like I was taking on a new role at a new organization. Do we have backups in place? Yes, great. Can I test them? Yes. Do they meet our RTO & RPO? Yes. Moving on. What have we got for monitoring? AWS RDS has a good percentage of the fundamentals. Now, it's laid out a little oddly. You have the stuff going through CloudWatch which is largely OS oriented. Then you have enhanced monitoring, which you have to turn on, which covers eight key metrics for SQL Server. Finally, you can enable Performance Insights which gives you metrics on query behaviors (and yeah, any or all of these may be the subject of upcoming blog posts).…
I'm expanding my skill set into AWS in a big way. So, one of the things I do when I'm learning a technology is to write blog posts about that tech. So, prepare yourself for a bunch of info on AWS. I'll be working with RDS, which will include SQL Server & PostgreSQL for certain. I'll also be posting quite a bit on AWS DevOps as I get into it. The usual stuff, including SQL Server, query tuning, Extended Events, Azure, Azure DevOps, and all the rest is not going away. I'm just adding another topic. Today, we're getting started on AWS RDS. Creating an RDS Instance The thing is, there's a lot of documentation available on getting started on AWS RDS, directly from Amazon. It's embedded neatly into the…
The general idea for this question came from dba.stackexchange.com: could we, and if we can, how, get row counts after execution. I was intrigued with the idea, so I ran some tests and did a little digging. I boiled it all down in the answer at the link, but I figured I could share a little here as well. Properly Retrieve Row Counts After Execution The right way to do this is obvious and simple. Before you need it, set up an Extended Events session. Done. The only question is what goes into the Session. First blush, sql_batch_completed and/or rpc_completed. Both will return a rows affected value. Although, interestingly, the row_count value is documented as rows returned. However, it's both. But, if you really want to get picky, batches and…
One of the most frequent questions you'll hear online is how to determine if a particular index is in use. There is no perfect answer to this question. You can look at the sys.dm_db_index_usage_stats to get a pretty good picture of whether or not an index is in use. However, this DMV has a few holes through which you could be mislead. I thought of another way to get an idea of how and where an index is being used. This is also a flawed solution, but, still, an interesting one. What if we queried the information in Query Store? Indexes Used in Query Store Now Query Store itself doesn't store index usage statistics. It stores queries, wait statistics and runtime metrics on individual queries. All useful stuff. Oh, and,…
I am very excited to announce that I will be taking my paid precon content "Tools for SQL Server Query Performance Tuning" and presenting it for free. This is all a part of a new initiative from Redgate Software called Community Circle. Read about that here. I'll be livestreaming the precon once a week on the Redgate Youtube. So, please tune in, every Tuesday at 13:00CDT. Or, you can watch the recordings of the livestream, which we'll host on Youtube, free, forever. Between classes, you can ask questions, make comments, and generally interact through a Discord server I've set up here. We'll be covering a whole slew of topics from Query Store to DMVs, SQL Server Management Studio to Extended Events, Execution Plans and more, lots more. Whether you watch…
I am an introvert. Lots of people don't believe it, but it's true. However, I really do love getting to see my #SQLFamily all over the world in my travels with Redgate Software. Unfortunately, our current situation is such that almost no one is travelling and all the events are cancelled or postponed. Redgate Software is here to help. Redgate Streamed We've decided to pull together a virtual event with a bunch of great speakers, people you know and love, and put on an educational event that is absolutely community focused. Yeah, OK, it's virtual. However, we're going to do all we can to make it as much like an in-person event as possible. We're going to connect up a ton of different software to make it possible for the…
I absolutely love Query Store and the ability it provides to force a plan is amazing. However, there are a lot of little gotchas in this functionality. I just recently found one that has quite a far reaching effect. Let's talk about what happens when you DROP and then CREATE a stored procedure. Query Store and Plan Forcing Let's quickly recap how Query Store works and how Plan Forcing works. First, Query Store is driven by query, not by procedure, not by batch, but by query. Second, plan forcing is also by query. However, there are queries and there are queries. Let's take this as an example: CREATE PROC dbo.AddressByCity @City NVARCHAR(30) AS BEGIN SELECT a.AddressID, a.AddressLine1, a.AddressLine2, a.City, sp.Name AS StateProvinceName, a.PostalCode FROM Person.Address AS a JOIN Person.StateProvince AS…