Voice of the DBA

Author: way0utwest

  • Deploy the Database First

    One of the patterns I’ve seen in some environments is people are trying to deploy changes rapidly to their database backed applications. That’s not news, but what is interesting is some of them are staging the deployment of the database changes first. Not as in I deploy database changes at 8:00pm and then application changes at 8:30pm. These people try to deploy the database changes on Monday, and their application changes will follow on Tuesday, Wednesday, or even a month later.

    It’s an interesting concept, though I think it requires a lot of forethought in your designs, as well as very tight coding from your front ends that won’t be disturbed by extra columns in a result set.  That’s not easy to do, but it’s certainly possible, and it can even be useful if you deploy feature flags extensively in your application.

    As we become more dependent on databases for our applications, and our customers expect systems to be running constantly, I think it behooves us to find ways to make alter and enhance our applications without downtime. While there are patterns to keep applications running when the database goes down, I expect that the reality is that we need to find ways keep the database up as we alter it, which for me means making non-breaking changes.

    I think it’s possible in many cases to upgrade a database over time by carefully planning your schema changes and accounting for those changes in your front end architecture. However it’s not easy, as I mentioned, and you do need to commit to very stable and careful programming practices for your developers.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Which Problem Are You Solving?

    One of the problems I’ve seen for years in computing is people seeing the forest or the trees. Not that either is good or bad, but far too often I’ve run across people that only see one of these, meaning they examine problems from a high level perspective, or a very low level perspective. While either of those can help you solve your issues, there will be a problem or a time when you need to examine the situation from another perspective. Knowing when to look at a higher or lower level can be invaluable in troubleshooting.

    This past week I ran across a great post from Grant Fritchey called Understand the True Source of Problems. In this post, Grant talks about some strange DBA “best practices” that were implemented to solve problems, but aren’t necessarily the best of anything. It’s an interesting list, and you might read it for entertainment, though I hope none of you are following these ideals at your place of employment.

    However the thing I liked about this post is that in the beginning Grant begins with an old doctor joke, which is still funny to me, but it often is the approache taken by people trying to solve problems. They just avoid the issue, and never solve it. That can work in the short term, but I’ve seen this build up over time to the point where people are afraid to make any changes to a system or code because of the fear of causing some unknown issue.

    I don’t think that every issue needs to be solve to the root cause. There are plenty of times something goes sideways on one of my computers and a reboot fixes the issue. I’m fine with that, but if it occurs more than two or three times, I do need to solve the problem. I need to be able to dig deeper to diagnose what resources are failing, what performance issue exists, or maybe what line of code is broken. Perhaps I need to step back and examine if some other part of my system, like the disk or network, is causing an issue that appears to be isolated to code. In other words, I need to be able to look at the wider environment (the forest) or dive into the particulars of a process (the trees).

    Knowing how to strike this balance is a bit of an art, and it’s what really makes the best problem solvers experts. I can’t teach you that part of computing, but I can teach you this. When you don’t think you’ve completely solved the issue, stop for a minute and take a wider or narrower view. Or maybe both. Look for what you might not have thought of. If you’re like me, there are probably plenty of possibilities that come to mind when you stop and re-examine the issue. Then work your way through those items, discarding the ones that aren’t relevant. Sometimes opening your mind a bit is the best way to find the exact cause of an issue.

    Steve Jones

  • Saying No – Feb 28 and Mar 28

    I hate skipping events. If I could, I’d go to all SQL Saturdays each year, but I can’t make them all, and I can’t travel every weekend. I can’t really travel two weeks in a row as it puts stress on my and my family, and with our busy lives, it takes me away from the precious little time I have with them.

    This year I’ve already missed the annual trip to Albuquerque. It comes up on Feb 7, but I’ll be flying back from the UK that day, so I can’t make it. I’m disappointed as the drive down, a day of skiing at Taos, and seeing the wonderful hosts in New Mexico is something I look forward to. Hopefully I’ll go back in 2015.

    I’ve also got two other dates that are out. My apologies as I’ve told a few people I’d try to make their events, but I can’t travel on Feb 28 or Mar 28. That means I’m not going to make:

    I’d say I’m missing Vienna as well, and if I could, I’d go there and ski, but I was tempted by Pordeone and a weekend with my wife in Italy. However I have a few kid events, and my trip to SQL Bits involves a stay into the following week, so adding 3-4 more days isn’t something I can (or want to) do.

    In March, my kids are on vacation and with some family coming into town, I can’t travel then, either.

    This year seems to have a strange schedule to it. Not many events spread out, with most of them being bunched up into a few dates this spring. That limits my flexibility, but that’s a me problem, not anyone else’s issue. However it does mean that I don’t get to see as much of the amazing SQL Server community this spring. As of now, I don’t have any SQL Saturdays in the first quarter.

    I’m still planning April and May, and I’m hoping to get to a few other events. I’m also hoping we’ll see a few more SQL Saturdays pop up and I’ll still get to 10 this year.

  • Custom SSMS

    In my career, I’ve gotten used to working with SSMS on a variety of machines. It seems that as I toiled in various environments, I’d often connect to different SQL Server hosts, or use various consoles that only had the stock Enterprise Manager/SSMS environments installed. I do like larger fonts and a few other settings, so I learned how to quickly change those items, but otherwise I often have just learned to work with the default SSMS.

    However that’s not a very efficient way to work. SSMS, and the Visual Studio shell on which it’s based, have a number of ways to customize and modify the application to suit the way you work. You can also even export and import settings to transfer them across machines.

    Most software has a variety of settings, though I still don’t change many of them. As I’ve matured in my career, I do look to customize my environments to suit me, but somewhat lightly. There aren’t a lot of changes that I make, but I suspect that’s because of the nature of my work. I tend to do what works, and I don’t often explore other settings. This week I’m wondering if you have tips and tricks.

    What customizations or add-ins do you use to customize SSMS (or other development software)?

    I’m curious what many of you do and how you do it. I don’t often explore the possibilities as I’m usually concerned with just getting work done. However I’m sure that I’m missing opportunities to work smarter. I’ve never been a big fan of the function keys, though I know some people love them. I’ve tended to rely on templates (and snippets in SQL Prompt) to work faster.

    If you’ve got idea, tweaks, or software, let us know. I’m sure that many of us would appreciate suggestions that might help ease our jobs.

    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.