Voice of the DBA

Category: Editorial

  • Extended Event Comfort

    I saw an interesting thread recently in the SQL Server Community Slack where someone posted about extended events (XE). They were asking about whether XE would have a problem with a situation. The problem wasn’t so interesting, but a quote from one of the responders was. The quote was:

    The best time to have learned Extended Events was ten years ago. The second best time is today.

    I love that, and I tend to agree. If you need to trace what is happening inside your SQL Server, you need to learn how to capture information with Extended Events. That’s the best way to dig into the details of how queries affect your system.

    It’s also hard. I know that whenever I need to use it, which is rare, I have to dig through some articles and docs to understand what thing I need to do. Even having some scripts hasn’t helped because it’s a sufficiently complex system that unless I use it regularly, I forget how all the filters, targets, events, etc. work.

    On one hand, I think it’s amazing, and on the other, it’s too hard to use. Even when I try the Extended Events profiler, it’s so different from Profiler that I find myself getting frustrated at times trying to dig through the information.

    I am curious how many of you think XE is easy to configure and if you use it often. What are the places it works well? For those of you that don’t use XE or haven’t learned, why not? Do you not have to trace what’s happening with queries in some detail? Or do you have another way that you dive deep into your system? Or do you not have the need?

    If you do want to learn more, we have a short Stairway Series on Extended Events to help you get started, as well as a few other articles. If you’re an expert, we’d love a few more on using XE in specific situations.

    Steve Jones

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

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

  • No End to Programmers

    There’s an interesting piece at O’Reilly this week titled The End of Programming as We Know It. That’s actually a good title, but it doesn’t mean the end to programmers, developers, software engineers, of whatever people call themselves.

    The piece looks back at history, starting with physically connecting circuits to program and moving to switch flippers, cards, compiled languages, and on to the web and mobile systems. Each of this brought more and more programmers into the industry because there’s no end to the software needs of the world and it’s hard to write good code.

    I like that the web was seen as the end of programming as anyone could easily build a minimal application to share things. Even frameworks like WordPress let novices create applications that do all sorts of useful things. However, we still need programmers. Look around at how many WordPress consultants are willing to help you.

    That’s because there’s a difference between configuring something off a shelf (or from a digital store) and actually having a working application for your situation. There’s no end to what people want to build, and really, they need someone to build it for them. Or at least modify, improve, or re-implement the proof of concept they created.

    The world of AI LLMs, and chat-oriented programming, is no different. Anyone can ask for an app and get a reasonable prototype. However, I don’t think this means less programmers. While more people will build more PoCs or prototypes, that also means more people will need a professional to clean up their system and make it work, scale, and perform well. And probably help secure it better.

    Programmers (developers, software engineers, etc.) will scale themselves with AI tech, as they’ll get the AI to do some scaffolding and initial work that they clean up. I’m sure the very best will build RAG AI systems that generate the type of code they want with a little training and input. I could see millions of AI assistants that help write basis code outlines, write tests, check for standards and code smells, and help the human shift left, catching small, simple, silly mistakes.

    I think we’ll have more people producing software in the future, but I also think that those who know their industry well will be in more demand. They’ll recognize issues in AI-generated code, they’ll guide AIs better, and they’ll communicate more clearly with AIs. They’ll get their pick of the best jobs, and they might be better compensated.

    Things they likely do today with their fellow humans.

    Steve Jones

  • Unreliable Narrators

    I listened to an interview with Grady Booch. If you’ve never heard of him, he has been a software engineer for a long time, developed UML, and worked at IBM and a number of other places. He has devoted his life to improving software engineering. He even told Bill Gates he didn’t want to be the Chief Software Architect at Microsoft.

    At one point he had a less than flattering description of AI LLMs. Politely, they are unreliable narrators. Less politely, he feels that they allow us to build at a global scale, unreliable BS generators. This is because the LLMs that are stochastic parrots, which can produce some coherent results. Primarily they allow us to navigate a very large lake in space, i.e. the Internet. I think that’s true. I have found AIs to be pretty good search engines. Not perfect, but good.

    Mr. Booch notes that LLMs, while interesting, are a shadow or a whisper of what humans can do. He’s critical of those who think AI is going to compete with humans. Here are limitations on what the tech can do, and Mr. Booch thinks that the approaches people are taking, architecturally, are wrong. As part of his work, he studies more of how humans work and think as a way of trying to build better software architecture.

    Caveat, he does think we can build more intelligent systems, but it’s not with Gen AI/LLM architectures.

    I tend to agree with him and do think that the LLMs are unreliable. They appear to be intelligent, but they are more predictive engines in many ways. They can be very helpful in many ways, but they aren’t necessarily replacing smart humans. They might help smart humans replace some other humans, but they are likely to be better assistants than replacements.

    It’s a great interview and worth listening to. There’s a walk-through where Mr. Booch touched on computing as well as a very positive outlook on the future of his career and the things that he is working on. It’s long, (1.5 hours), but a fun listen. Give it a go and let me know what you think.

    Steve Jones

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

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

  • Building a Data Center

    Most of you reading this have likely seen a data center, and maybe sat in one while connecting to a database, but how many of you have had to try and do some of the work to set one up? It’s not something most data professionals do, but since we often have some of the most expensive boxes in one, I thought it would be interesting to discuss what goes into getting one running.

    There’s a blog post that starts to cover what it takes to set up a data center. I found it interesting to read as I’ve been a part of the group choosing a space a few times, and a lot of the issues discussed in the blog were things I dealt with or experienced. Both with large and small companies, I’ve helped to spec out and decide what we need from a colocation facility or our own room in an office. In smaller companies, I’ve had some of the “what-the-duck” moments outlined in the post when I tried to rack and connect systems, only to find some issue with power, connections, etc.

    When I read that post, I think about the months of getting everything set up, it’s hard to see this as more cost-effective than the cloud in some ways. Certainly setting up racks and servers is easy. Getting them powered, having a cold and hot aisle, and deciding what gets connected to where these are relatively simple things. However, making decisions on networking, routing, and other complex tasks can take specialized expertise. For a single company, finding, hiring, and retaining someone who knows this stuff well is hard. Startups might get someone excited, but the really good people who can design this stuff are often working at a cloud company of some sort.

    Maybe those people are tired of the FAANG/Microsoft world and want to come to your startup, but for how long? And how do you replace them? Lots of companies found maintaining a data center to be more expensive than it was worth.

    I suppose a similar situation in the database world is setting up a complex system, perhaps something like a new Firebolt warehouse. If the person that did that leaves, can the rest of the company fill their shoes? Do you know how Firebolt works? Would it be better to use a more popular system, like Snowflake or Databricks, with lots of other people writing articles and blogs about how things work? I think it would be, if for no other reason than there are other models to follow and more people that can give you guidance.

    A data center, whether a private one or a cell in a large cloud provider’s footprint, is a complex beast. The days of using a closet with servers on a bookshelf are likely gone for most commercial enterprises. Even SQL Server Central moved on to hosted systems. We used to rent a rack in the early 2000s in a co-location facility, one I enjoyed visiting, as long as the visits were few and far between. Now I like connecting to EC2, which is much simpler and easier.

    Steve Jones

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

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