I have a proper blog post coming out tomorrow for T-SQL Tuesday, but today, celebrate with me that SSMS 21 finally, at long last, fixes the irritating fact that the New Session window in SSMS for Extended Events always opened to the wrong size. Here's SSMS 20: At the bottom of the screen on the right, there's actually more to be seen. Now, every version of SSMS from 2012 to version 20 has hidden the Causality Tracking. If you resize the window (I was in the habit of maximizing it as soon as I opened it), you can see Causality Tracking. Here's SSMS 21: There it is! Causality Tracking! WHOOOP!! There's been a whole bunch of other, little, fixes all over SSMS 21, but this one, I'm excited about. Now,…
Just a quick one this morning. I'm on the road and haven't worked up a full blog post, apologies. I've been using the preview for SQL Server Management Studio 21 for a little over a week now. You should check it out. It's been mostly stable (I got a crash. I didn't report it because I couldn't replicate it). I think the most interesting thing has been how much it's largely the same. It's in a new home within Visual Studio. However, the majority of the behaviors I've hit so far have been normal. Heck, Redgate SQL Prompt is working for me and my team told me we don't support SSMS 21 yet. I've spent most of my time in Extended Events and the Live Data Window. So much of…
Another discussion in Gothenburg (such a great group of people) around Extended Events lead to a (admittedly, tiny) idea for an additional use for sp_statement_completed. The basics for sp_statement_completed are pretty straight forward. If you want to capture a procedure's behavior, you use rpc_completed. If you want to know about the individual statements within the procedure, you use sp_statement_completed. Now, I don't recommend turning this on across the board or without some good filtering in place because, it's likely to generate quite a bit of data. However, it can be useful, including in the following manner. What Path Did I Take? I've got a silly, example, procedure here: CREATE PROC dbo.PathTest ( @Path1 INT, @Path2 INT, @Path3 INT ) AS IF @Path1 = 1 PRINT 'Path 1'; ELSE IF @Path2…
I had an excellent group of people in Gothenburg Sweden when I taught there and I was asked: Can You See Who Forced a Plan? I didn't know the answer for certain, so I said what I always say: I don't know, but I'll see if I can find out. Query Store System Views One of the first places I'd look to see who forced a plan is the system views in Query Store. No, I don't think it'll be there, but it's worth a look. The obvious place it could be is sys.query_store_plan. After all, that's where a plan will be marked as is_forced. But you look through that and there's nothing about who forced a plan. And looking through the other views, there's nothing showing that. So, this…
I'm still learning PostgreSQL and one of the things I've been looking at a lot lately is instrumentation. What do I mean? Well, if you're in SQL Server, think, Dynamic Management Views (DMV), Extended Events, Query Store, <hack, spit> Trace <spit>. How do we know how long a query took to run? PostgreSQL can tell you, but, and this is one of those wild, cool, but, honestly, slightly frustrating things about PostgreSQL, not natively. Let's talk about it. Instrumentation If you connect up to a PostgreSQL database, you actually do have the equivalent of DMVs. It's called the Cumulative Statistics System. And yeah, it's a bunch of views on a bunch of functions. It displays all sorts of data about IO, tables, indexes, etc.. It will even show you acive…
Oh good gosh. Six months without a single blog post. Most important information: I'm not dead. Apologies. The issue is pretty simple. I'm getting old. Ha! Seriously though, I am suffering a bit from a lack of energy to do ALL the things and still maintain this blog. However, to hell with that. Time for a refresh. Watch this space. I'm going to be cleaning it up. Changing a few things. Also, getting back to posting. I don't think as many of the posts will be technical though. I'm going to start posting some leadership ideas and suggestions. I've been involved in community for a long time, and I want to see it keep going. I have received so much from the communities I'm involved with, I want to give…
A great question came up over at DBA.StackExchange regarding the query store reports time intervals: How can SQL Server's Query Store Reports show data for minute-length intervals, when "Statistics Collection Interval" is set to 1 hour? I was intrigued because it's not something I had thought about at all. How Does the Report Decided on Time? The first thing you need to know is that all performance information inside Query Store is aggregated. By default, the aggregation interval is 60 minutes. You can adjust that up or down (although, I wouldn't recommend making it too granular, you'll see a massive increase in storage size). It's aggregated because trying to capture every execution of every query, as anyone who has done it using Extended Events knows, is expensive and has a…
Once more, my apologies for being late on getting the T-SQL Tuesday announcement out. I have no excuse. However, our extended event on Extended Events (yes, I'm the third person to make this joke, yes, I'm blatantly stealing) still has several entries, so let's talk about them. Let's get mine out of the way. I was simply curious what the search engines revealed when I asked a pretty common question: how do you identify slow queries? What I found was, the answers on most search engines to this question are old, very old. Not to say wrong, but since many of them were created before a working version of Extended Events (let alone Query Store) was released, how could they tell you. On to actually good posts. One of my…
Last week I posted the results from using Extended Events to snoop on what happens inside an AWS RDS database. This week, I'm taking a look at what happens on Azure SQL Database. I'm using the same toolset again, if for no other reason that I'm consistent in my approach. So it's basically just rpc_completed & sql_batch_completed on the database in question. Let's check out the results. What Happens on Azure SQL Database I would be doing the same thing as before, breaking apart the batch commands from the stored procs and/or prepared statements. However, after 48 hours, I only have 116 of both, so I'm just going to combine them this time. The batch called most frequently, for a whopping total of 8 times over 48 hours, isn't even…
I was talking with some developers from my team about monitoring, and I said, "We all use the same tools," referring to other monitoring software. Then, it hit me. How is AWS collecting monitoring data on it's RDS servers, specifically, the SQL Server instances. So, I set out to determine what happens on AWS RDS when it comes to the native monitoring. The Setup This part should be as obvious as it is easy. I'm going to use Extended Events. I've written before about how AWS RDS supports Extended Events, so I won't repeat all that here. I'll just leave you with the session I'm running to see what happens on AWS RDS: CREATE EVENT SESSION [ExEventTesting] ON SERVER ADD EVENT sqlserver.rpc_completed, ADD EVENT sqlserver.sql_batch_completed ADD TARGET package0.event_file (SET filename…