Content provided by Voice of the DBA. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Voice of the DBA or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Player FM - Podcast App Go offline with the Player FM app!
Do you have fond childhood memories of summer camp? For a chance at $250,000, campers must compete in a series of summer camp-themed challenges to prove that they are unbeatable, unhateable, and unbreakable. Host Chris Burns is joined by the multi-talented comedian Dana Moon to recap the first five episodes of season one of Battle Camp . Plus, Quori-Tyler (aka QT) joins the podcast to dish on the camp gossip, team dynamics, and the Watson to her Sherlock Holmes. Leave us a voice message at www.speakpipe.com/WeHaveTheReceipts Text us at (929) 487-3621 DM Chris @FatCarrieBradshaw on Instagram Follow We Have The Receipts wherever you listen, so you never miss an episode. Listen to more from Netflix Podcasts.…
Content provided by Voice of the DBA. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Voice of the DBA or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Content provided by Voice of the DBA. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Voice of the DBA or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
I read a piece recently that got me thinking that data breaches might be inevitable. Disclosure: This was written by Redgate, for whom I work, titled “ Data breaches May Be Inevitable—Compliance Failures Don’t Have to Be “. It’s based on our research with the State of Database Landscape survey as well as feedback and conversations with customers. The thing that caught my eye was the first part: data breaches may be inevitable. Do you think that’s true? Are we doomed to lose data in our organizations, not as a possibility, but something that will happen at some unknown time in the future? Those of you who have suffered breaches might agree with this, but for those of you who haven’t had to deal with that situation, are you resigned to it happening at some point? I’ve gone through phases in my career. In a few jobs I worried about this. When we started SQL Server Central, we were very careful and cautious, trying to be sure we wouldn’t be caught losing email addresses of the community members. We never had an issue, and I’m proud of that. These days at Redgate, I worry a bit more, mostly because we’re growing and it only takes one person to click on a phishing email to cause problems. Fortunately our IT group is on the ball and even conducts plenty of “mystery shopper” email campaigns to test our awareness with follow-ups to help ensure people are aware and careful with how we handle data. The criminals always have an advantage in that they are focused and only have to take advantage of one mistake to win. We have to constantly be vigilant, across all our staffers and systems. Simple mistakes, or worse, typos in complex configuration files could result in a data breach. One of the places this can happen is in test/dev environments where more people the make changes. If we have sensitive data in those places, we’re increasing our risk. I don’t think breaches are inevitable, mostly because companies are getting better at simple security measures and reducing the ways in which unauthorized access takes place. There’s also the fact that the world is huge and there are more and more systems all the time, which might reduce our chances of the criminals targeting us. Don’t get complacent, as automation gives criminals a tool to attack us at scale, in the same way it lets us get more done with less. One criminal can do a lot of damage, so remember that the next time you’re annoyed by your MFA or other security measures. Steve Jones Listen to the podcast at Libsyn, Spotify , or iTunes . Note, podcasts are only available for a limited time online.…
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.…
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.…
Welcome to Player FM!
Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.