Voice of the DBA

Author: way0utwest

  • Margaritas and TexMex at VS Live

    takes place in a few weeks and I’m excited. Austin is one of those cities I enjoy visiting, with a few friends, now a Redgate office, and some great good and drink. I’m hoping my wife will come along and we can enjoy a few days there.

    However, I’ll also be speaking at VS Live in May, which is a great conference for many of us that wear mixed hats. So many people these days don’t get to just work with SQL Server, or perform software development without having to understand more about deployment or networking or something else.

    If you’re trying to get, or being forced, to think about DevOps, VS Live is for you. Tell your boss, this is the chance for you to expand your skills, add development skills if you’re a DBA, or add DBA (or cloud, or Windows) skills if you’re a developer.

    Register for VS Live in Austin, which has to be one of the best locations. Good conference and content, good weather, great food, cold drinks, and plenty of music to enjoy at night. Register today today and

    I hope to see you there, and let’s talk SQL Server and DevOps.

  • Staging Deployments

    This editorial was originally published on Nov 30, 2011. It is being republished as Steve is out of the office.

    Software development can be a complicated dance. Most of us do not work for a software vendor and don’t have the strict requirements for our deployments when we control the client systems. That doesn’t mean it’s easier for us, especially as our environments grow more complex and the availability of our systems becomes more important. Application changes can become disconnected from the database changes, especially when the scope or scale of the change is large, which can present problems.

    Making database changes can be challenging since we must ensure that our data is not lost as objects are altered. We have to ensure that any application functions that depend on a certain schema receive the data they need, without unnecessary errors. The timing of changes becomes more important in the database than in applications in many situations. This Friday I am curious how many of you decide to stage these changes in your environment. If you have dependent changes, I’m wondering if you might alter the database first and change the application in a later deployment.

    How many of you deploy database changes before code changes?

    By “before” I mean you deploy the database changes, possibly making some application changes, but there are other code changes deferred for a separate deployment at a later time. The use of views, defaults, optional parameters and more allow database changes to proceed without accompanying application changes. It may require a bit more work, but the database can potentially be changed during a less busy time, even if development or testing for the all the application changes is not complete.

    The future will require more availability and stability from our systems as they become more essential to our organizations. Learning to update software, and databases, with minimal disruption is a skill that will set you apart in the future.

    Steve Jones

  • Speaking at SQL Saturday #621–Silicon Valley

    Once again I’m heading back to the Valley. I was accepted to speak at SQL Saturday #621 – Silicon Valley on April 22, 2017. This is one of the larger SQL Saturday events in the US and I enjoy visiting California, so I’m looking forward to the event.

    I’ll be talking DevOps again, trying to convince some of you to start testing database code, others that database development and deployment can move quickly. This is a similar talk to the one I’ve delivered a few times and hopefully I’ll get a few people to think about changing their development practices.

    If you’re anywhere near Mountain View on Apr 22, consider signing up and coming by the Microsoft Technology Center in the area. It’s a neat building and there will be some great speakers. A good chance to learn more about the SQL Server platform.

  • Dealing with Supervision

    This editorial was originally released on Feb 4, 2013. It is being republished as Steve is out of the office.

    I’ve been working at home for a decade, first for my own company and now for Red Gate Software. In that time, I’ve learned to manage myself, motivate myself, find work to do, and meet deadlines, all of which I’ve done without having anyone manage me. Over the last five years I’ve worked at Red Gate, I’d like to think that I was one of the easier people to manage since I work well on my own. I’m not sure if my various managers would agree, since I know that I can be particular about how I work and not necessarily work closely with others, but at least I haven’t required much of their time.

    A short while back I was talking with a friend that was under pressure to complete a deployment that was proceeding poorly and their manager stood next to their desk, watching, commenting, and asking how long each process would take. I’ve had to deal with that situation in the past, and it was  maddening to me. It’s hard enough to focus and work on a task when there are problems with the technology. Having someone that can’t contribute but is in a supervisory role nearby usually makes things worse.

    Ultimately I think micro-management says more about the manager than the employee. There are trust issues or control issues, or perhaps pressure from the manager’s boss. It can be hard to deal with micro-management, but if you plan to continue your employment, you need to find some way to deal with it.

    There is no shortage of ideas. You can search for “dealing with micro-management” and you will get a wide variety of advice. I’ve tried different techniques in the past and some have worked, some haven’t. The best way to handle micro-management seems to vary with the situation, but it’s good to have a few things to try.

    Steve Jones