If you go through all the stuff I've written about Extended Events, you'll find that I use causality tracking quite a bit. However, I've never just talked about what causality tracking is and why I use it so frequently. Let's fix that issue now. Causality Tracking Causality tracking is quite simple to understand. It's property that you set for a given session. A session, of course, is defined by one or more events and a target. You can define things about a session, like it's name, when you define the session itself. Turning on, or enabling, causality tracking is just a matter of defining that the session will have causality tracking. It looks like this in the GUI: It looks like this in the T-SQL code: CREATE EVENT SESSION QueryBehavior…
For those who don't know, last week was the PASS Summit. It's an amazing event every year, but this last week, I saw a ton of indications that our peers are spotting the changing technology landscape largely defined by three tools, Docker, Git and DBATools. None of those indications resonated quite as much as this tweet from Kevin Hill: 3 things I can no longer justify ignoring: #dbatools Git and #Docker for my dev SQL work@cl @sqldbawithbeard @Kendra_Little and @unclebiguns @GFritchey, I blame you 🤪😂There’s more but those are top 3— SQL Cyclist (@Kevin3NF) November 9, 2019 There are a million things to learn about in our rapidly shifting technological landscape, but I think this assessment, especially the way it was put, "no longer justify ignoring" really nails some of…
So, you say you're a DBA. I say you're not. You say you're a system administrator. I say you're wrong. We are all coders now. Every single one of us. You are a coder. Put down the brick and let me explain. Automation There was a time when I would give a presentation to a room full of people and ask, "Who is using PowerShell right now?" and get, 15 hands out of a hundred. Last week at SQL in the City in London, the same question came up and most of the room raised their hands. What's changed? Automation. Automate all the things!!! The simple fact of the matter is, anything easy, repetitive, and quantifiable is, has been, or shortly will be, automated. You should not be spending your…
Those my friends are, in my opinion, one of the single most wonderful things on earth, white chocolate macadamia nut cookies. Now, you may not like those. So, picture your own, special, favorite indulgence. Not a common indulgence either. Something truly lovely and special. Something important to you. Got it? Good. Now, I want you to equate that indulgence, whatever it might be, with the fundamental security of your systems. Let's imagine for just a moment, that you're developing a new system using the ElasticSearch database, one of the most popular data management systems on the planet right now. Did you know, by default, the basic and trial versions of ElasticSearch have security disabled? So, probably, if you're in development, you started with a trial version. If you just moved…
I consider myself to be the most responsible for making such a huge deal about the differences between what is labeled as an Estimated Plan and an Actual Plan. I walked it back in the second edition of the Execution Plans book. Hugo and I completely debunked the issue in the third edition of the Execution Plans book. That is the one you should all be referencing now. As I like to joke, the guy who wrote the first two editions of the book was an idiot (and lest anyone take offense, let's be clear, I'm the idiot). Now, I'm trying my best to make this whole issue more clear. Let's talk about the "different" plans you can capture in SQL Server. Estimated Plan This is where you have a…
If you've been reading these Database Fundamentals posts, you've already seen the WHERE clause because of your use of it when manipulating data with DELETE and UPDATE statements. It's also been used several times earlier in this series to limit the values returned from a SELECT statement. The primary places where people run into trouble with T-SQL is in the JOIN criteria and the WHERE clause criteria. This occurs because they don’t understand well enough what the filters and operators they’re using will do. They end up returning too much data because they didn’t us the WHERE clause or misapplied it. They also filter too much data out. Just remember, there are even more functions than we go over here in this series. While these basic operators answer most needs,…
I love going to SQLSaturday events because I'm always asked questions that make me think. I was just at SQLSaturday Indianapolis (a great event, if you weren't there, you missed out). I was giving a session called "Extending DevOps to SQL Server" (which I'm giving this Saturday at SQLSaturday Providence). I was talking about the fact that I've been involved in successful DevOps implementations and I've been involved in failed DevOps implementations. The question that came up was, "What were the key differences between the failed and successful organizations?" Great Question. Management Buy-In I've seen attempts to implement DevOps strictly from the IT side of things. A relatively high functioning team recognizes the benefits an agile approach that's oriented towards improved collaboration between people that uses automation in support of…
Not really, but sort of. The beauty of containers, at least in a dev/test environment, is the ability to spin them up while you need them and then throw them away when you're done. Containers give you a bunch of functionality not otherwise available through a VM. However, once you've spun up a container, they're so dull. Why Are Containers Boring Grant? I'm so glad you asked. Last week I was presenting at SQLIntersection (great show, you should consider attending). I was talking about Query Store in SQL Server 2019. One person in the audience asked, "Can Query Store run inside a container?" I responded, "Great question, let's check." I then switched over to VS code to show this: docker run ` --name DemoSharedVol ` -p 1460:1433 ` -e "ACCEPT_EULA=Y"…
I've been writing a bunch about Azure Data Studio. I've also been recording videos on the topic. A comment I received recently asked how to export a database from Azure Data Studio. It made me want to explore the topic of exporting a database as it relates to Azure Data Studio. Export? When we say export, what exactly do we mean. It could be as simple as exporting data to a flat file for consumption in Excel or something. It could be creating a backup. Maybe we mean creating a bacpac file. We could also be looking at creating individual scripts for objects within the database. Finally, what about a full export of the database object definitions? Any or all of these could be what the question was about. So,…
Query Store plans and the plans in cache are identical, right? There won't be differences because the plan that is in cache is the plan that was used to execute the query. Similarly, the plan that is in the Query Store is the plan that was used to execute the query as well. Therefore, they will be the same. However, some small differences actually can show up. Differences Between Plans In order to compare the two plans, first, we need a query. Here's a stored procedure that I'm going to use to generate a plan that will be in cache and in the query store: CREATE PROC dbo.ProductTransactionHistoryByReference ( @ReferenceOrderID int ) AS BEGIN SELECT p.Name, p.ProductNumber, th.ReferenceOrderID FROM Production.Product AS p JOIN Production.TransactionHistory AS th ON th.ProductID = p.ProductID…