Voice of the DBA

Tag: administration

  • Document, then Install

    I saw someone post a note that they had installed a new SQL Server and wanted to document the install. Did anyone have a good script or process for doing this?

    I’ve done this myself, but lately it seems to be the wrong way of actually building systems. One of the things I have started to feel is important is that I should strive for consistency and known states for systems rather than works of art.  However if I’m installing systems and then documenting them, I think that I’m doing things backwards.

    There has been a trend towards declarative actions in technology, whereby we tell the system what we want and it configures itself to arrive in that state. An example of how some this can be done is with Puppet. This is a case of the administrator essentially documenting what they want to be done first, and then letting the system put itself in that state. It’s almost like programming the installation and configuration of software, but with tools to make the process much smoother.

    In this model, administrators don’t need to document the installs. They’ve already declared what needs to be done. If vendors change defaults in the future it doesn’t matter, as the installations will configure themselves to the same state, ignoring defaults and human expectations. This also results in much more consistently configured systems, something that’s critical for building a smooth software delivery pipeline.

    The closest thing I’ve seen to this for SQL Server is the Finebuild project that Ed Vassie set up. That’s much better than unattended installs and I’ve seen Finebuild demo’d, and it looks good. I need to set it up so that I can ensure that every instance I set up is in a known configuration. I can have multiple configurations ready, but I’d rather choose one of my choices and then let the system apply the settings than remember to click a particular check box or change some item manually. I’d also appreciate this for DR and auditing, with some list of settings for each instance or host.

    That just seems more like a 21st century way of working to me.

    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. 

  • Automate Yourself to a Coffee Break

    I’ve worked as a production DBA in a few companies, and in those positions, I’ve always worked to make my position one of “insurance,” with me able to respond when things go wrong. My goal has been to understand, improve, and enable an environment that runs smoothly, which allows me to take leisurely coffee breaks and not hurried (and harried) sips of coffee as I walk from the coffee pot back to my desk.

    There was a good article published recently about the mindset of a DBA and how automation is an important part of your job. If there’s something you can easily automate, then it’s probably something you should automate. There are plenty of tasks that are easy to script into jobs, set alerts for, or have the system perform some action when they occur. If the system is performing that work, then you have time to deal with other, higher value tasks.

    What are those higher value tasks? Well, what things do people complain about, but you never get the time to work on? Perhaps tuning queries? Maybe practicing your skills for a disaster? Finding time to analyze the performance of systems and plan for the future? There’s probably no shortage of things that you wish you had time to deal with because there is no shortage of busy work you’re assigned.

    Do yourself a favor. Look for places to introduce automation through T-SQL scripts, Powershell commandlets, alerts, and more. Practice writing some small program to manage a task for you. It might seem like it will take longer than doing the work, and it will. However the next few times you’re asked to complete the same task, it should take you much, much less time.

    Steve Jones

    The Voice of the DBA Podcast

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

  • 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.