Voice of the DBA

Tag: T-SQL Tuesday

  • Automate Migrations–T-SQL Tuesday #94

    tsqltuesdayIt’s T-SQL Tuesday time again, and I’m slightly pressed for time, which is sad. This is a great topic.

    Rob Sewell hosts this month with his question about what we are going to automate? He’s a PowerShell advocate, so I’m not surprised here. As much as I enjoy working in various languages, PoSh becomes more and more handy to me when I need to work outside of the SQL Server platform. I’ve been trying to play with it, and I enjoy it more and more.

    If you want to participate, check out the rules:

    1. Write a post on the topic below
    2. Schedule the post to go live on Tuesday, September 12th (between zero am and midnight, UTC)
    3. Include the TSQL Tuesday logo in the top of your post
    4. Link the post back to this one (it’s easier if you comment on this post and link it)
    5. Optional: Tweet a link to your post using the #tsql2sday hash tag on Twitter

    Automate Things Between Instances

    The first time I saw the dbatools project in action was at SQL Saturday Cambridge, where Chrissy Lemaire gave a session with Rob. I was surprised at the power and ease of the project. I was impressed, and decided to help learn more as well as promote the project. I’ve tried to blog regularly about their cmdlets as I get a chance to play with them and I’m pretty much always impressed.

    The next time you need to move some object, setting, job, etc. from one instance to another, you should try this:

    1. install the dbatools module
    2. look through the command index
    3. try migrating your object(s) with PoSh.

    That’s it.

    Maybe you need to copy a database or login. Maybe you want to copy jobs to a new server. The dbatools module makes all of these things easy.

    So give it a try. There are some great tools for migrations as well as wonderful items for common DBA tasks.

  • T-SQL Tuesday #93–Interviewing Patterns

    tsqltuesdayIt’s time for T-SQL Tuesday, and this is a good topic. Not too close to T-SQL, but certainly something many people are interested in.

    Kendra Little hosts this month, and her topic is interviewing patterns and anti-patterns. Things that are good, or things that might appear good, but are bad. Be a candidate or an interviewer.

    You can read more about T-SQL Tuesday at tsqltuesday.com.

    Pattern: Groups

    One of the things that I think makes a good pattern for interviews is a group. It’s rare that any of us actually works alone or with just one person. Even if our group is 1 or 2 people, we often interact with others in different ways.

    Those other people depend on our knowledge and skill. Why not use them in an interview.

    I’ve had quite a few interviews like this, but they all are similar. Get the candidate in a conference room and bring in multiple people to ask questions. Usually it’s a round robin with everyone taking turns asking questions. Ideally, the same questions to all candidates from the same people. The discussions can veer into slightly different directions, but ideally in similar veins for everyone being considered.

    I’ve been in the candidate seat with as few as two (one isn’t a group) and as many as 12 or 13 others. This can be stressful, but if everyone is probing, then the candidate needs to interact and communicate with those that they’ll actually work with. In my mind, a good test.

    Anti-pattern: Confrontation

    I love the old Monty Python Silly Interview skit. I’ve been tempted to do something like this, but never have. It’s not fair to the candidate, and I’m not sure it tests anything well.

    I had a couple rough interviews in the past. One was where a VP of a small company was excited and interested after having talked with me over the phone and then in his office for 30-45 minutes. He then brought me to his consulting sysadmin/programmer, who peppered me with scenarios and questions. However, this gentlemen argued about every answer, and implied that I was answering incorrectly. In many cases I knew I wasn’t and said so, however the confrontation continued. In some cases, I just admitted I wasn’t sure.

    Later, I came to be friends with the guy, but never too close. He tended to rub me wrong most of the time because he was closed, cold, and argumentative. It was a good job, and we got along, but if he had been my boss (I was interviewing to be his), I wouldn’t have accepted.

    The other one was similar. I had a good phone interview with a technical person and then went in to meet the manager. He was brusk and short with me, constantly letting me know he was in charge, he didn’t think much of my credentials, and I should be expecting to work hard. With that offer was a pay cut I couldn’t accept, but not sure I would have in any case. His manner made me think that every day would have include some sort of insult, browbeating, or other unnecessary action.

    I think we can make an attempt to evaluate candidates without being jerks.

    Pattern: Flexibility

    The last pattern I like is the idea of quizzing people in a flexible manner. I’ve never liked schoolteachers or managers implying that most of our work is extremely set and susceptible to deadlines without flexibility. Or that we work a certain way. The real world isn’t like that.

    BTW, if you have hard deadlines, like shows or events, your stuff better be done well in advance, not hours before.

    When I’ve had good interviews, or gotten a good handle on a candidate’s skills, it’s from adapting to them. Some people like to show something on a computer. Some will whiteboard, some like to discuss the question in detail and ask their own questions. I’m OK in all those cases. When I work with the person, I get a better feel for how they think, how they solve problems, and what catches their eye.

    I can also evaluate their strengths and weaknesses, and decide where they might fit in our team.

    Evaluating someone is hard enough without being rigid about what we do. Expecting everyone to take a test well, or be able to answer any question orally, or any other specific way of interaction is asking to miss out on some potential good candidates, as well as potentially hiring someone that is good at interviewing, but not working.

  • T-SQL Tuesday #92–Hard Lessons

    A quick post, written last week as I’m relaxing in the mountains.

    This month the topic is lessons learned the hard way, from Raul Gonzalez. It’s interesting, and certainly one where I have experience. I make mistakes regularly, though I tend to fix them.

    You can read more about T-SQL Tuesday and learn how to participate, or even respond to old prompts at tsqltuesday.com.

    A Hard Lesson in Preparation

    I worked for a financial services company at one point, managing the live systems as well as performing database development. I had a few people working for me, some in each area, and we had contracts with a number of clients. Quite a few of these contracts specified a yearly DR test at a remote facility.

    The first year I was there, we packed up tapes and documentation, carpooled for 4 or 5 of us as if this were a disaster, and started rebuilding systems. Our contractor supplied xx servers as per our contract, and we had to start from scratch.

    We didn’t do well, and couldn’t get our web app or client server apps running completely. The db restored, but the system and docs were out of date. I knew this, and we updated some things, but we didn’t take the process seriously.

    A few months later our largest client was unhappy. Since we couldn’t get the website running, they wanted another test. At their site.

    Myself and another were chosen to fly to their site, shipping out spare servers and software. We had to wipe the drives and rebuild the system from scratch. Since the two of us had been at the DR test, we assumed we’d learned enough to do this in two days, sure we could rectify all the mistakes from the test team.

    We couldn’t. After two days, we didn’t have everything running, with too many dependencies and issues from various web components. Our developers had been running wild, with admin access to the webserver and database server, resulting in wonderful unique, snowflake servers that were hard to reproduce.

    Inadequate preparation, as well as poor security for years, contributed to the failure. I did get the database working, but that didn’t matter since this client used web access only. I had to take a large portion of the blame since I managed systems, and our company paid a penalty.

    It was embarrassing for me, personally and professionally. I hadn’t done a good enough job being ready for a disaster. This did server to motivate me to start cleaning up the systems and ensuring we could rebuild a new web server if needed, but it was a hard, and expensive lesson, to learn.

  • T-SQL Tuesday #91–Early DevOps

    tsqltuesdayThis month the T-SQL Tuesday invitation is from Grant Fritchey, my colleague at Redgate Software. Surprise, surprise, the topic is DevOps.

    I write and talk about this a lot, but for this month I’ll look back at DevOps for me in 2001.

    If you want to participate in the blog party, you need to publish on the second Tuesday of the month, GMT time. You can see the invitations at tsqltuesday.com.

    2001, A DBA’s Journey

    I started working for a small startup in 2001. I was the DBA (dev and production) with 4-5 developers. Eventually we grew to 10 developers, a couple QA people, and a UX person. Our goal was to release code every Wednesday night, and developers would work from Tues-Mon am on that week’s changes.

    The initial plan when I started was to get together with the lead dev and produce the scripts to upgrade our web application as well as the database. Early on we had a small system, so it was a few hours on Monday afternoon putting together a script for the QA server. Inevitably we’d make changes if QA found issues, and then Wednesday night we’d go into the office and usually spend a few hours deploying and fixing things. Often we had another developer or two with us to ensure that we could get the changes out.

    Over a few months we started to try and smooth our process. We talked about the issues, and started small. First with version control, Visual SourceSafe at that time. We’d get everyone to check in changes, which let us more easily determine what had changed that week.

    We also talked about what made life easier for the lead dev and me. How could we package code to easily ensure it gets deployed. For the database, this meant ensuring all files were named easily and branched to a folder.

    Ultimately, the technical challenges were few. A few scripts that automatically packaged changes for us and deployed them. However, the biggest challenge was cultural. Getting all the developers to think forward about what was needed to get code to production and slightly alter their behavior. We also had to break habits of “fixing” code in QA. We had to learn to reset QA, change our scripts in version control, and then redeploy.

    Sharing information, communicating, and adhering to a consistent process for deployments, ensuring that we practiced our production deployment on QA, helped us move to a release process that consisted of a phone call and a few minutes instead of a late night at the office.

    DevOps works, but you have to work at building a process for your environment.