Good question. I don’t have a clue. So let’s set up a test. I’ll create this stored procedure: CREATE PROCEDURE DL2e WITH ENCRYPTION AS BEGIN TRANSACTION UPDATE Purchasing.PurchaseOrderDetail SET OrderQty = 2 WHERE ProductID = 448 AND PurchaseOrderID = 1255; Then I’ll execute things in the following order. From one connection this query: UPDATE Purchasing.PurchaseOrderHeader SET Freight = Freight * 0.9 --9% discount on shipping WHERE PurchaseOrderID = 1255; From a second connection, my stored procedure: EXEC dbo.dl2e; Then, back on the first connection, this query: UPDATE Purchasing.PurchaseOrderDetail SET OrderQty = 4 WHERE ProductID = 448 AND PurchaseOrderID = 1255; That will generate a deadlock. It’s a straight-forward classic deadlock. I’m using extended events to capture the deadlock graph and the output looks like this: <deadlock> <victim-list> <victimProcess id="process472310928" />…
There are four different ways you can get information about deadlocks in your system. These are: traceflag 1204 traceflag 1222 trace events extended events For years I’ve been pushing traceflag 1222 as the best of the lot. Well, that’s over. I’ve been learning more and more about extended events and I’m currently in love with xml_deadlock_report event. Why? Simple, it has everything that traceflag 1222 has, but there are two glorious things about it. First, it’s not going to be filling up my error log with, for the error log, noise. Seriously. As much as I liked the information displayed from traceflag 1222, I didn’t like what it did to the log, but I saw it as a necessary evil. Second, it’s XML baby! That means you can set up…
Microsoft is supporting an effort by PragmaticWorks targeted at supporting technical training for returning veterans. I can’t think of a single better cause to throw some support behind. Not one. They’re going to donate money based on posts about #sqlfamily. Well done to Brian Knight (blog|twitter) and all the team at PragmaticWorks. I knew you were great people, I just didn’t know how great. Thanks to Microsoft and the SQL Server Team for their support of Brian. Oh, and for all the work you guys do with SQL Server. I may bitch about you guys more than you’d like, but it’s only because I live inside your software, constantly. I wouldn’t be there all the time if you didn’t do great work. Keep it up. We can talk about this…
I only half listened to the key notes. The party's the preceding night may have had something to do with it. First session was with Kalen Delaney on Plan Guides. She didn't really do plan guides though. Instead she talked about guiding plans. She is such a great presenter. I like her use of the language and precise definitions. Lubor Kollar (sp?) was in the room and made a point of standing up & addressing some of Kalen's info. My best take away was that plan guides (she covered those too) do not reduce compile time and can in fact increase compile time. Second best was the use of plan guides as a mechanism for testing since you can apply the guide, enable & disable, without rewriting the proc. Sessions…
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…
The first time you see a new execution plan that you're examining to fix a performance problem, something broken, whatever, you should always start by looking at the first operator. First Operator The first operator is easily discerned (with an exception). It's the very first thing you see in a graphical execution plan, at the top, on the left. It says SELECT in this case: This is regardless of how you capture the execution plan (with an exception). Whether you're looking at an execution plan from the plan cache, Query Store, or through SSMS, the execution plan, regardless of complexity, has this first operator. In this case, it says UPDATE: If you get an execution plan plus runtime metrics (previously referred to as an "actual" execution plan), you'll still see…
Starting with SQL Server 2016 Sp1 CU2, a new way of directly querying statistics, specifically the histogram, has been introduced: dm_db_stats_histogram. We've always been able to query the statistics using DBCC SHOW_STATISTICS. However, the output, three different result sets with three different structures, made automating access to statistics information a pain. Now, we have more capability through dm_db_stats_histogram. dm_db_stats_histogram To access the information in dm_db_stats_histogram, you just have to pass in the object_id and the statistics_id values for the statistics you're interested in like this: SELECT * FROM sys.dm_db_stats_histogram(OBJECT_ID('HumanResources.Employee'), 1) AS ddsh; It's very straight forward to use. The results look like this: Handy right? Now you can query the histogram directly. Yeah, I hear a few of you saying... and this helps me... how? Here's an example. This query…
[caption id="attachment_2827" align="alignleft" width="150"] This is me on the last cruise[/caption] In just a few more weeks I'll be setting sail on the first of two SQL Cruise events this year. I'm honored beyond my ability to appropriately express it to be included as one of the Technical Leads for both the cruise in February (7-14, 2015, I think there's a seat or two left) to the Caribbean and the one in June (14-21, 2015, definitely a couple of seats left) to the Mediterranean. Lest you think that this is just an excuse to hang out and drink, you ought to know a little about how sessions are presented on the cruise and the sessions I'm presenting. Don't mistake sessions on the boat for your typical one hour session at…
Red Gate visited three cities this year with our SQL in the City event; Pasadena, Atlanta and Charlotte. I just wanted to give you a quick assessment of how the events went from my point of view. Overall, each and every one of these events was awesome. I can safely say that because each and every one of these events provided something special, the opportunity to network with our peers and with the developers and project managers at Red Gate (who are also our peers, but not usually available to us). I both took part in the networking and stood back and watched it happen. I love seeing a bunch of data pro's sitting (or standing) in a circle exchanging war stories, ideas, questions, thoughts or suggestions. It means you…
If you asked me, prior to today, if I would type or say those words, I would have laughed right at you. But then, I saw this question on Ask SQL Server Central. It's from a college student, not yet twenty-one, who was considering paying his (assuming it's a guy since their handle is 'Eagle Scout') own way to the Summit and wondered if it would be worth it. It pains me to say that I suggested that he not do it. Don't get me wrong. I think the PASS Summit is probably the single greatest resource you have to advance your career. Where else can you go to get that broad a choice in training? Where else can you go to get that many of the leaders of our industry, specializing…