Voice of the DBA

Category: Editorial

  • Due Diligence

    I often talk with people about building their brands and finding a way to ensure they are a highly desirable employee. One of the ways that I think people can do this is with a technical blog about their career. Having a technical blog allows someone to show off their skills in a particular area. The blog doesn’t have to be ground breaking work or extremely innovative solutions to complex problems. While employers need those people, they also need people that do solid work every day on regular problems.

    An interview isn’t a great way to find good employees. Many of us have had experience with either (or both) sides of the interview table and realize that interviews aren’t necessarily that helpful. If we bothered to track the impressions we make of candidates and compare that to the actual work they accomplish over the first year or two, I suspect we’d find that we have no evidence that were making great decisions. The success of employees seems to be a bit hit and miss.

    A blog, however, provides the employer with a bit more confidence that a person can handle the job they are hired for. A blog takes time, and across months (or years), it can show quite a bit about a person’s knowledge and skills. It allows hiring managers, and co-workers that may interview a person, the ability to perform a bit more due diligence and investigation into someone’s skills than an interview provides. It’s much more of a representative look at a person than what they say or write on a resume.

    I know that it isn’t a perfect solution. People plagiarize posts and copy from Books Online and more, but the Internet helps here. Search a few of their paragraphs and you might catch plagiarizers easily. After all, someone that wants to copy posts to avoid work, probably has a few other tricks in their bag to avoid doing other work for you.

    Think about starting a blog today and giving potential employers a way to learn more about you.

    Podcast: http://traffic.libsyn.com/voiceofthedba/duediligence_57_v1062.mp3

  • Consolidation Matters

    Throughout my career I’ve been looking to consolidate SQL Servers when I find them. The typical employer I’ve had usually grows their IT infrastructure over time and many projects look like this:

    • Build or buy a software package
    • Buy a new server
    • Install SQL Server and one database for the application

    Over time this means I find lots of individual servers running at much less than full capacity. That’s something that DBAs like, because it means that we can handle the inevitable spikes in resource usage that our workloads will encounter. However that’s not what the rest of the business, especially the financial management, wants. Underused resources mean money that isn’t spent well.

    As a result, I’ve often looked to consolidate instances where possible. Often I let an instance run by its own hardware for a period of months, perhaps even a year, during which I can get a good idea of what level of resources the database and application require. Once I have that, I try to match up the needs with an existing SQL Server that might be underutilized by at least that amount of resources. Typically I’m looking at RAM and CPU since disk resources can often be transferred to a new piece of hardware. It’s not quite as simple as it sounds as I also need to look at workload patterns and potentially match up instances whose workload peaks occur at different times.

    I’ve successfully consolidated many instances this way, often reducing the amount of physical hardware in data centers substantially. As hardware cycles turn over and newer machines are purchased, I can usually repeat the process again and again. The advent of virtualization has made this even easier as bad guesses can usually be reversed or corrected by moving the database to a different instance.

    I suspect that virtualization will become more important in the future, especially as licensing changes in SQL Server make it much more expensive to add the ad hoc instance on its own hardware. I’d encourage you to plan on consolidating new databases from the beginning to ensure that your organization gets the most performance out of the hardware that it has purchased.

    Steve Jones

    Podcast: http://traffic.libsyn.com/voiceofthedba/consolidation_56_v1061.mp3

  • Advice for Newcomers

    A friend recently was asked to give a presentation on their career to a group of 12 year olds. It was a challenge to engage the students, and my friend was surprised that very few of the kids were interested in technology. I was disappointed as well since I think this is a great career choice, and worth a little investigation, especially at that age.

    It’s hard to convince people to enter this business if they don’t have any interest, but if they do, I’m wondering what you might tell them. Today I’d like you to think about your words of wisdom to someone interested in your job.

    What would you tell someone that you wish you knew early on in your career?

    You might impart some hints about how to approach technology. You might give them ideas on how to build skills faster or better? However for me, I’d tell them two things.

    First, you can’t underestimate the value of networking, no matter what field you enter. Whether that’s technology, medicine, law, or anything else, networking will help you. Learn to make contacts and interact with people.

    Second, learn what you don’t like to do. Experiment with the technologies, practice the jobs, and understand what you don’t like. You might not find something you have a passion for, but I’d certainly encourage you not to enter a field that you just don’t enjoy.

    Steve Jones

  • One Database to Rule Them All

    This is what you build to juggle 6,000 tweets a second. That’s the headline that caught my eye and it’s about the challenges of Twitter and the data that they handle. Twitter definitely has a tough problem, one that few of us have, but perhaps they can help us learn to better deal with our own data from their experiences on an edge case.

    The story is journalistic, not so technical, but it is interesting. Twitter has struggled with a blend of data that is partially crucial and must be consistent now (usernames) and other data that can be a bit out of date (tweets). They also have lots of unstructured data (photo/video) that is combined with more traditional, structured data. They’ve used a few different database platforms to store this data and assemble it with their application. That’s the same things that most of us also do when we deal with many different types of data.

    However Twitter is trying to find away around dealing with disparate systems. They’ve had a number of engineers working on Manhattan, their database designed to handle both structured and unstructured data. And because they work for Twitter, this platform is designed to manage all of this data with very high workload demands at scale.

    It will be interesting to see if they come up with any innovative ideas. Certainly SQL Server already has options for managing structured and unstructured data, though perhaps not at the scale Twitter needs.

    Steve Jones