Voice of the DBA

Category: Editorial

  • DBA Support

    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

    The Voice of the DBA Podcasts

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

  • A SQL Server Log Reader

    SQL Log Rescue
    It would be great to have a log reader built in. If you’re still on 2000, here’s a free one.

    One of the regular problems that data professionals have to deal with is the whoops disaster, or some type of data entry error. It could be the DBA running a delete without a WHERE clause, or a user updating a bunch of data incorrectly. No matter what the cause, this is a problem that you will deal with multiple times in your career. There are a few tools available that will read the SQL Server transaction log and build reversing transactions, but there are few, mostly because there’s just no money in the tools. People don’t need the tools often, and when they do, they are likely to just download an evaluation, fix their issue and not purchase the tool or struggle to undo the damage. As an aside, if you are still working with SQL Server 2000, Red Gate has released our Log Rescue tool for free.

    With every new version of SQL Server, there’s a lot of effort spent on building new features and enhancing old ones. Marketing and sales drive a lot of resource decisions in product development, and that makes a lot of sense. But it doesn’t mean that there isn’t value in plugging holes inside of the platform and making SQL Server easier to work with.

    A log reader tool would not be that hard to build and include in SQL Server. I’m sure Microsoft could build and release limited versions that might deconstruct certain types of statements, or might only read transaction log backups. I bet this would be a great intern project, allowing the very talented youth that spend a semester or two at Microsoft the chance to make an actual impact on the product. Back-ports to previous versions of SQL Server could be done with very little cost to Microsft, provide customers with a valuable tool, and allow college students to prove they are worthy of a future job working on the product.

    The ecosystem around Microsoft products is important, both for the growth of the platform as well as filling customers’ needs. Log readers, however, are not economical separate products. They ought to be incorporated into the platform, filling a hole that would greatly benefit lots of DBAs and developers who deal with incorrect data updates every day.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Walk on the Wild Side

    lou reed walk on the wild side
    Have you ever worked on the other side of your shop?

    In my career, I’ve worked in a variety of environments and positions. I’ve been a developer, and a production DBA, sometimes at the same time. Many of us aren’t working in environments where we are strictly performing one job. We often flex our work to meet the needs of our organizations, doing whatever is needed to get the job done.

    However many of us spend most of our time either producing software or supporting it, sometimes separated from the other side by internal rules or even regulatory requirements. Those of us that are successful usually learn to make friends with the people doing the other kind of job and these relationships allow us to bend rules and regulations to get things done quickly. That can be a good thing, but it often doesn’t really give us any appreciation for the job that others do on a regular basis.

    In a few large companies I’ve worked in, management felt it was important that the developers or engineers spent some time in the operations area. People would rotate out of their area for a month and spend time working in another area, gaining skills that might allow them to provide support in an emergency, but more as a way of helping them understand the impact of their work and how they might go back to their job with a new perspective in the future. The ultimate goal was for design and development to proceed more efficiently and at a higher quality level. It worked well at times, but often failed if the developer didn’t embrace the temporary assignment with a positive attitude.

    I’ve rarely seen administrators sent to work with development groups. Usually an administrator has to have an interest in development and is interested in making a career change. However I think that there is value from giving administrators some exposure to the development process. They might realize how complex and tedious it can be, how seemingly obvious problems slip through, and perhaps most important, they might learn how to better troubleshoot issues in production systems.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • A Software Warranty

    pocket knife
    Shouldn’t software developers give a warranty we can potentially void?

    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

    The Voice of the DBA Podcasts

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