Voice of the DBA

Author: way0utwest

  • Quick SQL Prompt Updates in a Pattern

    I work for Redgate and write about products. I’ve got a series of SQL Prompt posts here on little things I like. SQL Prompt might be my favorite tool.  SQL Prompt will be yours as well if you give it a try.

    We had a customer post a question today on how they can built an update statement with a pattern. Specifically, they said that the code often looks like:

    UPDATE dbo.Contacts
   SET 
   c.Salutation = @Salutation
, c.FirstName  = @FirstName
, c.MiddleName = @MiddleName
, c.LastName   = @LastName
, c.Suffix       = @Suffix
WHERE ContactID = @contactid

    The table columns are the same name as a variable. That’s a good pattern, and I’d think SQL Prompt could handle that.

    It doesn’t.

    The column picker doesn’t work with Updates (logged w/ product team), and I can’t duplicate selected text over (also logged for discussion). However, I do have a workaround.

    As I thought about it, I realized there are some features of Prompt that help here, and some of SSMS that will work.

    I made a quick video of the process, but I’ll describe it below:

    The Process

    The first thing is to get a column list. ssf<tab> does for me. I’ll get the select statement for a table and then expand the list of columns with a tab when on the *.

    Now, I’ll copy the columns. I tend to copy all since it’s usually easier to remove than pick and choose specific ones. I’ll wrap these in an update, which could be a snippet. If it’s not, that’s fine.

    From here, I use the power of Shift+ALT. If you’ve never done this, it’s amazing. I use this to select the columns and copy them. Then I’ll CTRL+ALT  to add the = and paste in the columns. I can then use CTRL+ALT once again to remove the alias and replace with a @.

    And, of course, I can reformat to make it look nice with SQL Prompt. Give SQL Prompt a try today and see how it can improve coding and feel free to share your tips here.

  • The Cloud is Better In At Least One Way

    Many people don’t see the cloud platform as necessarily better run than what they do in their local data center. That might be true, and certainly the caliber of people, their experience, responsiveness, and more can make a big difference to the way in which any environment operates. One would like to think that AWS, Azure, Google Compute, etc. would all hire the best people and pay them more to operate a top notch system. I’m sure they have some of those people, but they also may have some average people that might not be better than your administrators.

    Corruption is something I’ve experienced a few times in my career, and it was incredibly scary each time. I’ve been on multi-day support calls, trying to recover data, exported out pages to reconstruct values, and had to have very difficult conversations with management and clients to let them know data is gone. I think the worst experiences for me were breaking the news to workers that would have to try and re-enter data. Many of them had lots of extra work to look forward to without extra pay.

    The Microsoft Azure team takes corruption seriously, and there’s a good description in this post of how they protect against and deal with corruption in Azure SQL Database. It’s quite comprehensive, and it’s a set of things that I wouldn’t expect most companies to implement. Even some of the better SQL Server people I know don’t necessarily get called in during off hours when a corruption alert fires. Plenty of people working with SQL Server might not have been through an Immersion event and understand how to even deal with corruption outside of calling Microsoft.

    The cloud is a vast array of service and settings, many of which we can manage ourselves. In those cases, certainly the cloud might not do a better job than we would. No one on a cloud vendor’s staff is going to manage your VM or help you ensure your database design is solid. However, in checking for corruption, ensuring disk level backups, watching for DDOS and other threat vectors, the cloud vendors certainly do a better job than most of us. And for corruption, Azure SQL Database seems better watched than most databases I’ve seen in my career.

    Steve Jones

    The Voice of the DBA Podcast

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

  • 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.