Voice of the DBA

Author: way0utwest

  • Powershell in a Month Day 13 – Remote Control

    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.

    Remoting. It sounds complex, and intimidating. It isn’t, and it’s powerful. It’s also essential, allowing you to access commands on remove machines.

    The chapter starts with the idea of remoting, and running commands elsewhere. We learn this comes from telnet and other remote type access, and is implemented as a web services protocol, WS-MAN. Incidently, this is how SSMS works. Your T-SQL is executed remotely on the server, not on your workstation. Lots of people don’t get that and get confused.

    This chapter presents a challenge. You need a domain for security to work correctly, or easily, with remoting. There are potential workarounds, but it’s an issue. I haven’t had a domain at home because of overhead and not wanting a domain controller set up. That means some setup work to build a couple virtual machines and create a domain.

    Ugh. Annoying, but it’s something I should do. I have wanted to rebuild a domain for some time, but haven’t bothered, but this is the excuse to do so. As such, I read the chapter, and started setting up the domain. That will take a few days, so I’ll continue on with the next chapter as I get a domain ready. More notes to come once that’s done.

  • 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.