Voice of the DBA

Category: Editorial

  • Testing or Learning

    All of us get into challenging situations. This might be a coding problem that we struggle to solve. It might be an argument with a co-worker. It could be feedback from a customer on how we dealt with them or maybe just how our app works. Our responses to a challenge might determine how we view the situation, our future actions, or even just how we react to life in the next few hours.

    When someone struggles or feels as though they have failed in a situation, they tend to react in one of two ways. They can view the experience as though it were a test and they didn’t pass. This is quite common among many people, who might become sad, angry, or defensive. They might defend their approach or look for an excuse. They might seek to put the whole situation behind them and move on. This is a common reaction and one I’ve had often.

    Like many people, I want to do well, and when I don’t, it can feel as though I’ve failed or I am being attacked. Whether because of my words, actions, or code, I know I’ve often reacted in a way that I somewhat regret. I will try to solve the problem better, apologize, or find some way to rectify the situation, but it still feels like some sort of personal failure.

    The other way to view the situation is a learning opportunity. Things didn’t go well, but how can I improve things in the future. How can I improve myself, or what can I learn? Maybe, more importantly, this reaction often has the person looking for a similar challenge and the chance to do better the next time.

    How do you approach a challenge? Do you view most things as tests or learning opportunities? I tend to view many things as tests, but I am trying to change and learn how to view them as opportunities to learn. When I don’t or can’t solve a problem, I look to find out how I can improve my thinking and skills and at least solve that problem in the future.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Gathering Data Through Life

    Every once in a while, I find a list of places posted on the Internet with a “how many have you visited?” question attached. This might be US states, countries, cities, or even attractions. I love traveling with my wife and having new experiences, and as we’ve gotten older, we value the experiences more than any physical things. It’s something that I hope we’ve passed on to our children as well.

    My wife and I have been very blessed and have been able to travel a bit in life, though not as much as we would have liked with three children and a ranch of horses. We made it a goal about 6 years ago to try and visit a new country every year and experience life in another culture. The pandemic limited our travel for a few years, but we are starting to make plans to travel a bit more and gather some data for our minds.

    We don’t actually get data to store in a database, but rather experience life, see and hear things, taste new foods, and hear new languages. The database in our brain gets a few inserts, although I’m not sure of the long-term retention and accuracy of those memories. A few bits get stored in the form of pictures, and one of the reasons I do like social media is that I’ll get reminded of times gone past on a regular basis.

    Today, I’m wondering what data you might wish to gather through experiences? Is there something you have on a bucket list that you are hoping to experience in the next few years? This could be a place or an event. Perhaps there’s a concert or an experience. Skiing somewhere? Completing a class? Eating at an amazing restaurant? If you’re looking for inspiration, Brent Ozar has a list in his Epic Life Quest.

    I’ve included a list of places below from the list that inspired this piece, and I have a longer list of places on my blog, but let us know what dreams you have to experience something in life.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

    How many of these cities have you visited? (18 for me)

    • New York
    • Toronto
    • Tokyo
    • Bangkok
    • Melbourne
    • Mumbai
    • Hong Kong
    • Beirut
    • Cairo
    • Moscow
    • London
    • Munich
    • Rome
    • Copenhagen
    • Berlin
    • Milan
    • Kiev
    • Los Angeles
    • Sao Paolo
    • Istanbul
    • Montreal
    • Beijing
    • Singapore
    • Abu Dhabi
    • Casablanca
    • Dublin
    • Prague
    • Barcelona
    • Amsterdam
    • Budapest
    • Athens
    • Manila
    • Las Vegas
    • Vancouver
    • Jakarta
    • Shanghai
    • Cape Town
    • Stockholm
    • Paris
    • Vienna
    • Glasgow
    • Osaka
    • Taipei
    • Miami
    • Santiago
    • Seoul
    • Dubai
    • Lagos
    • Warsaw
    • Lisbon
    • Auckland
    • Hanoi
    • Honolulu
    • Perth
    • New Delhi
    • Rio de Janeiro
    • Chicago
    • Zagreb

  • Migrating a Large Database

    I have upgraded lots of SQL Servers from one version to the next, and for the most part, the process has been smooth. That’s not always the case, and there have been some long nights where the Operations staff had to scramble to fix things, script out old logins, call Microsoft support, and perform various data exports and imports to get a new instance running. I’ve been a part of quite a few of those teams.

    Most of my upgrades were with relatively small databases, at least small for that time period. However, I have upgraded a few “large” databases in the past. We had a 400GB database on SQL Server 6.5 in 1999 that was a challenge to move to SQL Server 7. I also upgraded an 800GB database in 2001 from 6.5 to 2000 for our Financial team, which involved a lot of stress.

    I haven’t upgraded a 1TB database, much less a 4TB one, but I know this can be very time-consuming to move all that data. Even with much faster hardware and networks these days, working with that much data can require a decent amount of downtime. That’s not very acceptable these days, especially for applications that are used by customers all around the world and all around the clock.

    I found an interesting upgrade story from a SaaS provider that runs PostgreSQL. I don’t use that platform, but I found the write-up of their process to be aligned with some of my experiences with SQL Server. They delayed upgrading an old version of PostgreSQL and then had the desire to move to as current a version as possible and delay future upgrades (again). I’ve certainly experienced that. Their goal was also to minimize downtime, as their customers are constantly connecting.

    The plan for the upgrade made sense to me. Use replication to move most data and then minimize downtime. That’s a technique that can work in SQL Server, though we’d be more likely to use log shipping to simulate this. They also trimmed and cleaned some data, removing the need to upgrade some of the tables. That’s something many of us might be able to do every year in some databases, especially for large logging tables where older data might rarely be read. I’d even think about moving that data to another database and using a synonym to access it if it were needed. That’s just a good idea for general DR planning.

    I also appreciated them creating a runbook and testing the process multiple times in staging. Their big takeaway here: practice over and over with a realistic workload. They created some problems for themselves by not using a real enough workload. That ought to be something your organization does on a regular basis to test your software and ensure new code performs well. Using the same process for upgrades is a bonus.

    Large upgrades are stressful and often they are “big bang” deployments where you can’t go back to the old system. Practice as much as you can, make sure you have backups, and then be ready to adapt to whatever challenges come up. Plan ahead, and be prepared for a long night. If you do, you’ll likely have success. If you don’t, I am fairly sure something will go wrong and you’ll regret not thinking ahead.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • The Craziness of Code

    Every once in a while I find a fun post that makes fun of programming. I think because the author is struggling with some piece of code, they write about the craziness of software development, often with an analogy that compares building something in the real world to how software programs get written. Here’s one, with a bridge construction analogy, that degenerates into a rant on the disparate ways in which different programmers work together and how the entire world of the Internet is held together in a constant patch-fix loop.

    I do think that most large software applications have a decent amount of inconsistency. I’d suspect most large databases (in terms of object count), also have a variety of techniques, tools, and standards in use. That’s because the tooling that we use to build things change. We don’t have the constraints of the real world, which is why we could have a stored procedure using a subquery to calculate a running total and another one that uses the OVER() clause.

    We can be more consistent in SQL because the language doesn’t change as quickly, but in application code, frameworks, techniques, and even libraries come and go constantly. Different developers have favorites, and without strong controls that limit the experimentation of your staff, likely your code base has a variety of styles and algorithms that do the same thing. Static code analysis, linters, and unit tests can help ensure your code runs effectively, but it still likely has sections that no one wants to touch.

    This flexibility can be maddening to developers, especially when they start a new position. At the same time, each of them probably thinks there are a few places where they think they can write the code better, and they will attempt to do so, even if they are creating more inconsistency in the project. Multiply this by the 40% of programmers that are willing to make changes without trying to mimic how others write code and pretty soon the architect (if you have one) has no idea how anything works.

    In the real world, we can’t easily get things to work together if they are disparate. We don’t suddenly change from framing one wall with a 2×4 to another with a 2×6. We might use different size nails or thinner brake pads or any of a number of other changes from one place to another, but often those differences don’t matter. At least not enough that we find houses and bridges constantly falling down. Of course, the workers building those structures follow a set of plans and standards, using similar tools and techniques.

    That doesn’t happen in software, where you are often not limited by external constraints, but often your imagination. We can construct things in software that no one ever thought of before, we can grab materials, i.e. code from Stack Overflow, and use them in our system. Often builders don’t get to source materials from wherever they want, which inherently limits the variation between parts of the structure. That being said, lots of little mistakes get hidden in construction projects, just like they do in code.

    I don’t think programming sucks. It’s always an interesting challenge, and I do think that when you have a group of developers that care about their craft and are trying to work together to solve a problem, we get some amazing software built and deployed. It might not be consistent or pretty, but often it works very well. If it takes regular maintenance, that’s fine. It’s an ongoing challenge that keeps us employed.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.