Voice of the DBA

Category: Editorial

  • Getting More Time from AI

    As I get older, I find that time is the most valuable commodity I have. It’s the one thing that I need more of, but I can’t get it. Even if I find more efficient ways of doing things, it seems there’s an endless list of things at work and on the ranch that need to be done.

    It seems to be the same for most of my friends in other jobs, whether in medicine, law, or any other position; they’re often overloaded with more work than they can get done in a week. Arguably, it’s not all important work, as sometimes we might tackle a task, only to have our boss throw the work away or delay the project. That’s annoying, but I also understand priorities change.

    Mostly, I understand people ask for a lot of things they don’t really need, but because it’s easy to ask. Over time, they may forget about their request or realize they don’t need it anymore. So I tend to do the work I’m asked and then not worry about if it’s really needed.

    However, that’s not what this piece is about. Let’s say that you have a useful AI Assistant that can truly produce better code, faster than you can. You trust the coding agent (under your guidance), and it saves you time. Let’s say that this agent reduces your coding load by 30%. Forget the issues with the agent stealing your joy.

    A number of studies show that the average developer only codes around 2-3 hours a day. Some might say 4, but that’s just 50% of your workday (I hope). If you save 30% of that time, then you’re saving 1:20 a day, 6:40 a week. That’s a nice chunk of change, but what will you do with the time? Or maybe more importantly, what will your boss expect you to do?

    A lot of management might see 30% and expect you to get 30% more coding done (of 40 hours), asking for 12 hours more of work. I see that a lot as management somehow things that developers work 8 hours a day and should get 8 hours worth of code written. When that doesn’t happen, and it never does, they often schedule more meetings to check on your progress. Hence to 2-3 hours worth of actual work.

    The smarter group of managers might think that you could get 5 hours more work done (30% of 3/day), and the really smart group of managers might use that time to improve the coding skills of the staff. That’s more than a 10% allocation of time and if focused, could help developers write more efficient code (especially SQL), improve their secure coding knowledge, and perhaps even tackle some technical debt with refactoring of existing problem areas. Maybe you could learn to better judge AI-produced code.

    I know that many people are skeptical of AI assistance in coding. I think it’s a tricky thing, but even if the AI doesn’t produce production code, but allows me to conduct a lot of quick experiments that can prove out a hypothesis, I think it can help developers become more productive.

    If they learn to use it as a tool and management doesn’t expect it will turn every developer into a 10x (or even 2x) engineer.

    If you had more time, what would you do in your work day?

    Steve Jones

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

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

  • All the Costs of Downtime

    I studied economics in university, which isn’t that close to database work, though I did have to work through linear regression problems by hand. I always enjoyed mathematics, so this wasn’t a hardship. Until I purchased a PC that was capable of letting me do graphs and calculations in PASCAL and BASIC. Then I realized that my enjoyment wasn’t that efficient or useful, and a computer could help me get things done way more efficiently.

    Many of us work on systems that process tremendous amounts of data, something our organizations couldn’t complete without computer hardware, efficiently or not. We just wouldn’t be able to get the work done by hand. That’s the main reason why downtime is such a problem in the modern world; we can’t fall back to manual systems in many cases.

    I ran across an article that discusses some of the large-scale failures in recent history (Heathrow, Delta, NYSE, Royal Bank of Scotland) due to computer system failure. Certainly, there are large financial costs and lost revenue for organizations that suffer these outages. However, there are other costs that are borne by the staffers, which don’t often make the news.

    When it’s “all hands on deck” to solve a problem, other work isn’t being progressed. There is certainly the interruption of Operations people, but often developers get asked questions or pulled into meetings to provide input. That can take them away from their existing work. Apart from the “23 minutes to get their head back in the game,” as noted in the article, can they even focus anymore? Will they be thinking through all the possible causes, and did they actually provide the right information or all the details needed?

    During a crisis, or even after, it is very hard for humans to focus on anything else. Apart from the technical details, IT staffers can have a range of emotions and thoughts. They might have sympathy for customers affected. They might worry they’re at fault and might be blamed (or terminated). They might be thinking about how they should have coded or configured something differently? Should they have tested more or accounted for issues? They might have simple anger at others who didn’t do their job, or frustration at the failure of a piece of hardware.

    Perhaps even more concerning is the load management can place on employees to get things fixed. If people work long hours, how do we ease them back into the flow of all the other daily work? I know I’ve struggled to get people to rotate work with rest as a manager. As an employee, I struggle to even sleep if I am sent home while others are still working. I’ve had to work 100+hour weeks and very quickly we get into survival mode, not productive mode.

    There are lots of costs to downtime apart from the financial impact. If you can’t maintain a stable environment that limits the time employees spend firefighting, you likely aren’t going to survive as an organization. Startups sometimes can do this, but often it’s from a few extremely dedicated employees who make a difference at a smaller scale. And these employees often pay the price in their personal lives with health, relationship, or other issues.

    The article goes on to look at predictive analytics that might help us reduce some of the issues from hardware issues. I think this is likely true, as we’ve seen digital twins that simulate loads on equipment help proactively catch issues.

    What do we do with software? If we don’t write well architected software that handles the load, how do we write an analytical system that can predict failures? This seems like a level of static and dynamic code analysis that we aren’t mature enough to build.

    Heck, even if we could, how hard is for many of you to get queries tuned in a running system? I find too often there isn’t enough effort or enthusiasm from developers, management and others to follow solid tuning advice and change your SQL. Maybe that’s too limited a view.

    Perhaps the AI analysts of the future will become the consultants of the past, whose recommendations often mimic the words of the current staff, but somehow carry more weight. Maybe they’ll get more things done and changed to help us build more robust systems.

    Steve Jones

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

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

  • Remembering Phil Factor

    One of the most prolific and popular authors at Simple Talk has been Phil Factor. He wrote many pieces on all aspects of database work and has probably written more articles on the Redgate Product Learning site than anyone else. He has entertained, informed, and inspired many database professionals in his many years as an author.

    Phil, aka Andrew, passed away recently. This was a shock to many of us and a sad day.

    Tony Davis introduced me to Phil, whom I always thought of as Andrew, many years ago when I first traveled to Redgate. Tony published a tribute to Andrew on Simple Talk and has many more fond memories of Andrew. If you ever get the chance to meet Tony, ask him for a few.

    Over the years, I’ve had the chance to get to know Andrew better. He, Tony, and I would often go out for lunch when I was in Cambridge. He came to PASS a few times, and he and I had many discussions about technology and ranch life over the years. Andrew lived on a plot of land similar to mine. We both tended to build, fix, and repair things ourselves, and we often discussed our latest projects.

    He also had a love of bluegrass music and wanted to come to Colorado for the Telluride festival. I’m not sure that he ever made it, though I somewhat regret not being more enthusiastic in encouraging him and offering to go with him. That isn’t my style of music, but does it matter?

    As I get older, I appreciate the time I get to chat with friends and family. I cherish the opportunities to spend time with others, however long or short. These are the important things in life: the events and conversations. It’s a sad time as Andrew and a few others I’ve known have passed away in a short period of time, but I hold many happy thoughts of the times we’ve spent together.

    I hope you remember to appreciate the opportunities you have to spend time with others. And in memory of Andrew, flip through his articles and pick one to read today. There are lots of great ones, and some fun ones, like the SQL Limerick.

    Steve Jones

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

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

  • Pushing the Limits of AGs

    Many of you reading this likely have an Availability Group (AG) set up on at least one database in your organization. Maybe not most, but many of you as this has proven to be a technology that many people like for HA/DR, upgrades, and probably other uses. As the technology has evolved from it’s SQL Server 2012 debut, it has improved in many ways. This might be one of the few features that has received regular attention from the developers in Redmond across multiple versions.

    That’s not to imply this is a foolproof or bug-free feature. Numerous people have had issues with the various types of AGs. From setup to performance to scale, I’ve seen many people post questions and search for answers on how to get their system running smoothly and reduce any late-night calls.

    Over the last decade I’ve seen various people test different parts of the AG technology, but not many pieces about how much you can stress the technology at high levels. Microsoft supports up to 8 replicas, but what about groups and databases? The recommendation page says MS has tested 10 AGs and 100 databases, but nothing else.

    I ran across a post on LinkedIn from Calin Oprea that covers his AG testing. He hasn’t written about it, but says he can make the scripts available. He tested 50,000 databases, maybe more. He says 50k+ in the post and notes anything beyond 500 databases per instances starts to fall apart and 1000 seems to be a hard limit. Failover doesn’t work, even without a workload.

    That’s quite a test of the technology at it’s extreme. I’ve never run more than a few AGs or databases, and I see people posting and talking about dozens. Most of the people I know doing things at scale are using less than 10 AGs and usually no more than 100 databases max.

    I wonder how many of you out there use more than 2 AGs on any instance and more than 20 databases. I’m sure there are lots of systems at this scale or larger, but I’d guess the majority are 1 AG and less than 10 databases.

    Take a look around your environment today and see what the average and extremes are for Availability Groups. And if you’ve never looked at them, it’s a piece of technology you ought to become familiar with. HA/DR is becoming a base requirement in many situations and it’s available in the cloud with the toggle of a setting. If you work on premises, it’s likely your clients expect your systems to easily failover to another location. Check out Stairway to Always On to get started.

    Steve Jones

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

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