Voice of the DBA

Author: way0utwest

  • Management at Scale

    Would you like to manage 20,000 databases by yourself? What about 20,000 instances? It’s not quite the same thing, but Facebook recently announced that each of their data center operations staff manages 20,000 servers. That’s an impressive number, and it comes about because of lots of standardization, specialized design, and lots of automation.

    If you watch the video, you’ll see that a lot of effort in the Facebook data centers is being paid to gathering and analyzing information. They seem to truly understand that having data about not only their systems, but their processes, is valuable. Maybe more importantly, they understand how to modify the way they work based on data to improve their efficiencies.

    We should do the same thing as DBAs. Perhaps even as developers. We should be monitoring our workflow and looking for ways to improve our effectiveness. We should take advantage of the tools that let us manage systems at larger scales. PBM, third party tools for monitoring and alerting, BIML or SSIS patterns and practices, and more. There are a variety of ways in which we can work more efficiently.

    I thought the best quote in the article was this one: The emphasis on automation is not because Facebook is interested in unmanned data centers, or having robots operate facilities. It’s because Facebook values its workers”. The next quote is “We want to hang onto our talent,” she said. “The way you do that is to give them the opportunity to work on high-value tasks.”

    Those are powerful quotes, and I wish that was how more businesses viewed their workers. To be fair, most workers haven’t proven themselves to be willing to tackle and want the “high value tasks”. All too often I find there are too many workers that want to get their job done, without providing more value than they cost. If they did, perhaps we’d have many more companies that would value their employees, and they could manage systems at something closer to Facebook’s scale rather than the much lower numbers I’ve seen in my career.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Common Checks

    One of the things that I recommend to DBAs is that as they write code to solve problems, they write some sort of check to catch future potential occurrences of the issue. For example, I worked with a product years ago that had an identity column as an int, but this product scanned thousands of our systems every 5 minutes, logging each scan. We found that after 8-12 months, we’d run out of identity ranges.

    While we considered changing to a bigint, this was a third party product and they did not want to allow us to alter the schema. Since there were only a few million rows in the table at any one time, we decided to write a check that would alert us when the table came close to running out of integer values. A DBA could then easily reseed the identity property to prevent issues.

    Across my career I’ve found many other instances where we could write checks to find issues before users were impacted. At SQLServerCentral we have checks looking for discrepancies in points awarded, in incorrect status values, and more. These often don’t impact the users of the site, but they are alerts that let administrators know about potential problems before they become issues.

    This week I’m wondering:

    What types of common issues have you found that could be valuable as checks for other DBAs?

    Perhaps looking for delays in replication or Service Broker? Jobs that never stop or never execute for some reason? Memory or space alerts? Do you look for localsystem as a service account? Let us know what checks you’ve written, or which ones you wish were available for you to download and use on your systems.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Too Much Choice

    As this piece shows, more information can be bad. As drivers get more choices, options, and opportunities to interact with information, they may not be driving as well as they otherwise might. Restaurants and retailers have seen something similar. Too much information either prevents decisions or slows the process. I know when I go to a restaurant that has too large a menu, I often find myself taking a long time to decide on an item.

    I think this can certainly be a problem for our clients in technology, as we discuss specifications and requirements with them. If we allow clients too many choices, and too many options, it can be hard for them to make a decision, much less understand the implications of their choices. As software professionals, we need to give clients two or three options, but recommend one and explain in a fairly simple manner what the advantages and disadvantages of each solution are.

    Too much choice can also be a problem for us in technology. If we have too many architectural options, we can debate entirely too long. If we have too many requirements, we may be unable to get work done if we can’t focus or distill them all down. If we have too many concerns, we may not find an effective solution because we’re looking for a perfect one. The latter is a situation I find all too often with developers that want a perfect, 100% solution when a 90% one will work fine because the edge cases so rarely occur.

    The exceptions to this, both in my restaurant experience, and in research, are when the person already knows what they want, or they have some preconceived idea. That can be good for us in technology, as we can move quickly when we have some idea of what is needed. However this is a double edged sword as it can lead us to work with tunnel vision, not thinking about the alternatives or possibilities we may face.

    In general I think more information is better than less, but we can’t let the abundance paralyze us from moving forward and accomplishing work.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Powershell in a Month Day 12 – A Practical Interlude

    This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

    This chapter is a practical one. Build a scheduled task that removes all jobs from a certain printer. Not that hard, but we’re using Powershell, and I’ve never done this for sure.

    The chapter walks you through a process, though I’m not sure this is the best one. After all, building scheduled tasks from Powershell seems to be overkill, especially since I’ve rarely scheduled the same thing across multiple machines. Except SQL Agent, and there it’s certainly easy to use T-SQL to do so. However, I get the idea. They want you to work through looking for commands, and then figuring things out within Powershell.

    The other problem I have from this item is that there are typos. The command they first show with a parameter of “printer”, but that caused me errors. It needs to be “printername”. That threw me at first, and made me think if things didn’t work, I wouldn’t know where the errors were.

    As I worked along with the authors to create a task, trigger, action, etc. I felt somewhat empowered, but I also felt that they didn’t quite explain the details enough of how they delve into the commands. A lot of information is returned when you run help, and it can be confusing or difficult to choose which items to link and how. Overall, I felt they shortcut’ed the explanation a bit for people learning Powershell.

    However, the lab was similar. Create a folder and share it.

    I’ve done this lots of times, but not with PoSh. I knew that many of the DOS commands like “mkdir” work, but I wanted to find out what was the basis. A little help showed me this was the New-Item command. A few experiments and I had created a C:\Labs folder on my machine. I was thinking this would be a pipeline command, so I saved it.

    $cf = New-Item -path "c:\labs" -type "directory"

    When I saw the folder in Explorer, I felt a bit proud of myself.

    From there I dug into help with *share* and found the SMB share items. I’ve know that file sharing was with SMB, but I could certainly see some DBAs and others wondering. When I’ve used “SMB” in a few talks, I’ve gotten some blank stares at times. Anyway, I completed the task easily, and figured out I couldn’t pipeline these tasks. However, I had remembered somewhere in my mind that ($cf) would execute that variable, and that worked.

    Overall this was a good chapter and exercise. I could certainly see this lab being handy as I’ve often wanted to standardize things, like backup directories, on a lot of servers. I’ve even had standard shares at times.

    This was a good building block to learning how to assemble some commands and accomplish a task. I’d like to see 2-3 small tasks like this to help learn how to build to bigger projects. Perhaps that’s coming.