Voice of the DBA

Tag: career

  • Staying Focused

    Most of us know when we’ve been working in the flow. Time ceases to exist, and often seems to have flown by when we stop working. We may not eat or take a break, just focusing on a problem and tackling it in a very single minded fashion. Whether this is a development task or some infrastructure effort, we can achieve flow.

    At the same time, many of us struggle to find the flow in a busy workday of meetings, interruptions, music, slack messages, and more. Attention is a commodity, and one that many of us struggle to focus on a single task. We may find that if we do achieve flow and something interrupts us, then we struggle to get focused again.

    When I give presentations and talk about remembering what code we wrote or changes we made last week, plenty of people will chuckle along with me. It’s a challenge to remember what we were last doing, especially when we move to more DevOps style work with small chunks of tasks being completed. Even coming back to work the next day, after an evening of family or hobby time, can be distracting.

    How do you get back into the flow quicker? There are lots of books and advice around, but I thought this programmer’s look at how to keep himself organized around a busy life was interesting. He uses some tools, primarily based around software coding, to help remind himself quickly of not only what tasks need to be tackled, but where he was in the flow of the work. In some sense, this reminds me a bit of Andy Warren’s efforts at keeping SQL Saturday organized.

    Flow is hard to come by. To me, this is one reason why more workers ought to have private offices and less meetings. A developer or DBA in the middle of the zone, working in the flow, needs to be left alone. That’s the most productive time for them, when they are most efficient and valuable. More organizations ought to try and foster this, not inhibit it.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Growing and Changing

    When I started with SQL Server, I worked on OS/2 and SQL Server 4.2. Eventually I moved on to SQL Server 6.5 at a few places, one of which had heavy workloads. While I liked v6.5 much more than v4.2, there were issues with nested views, and certainly issues with heavy tempdb loads. In fact, at one job, I banned temp tables unless we had no other way to get queries to work. This helped stabilize some of our code, and we essentially had a review group that a developer had to convince to allow temp tables since there were situations where we needed them.

    I was reminded of this recently after Grant published his Best Practices and Band Plans editorial. There was this comment, which noted: ” I have talked to some people that state “our best practices is to never use…” because they tried it when it was first introduced in SQL Server 2005 and it didn’t work for them so now they won’t use it at all. ”

    I’ve encountered this in my career, and I’ve been guilty of it. It took me a few versions, and more complex code, to start thinking in terms of temp tables at times. I still try to avoid them, but I’m not afraid of them, and I know SQL Server handles tempdb loads better with each version. They are a tool I reach for sooner, but not immediately. I still try to get a simpler T-SQL query if I can.

    Many developers and DBAs have plenty of experience with T-SQL, but how often do they update their knowledge? How many people question that the way they first think to solve a particular problem is the best way? The T-SQL language has grown and changed across versions. Some language changes are great, like the OVER() clause for window functions. Some might not be so great (STRING_SPLIT among them) or have limitations that you might not expect. Without questioning the way you write code and periodically looking for new techniques, you might not be aware that the amazing code you wrote a few years ago could be better structured today.

    There is a balance between relying on your knowledge and trying new things. Certainly most of the time I’d expect a developer to write code based on their experience and what works well, but I do think that you also need to periodically investigate new techniques. Regular learning is part of what we hope to help you with at SQLServerCentral, with articles, the Question of the Day, and blogs in our daily newsletter. Maybe you don’t read every article, but go through one once every week or two. Whether it’s something you do every day or have never tried, you might be surprised what you learn.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Organized Learning

    I really wish I’d do something like the DBA Training plan from Brent. Honestly, I don’t have the time to do it the way he is, and certainly can’t respond to any volume of emails, but I applaud the way he’s doing this. Brent is sharing a lot of ideas and information on how to start getting a handle on your environment. As of this writing, there are 8 posts (part 8). I expect more in the future.

    Becoming a DBA is often a random collection of experiences that almost everyone goes through in a different order. Maybe you started by having to recover a database with a restore. Maybe it was the need to install the server software and configure users. Maybe you find yourself more interested in writing database queries in T-SQL than methods in C# and switch over. However you learn, there are two things I know: your environment will drive your learning and there’s always more to learn.

    My start as a DBA came about when I needed to install a SQL Server instance to handle a new application. It was important that I understood the general admin duties to ensure backups and manage security. At first I didn’t think much of the platform, but as I tried to troubleshoot performance issues, I started to learn about how connections are made, resources are used, and what bad T-SQL looks like. From there, I moved on to more development before coming back to the admin side later.

    It would be great to have a class that teaches you to be a DBA, but really, the job has somewhat varied at each position I have held. There are some specific things that are important at every job, but the exception is often the rule as to how you ensure your environment works well. Once the system is in production, it becomes very hard to change anything, from security to code, without lots of testing and approvals. I find that often trying to work within constraints drives a lot of learning, though not often deep or varied enough to investigate all the options.

    I don’t know everything about SQL Server, but I have developed two very important skills in my career. I’ve learned how to learn, by reading, researching, and practicing new skills. I feel comfortable that I can come up to advanced beginner on a topic very quickly, usually competent enough to make something work. Second, I’ve learned how to ask for help. I’m lucky in that I have lots of friends I can call on for questions in specific areas. If you don’t know someone that’s an expert, I hope you know about #sqlhelp on Twitter and the forums at SQLServerCentral. These are great places to get help on whatever is troubling you about SQL Server.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Production Kubernetes

    Still learning more about Kubernetes. I’ve been working through the 50 days of Kubernetes (K8s). Let’s keep exploring

    The API is the security boundary

    Everything happens with the Kubernetes API. Therefore, we want some RBAC here for the roles of individuals, as well as processes, like CI/CD pipelines. We want to ensure we have validation, security scans, etc..

    Things will go wrong

    In addition, we need some monitoring on the cluster. We need this on any system, but with scale and complexity of containers in Kubernetes, we need something in place.

    In addition, you want to test failover, which is likely between clusters. Containers do make this easier, but it’s something we want to ensure is a part of our process. This means practice. We know practice matters in most places, but we often don’t practice well in IT.

    Scaling

    There is planning to think about a large application, or maybe large for your environment means thinking about global access and ensuring that you have a way for your app to easily redirect across clusters or regions. There are also data challenges, as Brendon notes, with things like databases. It’s an opportunity to push CosmosDB, but in the relational world, we know how to handle this.

    Kubernetes will make AGs and HA easier.