A couple times a year, I go away for a week to think about what's working well, what I need to change, where our industry is going, and how I need to react. I usually do it on a cruise because the crappy internet makes it easier to disconnect and reflect, hahaha, and that's where…
I hope you never have to look for another job.
However, if you do, I wanna give you as much reinforcement as I can. If you're the kind of person who attends my live classes, pays attention, asks questions, and does the lab homework, you deserve to be able to brag about that. You deserve a public record of your work, something you can point to on my site that links directly to your LinkedIn, and a certificate you can put on your LinkedIn.
You're looking at page split numbers in a monitoring tool or Perfmon, and you've heard that page splits are bad, so you're lowering fill factor, expecting your page splits to go down.
You're monitoring the wrong number.
Next month on Saturday, October 17, I'll be speaking at the free Day of Data Orlando. Registration is open now.
The event is 8AM-4PM at the Seminole State College Sanford/Lake Mary Campus at 100 Weldon Boulevard, Partnership Building, Sanford, FL 32773.
Today I'm back in the home office, finishing up teaching Mastering Index Tuning and getting ready to head out on a Mexico cruise. Let's go through your top-voted questions from https://pollgab.com/room/brento.
https://www.youtube.com/watch?v=JQWMdAsL4Dc
I teach Microsoft SQL Server performance tuning in a 4-class rotation. The winter rotation is getting ready to start:
Fundamentals Week - November 2-6
Mastering Index Tuning - November 30-Dec 4
Mastering Query Tuning - January 11-15, 2027
Mastering Server Tuning - February 8-12, 2027
NOLOCK is bad and you probably shouldn't use it, but every time I mention that publicly, the pushback just keeps coming. I don't know why people so firmly believe that their situation couldn't possibly be affected by bad/random data from NOLOCK.
Today's misconception comes from a LinkedIn commenter telling me it's safe to use if you're doing index seeks. Hoo boy. Let's whip up a table with an index:
For this episode, I'm up in the mountains just outside Vegas, enjoying the nice cool temperatures, spending the weekend at Mount Charleston. Let's go through your top-voted questions from https://pollgab.com/room/brento.
https://www.youtube.com/watch?v=GN31TnYVdgI
By popular demand, SQL Server 2025 added JSON indexes. You can eat the cake of being able to store practically schema-less JSON blobs as part of each row, and have it too by querying specific values quickly. (The common phrase is to "have your cake and eat it too", but did you ever think about…
When you run monitoring queries like sp_BlitzWho and sp_WhoIsActive, you wanna see the program names that are running the queries. It's super useful when you've got multiple apps running on the same servers, or when you've got apps scattered across end user computers.
If you don't set the program names, you'll either end up with empty strings, or your dev tool's default name, like Core .Net SqlClient Data Provider, which doesn't tell you jack.
I'm back in the home office this week, covering your top-voted questions from https://pollgab.com/room/brento, and we finish up the session with a discussion of the stoic habit I use to start my mornings.
https://www.youtube.com/watch?v=odkrYIQKaMA
No no, I'm not just talking about the people answering the interview question.
I'm talking about the people asking the question.
Is your company hiring for a database position as of September 2026? Do you wanna work with the kinds of people who read this blog? Let's make a love connection.
If your company is hiring, leave a comment. The rules:
SQL Server Agent is a solid scheduler for database administration and simple, database-local automation. In a small to midsize shop, it is the right tool for backing up databases, checking for corruption, and maintaining statistics.
But as a shop grows in complexity, Agent starts running into its limits, and teams find themselves duct-taping together workarounds to cover the gaps.
Normally when you're looking at an execution plan, and you see an index seek followed by a key lookup, that means it's running relatively quickly.
To explain, let's take the Users table in the Stack Overflow database and run this query that we explained in this post:
You wanna learn PostgreSQL, and you wanna use a sample database with big real-world data, the same kinds of issues that pop up with real-life data distribution skew, and fun query challenges.
StackOverflow.com provides a free data dump in XML format with their data as of 2024-04. The data is licensed under cc-by-sa 4.0, which means whenever you use it for public demos, you'll need to link back to their original data source there, just as I did.
Ten years ago, I published a blog post with the top 10 most highly upvoted requests for Microsoft SQL Server as shown on their feedback site at the time, Connect.Microsoft.com. That site has gone out to a nice farm upstate, but let's revisit that top 10 list to see whether Microsoft actually built what you wanted.
This week, I'm back in Vegas, spending time in the home bar to recover from jet lag. I'm not saying booze is the best way to recover - but - it helps me fall asleep after a 16-hour-time-zone-jump, and it makes the career answers a lot more colorful. Let's go through your top-voted questions from https://pollgab.com/room/brento.
Wanna play some Texas Hold 'Em style poker and make a pile of Query Bucks? Wanna watch other database people playing?
Fire up SSMS and connect to:
What's the difference between SQL Server's row compression and page compression, and when does each one make sense?
Row compression turns every fixed-length datatype into a variable-length datatype, using as little space as possible to store it
Page compression does that, AND adds a dictionary of repeated data on the page, getting more compression at the cost of more CPU
