Voice of the DBA

Author: way0utwest

SQL in the City Sydney in Two Weeks

It’s two weeks to our next SQL in the City Summit, this time in Sydney. I’m excited to be going back, though it’s a quick trip for me. Likely I’ll be fueled on lots of coffee for the two days I’m in Australia, so if I’m speaking a bit fast, remind me that the rest of you aren’t on a whirlwind, halfway around the world trip.

We had great reviews on our previous tour, and I was sad to miss Sydney, but we’re coming back on Sept 27. The schedule is slightly different, but we’re thrilled to have Damian Brady from Microsoft talking about their DevOps transformation.

Anderson and myself will represent Redgate and deliver a few session on our tools, and we’ll have the amazing Hybrid DBA, Hamish Watson coming as well.

Register today and come learn more about Compliant Database DevOps and Redgate solutions to help you write database code more efficiently.

September 12, 2019
The State of DevOps Report for 2019

It seems like just a few weeks ago that I went over the 2018 results with Gene Kim. That was an exciting few weeks for me, running over the report in prep and then having the opportunity to host a webinar with Gene Kim. Exciting times, but it’s been almost a year and the 2019 report is out. You can download the 2019 Accelerate: State of DevOps Report from the DORA site and read it yourself, but I found a couple interesting things in the report.

As expected, companies adopting DevOps are outperforming those that don’t, at least in the metrics measured. In fact, it appears that the high performers continue to outperform low performers in two major ways: speed and stability. What’s interesting, and as was pointed out by Kendra, is that these aren’t on the same scale, meaning there isn’t a trade-off between the two metrics.

You can move fast and achieve higher stability. In fact, moving fast can lead to higher stability if you are learning and growing from your efforts to build and deploy software. This includes the database, though that’s not called out in this year’s report. Instead, the report talks about ways to achieve speed and stability.

One of those is tools, and more importantly, easy to use tools. Staff will turnover or change positions. Knowledge can be hard to share in busy environments, so tooling is important. Bespoke, bought, homegrown, open-source, it’s important that the tooling is easy to understand and that it performs at some job in an efficient manner.

There are other items in the report, but one thing I think we often ignore is that sticking with your old process and people doesn’t mean you’ll fail. You clearly have some people and process in place that works, as you’re in business now.

However.

Both speed and stability help you work more efficiently. They help you compete better against others, and should ensure you reach your goals sooner. Speed increases value for customers, which in turn should help you improve how your organization functions. Stability makes both customers and staff happy. One thing the report points out: productivity has a positive impact on workers. They deal with stress better and burnout less.

Happier employees are hopefully helping your organization with more creativity in solving problems, more engagement with customers’ success, and less turnover. DevOps is better for your software, and your staff.

If you want to learn more, I’m hosting a webinar next week with Jez Humble to go over the report.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

September 12, 2019
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.

September 11, 2019
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.

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

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.

September 11, 2019