Voice of the DBA

Category: Editorial

  • The Aware DBA

    A long time ago, at least, a long time in the eyes of my kids, I worked for a large organization as a production DBA. We had a generic monitoring tool, but it wasn’t SQL Server specific. I ended up writing my own enhancements for the tool that used its data, as well as gathering other SQL Server specific items into a local database on each instance. From there, I had this data copied to a central location each night and a report generated. This helped us with ISO certification (originally) and later, Sarbanes-Oxley compliance.

    I was reminded of that when I read Pamela Mooney’s post on Things You Should Know About Your Server. She follows the simple method of ensuring each server monitors itself and rolls up that data. This works well, even if I’d never want to do this again. The time I spent building a monitoring system wasn’t really time well spent. These days I’d buy some monitoring software and then query that data, bother the vendor for enhancements and have either a notebook or a smaller set of processes that gathered specific data I might need. Likely I’d use XE and some stored query data, but if I monitor infrastructure, I don’t want to have to worry about building and maintaining monitoring software.

    The main point from Pamela’s post, however, is that she seeks awareness of how the systems work. That’s the key for a successful sysadmin of any system. You should not, and do not want to, check each system every day, but you do want to know how to find out what is “normal” quickly and be aware of changes. We want to quickly narrow down potential and possible problems because of our experience and history with some server/instance/application/etc.

    Most of us get calls on a few systems regularly. We may know those well, but often we’re fire fighting and normal can be an elusive definition. There are often many systems that we rarely get called to examine, but most good DBAs I know have some idea of how almost every system performs. Having a little data available quickly allows us to diagnose whether a problem is real or imaginary, chronic or transient, as well as how to proceed to resolve any issue.

    Awareness is an important skill when dealing with anything on a regular basis in your life. Certainly in parts of life outside of work, but even at work, paying attention and having some idea how how your environment should work will help you catch, diagnose, and solve issues. The best DBAs might do this before the client even calls.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Problem with Users

    I think Troy Hunt is an incredible thinker. His view and work to improve security in infrastructure and applications is incredible and valuable. I think the focus on better passwords and the implications of data breaches has grown in the world, perhaps due to Troy’s work with https://haveibeenpwned.com/. Plenty of non technical people know about the site, and more than a few government officials.

    Recently I read a piece from Mr. Hunt on passwords and why they will continue to exist for some time. I agree that the understanding and convenience of passwords makes them a tool that will remain widely deployed for some time. I like the additional verification from Google and other sites with a text or message on a phone for MFA (multi-factor authentication), and would love to see that in SQL Server, but this doesn’t eliminate the need for passwords. It just adds to them.

    The idea of password has a parallel in database development as well. One of the most basic things that we do as data professionals is fix problems on our systems. We do this in various ways, but I’d bet almost every organization has an individual that has made a change in a live, production database. Why? Because it’s easy and it needs to be done sometimes to fix code, data, or something else quickly. We know it’s not ideal, but it works.

    I try to talk about compliant Database DevOps, about having a process, the need for evaluating code and data changes, about limiting access to production, about ensuring every statement is tested elsewhere, about even masking/anonymizing/generating data in dev/test environments. Most of us know these are good ideas, and likely quite a few of us would like to adopt them. Why don’t we? Part of it is the ease with which we get things done. Another part is the success that we have with our current process.

    We fix things, we add indexes, we correct typos in code, we adjust our deployment to succeed, even though the scripts had problems. We roll forward constantly, coding by the seat of our pants, and for the most part our organizations continue to function well. Brent Ozar’s recent survey on production data in development shows that in some cases there isn’t a security risk, but quite a few times expediency and troubleshooting mean we work in production or copy data.

    I still think DevOps is the better way to move development forward. At Redgate, we have a suite of tools that help you smooth database development to reduce mistakes and problems. Not because you can’t be successful the way you are, but because you can go faster, make more experiments and changes, and deploy on demand rather than as a special event. We help you save time, which should translate into your highly paid staff spending time on creative new solutions, not fixing tedious problems. We even expect you’ll do things in production, which is why DLM Dashboard was built.

    We’re not the only vendor doing this. Plenty of others are trying to help you build a smoother database DevOps process, including Microsoft. Most expert software developers know that DevOps is a better way to build software that focuses and takes advantage of the creativity of your developers, while reducing the time spent on non-creative work. I, and many others, feel that the database needs to be a part of this to be as successful as we can be.

  • Republish: Technical Debt

    Still camping, so enjoy Technical Debt

  • Republish: Working with People

    In Custer this week, camping with the family, so you get Working with People.