I wrote a short blog post about the misperception that Profiler was easier than Extended Events when it came to the core concept of "click, connect, BOOM, too much data". Go read it if you like, but I don't think it's actually an effective argument for how much easier Extended Events is than Profiler. Here, we're going to drill down on that concept in a real way. Let's start with a little clarification. I'm going to be a little lazy with my language. Trace is a scripted capture of events on a server. Profiler is a GUI for consuming a Trace, either live or from a file, and for creating Trace events. However, almost everyone refers to 'Profiler' when they mean either Trace or Profiler. I may do the same…
I know, I know, I'm on #teamexevents so I think that Extended Events can do no wrong, but let's address this thought that Profiler is easier. Now, if we're strictly talking knowledge, sure, if you've got a lot of experience with Profiler/Trace and very little with Extended Events, of course Profiler is easer. However, what I'm told is that Profiler doesn't require very much set up, while Extended Events does. That's just wrong, but let's put it to the test. The Test For the comparison, we're not going to do anything special with either tool. I'm just going to start collecting query data with the fewest possible clicks and/or key strokes. I'm going to use both tools short cuts to make this as fast as possible. The goal is, click,…
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…
The more you work with containers, the more you just want to work with containers. However, there are still reasons to have a virtual machine for some types of workloads. So, what if you want to work with containers inside a virtual machine. Is that possible? Yes, and shockingly easily. Enable Virtualization In Virtualization I knew from conversations I've had previously that running Docker inside a virtual machine was possible. I just didn't know the details. So, with a complete lack of knowledge, I did the most expedient thing possible: I installed Docker in a VM and started it up. Now, let's talk about my setup for a moment. My laptop is running HyperV as my hypervisor. You have to have some type of hypervisor for Docker to work. I'm…
I've always said if you're running a script for the first time in a production environment, you're doing it wrong. Testing is fundamental to technology, yet it is one of the single most frequently skipped processes. Let's talk about this a moment. Developing in Production Through my work, I travel quite a bit. That means I get to meet a lot of different people with varying circumstances on their systems. I've even met someone who did all their development directly in production. Why? They ran a software that ran an assembly line. There wasn't a test assembly line. Oh yeah, they had checks and validations that all their inputs and outputs were valid prior to ever putting the code into production. However, they had no mechanisms, of any kind, for…
In order to take advantage of R and Python (and Java in SQL Server 2019) directly from your SQL Server scripts, you'll be using the function sp_execute_external_script. When you see this code in use for the first time, it's going to remind you of sp_execute_sql. The very first thing I thought about was, "Oh no. Another SQL Injection vector." I have a little good news and a little bad news. It's Not SQL The first and most important thing to understand is, we're not talking about SQL. Let's start with looking at some code. This is straight from the examples in the Microsoft documentation linked above: DROP PROC IF EXISTS generate_iris_model; GO CREATE PROC generate_iris_model AS BEGIN EXEC sp_execute_external_script @language = N'R' , @script = N' library(e1071); irismodel <-naiveBayes(iris_data[,1:4], iris_data[,5]);…
In case you can't tell from some of my blog posts, I'm a bit of an advocate for DevOps. I'm extremely fortunate in my employer, Redgate Software, that they are also huge advocates for DevOps. We not only teach it and promote it, and, oh yeah, make AWESOME tools for it, we practice DevOps in what we do. However, this post is not about DevOps. Instead, I'm trying to leverage some of the concepts of DevOps, Continuous Integration, Continuous Deployment, to arrive at some ideas around learning that I want to share. Pi-Hole Yesterday I spent several hours getting the software Pi-Hole set up for my home network. Now, this software really doesn't take several hours to set up. The reason it took me that long is because I hadn't…
I've been working in and around data for over 30 years now. My title has changed a number of times and is poised to change again. My responsibilities have also shifted fairly continuously over that time. Even though it has been more than 20 years since I first took on the title of DBA, some aspects of the job are the same. However, over that 20 years, a stack of new technologies and processes have fundamentally changed a whole swath of what I do. The DBA Song Remains the Same Are your servers online? Are all databases available? Did the data load process run successfully last night? When was the last time a backup was run on this database? I honestly don't care if you're in the cloud, on-premises, or…
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"…