Voice of the DBA

Tag: sql server

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

  • No Compelling Reason

    When I’m talking to people working with SQL Server, many of them are quite pleased with the platform. It solves their issues and problems. While they always wants changes and improvements, not to mention bug fixes, overall most people seem happy with their particular version. However, there’s no shortage of things that are slightly broken in SQL Server, and while I appreciate the Cumulative Updates every other month, I’d like to see even more work done fixing code.

    The development of SQL Server has accelerated in the last decade. After the five year span from SQL Server 2000 to 2005, we’ve seen new versions coming just over every 24 months, and I expect that to continue in the future. This rapid release cycle means that many of us end up supporting 3, 4, or more versions of the platform at any one time.

    We often install the latest version for new instances, often because that’s the only version we can buy at any time. However we don’t seem to upgrade older instances quickly. This week I’m wondering why.

    What are the reasons that prevent you from migrating those 2005/2008/2012 instances to 2014?

    Are there technical reasons you don’t upgrade? Is it cost-related? Or is there no compelling reason to adopt the newest features and enhancements to the platform? I suspect a combination of these reasons for many of you, though I also feel the platform is very mature, and has been for many versions. The applications I run, primarily SQLServerCentral, don’t really benefit from any of the features in later versions.

    Let us know this week, and I’m especially interested in knowing if there are technical reasons any of you can’t upgrade.

    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.

     

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