Voice of the DBA

Author: way0utwest

  • Relaxing on the Tab Management Terraces with #SQLPrompt

    I enjoy themes, and when I ran across the SQL Prompt Treasure Island, I had to take a few minutes and go through it. I’ve written about a few of the other items on the map:

    Tabs, Tabs, Tabs

    If you’re like me, you have a lot of tabs open in SSMS all the time. In fact, sometimes I think I have far too many open at one time. Likely that’s a sign of some distraction and too little focus, but it’s a habit that goes back through decades of SQL work for me.

    I used to love isql/w, as a very stable editor for my work. When Enterprise Manager came, I still often used isqlw. SSMS came along, I wasn’t thrilled at all, as it was a big, heavyweight tool. I’ve grown to like it and I feel comfortable, but I still have crashes at times.

    That’s where tab management comes in. SQL Prompt reopens my tabs, which I greatly appreciate, especially as I don’t always remember to save some random code I’m testing. Usually lots of development stuff is in a database, but having the tabs open automatically is a life saver.

    I don’t often use the Tab History item, but it is handy. I ought to use it more, because it is a good way to look back through work I’ve been doing and sometimes find a piece of code that I’m searching for.

    The coloring is great, especially as I work on a lot of different databases. Many times the color fades into the background, so it doesn’t necessarily help me with not working on the right instance/database, but when I wonder if I’m on a dev or test system, coloring is really helpful. Plus it looks great in demos and keeps the audience focused.

    SQL Prompt has lots of great features, many of which I’ve written about. After formatting and intellisense, this is the thing that I use most often.

    Give SQL Prompt a try. You’ll love the way it helps you write code.

  • Reading Through the Logs

    Have you ever tried to read a transaction log? I mean used a query against fn_dblog() to read data and try to reconstruct what happened with a transaction or a series of transactions? It’s a cumbersome process and takes a lot of knowledge, practice, and most importantly, patience. It’s not something I’d want to wish on anyone. There are a few products to help, but no one really does this that often, and it’s almost easier to just change some data by applying your own manual fixes.

    If you’re in the UK, you might have heard about the TSB bank meltdown. If you’re unlucky, you’ve been affected by the outage, which has been going on over a week as a system cutover failed. You can read some reporting about the plans, the rollout of some services, the initial problems , and the warning signs. If you go to the end of the third link, you’ll find this awesome tweet. Beans and bombs, he he.

    There are a lot of potential issues that we could discuss here. I’ve been a part of a failed rollout and I have sympathy for the IT staff dealing with this. The thing that I wonder about is the data. With the magnitude of customers (millions), the seemingly long list of places where things failed (notifications, scheduled payments, inquiries, etc.), and the rate at which people can bang on a system from their phones and various applications, how much data has been mangled and altered?

    I’d guess a lot, in which case, we aren’t just talking about updating rows on the basis of someone’s authority. Whoever is tracking through data needs to essentially read transaction logs, unwind the actions where data was converted incorrectly and then (potentially) subsequently changed. Then they need to work out the reversing entries. The database needs help from DBAs, developers, and probably financial staff to understand why things are in a state. Why are closed accounts are open, why payments are scheduled years in the future, where balances are, and more. With the possible cross contamination of data between accounts, this is an area where TSB needs to be thorough and careful.

    Data is important in today’s complex, interconnected world. There are certain areas where data problems are highly disruptive and can have lasting repercussions if mistakes are made by the data processors. The financial and medical areas certainly fit in these categories, and it’s sad that people are going to go through pain and problems that may affect them for years. Hopefully TSB will get things working soon and data issues corrected. If there’s one thing I learned from this is that for certain issues, I need to ensure I have my own paperwork to prove my side of the story.

    Steve Jones

    The Voice of the DBA Podcast

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

  • T-SQL Tuesday #102–Getting Started

    It’s time for another blog party, on the second Tuesday of the month. For this month’s T-SQL Tuesday, Riley Major has a couple of invites. One is on giving back, which is good, but doesn’t fit me. 

    The second option is to explain how and why we got started, so here goes.

    Giving Talks

    I started SQLServerCentral with Andy Warren, Brian Knight, and a few others. The site had unexpected success, and running this in addition to all of working full time jobs was tough. However, we built the site as a place where we could share knowledge and help others. In the first year, I’m not sure if I enjoyed writing articles or answering questions more, but both kept me busy.

    At some point, the Boulder SQL Server User Group invited me to give a talk. I’d been to the Denver group a few times, but hadn’t really thought about speaking. Bill Wunder was the person that convinced me to share some knowledge live and I went. I’m not sure I did a great job prepping and delivering information, but it must have been fine because I got invited back.

    At first I didn’t love the experience. It’s a lot of work and in this case a few people were critically listening to and questioning me on whatever topics I chose.

    A couple years later, we talked about doing a session at the PASS Summit. I hadn’t spoken there, but Brian convinced me we should do a debate on a topic and try out a new type of presentation. Looking back, this was really basic, but it was helpful and useful to do a few things.

    1. Have someone on stage with me to carry the load and divert some attention away from me.
    2. Pick a topic that I felt I knew something about
    3. Use the format of a debate, since we argued regularly, I knew we could pull this off.

    It went OK, though looking back, this was a rudimentary and unpolished session. Still, people seemed to enjoy it.

    Fast forward a few more years. Andy and I had been talking about SQL Saturday and kicked it off. At first I wasn’t sure this would work, and I missed SQL Saturday #1 in Orlando. However, with a few events in other locations, I decided to fly down for SQL Saturday #8.

    I can still remember sitting on an airplane, looking out the window as we descended to Orlando being amazed that I was traveling outside my local area to speak. I hadn’t delivered a talk at any conference at this point, so I was a little in awe of the experience.

    I had an afternoon talk, so I had the chance to watch others, but was a bit nervous. My room filled up, with all 20-30 seats taken and almost an equal number of people on the floor. Fortunately no fire marshal or administrative people were around to thin the crowd. The talk went well, and I felt confident walking away that I could share things.

    More importantly, I couldn’t answer every question, and had some “I don’t know”s or “I’ll check and get back to you” moments. In spite of those, I got great reviews and comments, so I continued on.

    From there, I submitted to more events, and different events over time. I’ve been accepted at most, rejected a few, and cancelled rarely. Life does get in the way, and I’ve learned to try and not over-extend myself. I’ve also learned I can say no. I do that more than I’d like, but I’m at peace with my decisions.

    I’ve even gotten over rejections. Plenty of large conferences have declined my submissions and even small ones do at times. SQL Saturday #735 – Finland just declined to choose me, and that’s fine. It’s their event, and they should pick the speakers they want, especially if they are local to the area.

    The one thing I’ll leave here is that I was terrified to present to groups in high school. I’d be nervous, avoid making eye contact, and try to say as little as I could. Over time I learned I needed to talk to other people in various jobs. Often 1 or 2, but sometimes a group of 5, 6, 10 or so. That’s really a presentation, albeit an off-the-cuff one. I learned that explaining a technique to another sysadmin isn’t far off from talking to an audience. It’s different, but not a lot.

    I still worry about new presentations, and I do try to practice them not only walking in circles around the office, but often with a smaller group. I would encourage you to try presenting, usually at work, because these are skills that are useful. If you’ve solved a problem, or fixed something, you can share. Give a 15 minute talk at your user group. You might not like it, and that’s fine.

    If you do, however, I’d love to see you start speaking at a SQL Saturday or other conference. I’m more than happy to give up a speaking opportunity if it gets more people to share their knowledge.

    Heck, I’ll even co-present with you if I’m at the event. Just ask and I’ll stand in front of an audience with you.

  • Pride in Azure SQL Database

    There’s a series on Azure SQL Database from Jovan Popovic on the SQL Server Database Engine Blog. Jovan has written posts on why database management is easier, the scalability of the platform, and a great one that claims the database engine can’t die. I don’t know that I quite believe that, especially as the guarentee is 99.99% availability. I’d expect 100% if you really think the engine can’t die on you. In any case, Jovan clearly has some pride in his work on Azure SQL Database.

    What I think is interesting in the post on the ever living engine is this sentence: “Azure automatically handles patching, backups, replication, failure detection, underlying potential hardware, software or network failures, deploying bug fixes, failovers, database upgrades and other maintenance tasks.” This notes that all of these operations are completed in less than 0.01% of the database life, hence the 99.99% guarentee. While that’s not 0, it’s close, and more importantly, this is something that to which DBAs ought to pay attention.

    These are often the tasks that many organizations will hire someone to complete. These tasks are becoming less of a time sink as organizations move to infrastructure as code or cloud computing, though they don’t disappear entirely. However, these tasks are mundane, tedious ones in many cases that should be solved once and then deployed easily to multiple instances.

    Azure SQL Database and SQL Server share the same code base. Most features get built and tested in Azure and then will get merged into a release for a CU or new version of SQL Server.  This means that as Microsoft learns how to better build these features, they will migrate them to our boxed SQL Server versions. With success stories in Azure and strong marketing, I’d bet that more and more management will be questioning whether they need more people, or even any people to handle these tasks in the latest versions of SQL Server.

    Don’t panic if you’re a DBA working on SQL Server 2008/RS, 2012, 2014 or other older versions. Those editions still require your time and things will change slowly for plenty of companies. They won’t want to upgrade too many instances at once, especially when there are potential vendor costs as well. You will have a job for some time, and I don’t think that lots of those older instances are disappearing anytime soon.

    That also shouldn’t mean that you rest on your existing skills and don’t learn anything new. You ought to be sure you are beginning to learn more about PowerShell, Azure, automatic indexing, and more. Improve your skills and potentially give you more career options. Even if you don’t change jobs, you’ll enjoy the learning.

    Steve Jones

    The Voice of the DBA Podcast

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