Voice of the DBA

Author: way0utwest

  • MTTD

    There are a lot of Mean-Time-To-xxxx acronyms. Many of us have heard of the mean time between failures (MTBF) for disk drives. Some of us use that information when considering which model to buy. In the DevOps world, there are also the mean time to failure (MTTF) and mean time to resolve/repair (MTTR). There is one more that I think is very interesting, and that is the MTTD: the mean time to detect an issue. This is the average amount of time it takes you to detect there is a problem after the problem occurs.

    There was an outage at Monzo recently due to a database upgrade, which was recounted on their blog. In this case, their MTTD, or rather actual time to detect, was a minute. I think that is amazing. In fact, I’m somewhat skeptical that an alert is raised, someone looks at it, the customer service desk calls the Ops team (who were upgrading servers), and the Ops person realizes in the space of a minute or two that there is an issue. It’s possible, but I have found that help desk personnel that discover something can take a few minutes to verify the issue and then scramble to find the on-call phone number. Relaying information can take a minute or two, so if this is accurate, huge props to the IT staff at Monzo.

    Many of us strive to high a high availability number for our systems, especially databases. This is one of the drivers for the growing use of availability groups in SQL Server systems: to ensure the database is highly available to clients. In determining availability, we often speak of the percentage of time that a system is available. The holy grail is five 9s, or an uptime of 99.999% of the year. This gives you just over 5 minutes of downtime a year.

    In the case of the Monzo outage, which took place in July 2019, the alert is reported at 13:14 and the incident was declared at 13:15pm, one minute later. The time to diagnose the issue (maybe another MTTxx item) was 63 minutes, just over an hour. At this point, availability is arguably down to 99.988%. The actual fix was completed at 113 minutes, or 99.978%. That’s the number if nothing else happens this year.

    If you’re attempting to get to 5 9s of reliability, you get less than 6 minutes of downtime a year. Can you figure out what’s wrong in 6 minutes? Much less fix it? That’s a difficult task. I think 4 9s, giving you 52-ish minutes of downtime, is realistic, but very hard. Most of us can likely handle 3 9s, which allows for 8:30:00 of downtime a year. While I’ve exceeded that before, it’s been rare.

    We have a lot of HA (high availability) options in SQL Server, and there are many successful implementations that achieve high levels of availability for the database. The network and the application are another story, but I think the quality of those areas has increased over the years as well. Doing HA well is hard, and if you aren’t 100% sure of what you’re doing, or your system is very valuable, you might engage a consultant, like Allan Hirt, to ensure that you’ve configured things well. SQL Server runs well in HA configurations, but getting it set up can be more difficult than you expect.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Changing the SQL Data Masker Connection Target

    This post will explain how to change the connection in your masking set when using SQL Data Masker from Redgate.

    I’m writing this more for myself than anyone else. I find myself using Data Masker for different databases at times, and I keep forgetting this. I just spent more than the 2 minutes I’d expect on Google searching, so I’m adding a post in hopes that I’ll remember this.

    When you start creating a masking set, you’ll connect to a SQL Server and choose a database. Later, you might want to change this, or test the masking set elsewhere. Where is the connection string? I had thought it would be in the settings somewhere, but it’s not.

    It’s in the controller.

    The controller is usually at the top of the list, but there could be other ones. However, they are the most left displayed items.

    2019-09-02 14_28_27-SimpleTalk_Prod_Mask_ Data Masker for SQL Server

    Double click the controller, and you’ll see something like this.

    2019-09-02 14_29_14-Edit Rule Controller

    Here you can change the instance and database needed. To save the changes for your session ,click the “Update Rule Controller” on the right. To save the changes in the set, save the entire set.

    Hope this helps you, and hope it helps me remember how to do this.

  • Republish: Business Pressures

    Flying back to the US, so think about Business Pressures

  • Finding the Visual Designer in Azure DevOps Builds

    This post is really a reminder to me, since I don’t create pipelines all that often, and I’ve forgotten a few times how to do this.

    Plus, while YAML is nice when you want to scale things, it absolutely sucks for getting started. It’s a horrible default and, IMHO, is the worst decision of the Azure DevOps team since the VS 2010 Release Management days.

    When you create a new project, and then select Builds in Azure DevOps, you’ll see something like this. It might be slightly different as the product continues to evolve every few months.

    2019-08-26 21_00_07-Builds - Pipelines

    This looks inviting, a pipeline should be easy. When you click New Pipeline, you’ll get a choice. The intention here is that Azure DevOps wants to help you get started.

    2019-08-26 21_00_40-New pipeline - Pipelines

    Don’t be fooled. If you say your code is in GitHub, you’ll get a YAML pipeline and you can’t convert back? Why? Apparently the developers at Azure DevOps don’t want to write GUI interfaces that render YAML code.

    Instead, at the bottom of this section, there’s a “use the classic editor” link. Click that.

    2019-08-26 21_03_29-Zoomit Zoom Window

    Once you do that, you still have all the choices for code repos, and it’s easier to get your build started.

    2019-08-26 21_04_18-Select a build pipeline template - Azure DevOps Services

    Hopefully I’ll remember that next time instead of fumbling around.