Voice of the DBA

Category: Editorial

  • Certificates Everywhere

    To me, certificates are the best way to secure communications and be aware of what’s allowed and what isn’t.

    One of the things that I think has been most disappointing to me in technology over the last few decades is the lack of progress is managing security keys and certificates. There hasn’t been a really good method designed that works well at scale for disparate organizations.

    Recently at the DevConnections conference, I saw a talk where Mark Minasi talked about the future of tablets and smartphones, where he mentioned the idea that we will use many devices in the future that don’t necessarily need to connect to the domain inside a company. They’ll still authenticate, but with certificates.

    That would be the ideal situation for me, a world where we individually have multiple certificates that identify us, and allow us to have secure communications, layers of security for different purposes, and a way to easily revoke, change, and add new certificates as needed. I’d be able to use easily manage certificates across devices to provide some level of authentication.

    As we move to the deep intermixing of user and company devices, it does start to make sense that we consider using a more ad hoc authentication scheme that can be deployed in a more distributed fashion, rather than the monolithic, authenticate to the domain completely or not at all, scheme we have now.

    I don’t have a solution worked out, but I know there are some very smart security people out there and I’d hope that they are working on a variety of solutions that will increase the security we have, while allowing us lots of flexibility.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The On-call Demands

    I used to sleep with one of these on my chest to respond to issues.

    I have been on call in all sorts of situations, but over the years the demands lessened at a few companies. Perhaps that was due to maturity on the part of the staff, or maybe the quality of basic software has improved over the years. I know that hardware has improved and it seems that less and less alarms from failed hardware interrupted my evening hours.

    However the amount of after hours calls varied widely, often related to the size of the company. In larger companies, it seemed as though there were more calls per week, but more people to handle them. Smaller companies often had me responding to anything, but there were few calls. This Friday I’m wondering what it’s like for you.

    What is your on-call schedule and the frequency of calls after hours at your current job?

    I’m wondering this week what type of demands are placed on you to respond to issues outside of normal work hours. I assume that a major issue might result in a late night call, whether or not you are formally “on-call” or not, but what is the official on-call schedule like for you. How often are you on call, and how often do you get called. Let us know this week.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Treat the Database like Code

    Source Control can drive people crazy

    In one of Grant Fritchey’s presentations at SQL Server Connections recently, he talked about treating the databaese like code, and storing the changes you make, the DDL for the objects, and more, in a version control system of some sort. Grant had a number of points to make about why this is good, not the least of which is that it brings the DBAs closer to the developers.

    It was a great presentation and it made perfect sense to me. I’ve always tried to store my DDL code in some sort of VCS, checking it and out as needed. I found it helpful for keeping track of which version of an object was released with which deployment. This also helped me to organize the changes which I was going to release, branching them away from the full list of changes stored in source control.

    Databases don’t inherently lend themselves to source control, with the various levels of state that must be stored, the strict ordering of changes, and more, but by imposing a little discipline, you can include the code and keep track of everything important for deploying changes. It’s not easy however, especially since the process of building a current version of your database from VCS would not be the latest change to each object. Objects are built with CREATE statements, but changes over time are made with ALTER statements. A little creativity will help you here, as will any number of third party tools that can keep a current set of CREATE statements handy.

    If you’re not storing your DDL in a VCS, I’d urge you to start. You might not need the features often, but when you do, having versions available can be career-saving. There are a number of free VCS systems available as well, so there’s no monetary reason why you can’t start tracking your code tomorrow.

    Steve Jones

    SQL Source Control from Red Gate Software can make version control possible from within SSMS. Download your trial version today.

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • My Little Friend

    Say hello to my little friend:

    script button
    I love this button!

    This button is my favorite part of Management Studio. It’s on every dialog that I’ve seen in the 2012 version of the tool and I’ve begun using it quite liberally. At a recent talk, I told the audience that they should never click “OK” in SSMS again, and should instead click script and then cancel whenever they were making changes.

    Someone asked me why, and I had a few reasons, all of which seem to me good reasons to make use of my little friend. First it’s easy, Apple/iOS easy. When things aren’t easy, we tend not to do them, but clicking “script” is painless, it doesn’t interrupt you, and it produces the script you need in a new query window. That alone ought to be a good reason to use it.

    However there are other reasons as well. It’s a chance to see the exact code being run and making sure it’s what you want. If you aren’t sure, and you shouldn’t be running code without understanding it, this is a good way to learn. It’s also a great logging tool. One of the things that has made me successful as a DBA over the years is documenting what I do. Many of my colleagues haven’t done this and then spent hours trying to determine what changed on a particular system. If I script out the code I run, I have something I can easily drop into a log for future reference.

    To me, this is one of the tools that should improve the knowledge of SQL Server professionals everywhere, by increasing their awareness and knowledge of what’s happening on their instances. I’d be happier if the “OK” button would just produce the script and never run it, but I’m not sure we’ll get Microsoft to agree to that change.

    Now if I only had a “Powershell script” button right next to it…..

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.