Voice of the DBA

Author: way0utwest

  • Using Backup-DbaDatabase for a Quick Backup

    I really like the dbatools project. This is a series of PowerShell cmdlets that are built by the community and incredibly useful for migrations between SQL Servers, but also for various administrative actions. I have a short series on these items.

    One of the core tasks of a DBA is backing up a database. In fact, I’d argue that it’s the most important thing for a DBA to know. Second would be restores.

    I’ve used the BACKUP DATABASE command so often from T-SQL that it’s a quick way for me to just get a backup of a database. I almost always have SSMS running, so I can easily just run the backup.

    For regular backups there are some great tools out there, SQL Backup Pro from Redgate, Minion Backup, Ola Hallengren’s scripts, and more. However, there still might be a time I want to make a few backups, perhaps copy them over, and that’s where I think dbatools and Backup-DbaDatabase might help.

    This is a nice, easy cmdlet to use. You can probably guess how to use it. Give it an instance, a database (or few), include a path, maybe create folders for each database, and let it go.

    That’s about it.

    If I run this interactively, I’d get the progress bar:

    2017-10-02 17_04_29-{15%} cmd - powershell (Admin)

    When the command is done, I see the results from each database. I get the file, folder, full path, and the script used.

    2017-10-02 17_04_36-cmd - powershell (Admin)

    I could include a different path if I wanted, and certainly I can chain this along with other PoSh commands.

    I don’t know that I’d use this often, but it is handy in places, and certainly if I want to script the movement of some files, perhaps for something like HA/DR testing or setup, or even to refresh other environments.

  • A Double Dose of Trouble

    It’s Friday the 13th, during the month of October. Halloween, a strange holiday associated with horrible events, and Friday the 13th, a bad luck day, are happening this month. Both are associated with horror movies, implying that this isn’t necessarily a good month for the world. It’s a double dose of bad luck, which is what Equifax would have you believe. I wrote about this yesterday, where the company would have you believe a single employee makes a mistake when a scanner fails, and hackers were ready to attack.

    I’ve, in general, had a lucky career. I’ve worked hard, and things have gone my way. That doesn’t mean I haven’t made mistakes or systems haven’t gone down, but overall things have gone well. As I think about Friday the 13th of October, I’m reminded about Murphy’s Law, where things that can go wrong, may just do so. I’ve tended to expect that some things will go wrong and prepare accordingly. In fact, in keeping with a corrollary that I’ve sometimes heard to Murphy’s law that if one thing goes wrong, I’d expect that something else will fail.

    On this double downer of a day, I’m wondering if you’ve experienced that. Have you had something bad happen at work, only to find that overshadowed by something worse? Hopefully you didn’t make a security mistake and then get hacked, but perhaps something else has broken?

    In my career, I’ve had this happen, though not directly to me. I consulted with a small company to make a little extra money and because I liked their business. I was rooting for them to succeed and wrote some database code to help speed up their application. One day they call me to say that a drive array failed with the database mdf on it. I wasn’t worried, and while in another state, I was ready to walk them through a restore process on the new array. Unfortunately, this was a default install, and the default backup path was on the old array. I hadn’t set this up, nor was I aware of their backup process.

    The lead developer was proud of himself. He’d made a backup the day before, using a file share on a network drive. He had the .bak file. I thought this would be a quick and easy call until he read the error message that not all media sets were provided. That’s when I realized that the developer, while making the backup in SSMS, hadn’t cleared the previous backup file from the dialog. He’d inadvertently created a striped backup.

    Eventually they managed to locate a backup that was many days old. I’m not sure how far back, but they angered a number of clients, who I’m sure all started looking for a new vendor. Eventually the company failed, and I moved on. There wasn’t much to be done in that situation, but it was a certainly double dose of things going wrong at the same time.

    I hope few of you have had double the bad luck in your career, but if you can share a story, we’re happy to commiserate with you.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Getting the Random Module in SQL Data Generator

    This is a series on SQL Data Generator, covering some interesting scenarios I’ve run into. If you’ve never tried it, SQL Data Generator is a part of the SQL Toolbelt. Give it a try today with an evaluation today.

    I have SQL Data Generator, and use it regularly to build quick  test data in non-trivial scenarios. One of the things I ran into recently was a minor bug, but one that’s been logged. Hopefully you won’t need this, but in case you do.

    I was trying to use a Python script and return a random value from a list. My code was:

    return random.choice(mylist)

    This gave me an error.

    2017-10-05 11_02_09-SQL Data Generator - New project _

    No biggie, I’ll add “import random” to the top of the script. That didn’t help. Apparently the distro with SQL Data Generator is missing the random module for some reason.

    Fortunately, I have Python 2.7 on my system. I clicked “Tools” and “Application Options” in SQL Data Generator.

    2017-10-05 11_00_47-SQL Data Generator - New project _

    This gave me a dialog. On the General tab, there’s a “Python” section. I added the path to my Python lib folder in here.

    2017-10-05 11_01_00-Application Options

    That worked fine. I didn’t need to import random; it was available. My script now worked.

  • The Blame Game

    Make no mistake, this is going to be something that happens again. The former CEO of Equifax blames their massive data breach on a bad scanner and a person. I’m not talking about a data breach, of course those are going to happen, and when they do, assume that every piece of data in the system is compromised. I know some digital forensic scientists are really talented, but is a company that didn’t necessarily pay attention to security in the first place going to ensure the analysis is done right? Not likely. Assume every record is compromised.

    In this case, the former CEO calls out a person that made a mistake, and then says technology failed. I don’t think that’s true, and I’d agree with Patrick McKenzie, who has a good thread on Twitter. A bad engineering decision, or even a process, is the result of multiple people making mistakes. Certainly there are people that must back up the Apache Struts patch person when they’re on vacation. Or there should be. If there isn’t, then that’s a management failure at multiple levels.

    The thing that concerns me is that we, as tech workers, are going to be blamed going forward. The individual isn’t named here, but I bet at some point they will be. And some, or many, tech workers will get sacrificed for a company that wants to show contrition and action for security mistakes. It’s common for someone to take the blame, but I haven’t seen a specific person be identified (or their inaction be called out) in the past. I’m sure some tech people were probably fired after previous incidents at large companies, but not publicly.

    While the person wasn’t named, there was a report that this individual was no longer employed. Fired? Quit? Who knows. Certainly it’s likely that once this breach became public, anyone who might have been responsible for watching CERT lists, applying patches, or anything to do with Apache Struts might be blamed. In fact, I don’t know I’d want to continue working at a company that might publicly blame my role for a massive breach. My career might be dead with that management, so I might as well move on. Much easier for everyone to blame me than accept responsibility.

    This is the first time I’ve seen an IT employee blamed. BA said an IT systems failure with their major issues. Yahoo and Target were hacked, but no one in IT was blamed. Sony didn’t blame their IT staff after their emails and films were released. Yet Equifax did. I hope this isn’t a sign of things to come.

    Steve Jones

    The Voice of the DBA Podcast

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