Voice of the DBA

Author: way0utwest

  • DeveloperBall

    I’ve been fascinated by Moneyball and the efforts made in sports to assemble good teams using data more than opinions. I used to think about baseball more, but lately I’ve been intrigued by American football. There are challenges in assembling a team, with the constraints of a limited budget, existing contracts that cannot be changed, and the fact that one player isn’t a replacement for another, even when they have similar skill sets.

    That got me thinking that we could do this with our development teams. Certainly the skills that each of posses might be closer to one another than athletes, but that doesn’t change the need to have a variety of skills on a project. We need someone that writes great T-SQL, someone that can manage front end code, someone that can build and provision environments, someone to help test.

    I know that many of you can do all these things, but do you want to? Maybe more important, is it a good use of your skills as a developer to manage restores or schedule index maintenance? Those are tasks that might provide a welcome break, but they aren’t necessarily the tasks that I want you to be responsible for or even spend time performing.

    There is also the very, very high likelihood that the people hired in your environment have different levels of skills. In a group of T-SQL developers, or SSIS package builders, or any other group that each of you can learn from the others. And you should learn from others, since it’s entirely likely that some of you will leave, and others will need to handle the load left behind. After all, the next person hired is as likely to be the weakest team member as the strongest.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Creating a Database Snapshot

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    I’ve rarely dealt with database snapshots, outside of lab experimentation. They didn’t exist when I did most of my DBA work, and since then we haven’t seen the need for them at SQLServerCentral, though, I may suggest we add them to our deployment process since we can quickly roll back if something breaks.

    However, I created one recently for a test and realized that I’d forgotten the syntax. Unlike the quick "create database xx" syntax I often use, with a snapshot I need to be more specific.

    The big item that I must specify is the location of the snapshot file. This is the file that gets written to with the copy-on-write process that ensures the original state of the pages when the snapshot is created are still available.

    You do need to give the database a logical name as well, which can be anything, but the reference below has suggestions. I’d say that this is bad:

    CREATE DATABASE sandbox_snapshot
    ON (NAME = MySnap
    , FILENAME = ‘h:\SQL Server\MySnap.ss’
    )
    AS SNAPSHOT OF Sandbox

    But this is better

    CREATE DATABASE sandbox_snapshot_20150122_1345
    ON (NAME = SandBox_Snap_20150122
    , FILENAME = ‘h:\SQL Server\MySnap.ss’
    )
    AS SNAPSHOT OF Sandbox

    Because the snapshot is based on an existing database, at a particular point in time, it’s useful to specify the time when the snapshot was created, if possible. While you can get this from metadata, if you have people that look to multiple snapshots for information, it can be handy to know when each is from.

    However if you are providing this on a schedule, like daily, for people to report from, you might need to have the same name every day. Think about this, as you cannot rename a snapshot once it’s created.

    SQLNewBlogger

    When I realized I had to lookup the syntax, I took a few notes and captured code, which meant I combined this writing (< 10 minutes) with other work I was doing.

    You should do the same. When you tackle something new, take screenshots, save code, and drop it in a OneNote/EverNote/etc notebook for your weekly blog writing.

    Reference

    The references I used:

  • Crafting Your Resume

    Your resume of CV is often the first glance that a hiring manager gets about your career. Even if you’ve been recommended by a friend or current employee, often a manager requires some summary of who you as a few paragraphs on a screen that they can study.

    I have my own advice, but this post from a manager at StackOverflow covers quite a few of the same things I recommend. I certainly agree with the first section, writing for humans. Over and over again I hear from people that make hiring decisions that they spend 30-60 seconds on a resume to get an impression.

    One minute. You should set a timer for one minute and let someone read your resume. Then take it away and ask the person for their impressions of what you know. In fact, maybe that’s a great icebreaker at a user group meeting or SQL Saturday. Find someone that hires others, or is an experienced person in your industry, and ask them to do just that.

    We learn a lot from experimenting and seeing what works well and what doesn’t. Many of us solve problems in code and realize later that we could rewrite things more efficiently. Why not do that with our resumes? We certainly can control how we present ourselves, be interesting, and more importantly, don’t waste the reader’s time.

    You get one minute, or less, to make a good impression, so spend some time crafting your resume. Control your brand and ensure that you let people know who you are. Do your best to communicate the skills you have, the things you do well, and the ways in which you are a good employee. Most of us will change jobs at some point, so why not be prepared to present yourself in the best possible way you can by working on your resume now.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Push Button Deployments

    I worked in an Agile team in 2000 and we deployed changes to our web platform every Wednesday for over 18 months. That was about the length of time I was involved before the small startup failed, but not for lack of technology. In fact, I managed a few weeks extra pay by helping sell and deploy our IP to another company.

    Deploying regularly and often, to meet business needs and get features into the hands of customers is important. For most businesses, this is something the CTO and CEO want. It can work, and there’s a case study with Nmbrs, a Redgate customer, that has used DLM with this quote:

    “The productivity of the team has improved dramatically. We were doing one database update a week, which took almost a full day. Now it takes ten minutes. We can spend the extra time we’ve gained developing new features.”

    That’s been my experience with tooling and automation. If you get things setup, as I did with my startup, then you gain confidence in deployments, are willing to make them more often, and get these small chunks of software to customers on a regular basis. It’s not just customers, as we found we could make some fundamental changes in databases and applications that helped smooth development later without affecting customers.

    I know I’m paid by Redgate to talk about DLM, but the concept, the idea, the processes really do work well. They’ll help you get features to customers quicker (and feedback to developers faster) as well as give you confidence that you can release, if you find an issue with your application.