Voice of the DBA

Author: way0utwest

  • Pluralsight for Another Year

    One of the ways that I try to keep current and learn is through Pluralsight. I’m lucky to get a subscription as a Data Platform MVP, but I’m sure Redgate would pay for one if I didn’t.

    My subscription ran out last week, but the support staff at Pluralsight was kind enough to renew me in minutes. Amazing service and greatly appreciated.

    If you haven’t tried online learning, I’d give it a go. Pluralsight has some great courses, but there are other choices as well. No matter what you choose, making some regular time to learn something fun, or improve those skills you use every day is a great way to keep your career moving forward.

  • We Need DevOps for Performance

    I read this nice piece on CosmosDB and setting performance levels. It covers how you set some level of performance for Request Units (RU) and CosmosDB handles the rest. Great, right? Set the level of performance you need and that gets handled. The question I have is how do you know what level of performance you need?

    This is one of the issues with the Cloud services that I see. It doesn’t matter if you use PaaS or IaaS, most of us really don’t know what level of performance works. We tend to guess, and far too many of us don’t use regular monitoring to decide if we are over or under powered. I find many DBAs and sysadmins would prefer to be over-provisioned and then let the server trundle along at a lower resource usage so that no one complains.

    When we move to a cloud type service, we tend to be more cost conscious, which makes sense when we’re paying by the minute. We want to minimum level of hardware we can get, but we don’t want to cause unnecessary complaints, either from customers because the system is slow, or from the CFO because costs are high. Using your old method of over-provisioning hardware (or DTUs) usually causes complaints from the CFO.

    The piece goes into some ways that you can start to evaluate your performance level for CosmosDB, and how to deal with throttling while you tune your RUs with a new application. This works great if you’re in a (more) greenfield area of development. Not so great if you’re lifting and shifting some application from another platform. Then we might need to ensure that we are responding quickly to issues, or better yet, have scripted responses that scale up or down.

    The same thing should be done for our relational systems. The Ops part of DevOps needs to be using monitoring and instrumentation to measure performance, adding capacity as appropriate, which should be before users realize there’s an issue. With today’s virtual systems, adding CPU and RAM usually is fairly easy, and it’s easy in the cloud as well.

    Of course, all this monitoring isn’t just to add capacity. Having a better sense of what’s going on can help you pinpoint poor code. Getting someone to fix that code becomes a lot easier if you can show that better code would cost less for our systems. It can be amazing how much more developers care about their code when the CFO gets involved.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Installing Pester

    One of the things that I believe strongly in is that we need better testing of software. Actually, what we really need is better habits and understanding of how to test our software. I don’t think we need to test everything, but we do need to know how to test some parts of our software, and we need to test those well.

    Enough on testing. Let’s talk Pester. I saw Rob Sewell (b | t) talk about Pester a few months back, and it’s been on my list to try something, but time and pressure have kept it on the list and not in the code editor. A week ago that changed when I saw Rob write Write Your First Pester Test. That spurred me to devote a few minutes after I read the piece.

    However, I ran into a snag. When I went to run Install-Module Pester, I got an error.

    2017-11-16 13_49_27-cmd - powershell (Admin)

    I tweeted a bit with Rob and Mike Fal (b | t), both of whom are some of my PoSh go-to people. They noted the Force option for install, which did work, but I not by itself.

    2017-11-16 13_51_31-cmd - powershell (Admin)

    As you can see there’s a security check. A good thing, but like many developers, I’m confident the Pester module on the Powershell Gallery at MS is OK. It’s got a different signature than the previous version. I could remove that, but I decided to add the –SkipPublisherCheck and move forward.

    This what I wanted to see.

    2017-11-16 13_51_41-cmd - powershell (Admin)

    Now I can move forward with Rob’s article and try some Pester tests.

  • Watch Out for Automap in SQL Compare

    I wrote a piece on SQL Compare and customizing the Automap feature. This was handy for me in a small project where I encountered drift and needed to fix the production side.

    In the article, I don’t map one of the columns in the target. In this case, I’d actually be dropping the target column in SQL Compare. After all, the idea of SQL Compare is that we want to synchronize the databases.

    If that’s not correct, then I’d need to do one of two things: add the column in development or add a filter. Filters are a great way to avoid issues in production when development items are in flight or uncertain (I’ve written about those as well).

    In this case, if I really needed to keep this column in production, I wouldn’t want to add a filter. Instead, I’d really want to add the column in development. In fact, I’d want to add it in the same place it is (column order) in production, so in Development I’d rebuild the table with the new column, in that order, and then run the Compare again.

    Automap can be a great feature, but it can’t know what your intentions are. It can only guess, like a new developer that is working on the system for the first time. SQL Compare needs guidance to do the job properly.

    SQL Compare is here to help you, and if you haven’t used it, give it a try. If you’re on a version older than 12, I’d say you should upgrade to 13 immediately. If you work with SQL 2017, then move from SQL Compare 12 to 13 and ensure all your comparisons work with the new features.