Voice of the DBA

Category: Editorial

  • Would You Move to Linux for Price?

    Running software on Linux is supposed to be cheaper than Windows. After all, you don’t need to pay for an OS license, right? I’m not sure I think the price of the OS is a determining factor, since it’s a relatively low amount compared to the cost of the database license. I’m sure some of your feel differently, and I’d be happy to listen to your argument as to why the Linux is better on price.

    In any case, Microsoft is looking to push the Linux version of SQL Server. For a limited time (until June 30, 2018), you can get 30% off the cost of a SQL Server license. They’ve also gotten the cost of SUSE Enterprise Server down to $0 for a year if you are a qualified customer. This does require an annual subscription, which I assume means Software Assurance. There’s not a lot of information available on their page, and I assume you’d need to call Microsoft and go through the sales process.

    It’s an interesting offer. I wonder if this would really make a difference for some of you. For the purpose of a discussion, let’s say you run an older version of SQL Server on Windows, like SQL 2000 or 2005. You want to upgrade, but your boss has been worried about costs. Now you see a 30% savings on Linux. Do you consider moving to a Linux OS instead of Windows? Let’s assume you have some Linux resources inside the company, and so there isn’t a large learning curve. Does 30% make enough of a difference do change the underlying platform? After all, for the post part, SQL Server is SQL Server.

    What if you are a Linux shop already, and you have Oracle or DB2 in house. You’re looking to move some software to a new system, or maybe develop new applications and SQL Server is being considered for cost savings. You’ve avoided it because it has required Windows in the past. Do you now consider SQL Server a more viable candidate as a relational database inside your environment?

    Would you move to Linux for a better price?

    Steve Jones

    The Voice of the DBA Podcast

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

  • Auto-Deleting Data

    Email has been a part of my life for well over nearly thirty years. It’s kind of amazing to think of a time back in high school when there weren’t electronic communications. That seems foreign now, as we don’t have to send physical objects or converse with voice to communicate. The world of communications have changed dramatically.

    These days email is still a preferred method of communication for many people. Even if we use sites like Facebook, NextDoor, or SQLServerCentral to communicate with others, we often get notifications of changes through email. If you’re like me, many of you might keep far too many emails in your mailbox, rarely removing unnecessary ones. In the era where we measure storage in dozens or hundreds of GB, or even in TB, do we bother to even manage text communications?

    Some firms do require this, often for legal reasons. With the GDPR, I wouldn’t be surprised to see more organizations starting to set retention policies that ensure that communications don’t live forever. There are some systems that do this now, but the practice isn’t ubiquitous, but maybe it will be soon. Google is redesigning Gmail, which will include Confidential Mode. Not only will there be limits on these emails, but one of the more interesting is the ability to expire an email and have it automatically deleted.

    I don’t love the idea of having communications disappearing, but that might be because of the way I’ve grown up. I don’t like using Snapchat with my kids, because I don’t want pictures I take to disappear. However, younger generations don’t feel this way. As I wonder why I try to hold onto old communications and records, I start to wonder if the idea of expiring data is something that we should be embracing as data professionals. Do we really need sales records from a decade ago? Are recordings of web traffic valuable from the early days of SQLServerCentral? Is there really any point to holding onto much of the data we generate?

    I know that there are corporations that hold onto decades of paper records. I worked at one that had nearly a 100 years of old records, most of which might never be examined again. Likely plenty of them aren’t even legible or useful at this point. They’re being stored for, well, I’m not sure why. I’m sure there are plenty of writers that might come up with a detective story that requires old paper records, but I’m not sure there’s practical use for this data.

    I expect that we’ll start to see organizations changing their record retention policies as we look to avoid more liability and risk from data breaches. Every old record, every piece of PII data that we no longer use probably needs to go. Even records for existing customers might need to be removed. I don’t necessarily need to ever access the record of my first Amazon order from 1998. I’m really sure that Amazon having liability for holding my old address, which potentially could be used to validate identity, is a bad idea for both them and me.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Replication Gets Some Love

    I really like replication in SQL Server. At least, I like it as a concept. It solves some hard problems and lets me move data around in a way that can handle larger loads, reduce queries to OLTP servers, and more. I’ve been hoping Microsoft would see this feature as critical to the future success of SQL Server and enhance it’s tooling, reliability, and feature set. Each time a new version is completed, I’m hoping that the Release Notes include a lot of replication changes.

    I’m usually disappointed, but not always. Recently I was excited by a change in a CU, not a new version. The SQL Server team added the ability to put the distribution database in an Availability Group. This is incredibly useful and helpful for ensuring HADR for replication scenarios. Prior to this, you could put the publication database in an AG, but not the distribution database. This is being added in CU6 for SQL Server 2017 and will be back ported to SQL Server 2016 in a future CU.

    There are plenty of restrictions in this first version of the feature, including the fact that local distributors aren’t supported. In fact, with all of the ways you can’t use this, I bet many replication environments can’t implement this.

    Yet.

    I have hope that future CUs will enhance this feature to remove restrictions and allow more flexibility with replication in AGs. I think that handling naming and networking issues in HADR situations is incredibly complex and replication was built quite some time ago, when we didn’t think so deeply about distributed systems. I slowly see Microsoft adapting parts of SQL Server to the modern world, and I hope that they continue to do so for replication.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Taking Shortcuts

    Many of us work in situations where we feel pressure to get work done at a pace that’s faster than we might like to move. In some sense, this is the nature of life, where customers and clients always want something done immediately. Whether they’re ordering food or building a house, it seems that quite often the customer expects the creator to just work harder and faster, without making mistakes, and deliver the goods quickly.

    That may or may not work, but if does often result in issues in software. While we can fix them, there can sometimes be larger issues, especially where sensitive data is involved. There was an incident recently that reminded me of this, though fortunately, it appears the data loss was minimal in scope and sensitivity.

    The mobile app at a recent security conference leaked data. The builders of the app embedded security keys and passwords that allowed anyone that registered to download a database of attendees. Fortunately this was a limited set and it appears only names were exposed. However, it could have been much worse, especially if this were a typical non-normalized database that might contain all data about an attendee in one row.

    I don’t know the timeline here for development, and I certainly don’t know the requirements. I do know that embedding keys and passwords into application is a bad idea, and even worse when those applications are going to be installed on customer devices. These are fundamental rules, and I certainly hope that whoever worked on this application, and anyone reading about this story, knows not to do this again.

    No matter how rushed we are, it’s important that we follow some practices and include some seucrity in our systems. I’d argue that data security ought to be number one and built into the system from the start. As the GDPR asks, we should be ensuring this is included by design and default. As much as it might seem that new legislation is overreaching and burdensome, I’d argue that mistakes like this one are all too common when we feel pressure to get work done. We shouldn’t be making these mistakes, nor should be be pressured to ignore security for the sake of expediency.

    Steve Jones