Press "Enter" to skip to content

Category: Learning

The Importance of Testing Received Wisdom

Mark Wilkinson lays out an argument:

Life is full of “absolutes”. For example, the Star Trek: The Next Generation episode “The Measure of a Man” is often cited as the best episode of the series, and many folks will tell you that you should never adjust max worker threads. But once you take the time to dig in, you realize that “Darmok” is in FACT the best episode of ST:TNG, and you’ll also find a small cohort of folks adjusting max worker threads on all of their SQL Server instances. Are these people just abnoxious contrarians? No. They just did their own testing to validate the common wisdom.

Click through for an example from Mark around 64K allocation unit sizes for NTFS volumes. And I’ll give one on max worker threads. I had a consulting client at one point which had per-customer databases. Each customer was, in general, quite small, so they had thousands of databases on the instance. They also wanted high availability on the system, so they wanted each database mirrored to a different server.

If they didn’t spike max worker threads to extreme levels, the server would have fallen over simply from the weight of all of the open database mirroring connections. The actual server workload was fine and it could handle all of the open worker threads because the large majority were doing nothing. But if a zealous problem-solver popped in, ran a diagnostic, saw that they were violating “best practices,” and “fixed” the problem, that would have been a bad day.

Unrelated but similar story: the one time they did need to fail over due to an emergency, it was also a bad day. Because even if the instances can handle 2500+ databases, it turns out that having them all fail over at the same time on low-powered Azure hardware was not a pleasant experience.

Leave a Comment

Solving Kusto Detective Academy Case 4

Tom Zika wears a trench coat and works out of a run-down office in a mess of a town, all in black and white:

Someone hacked into Digitown’s municipality, stole classified documents, and vanished. All we have is 30 days of router logs and a lookup table. Time to find a needle in 45 million rows of hay.

I really like the work the Kusto team has put into Kusto Detective Academy. Tom’s blog post is a spoiler if you want to answer it yourself, of course.

Leave a Comment

Gotchas for a Move On-Premises

Brent Ozar lists three pain points:

For T-SQL Tuesday #199, Koen Verbeeck posed an excellent question: if your company moved up to the cloud, but after migrating, had to come back on-premises, what would be the big problems?

I’ve had clients in this exact situation! Here are some of my favorite gotchas from those experiences.

Click through for those three. I’d say that the first one is a major issue and will probably be one for the next couple of years—unless the bottom drops out sooner than I expect and we suddenly have a rush of used hardware from highly unprofitable organizations hit the market.

Leave a Comment

The Importance of Working with People

Mark Wilkinson hits migration from a different angle:

I haven’t written a blog post (here) in over 5 years, so what better time to start things back up than a T-SQL Tuesday? Big shout out to Koen Verbeeck for hosting this month, and picking a great topic: Back to on-prem?

As someone that just ended a 10+ year stint managing a hybrid environment, this topic is very near and dear to me. I went back and fourth on what to write about for this one. There are a lot of great topics. Reliability and observability almost won out but instead I landed on maybe an unexpected topic: soft skills.

Regardless of whether your company is fully on-prem, fully in the cloud, fully hybrid, or fully without a clue, Mark’s advice hits home. And is also one of those things I’ve struggled with.

Leave a Comment

Guidance on Building an Application

Brent Ozar talks marketing:

I do absolutely consult for software vendors. I used to work for Quest Software, and I’ve consulted for Amazon, Google, and a lot of third party software vendors. It’s real work that requires real effort on my part, and I need to get paid for that.

Having said that, I still wanna help you for free, so I’ve put together this blog post with my favorite advice for software makers. There’s a lot of hard-learned lessons in here, and I hope you can just read ’em and avoid some of the most common pitfalls that folks run into.

As one of the few people in the SQL Server community who’s good at marketing, Brent’s advice is worth a careful read.

1 Comment

The State of the Database Market

Simple Talk’s editor digs into the data:

Leading research and analysis firm Gartner recently revealed its DBMS Market Share Ranks for the 2011-2025 period, and it shows a clear pattern. That is: while the dominant database vendors are losing their stranglehold on the market, it’s happening very slowly – so don’t expect to see big changes at the top any time soon.

It’s a trend already uncovered in the Redgate DB-Engines rankings in recent times, despite it using a very different set of metrics compared to Gartner’s analysis.

I had no idea that Redgate owned DB-Engines. But there’s some interesting information to come out of these results, especially because they come at the problem from very different angles.

Comments closed

T-SQL Tuesday 197 Round-Up

Steve Hughes learns something new:

Thanks to everyone who joined the blog party this month. I noticed three themes in the responses. Every response had one or more of these themes woven into their response.

  1. I learned something.
  2. I discovered ways to improve my presentations.
  3. I get more value in the hallway conversations.

Click through for this month’s participants and what they’ve learned.

Comments closed

Presenting for Impact

Rob Farley tells a story:

I like this topic from the legendary Steve Hughes. It’s been a long time since I’ve seen him, but he was always a thoroughly good guy. We both spoke at conferences back in the heyday of the SQL community, and although his journey has been tougher than most in recent years, he is still impacting the world in amazing ways.

Steve is hosting this month’s T-SQL Tuesday, and asks about what we’ve learned from conference sessions, things which impacted us and how we work. It’s an interesting topic for two reasons – firstly, I enjoy giving conference presentations, and secondly, they’re really not my preferred way of learning.

Rob goes on to talk about conference sessions that caught his interest. One book that helped me considerably in my ability to present is Peter Cohan’s Great Demo! This is, admittedly, for sales presentations rather than technical presentations. However, I think it’s pretty straightforward to map most of the concepts to technical demos, and the advice in the book is great for getting your point across early and letting people make sure they are in the right room at the right time straight from the get-go.

Comments closed

Disclosing Testing Machines

Louis Davidson lays out an argument:

Something that every writer needs to be careful of is doing too much benchmarking-type work. In many of the software licensing agreements you have signed, you promise not to do that. But at the same time, you can generally give out performance numbers if you aren’t making claims about particular software, especially compared to another.

So, if you come up with an algorithm to do something in a better way than you have seen, it is nice to show the software, give the reader access to the code you are showing the performance of, and include the computer you are running it on.

Louis is referring to the DeWitt Clause, a fairly common clause in commercial database products that came about because Oracle was angry that David DeWitt made them look bad by providing a fair comparison to other platforms.

Comments closed

Where the Buck Stops

Louis Davidson talks slop:

I loathe the phrase AI Slop. I have said it before, I don’t like the phrase because it is generally attributed to some content that a person has posted. I blame the poster, not the generator. We all use AI these days, just like they used tractors to farm, computers to do accounting work, and CGI to produce movies. These are all tools.

But when I sign my name to something, it is really and truly mine. In this blog, I will discuss this and more. So as the title says, don’t blame AI, Google, a person’s teachers in grade school, nope. Blame the person who said, “This is good enough to put out in my name”, or in other words, the person in the byline. For this post and video, that is Louis Davidson.

I understand where Louis is going with this and it’s fair. When you publish something, the person ultimately responsible looks suspiciously like the picture on your driver’s license. But I think it can serve as a useful descriptive term for a category of garbage output without removing agency from the perpetrator.

Comments closed