Voice of the DBA

Category: Editorial

  • A Day in the Life of an Advocate

    I have one of the best jobs in the world. I get to work from home, travel to lots of events, set much of my own schedule, and I work for an amazing, supportive company. I’m incredibly proud of the way Redgate Software has handled this pandemic crisis. From strong leadership, a commitment to employees, the Community Circle, and the very strong work by our Core services team to ensure technology has helped us continue to operate as a business.

    We maintain an internal company blog where lots of information is shared by individuals and groups. Each week we compile a list of important posts that are sent to all employees on Friday. It’s a way to understand different things that are happening inside the company, since many of us are focused on our own jobs and might not know what others are doing. Recently, I was asked to write a post for the blog on a day in the life of an Advocate. I was happy to tackle it, but included Kathi, Kendra, and Grant as well, since we all share that title, but have very different jobs.

    What do we do? For the most part, we do what the title says: we advocate. We advocate among the public for Redgate, and, as Microsoft Data Platform MVPs, we advocate for people to use the Microsoft data platform. At the same time, we advocate for customer needs inside of Redgate, liaising with developers and others to influence what and how they build software. We advocate at Microsoft on behalf of all the customers that want new features and struggle with existing ones.

    For all of us, this might be through meetings, presentations, written content, emails, and more. In some sense, we are communicators that move information and knowledge around. All of us have done that throughout our careers, and it’s what many of you do as well. In fact, I think some of the most successful technical professionals I know are great communicators. They many have great technical skills, but they also have the ability to communicate well with others.

    I saw a famous software developer once recommend that anyone really wanting to be a developer ought to major in a subject like English (or your language of choice) to learn how to analyze writing and communicate your thoughts back to others. Certainly you need technical skills, but most of us really need to learn how to work well with others. A soft skill, but a vitally important one.

    That’s most of my day as an advocate. Communicating. Hopefully many of you find that I do it well and have learned something, been inspired, or even entertained by my work. I look forward to continuing it for many years.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Methodical Testing

    Performance tuning is a challenge for many data professionals. Often, it’s also a task that we struggle to find time to perform in many environments. Developers have new features to build and DBAs have plenty of other work. As a result, performance testing is usually done in a crisis.

    Netflix is always looking at performance, since their customers and audience are very sensitive to delays. They wrote a post on examining the performance of a potential technology change, which was a good look at different ways they test the effects of something new. In his case, they talk about the changes they were considering for networking stack. There is some technical discussion of why, but the interesting part of the piece, for me, was the A/B testing section.

    They planned an experiment, conducted it, and then measured the results. This wasn’t just a test for a developer workstation, which I’ve seen most people do. This was a test with half a million users. Netflix has over 150mm users, so this isn’t a significant number, but it’s also not a tiny number. It’s enough to look for potential issues, though I’d hope they’d expand this to a 2-5% of users to verify their results before they deploy to everyone.

    Too often I see developers assuming a test on their workstation of a very small set of data determines if their approach makes sense. I do believe that is a good place to start, but before getting too far along deploying your changes, some significant scale test ought to occur, with repeatable measurements. If you want to ensure your auditing trigger or update code or anything else that might impact lots of users will cause issues, test on a larger set of data. Then repeat the test and verify that your results make sense.

    Testing is a skill. A bit of an art, but very much a science. You should make sure you use test harnesses that are large once you think your code works, just to be sure it does. If you want ideas on how, Jeff Moden and Dwain Camps have a few articles that might help.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Remote Data Challenges

    With many of us working remotely now, security is going to be a concern for many organizations. While some might have company provided hardware, many of us will use our personal equipment to connect to data and systems. This brings even more challenges to ensuring security than we’ve had in the past. This might be especially true for organizations that have (or are) scrambling to get everyone connected and ensure access.

    There are a number of areas in which this might affect us as data professionals. First, we should ensure our devices are patched. Windows, OSX, Android, iOS, whatever platform you run, you ought to be properly patched. This might be especially disconcerting for some home users that run older versions of host platforms. This might be especially true for networking stacks, which have grown more secure over time. It is important for most of us, especially when using privileged accounts, to have fully patched devices.

    There’s also the issue of viruses, ransomware, and more transiting from home systems to work platforms. I know some companies are doing lots of work through remote access, but that’s not practical for many of us. I do think the idea of separating out traffic to production systems is a good one, and requiring some sort of remote terminal to a jump box might be preferred. Having some sort of PAW is a good idea as well, though not always easy to set up, especially right now.

    There are still the actual access rights and least privilege principles we want to maintain. Even as people struggle to get work done remotely, opening up all resources to users that want them can be a poor choice in many companies. We want to maintain adherence to good practices while working in an unfamiliar environment.

    There is also the idea of good data protection. This piece talks about DR and data protection, something that many of us data professionals think about regularly. I don’t know if organizations want to add home machines as remote backup targets, but we should certainly ensure that documents, code, and other information is protected. Workstations and laptops are going to fail, as we want to minimize data loss. Having version control for developers and default save locations that are remote are good practices for remote work. I know I keep most of my data in remote git repos, Dropbox or OneNote drives, or some other shared location that will persist if my hardware has issues.

    While many of us try to keep moving forward at work, and our management certainly wants us to do so, we should keep in mind the security and data protection are still important parts of our jobs.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Choosing Sequences Over Identity

    When I was building software as a full time job, the choices for automatically generating surrogate keys were the identity property and the NEWID() function. At that time, GUIDs were too cumbersome to deal with, and I often used identity values in tables. I looked for natural keys, but often these were secondary keys for me and I preferred to use numerical values in many tables as PKs and FKs.

    In the last few years I’ve run into a few customers that prefer sequences, which are a separate object in your SQL Server database. There are some challenges with sharded systems and using deployment technologies like SQL Compare, which is one reason I’ve avoided them. However, I was reading Dr. Greg Low’s blog recently where he noted that he prefers sequences to identities. He gives a good comparison of the reasons why sequences can be easier to manipulate, with some advantages because these are a separate object. I think he makes a good case why we might always want to consider sequences over identity values in new development.

    He’s convinced me, though now I need to learn a new habit and build new skills to quickly and easily develop sequences for table keys instead of relying on identity values. This is a big change for me, with nearly 30 years of writing identity properties in CREATE TABLE statements.

    Learning to adopt new techniques and changing habits of the ways that we grow and change, and certainly how we build better software. That’s a tenet of DevOps. Experiment and learn. This is a place where I’ll start to grow and see what I think as I build demos and PoCs for customers, giving sequences a chance. I wonder how many of you might rethink using identities in the future as well.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.