Voice of the DBA

Author: way0utwest

  • No Magical DevOps

    I saw this comment in a post a short while back. A reader said “I’m still trying to wrap my head around “devops” as it pertains to database deployment. … how do you deal with those potentially dangerous/destructive changes without manually coding? … what tools are there that help in that regard? That’s what database developers really need. The only tools I’ve found that’ [are] useful so far are experience and care.”

    We have some tools over at Redgate software to help with database DevOps, but there aren’t any magic solutions that can alter your database in some way that doesn’t impact users and preserves all data. In fact, if anyone claimed to have a tool, I wouldn’t trust it because there are just too many variables in database deployments. I certainly wouldn’t trust a tool with automated rollbacks. Ultimately, experience and care are needed to build better software.

    And, by the way, DevOps doesn’t solve deployment issues. All DevOps does is help you automate the tasks you’d run manually in a reliable, repeatable fashion. DevOps teaches you to learn from your actions (gaining experience) and experimenting with small changes so that your mistakes aren’t as impactful (developing with care). DevOps isn’t magic, it’s good, solid, learning from what works and what doesn’t, altering our habits, and striving to be better. DevOps is often just providing a reliable, repeatable way of automating the things you do manually now, not inventing new processes.

    I do believe in DevOps and I think that it can work well, but it requires balance, commitment, and huge culture changes. Automating code deployment is easy with some tools. Getting people to write better code is hard. I can help with the former, and I try to help with the latter here at SQLServerCentral, but it’s really up to most of you to make an effort to become better at your craft. Getting that to work in any size organization requires that your management supports teams learning to be better and tolerating a few mistakes here and there.

    Many successful developers and DBAs have been practicing for many years (even decades) what the media and high profile companies have been calling DevOps for mere months. You can join them by looking to improve all parts of your software development pipeline through collaboration and automation. Just don’t forget to also learn to write better code along the way.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.5MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Starting from Scratch

    As the new year starts today, I find myself looking at my blog and seeing no posts in queue. My last editorial published today and no blogs scheduled for this week. In other words, the same state that many blogs are in.

    I’m a big fan of writing regularly, and if inspiration strikes and lets you get more than one post done, schedule it out. Usually I’ve got 5-10 posts scheduled at any one time, but not today. With two weeks of travel and then holidays to close out 2017, I didn’t do much writing.

    So today the focus is getting back to work, while also keeping an eye out for those things to write about. As I work with T-SQL, I’ll make notes of things that are interesting, or that I learn, and start adding blog posts.

    I don’t have a goal for 2018, but I did end up with 219 blogs (excluding editorials) with an average of 18 posts a month. We’ll see how I do this year.

  • Understanding Your Value

    Many of us work for some organization and get paid to do so. We might work for ourselves or others, but every so often we hope to get some renumeration for our efforts. For most of us, we negotiated some pay rate and then hope to get annual raises the reflect our work product.

    The interesting thing that I’ve learned in many years of changing jobs and negotiating pay is that many of us have no idea what others doing similar jobs are being paid. There isn’t a set scale of pay, unlike many other industries, and since our jobs can vary dramatically from organization to organization, despite having similar titles, we may learn that our compensation deviates dramatically from others in similar situations.

    Last year SQLServerCentral ran a salary survey and then released the aggregated data. This was a quick attempt to help you understand where you might stand relative to others, and it was very popular. Brent Ozar took our survey a step further, with a more detailed set of questions and data. This year Brent has beat us to the punch, with a new survey for 2017. I encourage you to participate and help build a useful data set. I plan on doing our own in the new year, probably this month, and hopefully we’ll have two good sets of data that you can review and analyze.

    Most of us are data professionals, and we know that having more information helps us to make better decisions. Filling out these anonymous surveys can help others understand where they might stand relative to you and vice versa. This is the type of data that can enable you to better negotiate your own pay in the future. After all, there’s nothing like presenting some data professional specific results to management to help your case that an adjustment might be needed.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.7MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Sizing New Servers

    I ran across a post this week from Joe Chang on server sizing. It’s short and talks about some of the issues that you might consider when looking at a single socket v multi-socket systems. What first caught my eye, however, was the opening sentence: “Standardizing on 2 and 4 sockets systems for servers has been an established practice going back to 1996”.

    I think that’s been my experience overall. For most of my early career, we often did purchase 2 or 4 socket systems. A few times I had 8 sockets, but hardware costs and licensing were high. When VMs became the preferred method of building servers, we tended to just ask for 2 or 4 vCPUs. If the system ran slow, we just doubled the vCPUs.

    Time has moved one and hardware has advanced at incredible rates. These days licensing by core has really changed the way that I look at hardware. I couldn’t tell you how many sockets servers have, as I’d likely just ask for a VM with x CPUs (and lots of RAM) allocated. Whether the system was 1, 2, 4, 8, or more sockets wouldn’t be a consideration. In fact, I’ve somewhat given up on trying to track which CPUs have what cores and what the best choice is. I take the simplistic view of a core is a core and the hardware geeks will figure out how to get those into my VM.

    I wonder how many of you actually worry about the hardware in your system beyond gross layout? Do you dig into tracking which CPUs need to be inside a physical box, the type of RAM layout, the drives (beyond size and count)? Or are you like me. Your system is JBOC (just a bunch of cores), JBOR (just a bunch of RAM), and JBOD. If things run slow, after fixing code, I usually JWM (just want more of something).

    Certainly there is a need for someone to pay attention to hardware details, perhaps if for no other reason than to ensure that price/performance is being considered and there are spare parts available. For me, as a data professional, I’ve tended to just look at the performance needed from a system and ask for that. Even in my last position as a DBA, my concern was the SQL Server process and how it worked, limiting my hardware concerns to knowing the CPU count, RAM size, and number of disks. I’ve abstracted away hardware for the most part, focusing on a higher level of the system.

    For those times when I do care about hardware, such as when laptop shopping, a simple query of a few colleagues or a tweet nets me enough information to make a choice. After all, that’s what friends are for.

    Steve Jones