Voice of the DBA

Tag: administration

  • The Ten Commandments for DBAs

    I like lists, and this list certainly caught my eye: the 10 commandments of database management. It’s from a lead database architect that has experience with a variety of RDBMS’s as well as NoSQL technologies. It’s an interesting list, and one that tries to cover all the aspects of a DBA’s job.

    It’s a good list and for the most part it’s how I’ve tried to manage systems throughout my career. I believe in monitoring systems. I believe in testing backups. I believe in change management, though it doesn’t have to be heavy-handed. I think automation is key, and certainly DBAs should understand the pros and cons of their platform.

    However, I don’t know that I think upgrades should be completed for systems without some evaluation of the benefits and risks. These days, with releases of database platforms coming every 2-3 years, I’m not sure that I would want to upgrade many of my systems to each version. I might skip every 2-3 versions and upgrade rarely.

    I recognize that some of these can be outside the control of the DBA, but to the best of their ability, I do think a DBA should be looking to help developers, secure their systems, and choose the best systems to meet their needs, given whatever restrictions their organization puts on them.

    I don’t know that this is the best list of commandments for a DBA, but it’s certainly a great start. It’s also a good basis on which to conduct yourself as a DBA if you don’t have a well defined code you follow.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Real Scary DBAs

    I ran into someone recently that told me they were scared at their job. This person had built a number of ETL jobs to move data around between systems. They were trained as a developer, but had a little experience, got sucked into working with SQL Server, and had made a career without really considering themselves a DBA. They seemed a bit bewildered that they hadn’t messed up the data in any of their employer’s systems.

    I’ve met quite a few people like that, who seem amazed to be trusted to accomplish the work they do on a regular basis. It’s good that many people can go through a career in SQL Server and successfully accomplish the things their employer needs done. However there’s no shortage of “scary DBAs” out there that are in over their heads and do cause damage to data and systems.

    I see questions at SQLServerCentral on a regular basis that scare me. Not because the question is particularly hard, but because the person asking the question seems to be trusted with way more responsibility than they are capable of handling. I’m glad they’re asking questions, but often the additional questions they ask, or the lack of understanding they display about the answers have me worried. It’s not that these people are stupid, but often they don’t have the experience to do the job they’re assigned.

    All of us have things to learn. Many of us continue to learn on the job, often as we’re getting work done. I think that’s a valid way of going through your technology career and I hope most of you continue to improve your skills on a regular basis. However there are quite a few people that have little aptitude for their chosen field, learn the barest minimum to get by, and often implement code and configurations without understanding what they are doing.

    Those are the really scary DBAs and I’m amazed that so many of them are trusted by their employers to actively manage organizational data.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music.

  • Hooks

    I read this sentence recently, and it really caught my eye, mostly because I’ve rarely seen hooks being built into the software systems that I’ve written, or that have been deployed to my production systems.

    “A quick chat with your Operations team should convince you of the necessity to log every error condition to a single wellknown location, with the appropriate severity, so that they [the Operations team] know exactly what the problem is.”

    It seems obvious, but so few people I know have taken advantage of this. Far too many software products build their own logs and display errors on screens rather than alerting operations departments. So few people have taken advantage of RAISERROR to write to Windows logs, or the custom SQL Server performance counters to disclose information to operations systems or personnel.

    That’s my experience, but I wanted to ask you this week how you’ve handled things. Do you have software installed that does this? Is it a part of your development process to include hooks?

    Do you hook your logging into operations systems to alert others?

    As I think about it, I can’t imagine not doing this now. After all, I like to sleep. I don’t need calls at 2am from Production operator trying to find a log and debug a problem. I’d rather ensure that I log information to well known places and ensure exceptions will catch the eye of operations people. I want to give them as much information as I can in order to help them solve the problem. I’d rather sleep and depend on the on-call staff then be woken up because they rely on me to solve problems.

    Personally I think that logging to the Event logs, or including configuration switches to send alerts to other software ought to be part of the best practice of developing software. It’s a maturity point where we recognize that we’re building interconnected systems, not individual bits of software that live like hermits.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Reverse Engineering Disasters

    If you are responsible for managing systems, you should have some sort of disaster recovery plan. Even if you are only managing the one system you carry with you on a regular basis, you should ask the question: What would it take to destroy this data?

    It’s a good question, and in the post I’ve linked above, a technologist talks about some of the failings of disaster recovery plans because they forward engineer plans to recover systems. People think of specific problems and try to prevent them. They don’t reverse engineer to find out what events would cause them to lose their system.

    That’s really the key to a lot of design and architecture in computer science. You can’t think about just what you expect to happen, or even what you want to happen. You have to consider the other ways in which events could occur or the issues that could cause an problem in your system. In development, the things you expect are considered to be the happy path. A good architect or engineer will think about everything else in addition to the happy path.

    I sometimes think that far too many decisions are made while considering the happy path, but ignoring or discounting the other paths available. These other paths may be unlikely to occur, but having worked with computer for over 25 years, I can tell you that I often find the least likely events occurring far too frequently.

    As the author says, you should never say “I never even thought of that happening.” Consider reverse engineering problematic situations and then make a judgment of how likely is it that any of the events will occur. That way you have at some idea of what could go wrong and what events you are willing to protect against.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.