Voice of the DBA

Category: Editorial

  • Project Zero for Better Security

    Google started Project Zero to study zero-day vulnerabilities in systems. They want to improve security and safety, at least from a software and hardware standpoint. Its mission is to make it more difficult to find and exploit issues in software. They published an update recently that showed vendors patching their software quicker, at least according to data from the last few years.

    The metrics show a change in patching from an average of 80 days a few years ago to 52 days in 2021. There were also patches that missed the 90-day deadline, though only one missed the 90-day time and also a 14-day grace period. They are also trying to help with the understanding of how well vendors are adapting to new challenges. I hope this pressures and inspires smaller vendors and even individual organizations to take security more seriously.

    I think that security is becoming *slightly* more important to vendors, especially as competition grows in any particular space. Vendors aren’t necessarily looking to spend time and energy where they don’t see a problem impacting revenue, but they do worry about customers abandoning their software, and a security issue is one reason for customers to look elsewhere. In the 2020s, there are plenty of customers that would consider changing software over security issues that don’t get fixed.

    I saw another note that showed more and more hackers are exploiting zero-day vulnerabilities. Even if you think you have strong security, who knows when someone will misconfigure a firewall and expose your system. It’s worth staying up to date, at least within the last patch for your critical systems. I certainly consider a database a critical system, and I’d include helper databases like Redis and Elasticsearch as critical systems.

    It’s easy to delay patching when nothing seems to be broken. However, patches are like oil changes. When the system lets you know that maintenance is overdue, it’s usually a catastrophic event.

    I like the disclosure and openness of groups like Project Zero and hope they start to pressure more software developers (and project managers) to promote secure coding along with quick patches for vulnerabilities.

    Steve Jones

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

  • 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.