Today I was working on some code samples for a user question, and I hit a weird roadblock.
There was a bunch of garbage in my execution plan that I couldn’t explain. And by ‘garbage’, I mean a nested loop to a whole branch of code that I hadn’t asked SQL Server to run – and a warning about an implicit conversion possibly causing problems with the quality of my execution plan.
Sometimes you know a query is out there, but it’s hard to find the exact query.
SQL Server stores query execution plans in cache, but it can be difficult to query the XML it stores. And there’s always a chance that the query plan won’t be there, due to memory pressure, recompile hints, or the plan cache being cleared by setting changes or other administrative actions.
Over the years, I’ve come across a pattern fairly frequently: an application in an OLTP database periodically creates new tables, loads some data into them and fixes it up, then does a switcheroo and replaces old tables with the new tables.
This can cause major problems with blocking if anyone else is querying the table.
I don’t find bugs in SQL Server all that often. I find bugs in my own code all the time.
In this case I double checked, and I think it’s a real SQL Server bug.
When I was recently testing tempdb file usage, I used an Extended Events session that used SQL Server’s histogram target to track sqlserver.file_read events in the tempdb database for a specific session.
I recently received a question from a vendor about databases created by software vendors.
I’m not always the best at learning to use graphical interfaces. Maybe that’s why I often don’t like them?
I’m sometimes asked if the number of CPU cores used by a query determines the number of tempdb files that the query can use.
Good news: even a single threaded query can use multiple tempdb data files.
You can’t do everything with a columnstore index – but SQL Server’s optimizer can get pretty creative so it can use a columnstore index in ways you might not expect.
Deadlock graphs are incredibly helpful for figuring out why queries are getting automatically killed off by SQL Server.
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.
