Voice of the DBA

Category: Editorial

  • Assembling Your Own Toolbox

    Last month Brent Ozar posted that September was community tools month. He had a number of posts that highlighted tools and a number of other people (Francesco, Erik, VladDBA ) did as well. I didn’t do any blogging because, well, it was a busy month for me. I was gone from home for 21 days, so a bit harried in life.

    As a part of this effort, I saw Ken Fisher write about being a Script Magpie, which is an interesting analogy. A magpie is a bird that collects various shiny objects. Ken collects scripts in the same way. Things that catch his eye are added to his repo of scripts that he keeps handy.

    I used to do something similar. I didn’t have a repo back then, though I should have. However, all VCSes in the past lacked some of the ubiquity of Git. Instead I had a folder that I kept synched on various flash drives that I carried from job to job. I’ve also usually had a share inside companies where a team of developers or DBAs could share SQL scripts.

    I’d hope that most technology professionals would share scripts, especially when they can be tokenized or added as SQL Prompt snippets. Reusing work is a big part of working with computers and why many people have embraced tools and utilities that they didn’t write themselves. I certainly think having a toolbox is important, especially tools that integrate well with an existing environment.

    I don’t think it’s worth rewriting many tools inside a company. I work for a software vendor, and I’ve seen the effort put into building tools. Both free and paid tools can save you a lot of time and effort inside your job, not the least of which is maintaining the tools over time as versions and editions change.

    What are the contents of your toolbox? Which things are those that you’d bring to a new position if you moved organizations or groups? Let us know today.

    Steve Jones

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

  • The Value of Seniority

    There was a short but interesting post on the value of seniority. It’s written from the perspective of someone that gets a new co-worker, but the co-worker is from the future. In fact, it’s the future you. The post is actually titled senior engineers are living in the future.

    We (hopefully) are more capable and impressive over time. I would hope most of us are learning more each day and our work reflects that. The code you write today should be better than what you wrote last month or last year. The choices you make, the bugs you solve, the experience you bring to work often does reflect your seniority. Not always, but often.

    Sometimes the extra experience you bring is valuable because of the knowledge you gain over time. Most of us have probably known people that seem to be the go-to resources for answers to questions or to solve problems because of the things they’ve learned over time about the environment. This can be frustrating to newer employees, and I’ve certainly seen my son experience that, but it’s one reason why staff who have worked there for more time are valuable.

    There’s a point in the post that notes you shouldn’t compare yourself to more senior people. They can seem like they’re from the future because they just know more. Junior people will get there, if they work at learning more.

    That’s a big point of focus that I try to emphasize to people that I work with, speak to, or read my editorials. Put effort into your career, learn more, both specific to technology and about the way your company works. Growing your skills, tech, soft, whatever, is a way that you can enhance your career and prove yourself to be more valuable.

    It’s a way to make people think you are from the future.

    Steve Jones

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

  • The Growth of IQP

    When Microsoft started to talk about Intelligent Query Processing (IQP) before SQL Server 2017, I wasn’t sure what to think. There was a diagram with 20 things on it, and only 5 were highlighted (you can see that in the article linked). That felt like something, but barely something. Over time, as we’ve gone through SQL Server 2019 and now 2022, the diagram now looks more filled in. In fact, now there are a lot of things filled in.

    When I think about new features of SQL Server, I don’t often spend a lot of time on the IQP stuff. First, I don’t have to live with people yelling at me every day about slow performance. If I did, I might be more anxious to test and evaluate the changes. Second, these are mostly just hidden things that come with the product and (fingers crossed) improve my workload.

    There’s an article on the 2022 changes, which improve upon some of the older IQP work as well as add some new items. It seems the feedback loops are getting better, though not perfect. I’m sure all the performance tuning experts will write posts about where these things fail, which is good. We want to know where we might have problems. Hopefully, we’ll also see lots of demo code that shows where these things work.

    One of the more interesting things is the Parameter Sensitive Plan Optimization. This should help with parameter sniffing issues, though it will be interesting to see what percentage of a variable workload is improved by this. I also wonder if loaded systems that struggle here might have other plan issues. I already know some people have an overloaded plan cache now. If they could have even more plans for each type of query, there might be other issues to contend with.

    For the most part, SQL Server works well for a wide variety of situations. Many people seem to be quite pleased with how well it performs. I don’t know if that means customers look forward to upgrades or are happy where they are, but I am glad that the product doesn’t just add developer features or complex technology for administrators to learn. Getting investments in better query performance is important, especially as it can be hard to get developers to write better code on their own.

    Steve Jones

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

  • How Important is Software?

    I have a mechanical gaming keyboard, not because I’m a gamer, but I did want to tactile, mechanical feel and I like the idea of lights on the keys. I’ve enjoyed the experience, but the software leaves something to be desired.

    I thought about my experience as I read this review of a more complex keyboard, with the title that notes it’s so pretty you can almost forgive the software. The poor UI and the complexity of operations, not to mention the splitting of the remap functions being unnecessarily complex. That was my experience as the only thing I cared about was remapping the home and end keys to the places I was used to them being on Logitech devices. I have spent a few hours across the last year learning how to map keys, and then relearning when my profile is lost in an upgrade or hardware glitch.

    How much does software matter to customers? I’d argue it is becoming more and more critical all the time. The experience of using hardware, or really any device or service, is impacted by the software that drives it. Software is eating the world, and I think we need to understand that better software design and quality is needed.

    I find that the most talented hardware companies sometimes have the worst software. It’s almost as if they assume their customers will be as talented as their hardware engineers and don’t spent enough time understanding how to better design a user experience for their products. Keyboards, routers, motherboards, and more often use archaic, confusing methods to have customers configure or update the systems.

    I know UX is hard. This isn’t even about graphics or visual appeal. In many cases, it’s about just better understanding of how others view the process and what information they take from what appears on the screen. Over the years I’ve learned that this is not only hard, but also that it takes time and debate, just like features do. I enjoy these moments, and I like to think that I help my employer produce better software for our customers with my feedback.

    I urge developers to have others look at what they present on the screen, and spend time learning from users, both experienced and novice. We often forget how something appears to others when we look at it every day and rush through workflows as we test our latest code. It’s easy to gloss over daily changes as minor when the sum of all changes can be a jarring experience for our users after an install or upgrade. UX is important, and it’s worth putting effort into our software designs, our data models, even the metadata we expose to others.

    Steve Jones