For this month’s TSQLTuesday, I asked y’all to describe the most recent issues you closed.

If you ask someone in IT, “What do you do for a living?” they struggle with job titles. They say things like:

• “Well, my job title is sysadmin, but I spend most of my time in data”
• “They call me a DBA, but I write a lot of reports”
• “I was hired years ago as a developer, but I don’t really have a job title, and right now I’m working on a cloud migration”

So when I’m meeting a new team and learning what they do,  I’ve found it helpful to ask, “What specifically was the last issue you closed?” Note that I don’t ask, “What are you working on now?” because that tends to lead to long-term projects that people want to do, but not necessarily what they’re paid to do. If you ask them about the last specific task they checked off, that’s usually related to something the company demands that they do because it’s urgent. It leads to fun discoveries about what people think they do, versus why managers really keep them around on the payroll.

It’s also fun because sometimes people say, “Is AI going to take my job?” Well, to find out, let’s look at what you’re actually doing, and ask, “Could AI automate that today?” The answers usually make it obvious that your job is still safe, for better or worse.

Your Blog Posts

Closing Out the Cancer Ticket – Hugo Kornelis had unquestionably the toughest issue: surviving leukemia. I’m so happy to read that he’s doing well and getting back to what he loves.

The Disaster Recovery Site Went Down – Eitan Blumin’s client did an exercise in the production environment and managed to bring down the DR site as well. Oops! The post explains the challenges with configuring quorum.

Importing Flat Files with BCP – Peter Schott gets the task that every data professional gets. Learn a tool to do this – any tool, doesn’t matter which one it is – and once you’ve learned it, you’ll rely on it for the rest of your career. In this case for Peter, it’s BCP.

Extracting Errors from Unstructured Text Logs – Jeff Mlakar had to figure out the aftermath from a “crime scene” (I love that expression) and used regular expressions in KQL to do it.

The Monitoring Went Down – Koen Verbeeck asks the classic question of, who monitors the monitoring software? Because when it goes down, all failures kinda snowball into larger issues.

Fixing a SQL Server 2022 Regression – when Deborah Melkin’s shop upgraded to SQL Server 2022, she found that a stored proc was taking way longer, and used sp_WhoIsActive and Query Store to diagnose the problem.

Visualizing F1 Team Journeys in Power BI – SQLDevDBA was tasked with showing how far customers will travel for one of their events. The first step was to try it in their home lab using public data. He even streamed a real-time video of the process! It’s 4 hours long, but it’s broken up into chapters listed in the video’s description.

Retrieving DAX in Microsoft Fabric – Kevin Chant didn’t have the permissions to edit the data models, so he wrote a Python notebook using the new SemPy library.

Slow Deletes Due to Foreign Keys – Aaron Bertrand couldn’t believe a simple delete could be so slow – until he checked out the query plan.

Slow Merge Due to Foreign Keys – Erik Darling hit a perfect storm of problems that ended up with no other option but to abandon referential integrity.

Problems Sending Mail – Shane O’Neill troubleshoots sp_send_dbmail and ends up in the horrible land of Kerberos.

Troubleshooting IO Spikes – Andy Mallon noticed that during log backups, the data files were active too, which shouldn’t be happening.

Smoothing IO Spikes – Michael J. Swart was tasked with an issue that sounds similar, but is wildly different: modeling IO and then figuring out how to smooth out the peaks with Resource Governor for server consolidation.

Splitting up CHECKDB – Mikey Bronowski had to split up corruption checking across lots of Agent jobs.

Checking Installed Versions – Lucas Kartawidjaja was tasked with finding out which clients were running unpatched OLEDB and ODBC drivers.

Reading the Documentation – Justin Bird has to deal with something that’ll ring true to all of us. Folks open issues because they haven’t read the fine manual.

Troubleshooting Replication – Deepthi Goguri has my sympathies because I’ve been there too, having to rebuild a complex replication setup from scratch when I wasn’t exactly functioning at my peak capacity.

Configuring Multiple Environments for Clients – Chad Callihan has to set things up for other folks every couple of months or so. It’s that awkward level of work: just enough work, and pops up just often enough, that it’s probably too time-consuming to automate.

Detecting File Changes – Steve Jones needed to stop a deployment if the contents of a file changed, so he used checksums.

A Post About Nothing – Rob Farley maintains his streak of blogging for every T-SQL Tuesday, and he keeps it up here without following the instructions in the T-SQL Tuesday request, ha ha ho ho. His post reminds me of the old saying about Seinfeld: it was a show about nothing, and yet we loved it. No hugging, no learning.

Performance emergency caused by GRANT PERMISSIONS by Brent Ozar – in which someone added a GRANT to the end of some stored procedures, and the GRANT was actually running every time the proc ran.

What Did We Learn?

Y’all do a lot of different tasks! We’re data professionals, but the work we do is all over the map. The posts covered different tools, different languages, different features, you name it. Furthermore, a lot of it boiled down to, “We have a new problem, and we had to do something new in order to solve it.”

Many of these posts cover completely new topics, too. For example, there just hasn’t been a good blog post before about how to model what IO consumption will look like after it’s been throttled with Resource Governor. That means this job isn’t going to be replaced by ChatGPT because ChatGPT simply couldn’t have learned this from something else before. (Go ahead, try to reproduce those same end results with ChatGPT – I’ll wait.)

That doesn’t mean AI won’t change your job over the coming years and decades. It will, just as the Internet changed IT jobs, and then Google changed it, and then Stack Overflow changed it. These are all new tools, and your company is going to need people like you who know how to operate tools proficiently.

Hope y’all had fun writing & reading! If you want to host a future T-SQL Tuesday episode, leave a comment on this post over here.