T-SQL Tuesday #187–Solving Problems

Posted on June 10, 2025 by way0utwest

This month we have a great invite from Joe Fleming, a first time host of T-SQL Tuesday. Joe reached out when I requested some hosts and I’m glad he did. He’s got a great challenge for people and I’ll answer in two ways, for work and non-work.

I manage the T-SQL Tuesday site and I’m always looking for hosts, so if you want to host one month from your blog, send me a note on Twitter, Blue Sky, or at SQL Server Central.

Troubleshooting SQL Server

In my career, I’ve had all sorts of issues come up. Here’s a description of one of the stranger issues. This isn’t the exact issue, but it was similar to this.

A user reported they couldn’t log into the server. They were logged on earlier, but can’t connect now through an application. What could be the problem?

When looking at this type of issue, I usually think there is some sort of network issue here, or perhaps a service issue. My  thoughts are:

  • Can I connect? Or can others? (trying to determine if it’s this user)
  • Can this user connect with another app that might give an error message?
  • Is the server instance up? (check the basics and isolate if this is networking)
  • Has this login had a change to permissions/password/etc. Perhaps an AD change.
  • Has something else changed on the server?
  • Has something changed on this user’s machine?

At some point, I’ll isolate where the issue is and determine how to fix it. In this case, I managed to determine the user was a DBA that was playing with a logon trigger and locked themselves out.

The UTV Won’t Move

On the ranch we have to learn to handle lots of things ourselves. YouTube has been a boon, but it’s also a bit of common sense and problem solving that we need to get things done. It can be hard to get people out to the ranch, especially for small things.

Sometimes big things.

Awhile back I came back home from a trip to find the spare UTV we have in one of the fields. I asked what had happened and a kid said that it died.

That’s not a good description, so I asked how it died. What was going on? what was happening? This kid said they’d stopped the vehicle to do something and put it park. When they went to shift into drive, it wouldn’t move.

Did the engine run?

Yes, but the UTV didn’t move.

Now that I had a better story, I could debug further. I knew that it ran and went out to start it myself. Sure enough, it starts and the shifter didn’t do anything, but it felt loose.

Sometimes hands-on helps. I knew immediately a cable had broken.

First thing, get this out of the field. I knew there was a way to shift it without the cable, I just had to figure out. (YouTube to the rescue). Once I did that, it’s research to figure out how hard this is to replace and where I can get the part.

I logically move through the steps of how can I practically get things done.

From here, I saw someone talk about this on YT and show me this isn’t hard. I learned how to shift into Drive with a pair of vice grips, got it up to the house, and I found the part online. I ordered it, send the YT link to the kids, and tasked them with fixing the cable.

They did, after some problem solving from me.

Posted in Blog | Tagged , , | Comments Off on T-SQL Tuesday #187–Solving Problems

Shorten the Debate

Posted on June 9, 2025 by way0utwest

Many of us are faced with choices and decisions constantly in our jobs. How do we approach a problem? What should we do as a team to get the work done? How do we code or manage or test or do something else with a database?

Maybe more importantly, how long do we spend deciding?

I have seen teams spend way too long (in my opinion) debating options and examining possibilities. I’ve seen them take days or weeks arguing and considering edge cases and move slowly. It seems there is no shortage of reasons why something isn’t done. It can drive me a little crazy.

I was listening to a podcast recently and heard about this technique, which I love.

Get a whiteboard that everyone can see (physical or virtual). One person is designated to write down all the discussion items about the issue. Each person can make an argument for or against an idea for the solution, and nobody can stop that argument from being added. However, nobody can remove anybody else’s argument, and nobody can repeat an argument that is on the board.

This can shorten discussions because people can’t repeat things. I’ve seen far too many debates (arguments) continue in a circle because people keep repeating things or circling back. When no one has anything new, we just take a vote and move on.

I am a big fan of getting things done. Even if we don’t have the best, or optimum, or more efficient solution, we need to get moving. Perfect is the enemy of good enough, and far too often, I find technical people chasing perfection, or near perfection, at the expense of moving forward.

Timebox decisions and get moving. It’s how you accomplish more, and it’s what your employer wants.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | 2 Comments

Monday Monitor Tips: Customizing Data Retention

Posted on June 9, 2025 by way0utwest

One of the biggest challenges with monitoring data is managing the volume over time. Lots of bespoke/home-grown solutions don’t do this well, and some commercial products have a gross approach that might not meet your needs.

Customers constantly ask me about this, so here’s a quick tip on how you can manage data retention in Redgate Monitor.

This is part of a series of posts on Redgate Monitor. Click to see the other posts.

Checking the Configuration

As with most things in Redgate Monitor, this is a config item. In your Redgate Monitor solution (or on the public demo site), you can find the configuration gear icon in the upper right.

2025-05_0114

Click this and you get to the settings page. Scroll down to the Preferences area and there is a Data retention settings link. Click that.

2025-05_0116

You will get to the Data retention settings page (public site), which has a few sections at the top. You will be setting this per Base Monitor, using the drop down at the top.

Scroll below these to the data retention section, which you see at the bottom:

2025-05_0117

In this section, you see quite a few different sections. I’m showing the trend data below.

2025-05_0118

There are sections for

  • trend data- long term data for understanding how performance and baselines work
  • performance troubleshooting data – query, waits, plan, etc. data

Each of these sections is described, along with where the data is displayed. You can see that in the image above.

To the right of these, are the retention settings. I’ve got an image of the first few items. You can see the time for which to retain data and then the current size of that data.

2025-05_0119

You can set a fairly granular level of retention for data here, broken out by the various data elements we capture.

The choices for retention are shown below, including indefinitely (be careful of this one).

2025-05_0120

We have this documented, along with what we think are good defaults on this page. For example, we keep top query data for only one week, since this is a lot of data. However, if you want more time, then set it to something that works for you.

Summary

Data management is always a challenge, both in production databases and in our monitoring systems. Redgate Monitor gives you lots of choices, and those can vary by Base Monitor, so if you have a BM in the cloud doing some stuff and one on premise doing other things, you can set separate retention settings. That can be handy, especially when the cost of storing things can vary dramatically.

Watch this over time and adjust settings as needed to keep your system performing optimally.

Redgate Monitor is a world class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.

Posted in Blog | Tagged , , | Comments Off on Monday Monitor Tips: Customizing Data Retention

Reflecting on the Mythical Man Month

Posted on June 6, 2025 by way0utwest

At an event recently, I had a chat with someone after one of my sessions. I had been speaking on DevOps and ways to better structure your team and build software. After the session, one person asked me if I’d read The Mythical Man Month and if I felt we’d gotten a lot better at building software since that book was published.

I do think we have gotten better, way better, in fact. I caught another review of the book a while back from the Pragmatic Engineer. That review looked at what’s changed in 50 years since the first edition, as well as contrasting the world today. You have to subscribe to read that one, but I’ll give you a few thoughts from me on the book itself and the review.

Perhaps the most famous part of the book is the notion that adding more people to a late project makes it later. That doesn’t always happen in other fields, where people can tackle separate tasks and get things done. Certainly feeding hay to horses goes quicker with more people. However, in software, things don’t work that way. Perhaps this can work better today if we use microservices and separate architectural sections, but for any single piece of software, this often holds true. Even for microservices I’m not sure it’s true because developers take time to get productive.

And yet, people still try to add more staff to projects in the hope they’ll complete the application sooner.

Another great quote from the book is that programmers (developers today) can build castles in the sky. We can use our imagination to create, polish, and re-work in a way that isn’t easy in the real world. That, along with the joy, complexity, and opportunity to learn, are why people program. The Pragmatic Engineer’s view notes that there are other reasons, such as so much of the world uses software that people want to be a part of that, and the career is lucrative. I agree with that for sure. Working with code is a good job in many ways.

The book notes several challenges to building large systems, such as precise coding, lack of control, dependencies, debugging, and obsolescence from delays. Of these, some are true, but we have tools, like SQL Prompt, that help us avoid poor typing of code (and CI for checking). We also have moved to a much faster pace of delivering parts of a system and evolving them, so we are  often targeting just what our customers need, at an apparent faster pace. I’d also say that being able to deliver something quickly is important, as customers are quick to move on if you cannot.

One interesting part of the book that isn’t quite so relevant is the discussion about why projects are late. While I don’t know we estimate better, we certainly are better at getting smaller pieces of work done, which might hide some of the delays for larger features. We have so many more ways to track work and ensure we aren’t forgetting what we have planned. There are also many more good managers today that empower their people. These are also the things in DevOps that have vastly improved how we build software.

Onboarding is a major issue in the book, as finding staff who knew tools/techniques/whatever was hard back then. There just weren’t many people. Today, we struggle to onboard some people, but I’d like to think that it’s not the same as in the past. However, I certainly think database techies in many cases haven’t kept up or learned a lot of core software dev practices, such as version control, CI, and lots of things we bundle into DevOps. At the same time, I think we’ve burdened many people with full-stack development when they don’t have a good understanding of core technologies, like databases and networking. I still think onboarding people quickly is a major advantage for any company that needs to build software and compete with others in their industry.

In the book, Brooks talks about the 10x engineer, a hotly debated topic in the modern software world. Are some people much more productive? I do think so, though if they are 10x as skilled as many others, I’d argue the others aren’t earning their salaries.

If you’ve never read the Mythical Man Month, pick up a copy. It’s worth your time as a developer or a DBA.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | 4 Comments