10Oct 2022 by Grant Fritchey No Comments

Check Every Metric

SQL Server
Recently, a person asked about the costs differences in an execution plan, referencing them as if they were performance measures. The key to understanding performance is to check every metric. When it comes to execution plans, I'm sure I've said this before, so please allow me to repeat myself. The cost numbers shown in an execution plan, which, barring a recompile, will be the same for an execution plan or an execution plan with runtime metrics (aka, estimated and actual plans), are not measures of performance. They do not represent actual metrics. Instead, they are calculations of a theoretical actual performance measurement. So, you can't look at two plans, with two costs, and say, "this plan will perform better." Instead, you can say, "this plan has a lower estimated cost."…
Read More
03Oct 2022 by Grant Fritchey 2 Comments

Function Vs. Performance

SQL Server
Recently I was looking through DBA.StackExchange when I saw a pretty simple question that I decided to answer. I went off, set up a test database and some test tables and quickly wrote a query to answer the question. I got it all formatted pretty and was on my way to post it when I saw that another answer was already there. Yeah. Identical to mine. Almost line for line. Well, nuts. I know. I'll write a blog post. The Setup The original poster had two tables that, frankly, are badly designed. However, they share enough data that they are "related" if not relational. Here's the code: CREATE DATABASE Testing; GO USE Testing; GO CREATE TABLE Table_A ( ID INT IDENTITY(1, 1), Score INT ); CREATE TABLE Table_B ( FromPoint…
Read More
19Sep 2022 by Grant Fritchey No Comments

Extended Events for Anything but Query Tuning: bulk_insert_usage

SQL Server
Wouldn't it be great to be able to directly monitor specific behaviors within SQL Server, like, oh, I don't know, knowing exactly when, and how, someone is using BULK INSERT? Well, you can, thanks to Extended Events through the bulk_insert_usage event. Bulk_insert_usage The BULK INSERT command is extremely useful within SQL Server. It's a way to move data into the database and provide some formatting on the way, efficiently, all through T-SQL. Hard to argue with the utility. Obviously, if you're doing traditional data collection through Trace or Extended Events, you'll see BULK INSERT commands within the T-SQL. However, Extended Events provides a specific event that tracks just the behavior of BULK INSERT: bulk_insert_usage. Documentation on this is somewhat sparse. Some of the best is from a standard source, Jason…
Read More
05Sep 2022 by Grant Fritchey No Comments

Database Fundamentals #33: Check Constraints from the GUI

Database Fundamentals, SQL Server
The other types of constraints are referred to as check constraints. They limit the data by defining a logical operation that checks the state of the data prior to allowing an insert or update to the table. The logical operation is not against other tables. The logic can be against multiple columns in the same table. Let’s start with a simple example. The business has determined that the transactions it’s recording will never be less than $10. As part of the business definition, they would like a constraint put in place that limits the TransactionAmount values in the Finance.FinancialTransaction table to only accept values that are greater than $10. Let’s create this constraint using the GUI and again, in the next post, using T-SQL. Check Constraint with the GUI We’ll…
Read More
15Aug 2022 by Grant Fritchey 1 Comment

Distributed Replay: The Little Engine That Almost Could

SQL Server
Honestly, sincerely, no kidding, I love Distributed Replay. Yes, I get it. Proof positive I'm an idiot. As we needed proof. To be a little fair to me, I love what Distributed Replay could have been, with a little more love. However, fact is, it's on the deprecation list for 2022. Which means, what minimal amount of love, if any, that Microsoft was giving to it, it's all gone, forever. Unlike the Little Engine That Could, turns out that Distributed Replay was the Little Engine That Almost Could, But Didn't. Really Didn't. Let's discuss it a bit. Distributed Replay The concept is wonderful. Capture a bunch of queries from your production system. Replay them on a non-production system for testing. Add in the idea of being able to chain together…
Read More
08Aug 2022 by Grant Fritchey No Comments

Extended Events for Anything but Query Tuning: Object Changes

SQL Server
I hear this one all the time: How do I find out who implemented object changes? I also get: Can I see the query that caused object changes? Let's take a look at how you might audit who is doing what and how to your databases. Object Changes in Extended Events If you open up the New Session window for Extended Events in SSMS, the easy way to track down events is to simply type into the box. Here, we care about capturing object changes, so I'm going to simply type object, then scroll a bit: There we are object_altered, object_created and object_deleted. These are the same events that you would see in Trace. Let's use the GUI and take a quick look at what fields they capture: That's in…
Read More
25Jul 2022 by Grant Fritchey No Comments

Database Fundamentals #32: Create Unique Constraints with T-SQL

Database Fundamentals, SQL Server
In the last Database Fundamentals post, I explained what a unique constraint was and how you can create them using the GUI. Using TSQL to create a constraint is very similar to the primary key and foreign key constraints that you created in this post. You can use either the ALTER TABLE command or create the constraint when you make the table with the CREATE TABLE command. Using CREATE TABLE to Make a Unique Constraint There aren’t any new tables we need for this post, so we’ll create a table that we can drop immediately as soon as we’re done experimenting. You should already be familiar with the CREATE TABLE statement (or follow the link above): CREATE TABLE dbo.ConstraintTest ( TestName VARCHAR(50), CONSTRAINT UniqueName UNIQUE (TestName) ); This script creates…
Read More
11Jul 2022 by Grant Fritchey No Comments

Extended Events for Anything But Query Tuning: xml_deadlock_report_filtered

SQL Server
One of my favorite little bits of information about Extended Events is the fact that everyone running a full instance of SQL Server has deadlock information available to them, even if they never enabled Trace Flag 1222 through the system_health session. That captures the xml_deadlock_report which has the full deadlock graph. However, what if you want to capture deadlock info, but, you're dealing the GDPR, and transmitting query values could be problematic? Enter xml_deadlock_report_filtered. xml_deadlock_report_filtered If you do a search for this event, you're not going to find much. Doesn't seem like anyone, including Microsoft, has bothered to document it. This is not going to be a comprehensive definition for all things xml_deadlock_report_filtered. However, I can show you why you might want to use it. This is a port of…
Read More
05Jul 2022 by Grant Fritchey 2 Comments

Extended Events for Anything But Query Tuning: Unique Constraint Violations

SQL Server
Most of the time when I talk about or demo Extended Events, I spend more time talking about query tuning (I have a problem). However, there are tons of things that you can do with Extended Events. Here's a little one that came up, auditing unique constraint violations. Unique Constraint Violations Whether we're talking a primary key or just a constraint, the error you get is number 2627 when you attempt to add a non-unique value. So, the code for a simple way to track this in Extended Events would look like this: CREATE EVENT SESSION [UniqueConstraintViolation] ON SERVER ADD EVENT sqlserver.error_reported (WHERE ([error_number] = (2627))); That's it. That's all you need. Probably, it'd be a good idea to output this to a file (that's usually what I do). However,…
Read More
11Apr 2022 by Grant Fritchey 7 Comments

Query Tuning and Easy Solutions

SQL Server
TLDR: There ain't one. I was privileged last week to be able to present a couple of sessions at the SQL Server and Azure SQL Conference (great event, I recommend it). One of my sessions was an intro to query tuning. Basically, I went through a bunch of common code smells and suggested different possible solutions. The one thing that came up, both from my own stories and the questions from the (engaged) audience, is just how much everyone wants a magic, run fast, switch. Query Tuning The Easy Way Here you go. The single easiest way to make your queries run faster: Just throw money at the problem. Buy more hardware. Buy bigger hardware. Get more disks and disk controllers (not just more disks). Go to the next highest…
Read More