Voice of the DBA

Category: Editorial

  • The Journey to PostgreSQL (or anything)

    Most of you reading this work in technology, and I assume that you’ve had to learn something new on the job. Technology is constantly evolving, even on our existing platforms. On top of that, we are regularly given tasks that are outside of our current skill sets. Maybe not far outside, but to meet the changing demands of our jobs, we need to learn new things.

    I ran across an interesting post (on a new site) from Brent Ozar. I think that guy writes as much as me, but he wrote this one: Why I Started Using Postgres (And You Might Too). It’s a little provocative, but there are good posts on the site about things Brent learned in PostgreSQL. I won’t go into whether learning PostgreSQL is a good idea.

    The thing that struck me in this post is that Brent knew that this move was a risk. He was worried about moving to a new platform, despite all the reasons he had for doing making the change. I would bet a lot of us are in similar situations. It might not be PostgreSQL we are being asked to learn, but it could be Fabric, Databricks, Python, PowerShell, CosmosDB, or whatever other thing someone in our organization thinks is cool.

    The best sentence in here is this: “I gambled that I’d be able to learn how to do performance tuning quickly enough, …, in time to head off issues.” That’s the attitude I’ve often had in my career when I get requests to do something new.

    I’m willing to bet on myself.

    You should be willing to do so as well. Not bet on me, but on yourself. I know you don’t want to work 80 hours a week to learn, or get stuck trying to solve problems every weekend with new tech. However, I hope you are willing to do that for a week or one weekend. You’re willing to do some reading at night or experimenting during lunch in order to make something work.

    You’re going to have tough times. You’re going to question if you can make something work. Getting comfortable with being uncomfortable (for short periods) is how we grow and learn. It’s how we take leaps forward.

    It’s how we take advantage of opportunities that are in front of us.

    There are always opportunities to make a difference, to effect change, to build something you are proud of or that your organization values. Those stressful times when you drive to make something new succeed and have to learn a new skill in the process, these are the times when you can take advantage of an opportunity.

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

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

  • We Should Demand Better

    I ran across an interesting open letter. Most of these are from individuals, often complaining or lamenting on the way something in the world works, or maybe doesn’t work.

    This latest letter was from the Chief InfoSec Officer at JPMorganChase, a large worldwide bank. This open letter was written to the software suppliers looking to do business with JPMorganChase, especially those in the SaaS area (Software as a Service). The letter opens by noting that SaaS is enabling cyber attackers and asks for three things: prioritize security over features, modernize security architecture, and work with security collaboratively to prevent abuse of connected systems.

    It’s a good letter. It talks about the problems at a high level, but is specific enough to recognize problems. Software is often delivered as a SaaS type application, even when there might be local components. For example, I lament Postman working this way, as it now seems to now require me to be connected in order to work. That’s something I learned while trying to get work done on an airplane, and I couldn’t get to any of my queries as I didn’t have wi-fi, despite the application running locally on my laptop.

    The threat of more attackers is amplified by the connectedness of new systems, new agents, and new protocols that allow a breach to escalate deeply inside systems. This is something we’ve faced in the past, but not at the scale that we face it today. Automation has become embedded in the computing world, not just inside organizations, but also inside hacking organizations. Malicious actors can and do use scripted attacks at a rate that we haven’t experienced in the past.

    I wish that most people purchasing software would prioritize security when making a decision, but often price and expediency outweigh anything else. While I do see many companies asking for security information, too often the requests are at high levels, and vendors can word their answers in a way to satisfy the screen without actually improving their own security coding and architecture.

    I do think the authorization and authentication of users is improving, so I have hope that more patterns and frameworks are published and widely used, and we’ll see more consistent security throughout software. Now, if we can just ensure the authors of those platforms do a good job of security, we might see the request from JPMorganChase come true.

    Steve Jones

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

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

  • 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