Voice of the DBA

Author: way0utwest

  • Multi Script Removes 25 Database Limit

    I woke up to a Slack message that alerted me to a post in one of our channels. An engineer noted that SQL Multi Script was being upgraded today, releasing to all channels with v 1.3.3. The post alerted me to not the release, but the fact that the 25 database limit (for parallel execution) has been removed.

    Woot!!!

    That’s one I’ve been asking for across quite a few years. We don’t have a lot of Multi Script customers, but there are still quite a few and across time, I’ve had many of them ask me to remove the limit.

    Some have 30, 40, 50, 100 separate servers on which they want to run a query. Some have hundreds of databases on which they need to deploy the same code. All of them have struggled a bit with the need to run Multi Script many times to reach all their databases, with no good reason as hardware has improved and many of them have 16 GB of RAM. Back in 2007, when Multi Script was first released, most people likely had 2 or 4GB, and much slower CPUs.

    With my advocacy, and a few salespeople, plus some reorganization internally, we were finally able to press the engineers to dig into this code and remove the limit. This is good news for customers. It’s also good to have

    If you’ve never tried SQL Multi Script, give it a go. It’s a handy tool that I think is much better than a CMS. If you own a SQL Toolbelt license, you have Multi Script. If you don’t, grab a trial and see how this might help you.

  • I Will Write Bad Code

    I’ll write bad code. I know it will happen. I’ll produce a bad query, incorrect logic, or the wrong data transformation being returned.

    This won’t be a malicious act. It might be because of ignorance, or perhaps just a simple mistake. My code might be the result of short-sightedness or not accounting for a potential situation. I might even misinterpret poorly written specifications and place the blame on others. Maybe I’ll misread the code and won’t realize there’s a problem.

    And, for sure, this code will get deployed to production.

    At some point I know this will happen, to me or someone else. And for whatever reason, I need to account for that fact in my software development process. I can’t prevent mistakes, as decades of software development have proven. Despite my best efforts, code reviews, the tests implemented in QA and elsewhere, bad code is going to get deployed.

    The important thing in any software development project is how you handle the mistakes. How do you move forward, and certainly, how do you apply a patch? Can you do it quick enough to minimize the impact to clients? Or must they deal with the issues, developing the workaround or missing functionality for a significant portion of time? Or will they consider abandoning your software for some other vendor?

    One of the reasons I continue to advocate for a DevOps approach is that a known process can enable you to fix your mistakes in a timely manner. With a consistent approach to writing, testing, and deploying software, you can apply a patch when it is needed. Certainly the code needs to be logically fixed, but a reliable process will help ease all the overhead of getting your code to a production system.

    DevOps can be implemented many ways, and if applied in name only, things won’t improve. We can’t say we’re using DevOps, or we’re coding faster, or we release every week. We need to really implement the three ways. However, if you approach your project and staff with the idea that although things are flawed, they can be improved and made better, you’ll find that you can deliver those fixes for clients in an extremely timely manner with a minimum of risk.

    DevOps allows us to move faster, but that’s not the goal. The goal is that we improve things and have confidence that we can release when we want to, in a repeatable, reliable, less risky fashion.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • A Backup Change

    Backups are a fundamental skill for most DBAs, and hopefully, for most technology professionals. For developers, I’d hope that most of you use some sort of version control, and that you back up your VCS database. I actually had someone ask why we needed to back up the VCS if we had the code on our machines. Certainly the local code on your system, or in your database, provides you some level of redundancy, but all the branches, all the code from other developers, you really want a real backup. For git, this is a simple file level backup.

    I recently got a letter from Crashplan, who I’ve been using for a few years as a backup provider. Apparently they are exiting the home backup market, choosing to focus on businesses. I chose them since it was an economical provider, with good ratings, that let me back up multiple machines. I’ve been happy with them, tested a restores of a few files, but never needed the service. Now, I need a new solution. I keep two copies at home, but what about a fire or disaster? I want an offsite backup.

    One of the things I’ve wanted with a backup solution is a hands off process. While I’ve managed to use cloud sync software and VCS reports to move most work stuff from one machine to others, there are pictures and other data that I don’t want to lose. I’ve also got computers for my wife and kids that I’d like to have backed up. The Crashplan subscription for 5 computers worked great for me.

    It doesn’t seem there are a lot of providers out there for families. Most focus on businesses or the individual, which is fine. Backblaze seems like the next best choice, and at $50/yr/computer, perhaps that’s a fair price. I’ve considered using Amazon Glacier and CloudBerry software, but that feels like I’m giving myself another management job to track. Though, maybe with PoSh available cross platform, I could just build a set of scripts to let each computer notify me if there are issues. I’m still trying to decide what makes sense.

    Backup is important, and it’s becoming a more cumbersome job over time. As my family generates more pictures and video, I get more concerned about backup. Especially the cost. The same problems and challenges I face as a DBA, though often with a slightly bigger budget. However, the challenge of balancing a budget with the requirements to meet some RPO is the same.

    Steve Jones

     

  • Data Governance Survey–Still Time

    Just a reminder. Redgate is doing research into data governance, and we have a small survey we’d love to get some answers to about how you view the process inside your company.

    Take the Survey and be entered to win $100 gift card.

    If you want to read some thoughts on why we’re doing this, check out this post from the Foundry at Redgate.

    I think this will become more important over time. It’s not just GDPR in Europe, but more and more companies are getting increasing negative press and potential fines for losing data. As much as the Equifax event angers me, I’m glad there are calls for investigations, as their should be.

    No good excuse for not having strong security from all vendors, even if it slows deployment and enhancement. We can’t have data being lost to criminals this often because of misconfiguration or silly issues.