Voice of the DBA

Author: way0utwest

  • Using the DAC

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    The DAC is a really important tool for anyone managing a SQL Server. You might not use it often, but when you need it, you really need it. I’d suggest you connect to your instances one a month or so using the DAC, just to be sure you know how to do it.

    The most common reason to use the DAC is when a runaway query is consuming so many resources the user can’t connect. The DAC is guaranteed resources, so you can always connect.

    When you use SQLCMD, the -A switch lets the connection method know you want to use the DAC. The DAC only allows one connection, so only one admin can connect. This also means it’s important to disconnect quickly if you don’t need the DAC.

    To connect, I use a normal set of parameters, -S for my server and -E for Windows auth. However I then add the -A, which connects me through the DAC.

    2015-07-13 10_48_04-Command Prompt

    Once I connect, I can run any of the normal commands, I need, like rebuilding master or killing a connection.

    2015-07-13 10_48_23-SQLCMD

    Keep this as a tool in your toolbox and practice regularly.

    SQLNewBlogger

    This was a quick post that follows on from starting SQL in single user mode as well as using the DAC in SSMS. I really just took some shots as I connected from SQLCMD.

    References

    The first link I saw was from my friend, Pinal Dave.

  • Be Professional

    I’m not a very comfortable flyer. I do it regularly, and I’ve gotten used to it, but I’m a bit scared when the plane appears to be anything other than a slow elevator to me. I’m not quite sure how I’d react if I were on a small plane and experienced what this author did above Washington State.

    The piece is really about being professional, and the way the pilot reacted in that story certainly wasn’t the professional image most of us want from their pilots. A few might like that, just as a few might accept most behaviors, but the majority expect something else.

    In the article, there are seventeen habits that can make you look more professional in the piece I linked, and for the most part I really think these are the types of traits and images that a professional wants to project. Whether you’re a CEO or a developer, having confidence and candor are as important as realism and caring. We all expect professionals to follow through on commitments and be diligent in their work.

    The only item I might disagree with is fitness. Perhaps that’s more important in some areas than others, but I have found many people that are highly professional, competent, dependable, and worth every penny that I pay them, but not very healthy. Some might be unhealthy to the point I’d be concerned for their long term prospects, but that wouldn’t mean they aren’t good professionals in the short term.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Security Payoff

    I wrote a few months ago about United offering rewards for people that discovered security issues in the United Airlines software. Not the plane software, thankfully, but in their customer facing IT systems. Apparently a few people discovered flaws and were recently awarded frequent flyer miles, a couple of which received 1 million miles. That’s a nice bonus for some people, though I hope the end result of this is that United builds better security into their software and learns to code better. Certainly other manufacturers have programs that have helped in the tech world. Microsoft, Google, and others have programs that pay bounties for flaws that are discovered and reported.

    However I wonder if this isn’t something that should become an accepted practice. I don’t necessarily want regulation here, though I would prefer our regulation not prevent the research and exploration of security issues. Imagine, however, if we had an accepted, known process for finding flaws in all software. Maybe this would be like a standard process, like reporting spam to the webmaster@ address for websites. If someone finds an issue, they let the company know. The company has a bounty of some sort, perhaps a token reward, and a limited time to fix the issue. One the time passes, the individual is free to disclose the issue to the public, the problem can be publicly discussed and analyzed. More importantly, the company now has liability for any data loss or productivity issues.

    In theory this should already exist. However it doesn’t seem to regularly work, and we have lots of software with flaws, along with no incentive to fix the issues, even when data is exposed. There are some laws for personally identifiable information (PII), but what about random data that might be annoying to users? What about the various software packages that we use that monitor our systems or provide anti-virus protection or manage other aspects of business. I’d like to see perhaps more class action arbitration (not lawsuits, we need less lawyers involved in the world) that perhaps doesn’t award damages, but refunds purchase costs. If that CMS doesn’t work, your money is refunded. I’d think that would incentivize some secure coding practices. If vendors had to make insurance claims, I bet we’d start to see more requirements of code reviews and PEN testing of software in general.

    This is certainly a hard issue to discuss. For every solution out there, plenty of edge cases or exceptions will be an issue. The openness and ease with which people can create software is a double edged sword. This encourages innovation and experimentation, resulting in some amazing new concepts, but that same freedom often also brings about lots of poorly written software, full of vulnerabilities and bugs. I hope that we find a way to mature this industry and start to build better, standard, well engineered practices and habits that encourage secure, robust, well written code.

    Steve Jones

     

    The Voice of the DBA Podcast

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

  • Hiring for Culture

    I’ve written in the past that I think that it’s important the hire people that get along with your group first, and with technical skills second. It’s not that technical skills aren’t important, but I think that fitting in with a team is more important. We can teach someone to be a better developer. We can’t easily teach them to be a person that others like to work alongside. Certainly, however, the person needs to have the technical skills needed for the job.

    When I was interviewed in college, the hiring manager told me there were two important tests to pass: Would he drive cross country with me and would he go out for a drink with me after work? That doesn’t imply that those are the most important (soft) skills for a candidate. It’s that all the other, more quantifiable skills were similar in all the candidates. The ability to get along socially was a differentiating factor.

    I was reminded of this reading a blog post that hiring for culture can hurt your culture. It’s a look at a developer’s opinion about the ways in which some startups operate. However I think the author confuses social situations or behaviors with culture. The culture includes much more than our schedule of activities outside of work. It includes our attitude towards work, towards building software, towards each other. Certainly this is mentioned in the piece, but there seems to be an emphasis on the social interactions with new hires.

    Certainly a person coming to work at a company that refuses to engage with others in any way outside of work can be a problem. We need to get along with each other as social creatures, and be able to hold a conversation with each other that might not involve work. However I’m not sure that anyone expects every other employee to have, discuss, and participate in the same interests as the manager or even a group of people.

    Finding a cultural fit is a difficult task. I do think plenty of people hire the best programmer they find (whatever that means), regardless of their ability to get along with others. I also think plenty of managers hire someone that gets along great, but isn’t a good employee. As with many things in hiring, finding a balance of talent, attitude, work ethic, and social compatibility is important and worth striving for, but difficult to actually achieve in practice.

    Steve Jones

    The Voice of the DBA Podcast

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