T-SQL Tuesday: The last ticket I closed

February 13, 2024 Andy 4

For this month’s T-SQL Tuesday, Brent Ozar (blog|Instagram) asks us to describe the most recent ticket we closed. “We had a pretty significant wait spike…” The literal last ticket I closed was “please run this script in production…”, and I don’t think it would be … [Read More]

Stop trying to shrink tempdb files

April 28, 2020 Andy 1

Stop shrinking your tempdb data files I recently wrote about growing, shrinking, and removing tempdb files. In that article I explained that SQL Server won’t move a page that contains an internal worktable object, and thus trying to shrink tempdb files can be futile. Today, … [Read More]

When STRING_SPLIT() falls short

March 20, 2020 Andy 0

This morning, my friend Aaron Bertrand (blog|twitter) posted a plea for help with STRING_SPLIT() improvements. I’m very much in Aaron’s corner on this, having written about the olden days myself. Why STRING_SPLIT() is supposed to be awesome CLR was fast, but inaccessible to many DBAs. … [Read More]

Code to purge data based on creation date

April 4, 2019 Andy 6

Yesterday, I talked about batching deletes, and the day before I talked about how much I like to delete data, and why it’s necessary to do it, despite being a data pack rat. Today, let’s look at just one scenario, and how I like to handle it. In my experience, this is one of the most common purge requirements (and probably the easiest), so first, let’s look at the business requirements.

The thrill of purging old data

April 2, 2019 Andy 0

DBAs & Data professionals tend to be digital packrats. My personal Google Drive is filled with random files that I refused to part with–even though it’s of questionable value. I lament that I do not have a copy of every paper I typed in high school or college–and I envy those who do. You never know when you’ll need notes from that meeting 6 years ago, or when you’ll need that funny GIF you created for an inside joke you no longer remember.

Performance Myths: The query result cache

July 23, 2018 Andy 0

I was recently doing a training session when a developer commented that it was OK to run an expensive query twice because on the second execution, SQL Server would use the “results cache” and be “practically free”. It’s not the first time I’ve heard someone refer to a “results cache” in SQL Server. If you don’t know better, you might think SQL Server has a “results cache” because the second execution of a query is often faster.