Voice of the DBA

Category: Editorial

  • A New SQL Server Edition

    I first heard about this edition of SQL Server over a year ago, and at the time I wasn’t sure there was much of a market for it. Microsoft disagreed, and they moved forward, putting this in preview and then finally releasing it this past week. Now you can order and set up an Azure SQL Database Managed Instance. According to Microsoft, this is an edition that is near 100% compatible with on-premises instances. The difference is this is a PaaS option that removes much of the administrative burden for patching, backup, HA, etc.

    This seems like a VM that Microsoft manages and you connect to, except this isn’t really a VM. You do not have any access to the host, but you do get the option to have multiple databases and most of the features that don’t exist in Azure SQL Database are here. Keep in mind that near 100% is not 100% and there are limitations, quite a few, which may limit your ability to lift and shift your particular application.

    Brent Ozar Unlimited tackled this feature first, putting together quite a few blog posts on the topic. The first one notes that a new instance might take 24 hours to deploy (in the cloud??), and theirs did. In that post, they also discuss the networking, which isn’t necessarily hard, but it’s not as simple as most DBAs and developers are used to. In fact, while reading the post, I recalled memories of my time as a network admin, learning how to migrate from IPX to IP based addressing. For those of you not used to networking terms and configuration, you might want to read about this topic from the experts.

    The Azure fabric is managing all the HA behind the scenes, and I’m guessing they’ve got some advanced featuers that might end up in the box product at some point. It seems from reading Brent and Erik’s experiments that you really get a dedicated instance with some CPUs and schedulers turned off it you don’t provision the largest instance. There are new objects inside the instance, which again, might get into the box at some point.

    Are Managed Instances for you? Perhaps. Removing this administrative issue might make financial sense for your organization. Not for you, but when you factor in taxes and staff to perform tedious actions, maybe this works. Certainly you should understand if you have an option here for any applications and then present this as an alternative to the business and let them decide if this makes sense. I’m not sold, but I do like the idea of this as a new cloud option. We have public, government, private, hybrid, IaaS, Paas, and SaaS options. This slips somewhere between hybrid and PaaS, giving us more choice, which I do think will work for some organizations.

    I don’t know how these will perform, and really none of us do outside of Microsoft. They’ve been testing, and I hope this will work well, failover cleanly, and not be so confusing that customers find themselves misconfiguring networking. However, if you’re using parts of Azure, have AAD implemented, and want to get new instances provisioned that look mostly like what you have in your data center, take a look. Hopefully the provisioning process will smooth out and speed up, since 24 hour notice might be great for some large corporations, but it certainly doesn’t feel like the cloud to me.

    Steve Jones

  • Great Developers Use Source Control

    I was rewatching Ike Ellis (b|t) talk on the habits of Great SQL Developers from SQL in the City 2018, and his first item was “Use Source Control“. I happen to agree with Ike, which is why I’m writing this, and I really hope you do as well. Certainly at Redgate we’ve built tools that help you get your T-SQL code into a VCS, but whether you want to work manually, use someone else’s tool, use our SQL Source Control or ReadyRoll, I’d ask that you consider getting all your code into some sort of VCS (Version Control System).

    Ike notes that if viewers did this one thing, he’d be thrilled. I agree. Please, learn to use version control. If you wonder why, listen to Ike’s talk. He relates a story that notes that using source control doesn’t make you a better developer, but that better developers do use a VCS. This is a habit that helps build better habits and is a step on the journey to you becoming a great developer.

    Does it help? Well, I think it does in some sense. Developers that use a VCS often build a habit of checking in changes before they try something that might be problematic. They also in a more integrated fashion with their work, and easily rollback problematic code without wasting time (or focus) trying to undo something. They get a previous version back and move forward.

    I do think that this one thing changes the way you view code, and it provides you with a safety net. This is one of those skills that I’d really recommend you learning, as it will pay back it’s value tremendously over time as you learn to depend on the VCS and stop doing things like keeping multiple objects or files around, and trying to sort out what code is where. As you work with others, or even with your past self, you’ll learn to include better comments that help you change focus quickly and understand the particular reason behind a version of code. This will help you learn to be a better developer.

    There are numerous ways to get your T-SQL code into a VCS. There are tools, but there are plenty of PoSh or other scripting methods. In fact, every DBA should get in the habit of scripting out instance level objects (which most tools don’t handle). Store them away, and then repeat as you need to make changes. You might be surprised how often you’ll be glad you have the previous version of a job, a schedule, a linked server, or more. I learned to keep all my scripts, from replication to running a quick report for a business user, in a VCS. I’ve never regretted this choice.

    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.

  • The Last iPhone

    A few years ago the iPhone 7 was released. This was a big release for Apple, and I knew quite a few people that were ready to plunk down their credit card on day 1 and upgrade. I wasn’t, and in fact, I upgraded to an iPhone 6s+ from a 6 a few weeks after the release. At the time, my old phone felt slow and small, and I decided to make the upgrade sooner rather than later to my last iPhone. Why? Really for one main reason.

    Most of us reading this work with technology and software. We often deal with upgrades to our tools and systems better than most of our friends, but not without complaint. Quite a few of us have been annoyed, or even angered, by the changes that Microsoft has made to software. From SSMS to Office, what the developers in Redmond might see as an upgrade, we see as a step back. One that interferes with our workflow and forces us to adapt and build new habits. The Ribbon bar in Office and the “Modern” look in Windows 8 come to mind as some of the more disruptive upgrades.

    I get it. I work for Redgate Software, and we often struggle if we make significant UI or workflow changes to software. We might have reasons to view a change as better, but without a doubt, there are a percentage of users that always disagree. We try to ensure it’s a small percentage, performing a lot of research among customers before we implement a change, but someone will dislike our decision. As a side note, if you care about your software, participate in research with your vendors. You can help them determine if something should, or should not, change.

    In the case of my iPhone, I use this device to listen to music quite often. Whether at the gym, in an airplane, or between matches I’m when I’m coaching, I depend on headphones. In my case, I prefer wired headphones and I wouldn’t buy a new iPhone because there was no headphone jack. I’m on the go, in various places, multiple vehicles, with different bags, and I don’t want to depend on a dongle, nor do I want to have bluetooth devices run out of charge. I also sweat and destroy or lose a few pairs of headphones a year. As I watched rumors, and contemplated upgrades, I decided that the iPhone 6S+ would be my last device.

    I’ve owned 5 Apple mobiles, but I’m moving away from them for good. Not because of software, which I think is similar among both major platforms, but because of hardware here. I ordered a new phone, and I’ll say goodbye to the platform. I have liked iOS, and I think there are things it does better than Android, and certainly some conveniences that apps include, but Android is close, and I’ll adapt.

    Most of us won’t do that in our career. We won’t change desktop OS or database platforms or even programming languages. We might adopt something new, but we often stick with what works. There are good reasons to do this, especially when we can take advantage of the built up knowledge. However, never say never. If there’s a very strong reason to switch, I’d like to think most of us would.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Reliable DBA

    Many of us would consider ourselves to be reliable at work. Our employers count on us, co-workers may assume we’re handling certain tasks, and it’s human nature to think that we are meeting our obligations and responsibilities. Maybe not 100% of the time, but certainly I know my goal is to complete tasks I’ve committed to, on time, and to avoid dropping any balls that I’m juggling. I think I am mostly successful here, but certainly am late or forgetful about things at times.

    However, as a group, department, or even a set of services, does your organization think highly of the databases? Are your systems meeting their SLAs for performance and availability? If not, does your group respond in a timely manner? We sometimes think that we are, but without feedback and communication can we be sure? This certainly could be taken the other way, with other groups constantly complaining about your performance, even while you are meeting your commitments.

    I ran across a talk from Uber on reliability. It’s more of a high level architecture talk about distributed systems and being able to detect and respond to issues. Certainly Uber works at a rate and scale that few of us will reach in our organizations. Add to the highly public nature and real time demands, and reliability is extremely important for their business. Mistakes can have dramatic hard dollar effects instantly, and there is a lot of pressure on their staff.

    For most of us, our databases do continue to become more important, and even when we are meeting our SLA commitments, are we providing reliable service from the entire staff? Is information being shared, with root cause analysis or retrospectives that help knowledge transfer among all of the individuals that might respond to an issue? Are you dependent on a superstar that must be called in to solve issues with the database, network, or storage?

    I’ve been the main person on call, the expert for a system that received calls on weekends, vacation, and other downtime. It’s no fun to be in this position, and it certainly distorts work life balance, not to mention upsetting the rest of my family. My goal is to be there if necessary, but train others so that they can provide a consistent, similar level of service to customers and clients if need be.

    Becoming too dependent on any one person isn’t much different than becoming too dependent on one server or disk drive or network cable. At some point you’ll have a failure and that item will no longer be available. If you don’t have a spare, you’ll have regrets.

    Steve Jones

    The Voice of the DBA Podcast

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