Voice of the DBA

Category: Editorial

  • 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

  • The CDO

    One of the cornerstones of GDPR compliance is appointing someone as a data protection officer for your organization. This person is responsible for ensuring that your systems and data are safe and protected, and presumably, complying with the various articles in the GDPR. Article 37 notes that both a data controller and data processor shall designate a DPO in certain cases.

    That makes sense for companies working under GDPR jurisdiction, but for those of us outside the EU, do we need a senior level data executive? I wonder. As I’ve been researching the work by others and working with various clients and customers, it seems that some companies do have an executive, not necessarily in charge of protection, but in charge of data.

    This week, I’m wondering if any of you have a Chief Data Officer in your organization. I’ve heard a few people say that if you do, it’s a sign of maturity in your organization, where data is treated as a truly strategic and important asset. You likely have some sort of data quality metric, you many have master data management systems in place, and the organization constantly looks to extract more value from the data they store.

    I don’t know if this is a sign of a more mature organization, but I do know that having some resources in place to ensure data quality, mapping your data estate, trying to ensure some level of consistency are signs of more data maturity. I know many of us realize data is important, and certainly our employers want our systems to run smoothly, but do they really make an effort to use data wisely? If so, then I think the company is mature. If not, maybe they’re letting opportunity pass by.

    Lots of us data professionals do look for opportunities to better use data, to build useful reports, and find new patterns in data. Whether there’s a Chief Data Officer or not, many of want to explore data and make use of information we find. I think if our organization supports that, we’ll enjoy our jobs more. If not, then maybe the job is just a job for many of us.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Cloud Snake Oil

    I’m sure that those of you reading this have a variety of opinions about the “cloud”. Actually, I’d guess that many of us have different definitions of what the cloud actually means. That’s fine, since it’s really an amorphous, marketing term that encompasses quite a bit of different technologies, services, and products from many different companies. Some of you might use the cloud, and if you do, then perhaps this will ring true to you.

    I was reading Dr. Greg Low’s blog, and he asked the question in a post about what a managed service was. In this case, Dr. Low was looking to host his blog on some service, and apparently the definition of a managed service varied from provider to provider. His first provider didn’t tell him that backups were being run, with each file being counted against the space that he’d contracted for. When he asked for them to be deleted, he was told it would take a day or two as there wasn’t anyone to provide the service.

    He continues looking at how other providers define service, which does vary, but the interesting thing to me is that many of these companies aren’t really providing management of systems. They’re selling you a product, which has some capabilities, but they aren’t really managing anything. At least, that is my impression. I know if someone asked me to manage a system, I’d expect to deliver some level of service that would be useful for the client.

    In the cloud, it’s really a wild west version of computing, where companies want to sell you some service, often touting various management aspects, but they may not necessarily provide the level of service you expect. Cloud vendors, even worse than other computing vendors I’ve dealt with, want to work at scale, and they want to standardize how things work as much as possible. They don’t want to engage in person to person communications if possible. I learned this lesson with Google and their products, few of which had any way for a user to contact a help desk.

    Apart from that, what I’ve seen too often in the cloud is that a company wants to offer some service or capability, but they don’t often have the tooling available for end users. This is especially true for new services, where it seems the purchase process works flawlessly, but the configuration or cancellation process doesn’t work, or might not even exist.

    The one piece of advice I’d pass on from my cloud experiences is that anyone using services needs to reconcile their bills regularly. We can add resources easily, but removing them is hard, and often a customer service person promising removal doesn’t follow through. I’ve had people in the support centers not even be sure of what resource I was referring to when requesting removal or credit. It’s a frustratrating experience that has led me to adopt another habit. I grow resources very slowly, ensuring that I know what the billing is and that I really need the service. That seems like the opposite of what the “cloud” is supposed to offer.

    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.