Author: way0utwest

  • Monday Monitor Tips: Query Recommendations

    We keep adding stuff to Redgate Monitor, and it’s easy to miss some of the improvements. Here’s one that’s been around quite awhile, but while discussing the product with a customer who uses Redgate Monitor, I realized they weren’t aware of this.

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

    The Blue Blob

    I was looking at a set of queries on the SSC servers with an SE and a customer. The SE pointed out that we surface some code issues on this page. There’s a blue lightbulb next to one of the queries.

    2026-06_line0007

    I’ve zoomed in, but if you go to monitor.red-gate.com, you’ll find this somewhere in the list. This is to the right, where the database name is listed.

    2026-06_line0006

    If we expand this query from the left side (the arrow), we see details, but below the plan handle, we’ve noted that Redgate Monitor has run code analysis and identified an issue. In this case, there’s one issue, but I’ve seen 3 or 4 on some client systems.

    2026-06_line0008We can click the blue text above (1 issues with this query) and this opens a dialog where I can see the query and the code analysis issue identified. In this case, we don’t have a schema name in here, which is just poor practice and a potential place you could have issues, if you add schemas and users might have a different default.

    2026-06_line0009

    One cool thing, is that if I click the slide in the upper right, I get a better format for the code.

    2026-09_0164

    Our code analysis rules are documented on our side, and there is a link at the bottom of the dialog that popped up. It’s to the lower right, and I cropped it out to get a slightly better image. If does to the Code Analysis pages at documentation.red-gate.com. Here you can read about our code smells and rules, which are also checked by SQL Prompt.

    Summary

    This is a small thing, but it helps with Operations people who might want to suggest ways that code could be improved, whether to clean up the codebase or for better performance. Once you start to establish guidance, and provide useful solutions, you can collaborate and other changes are possible.

    If you use Redgate Monitor, look for these items and see if you can encourage some refactoring from developers.

    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.

  • Choose the Second One

    I wonder if any of you have ever tried this. When faced with a problem, think of a solution using whatever comes to mind. For most of us in the data space, this is a SQL-based solution, hopefully a set-based on for MSSQL. For Oracle, you might approach things differently. In any case, solve the problem.

    Then force yourself to imagine that you weren’t allowed to implement the first idea for some reason. No funding, no time, whatever the reason, you can’t implement it. Maybe it’s your team hates your ideas and just won’t approve the PR.

    Now, come up with a second idea. Something new and different. This might be harder in the data space with SQL than in application programming (C#, Java, etc.), but the idea is expressed in A Philosophy of Software Design by John Ousterhout. It’s how he has often taught his software design course at Stanford. His approach is to force students to think more deeply about their design, and he often finds that they build a better system the second time.

    Hard to do, but arguably a good idea. He talks about this in this podcast with the Pragmatic Engineer, and how many smart people underperform when building their software. He says it doesn’t necessarily take more time to do this twice, which I am skeptical of. This might be easier for students, but in the real world, is it even practical? Often we’re not working on very hard problems; we’re working to implement something that needs to get done, and often isn’t that well-defined. In fact, many of the things I find developers are asked to build things that either aren’t well thought through or are relatively trivial. There might not be a good second solution for a lot of vague ideas whose value is unclear.

    I do think that often we go down a path that quickly becomes complex. Engineers will start to overcomplicate things, so perhaps slowing down, spending a short period of time thinking of a second solution, debating another approach with others is worth a little time. Maybe you wouldn’t implement it, but at least think it through and game out the approach with pseudocode.

    I haven’t run into anyone who approaches software this way on a regular basis, but if you do it, let me know. If you think it’s a good idea, maybe it’s worth trying at the beginning of the next sprint when you tackle a new design requirement.

    Steve Jones

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

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

  • Advice I Like: Time and Focus

    “You don’t need more time because you already have all the time that you will ever get; you need more focus.” – from Excellent Advice for Living

    Boy, I wish I had more time. As I get older, I know time is shorted and more precious.

    I’m not sure we don’t need more time. I certainly feel like I need more time to tackle all the things I enjoy. Apart from work and coaching and chores, I want to play guitar, take care of my health, cook, etc. I do find myself running out of time, and I have to focus on what’s more important. That might be tackling something on the ranch instead of playing guitar.

    Or playing guitar instead of a chore because my mental health needs a break.

    Often we do make hard choices, and that means focusing on what’s important and letting other things go. We definitely are limited to 525,600 minutes a year, and it’s up to us to decide how to divide those among days, weeks, months, and the various items that matter to us.

    Remembering that time is important and limited is helpful for prioritizing. The other part of this is then making the decisions about what’s important and not just tackling what’s in front of you.

    Focus is learning to pick the important things and spending time there.

    I’ve been posting New Words on Fridays from a book I was reading, however, a friend thought they were a little depressing. They should be as they are obscure sorrows. I like them because they make me think.

    To counter-balance those, I’m adding in thoughts on advice, mostly from Kevin Kelley’s book. You can read all these posts under the advice tag.

  • Power BI Fun With Travels

    I’m back from a great vacation. I had the chance to visit two new countries (for me and my wife) and many new cities as we cruised around the Adriatic. We also had a chance to see our daughter, who is in school in Leuven.

    I’ve been tracking my travel for years, partially for fun, and partially with my boss so we can try not to overload me. I capture some data, which helps me understand where I’m going, as well as how far I am from home. I’ve written about this a few times, and showed the image below in my 2023 year in travel.

    This lets me see a frequency of travel at a glance, as well as how far I am from home. That June above was a tough time with too many trips too close together, all of which were far.

    I decided to have a little more fun, as I have a map in my Power BI report. I filtered travel by year, and then recorded myself clicking through the years. This spans 2014-2026, and as you can see, I have some very wild travel patterns across the years.

    I bet you can also guess where 2020 falls in the animation.