Voice of the DBA

Category: Editorial

  • The Improvement Limit

    I caught a short post from Gary Bargsley on LinkedIn that had this quote: “Many people do not believe this is true. If there isn’t a fire to put out, then you are not doing a good job.” He included a repost from Shaik Ashraf with that quote and an image that explains better what things a DBA is doing because they aren’t always busy.

    I would say that by busy we think of a DBA as rushed and always trying to fix something that isn’t working well. I’ve certainly walked into operational positions where this was the case. Things weren’t working smoothly or breaking regularly. My phone was always ringing, as I moved from crisis to crisis. For some systems, rebooting them regularly was the fix, not because I didn’t want to determine a root cause and fix them, but because I had too many other priorities. A reboot at least recompiled plans, cleared caches, and got the system working for a few days.

    In those environments, it often took me about 6 months to make changes, implement some standards, find root causes and fix them, and change the way others worked. My approach was to find a problem, consider a solution, and present it to others in a rational way with evidence. I could almost always get approval to start making changes. Or I could convince a manager/director to get others to make changes to stabilize the environment.

    Almost always.

    Not always. And I’ve had a few jobs where things were broken, but everyone else wanted to keep their existing process and keep adding new features/apps/database/etc. and let the DBAs deal with the instability. After all, if I’m working for a salary, does my boss care how much I work? If he/she doesn’t, then I have learned I need to find a new job.

    After 6 or so months, I often find that I’ve reached an improvement limit of some sort. There isn’t a lot I can continue to change and fix, usually because of dependencies and a lack of desire by someone else to change. New work can often be built better, but I’ve often found that I have to live with anything else I haven’t been able to change. Even something as simple as adjusting a query can be a problem when the app developers don’t have an incentive to help.

    Have you reached an improvement limit in your job? Or maybe you have reached a limit to what you are willing to improve, given the environment in which you work.

    Steve Jones

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

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

  • Republish: Start Fixing Your DB with Better Code

    Still in Italy, so while I’m sipping wine, you can Start Fixing Your Database with Better Code.

    I realized I never put this on the blog, so here it is:

    Start Fixing Your DB with Better Code

    I ran across an interesting article from Gitlab. They host git repositories for companies that develop software, and of course, part of their hosting is tracked in a database. They use PostgreSQL for their data, and were not happy with the performance of their database backing the system. Up front they admit part of the issue is their own coding, which is likely the problem in so many software projects.

    Gitlab accepted this, and certainly many database developers or consultants will let management know that the problem causing poor performance is often poorly written code. Jeff Moden constantly explains in his articles how better code can dramatically reduce the load on your SQL Server, yet fixing code is often the one thing few organizations want to focus on. It’s easier to buy more hardware, which often just hides the problem for am all-too-short period of time. Or just complain and try to write new features that take the place of old ones.

    I’m sure many of you have heard your parents or teachers tell you it takes about as long to do something right as wrong, so do it right the first time. Often taking a shortcut doesn’t really save time. I’m not sure that’s true with development. Often it’s quicker to do it wrong because doing it right takes a little more planning, and perhaps some testing, likely a bit more time to carefully construct code, and certainly more time to learn how to write code better. That last item is the issue, as so many of us learn to write code poorly, without examples that give us good habits from the start.

    The best developers have spent lots of time writing code poorly and learning how to improve their work. They know the tips and tricks in their language(s) of choice. That might be better SQL to create efficient queries, better C# to avoid constantly hitting the database, or something else. However, as most of us learn to write code, we don’t learn the best way. We learn the ways that are easiest to teach a user concepts, most of which don’t scale well.

    If you’ve made the investment to learn about writing better code, then it doesn’t take any longer to write good code from the start. If you’ve made the investment, and if you practice what you’ve learned. Jeff has lots of great articles on writing better code, as do many of our other authors. Take a few minutes today and learn to build better SQL code. Your database (and users) will thank you.

    Steve Jones

  • Republish: Getting Fired

    I haven’t been fired as a DBA, but I was asked to resign. It was a tough day, though a big relief as my boss was a ****head.

    I’m traveling around Italy with my wife, so you get to re-read Getting Fired.

  • Cleaning Up the Cloud

    Recently, I got a bill from Azure. That’s not an unusual thing for many of you, but for me it was a surprise because it said I was late paying. I’ve had a number of services running, and I thought at first that I had left something running too long, like a VM. As I checked, most of the things were paused, even the expensive ones like a Synapse workspace. Instead, I found that my free credits were not being applied. Fortunately, I had changed credit cards or I might have been billed for a few months before I noticed.

    This was a change in how Microsoft managed benefits, which is fine. I opened a support call and someone helped me, but it took several days to get a response. I was slightly worried about the bills, so I decided to audit the things I had running.

    It was amazing how many little things had been created or added as I’ve worked in Azure. Little experiments, even some targeted demos didn’t consist of just a database or a website. There were storage accounts, network endpoints, analytics and log services, and more. Quite a few resources had been auto-created when I deployed something else and had auto-generated names and I wasn’t sure where they were being used. Even in places where I had tried to group things into resource groups, I wasn’t sure of the purpose of each item.

    And that’s just me. Imagine a team of developers or infrastructure people being asked to create things, spin them up for a purpose or after getting a request, and then having some staff turnover. There would likely be dozens or hundreds of resources, which might be poorly or inconsistently named, tagged, or grouped. After this I can see why organizations often feel they’ve lost control of the cloud if they allow too many people to create their own resources.

    It was a sobering experience for me, someone trying to stay under $150/mo of costs for various projects. The number of experiments and deployed services I no longer needed was astounding. A good late-summer cleaning taught me to be a little more organized with my resource groups, and to ensure I’m auditing what I have running every few months.

    Something most organizations should do, but likely struggle to complete effectively in any way.

    Steve Jones

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

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