Voice of the DBA

Author: way0utwest

  • DBA Support

    This editorial was originally published on Oct 28, 2012. It is being republished as Steve is out of the office.

    There was a time when I managed two production databases on SQL Server. Two. I had a development version of one database where we paused development for testing, and only two production databases to manage. Since I had to also handle development, application support and hardware repair/replacement, that seemed like plenty to me. I was the accidental DBA, with database administration being the lowest priority of my day.

    After that I moved on to administer databases in a number of jobs, sometimes as a priority, sometimes not, but in each case, I learned to work more efficiently and effectively. My goal was to automate as much as possible of the routine work so that I could spend my days adding value to the company. I learned to use scripts, alerts, jobs, and more to keep systems running while I was doing other work.

    I’m sure many of you work in a similar manner, or at least I hope you do. This Friday I wanted to ask you at what scale do you need to become efficient, based on the size of your organization. The question this week is:

    How many databases does each DBA in your organization manage?

    I know some of you manage lots of databases in raw numbers, but also let us know if you need to do much with these databases. Is maintenance automated, or is there much active management you need to do in order to ensure these databases are running on a weekly basis. Let us know the size of your load as well, perhaps the amount of data is a better way of measuring the DBA load.

    Steve Jones

     

  • Back for a Day

    I hope everyone is well in Florida, but the hurricane caused a postponement of SQL Saturday Orlando. Fortunately I caught the note early enough on Wednesday and spent about an hour at lunch cancelling travel plans and moving my flight from DC to Orlando to Denver to an early DC to Denver flight on Thursday.

    That worked out well, as I delivered my session just before lunch, raced to the airport and made a flight out to Denver, arriving in time to get down to watch my daughter’s volleyball match. I even only missed 9 points.

    Now ‘I’m sad in that I won’t make the 10th SQL Saturday in Orlando, but I am happy to have a day back in my life to catch up on a few things.

  • A Software Warranty

    This editorial was originally released on Oct 21, 2012. It is being re-published as Steve is traveling.

    Years ago I worked in a large company on the operations team. We were responsible for all production issues for the 6,000 people and the assorted machines, devices, and applications that come with a large workforce. There was a department that was aligned with our group that focused on engineering and various development groups that built different applications. The engineering group was good at working closely with the production team to ensure smooth deployments, but they weren’t on call and would at times respond slowly to develop solutions when problems occurred. They were, however, better than the development groups who often sent code to be deployed, and accepted bug reports back, but provided little support or assistance for problems with their code.

    I ran across this link from a DevOps person called You Write It, You Support It in the Brent Ozar, PLF newsletter. The piece makes a case for the problems that occur with some deployments, like a lack of, or surplus, of logging, switches to turn features on/off, error handling, and more. It’s a pretty good description of typical problems I’ve often seen, and it calls for developers to support the features that they write, even in production systems.

    I like this idea, though I don’t think that it should be a continuous expectation with developers required to support their code forever. I would like to see developers giving their code a “warranty” of sorts, perhaps a couple months of priority support when code is deployed into live environments with developers taking responsibility and responding to calls, even after hours.

    There are arguments to be made that developers’ time is better spent enhancing applications and applying their creativity to new ideas, but this leads to a human frailty. Too often we view a job finished as a job completed, and that’s not always the case. Doing a job well means more than completion. It implies a level of craftsmanship and pride in the finished product, both from the developer and the client.

    Developers should write code that works. If it doesn’t, then it’s not really finished and should be fixed. With that contract in place, we usually find that the developer spends a bit more time ensuring the product is built in a quality way that reduces the need for much support.

    Steve Jones

     

  • Off Again

    It’s another week of travel for me, starting early this morning. This is another crazy trip, and yes, I did this to myself. However, I am taking note this time and I’ve already declined and refused a few things for 2017 to try and avoid these trips.

    My week:

    • Tues am – Fly to DC, get prepped.
    • Wed – Speak VS Live
    • Thur – Speak in the am at VS Live, catch a late afternoon flight to Orlando. Arrive after midnight.
    • Fri – Work a bit, then help Andy Warren with getting ready for the 10th SQL Saturday Orlando. Ten!!!!!!
    • Sat – Speak, SQL Sat Orlando, twice.
    • Sun – am flight home. I’ll be likely doing a few chores on Sun, maybe helping my daughter practice some volleyball or do homework (or both).
    • Mon – work, then fly to Las Vegas in the early afternoon
    • Tue – Speak at IT/Dev Connections twice.
    • Wed – Speak at IT/Dev Connections. Catch evening flight home.
    • Thur – Try to get back to normal. For a week.

    I head to the PASS Summit on the 24th, so not a lot of time to try and establish some normalcy at home and work. I have to find a way because I turn around and have two work trips in Nov and two more in Dec, plus a Christmas vacation with the family.

    For 2017, I’m planning less, so we’ll see if I learn anything.