I’ve been traveling a bit lately, but this week is a little crazy, two trips to two places, and so I’m more out of touch. You get a re-run of Evergreen SQL Server, which is a fun one to re-read. The idea of upgraded database software is something that is more common these days than in 2019.
Category: Editorial
-
Deleting a Database
Who among us has deleted a production database?
I’d hope it’s very few of you that have done this in your career. I’m sure a few of you have deleted (or truncated or updated all rows for) a table in production. I’ve done that a few times, but fortunately, I’ve been able to recover the data quickly. I had this happen in SQL 6.5 and was grateful I could start a single-table restore before my phone rang.
Here’s another question: which of you has had a storage admin delete or remove some remote storage and cause you database problems? Has anyone had that happen in their environment? I haven’t had this in production, but I have had this happen to test systems, and I was very irate with the storage people when it did. After that, I’m sure they were very cautious about changing any configuration for database servers. I’m also sure that also contributed to my struggles in getting more space promptly as well, so I’m not sure I came out ahead in that situation.
A hospital system had issues after this happened to them: engineers deleted critical storage that connected to a database system. Fortunately, no services have stopped, and no patients are missing services, at least as far as we know. Everything has to be moving slower, and that might mean that staff is spending more time on “downtime procedures”, i.e. paper, than focusing on patients. Knowing a few medical professionals, this means they’re more stressed and working harder to be sure patients aren’t affected. Sucks for them, and I doubt the hospital compensates them for an engineer’s mistake.
I haven’t heard about this happening in a long time, and I’m surprised by that. Almost all storage these days for server systems is remote, especially in the cloud, and it would be easy to click the wrong button or select the wrong disk when re-configuring a system and remove critical storage. Maybe we’ve gotten better at popping up warnings that slow people down and prevent mistakes.
Or maybe we don’t delete disks and only add them to database systems 😉
In any case, I hope they can recover things quickly and easily. If you’ve seen this, let me know. If you haven’t, here’s a reminder that this could happen. You should be sure your backups are running AND you can perform a test restore.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
-
Database DevOps Recommendations
The DORA organization is constantly researching how to better produce software at any organization. This is similar to work done by Carnegie Mellon Software Engineering Institute many years ago. Both groups are trying to determine what things help engineers work better and produce high-quality software.
On the DORA site, there is a database change management page, where they recommend approaches to managing database schemas. The main thing they talk about is treating all schema changes as migrations, which is something some people do. However, many teams also like a desired-state-configuration approach, where they just deploy all the changes from dev (or QA) to prod in a state-based flow. Both can work, but I do think as software matures (and becomes legacy), migrations are preferred. The article lists lots of frameworks in different languages. Flyway is among them, which is the product on which I work and sell at Redgate. If you haven’t looked at a migrations framework, I’d recommend you do so. They do really give you a tremendous amount of control and flexibility. There are trade-offs, so I’m not blindly recommending this approach, but it’s worth educating yourself on how migrations frameworks work.
The other thing they recommend is using a zero-downtime change approach. They list a few strategies that you can use make changes without impacting clients. None of these are hard, but they require a little coordination with application developers, as well as some patience in splitting changes across multiple deployments. They also require good coding practices, so many of us have a few habits to unlearn.
DORA does also recommend considering a NoSQL database since you don’t have downtime from schema changes, but my view is that you’re likely making trade-offs that aren’t worth in. If you read that paragraph in the article, my guess is many application developers read everything but the last sentence, or they dismiss that last sentence. Then they just start developing against a NoSQL database platform and expect it to magically be better. It might be, but it might not work as well.
The one thing I wish they had a better answer for was how to measure our work as database developers. This section doesn’t give you any concrete things to measure, just some suggestions, which are often hard for people to implement in their environment. Most of us don’t have salary or time numbers for others, and need more help in trying to determine how to measure changes. Maybe the one good measurement to aim for is 100% of database changes made by automation, rather than manual execution.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
-
How Helpful is a GenAI Copilot
I’m sure many of you have tried a GenAI LLM to do something. Maybe write some code, maybe get some sort of recommendation or suggestion, maybe to rewrite something or summarize text. I’m sure you have had some feelings about whether the tool made you more or less productive.
There was a trial conducted by the Australia Department of the Treasury on Microsoft’s 365 Copilot, asking for volunteers to participate and use the tool in their daily work. They used it and then completed a survey, which are summarized in this piece. Only 218 people went through the trial, and the results are interesting.
The headline says that the staff rated the GenAI less useful than expected. Those last two words are interesting because your expectations shape a lot of how you view anything in the world. If you expect little and get a little more, you might be happy. If you expect a lot and don’t get it, you might be very disappointed.
The sub-headline and the first sentence note that there still is an ROI from the tool. It isn’t as helpful and isn’t as widely applicable as people expected, but they chalk some of this up to product limitations and some to limited use by people. It was useful in summarizing things and drafting content, which are what they call basic administrative tasks. That’s interesting and likely where GenAI tools can help quite a bit.
Maybe the most interesting thing to me is that if Copilot saves 13 minutes a week for mid-level workers, it pays for itself. I don’t know how much time it would have to save me, but an hour or two a week might make me use it more. It certainly would be use a small monthly cost. So far, I haven’t committed to regular work with the tools, and I think I still spend more time learning and typing with GenAI tools than I’d like. I’m not sure if I am saving time over just doing the task myself. Some of that is because I have habits that allow me to work quickly and to use a Copilot, my pace slows.
This also brings up something I wonder about with these GenAI services. With the cost of compute services, there might not be a lot of margin for vendors to raise prices if people are only lightly more productive. I can see lots of companies starting to use these tools, realizing there isn’t as much value as they expected from increased productivity, and then dropping the cost from their budget. That might be some of what we saw in this years State of the Database Landscape, with less people using AI for database management tasks. I suspect some of the hype has died down and people aren’t finding the tools as useful as they expected.
I do think GenAI is helpful, but just helpful. It can’t do the work, and it can’t be trusted more than a junior worker. At least not yet. Maybe that will change, but I haven’t seen it to date.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
