The problem: by default, the Performance Monitor application in Windows doesn’t remember which counters you like to use.
This can mean a lot of clicking every single time you open perfmon.
An important query is suddenly slow. Is it because statistics are out of date? This is tricky to figure out, and updating statistics right away can make troubleshooting even harder. Learn how to use query execution plans to get to the heart of the question and find out if stats are really your problem, or if it’s something else. In this 35 minute episode: 00:39 SQL Server 2017 Announced 01:10 New video from Microsoft’s Joe Sack demonstrating Adaptive Query Processing 03:05 This week’s question: Are bad stats making my query slow?
You can enable and disable trace flags either globally or per-session in SQL Server.
This makes it seem like perhaps if you enable optimization trace flag 4199 globally for all sessions, you might be able to disable it per-session.
But that’s NOT how it works.
They made their index maintenance job smarter, and their queries got slower in production afterward. Could the index maintenance have harmed performance?
A while back, I got a question about enabling SQL Server’s ‘Optimize for Adhoc Workloads’ setting. The gist of the question was whether or not enabling this setting might free up extra memory on their SQL Server instance.
I had a fun highlight recently that I wanted to share. I’ve got a new poster idea I’m crazy about.
The dev server got bogged down during a deployment and lock timeouts were everywhere. Was the perfmon counter way off about how much memory was being used just for locks?
Trace Flag 4199 has been in SQL Server for a while. I’ve long thought of this as the “Bucket of Optimizer Hotfixes” trace flag: enabling it turns on a variety of hotfixes that have been implemented over the years.
As I’ve gotten back into the swing of a more-or-less regular work schedule after the initial launch of SQL Workbooks, I’ve revived some of my favorite work habits and free tools. Tracking time with Toggl I’m a big fan of the time-tracking tool Toggl. Their tools are easy to use, and even the free version is very cool. Tracking time may seem like a giant pain if you’re used to using terrible tools for it.
A little while back I wrote about Why Indexes Reduce Locks for Update and Delete Queries.
I got a great question on the post from Zac:
What’s not super clear is why it takes out a lock on the whole table, is this because it does a lock escalation as a result of the Full Scan? Will this always happen, or is there a threshold of record update counts where this will occur?
This was tough to answer in just a comment, so I promised a full post on the topic.
Copyright (c) 2024, Catalyze SQL, LLC; all rights reserved. Opinions expressed on this site are solely those of Kendra Little of Catalyze SQL, LLC. Content policy: Short excerpts of blog posts (3 sentences) may be republished, but longer excerpts and artwork cannot be shared without explicit permission.
