Voice of the DBA

Author: way0utwest

  • Learning Goals–April Update

    Here is the update: I did better.

    Extended Events

    I did a little more multi-tasking this month, ensuring that if I rode the stationary bike for exercise, I had my tablet and watched some Pluralsight or read some content.

    Here I learned a few things:

    Predicates

    These short circuit, and this means that we want to write our predicates to end early if possible. We also want to write our predicates to look at local data before global data so that we can stop event code as early as possible.

    There is also a 3000 byte limit, so be careful with structuring the event predicate statement.

    I also found that u_tables.sql lets me rebuilt the default sessions for an instance. It’s in the install folder. That’s handy as there are times that I’ve removed the default sessions or changed them and I’d like to get back to the beginning.

    Event Sessions

    The structure for event sessions is like DDL for other objects. These are always created with events, but we can remove all events. I’m not sure why you want the placeholder, but it’s an interesting anomaly. I suspect that this is a hole in the DDL parser.

    I also learned you can drop sessions without stopping them. Convenient? Sure. However, this means that I could make a mistake and not get a question about dropping a session that I, or someone else, is using.

    Changing event or target configuration means dropping and adding back the item. That’s good to know. No way to alter an event predicate.

    Python

    I made it a point to do some coding every week, and work on Python. I did some fundamentals, ensuring I understood how modules work and are imported. I spent some time on variables and mutable/immutable items. I wanted to be sure I understood how these worked compared to other variables. It’s good to know that some of the assignments don’t create a new variable, but merely set a pointed to the existing item.

    I set up a Jupyter notebook in Azure, which was interesting. I need to use this more, and perhaps do some coding here on the Advent of Code or other projects. I solved a couple more days of puzzles, which was fun. These are challenging, and it took a little time to work through items.

    I didn’t do this every week, as I had some travel this month, but I did make an effort to work in python a bit more.

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