Voice of the DBA

Category: Editorial

  • 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

  • Happy New Year 2018

    It’s the start of a brand new year, and hopefully many of you are not anywhere near your work today. I hope to be running a 5k this morning, so I’m up early, at my usual time for work, getting ready with a jolt of coffee before a nice jog. I haven’t run a lot the last few months, so I’m just going for fun. I’m writing this early, so if the weather is bad, I’ll likely go to yoga instead.

    In any case, this is usually a day off for most people working with data, so I hope you enjoy yourself with a quiet day before we begin the new work year tomorrow. I’m excited, with less travel, to tackle some projects around SSC. We are looking to upgrade hardware and software, moving into the new era of SQL Server, maybe even with graph tables! If there’s something you’d like to see, apart from bug fixes, let us know. I’ll be meeting in the next few weeks to lay out a direction and try to get moving forward.

    Happy New Year!

  • 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