Voice of the DBA

Category: Editorial

  • Double Half and Quarter

    I’ve worked in a a couple very high performing organizations that adapted to changing conditions and built software well. I’ve worked in more poorly performing organizations that struggled to release updates and patches, causing tremendous stress for the IT staff.  DevOps is designed to help improve our software delivery and quality, if you work on improvement in many areas.

    I saw a post on LinkedIn, from the Chief Architect at HSBC bank. This was interesting to me because I see HSBC ads constantly when I travel to the UK. They’re the 7th largest bank in the world and was founded in 1865. If ever there was an organization with lots of legacy everything, this is it. They have every reason to do what they’ve been doing for years, since it’s worked out well.

    The post notes that Jez Humble, well known DevOps author and co-founder of DORA, came to talk to them about software delivery and DevOps. For the author, the highlight of the day was the CIO giving this challenge: “… setting every team the goal to double, half and quarter every year: double the frequency of releases, half the number of low impact incidents, and quarter the number of high impact incidents.”

    That’s an ambitious goal, and as the post notes, this results in exponential improvement year over year if the team can achieve this. I think there is likely some limit to this, based on team size and application complexity, but certainly when you’re going from a mid range performing software development group, this isn’t bad.

    I like that this goal was set not just to increase deployments, but to also prevent incidents. I think too many managers look at speed as the goal, without requiring quality to improve. This goal doesn’t quite address this, unless the impact incidents include bugs and poor performing software. It can be easy to limit incidents to downtime from deployments, and not necessarily the use of software.

    The hands off management of this approach is good as well. Not specifying how this gets done. Leave it to the technologists to get this done and hold each other accountable. With that kind of support from management, I’d hope most professionals would step up, improve process and quality, and take pride in their work. It seems to have worked as HSBC, as they’ve been written up a few times in their DevOps approach to IT. I think it can work anywhere with the right management approach.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Social Impact of Data

    Let the data drive your decisions.

    This has been something of a mantra for many technical people, and even many business people, across the last twenty or so years. The allure of business intelligence is harnessing lots of data to make decisions that are rooted in some rational analysis of what has happened. Many companies use “data driven decisions” as a way of achieving success.

    However, what about when the data is flawed? When deliberate or inadvertent actions give us data that isn’t quite as pure as we expect. In the last week we have seen many protests and complaints about the ways that many people feel they have been unfairly treated by police. That brutality, particularly for African Americans in the US, has been a problem for decades. Some of that is due to human biases, beliefs, and more. However technology plays a part, and will for some time to come.

    I have watched as algorithms have been used in sentencing, and I’ve questioned their use, as have others. There is this idea that computers will be more fair, looking at inputs and making a decision that isn’t encumbered by human biases. The problem is that humans that program the systems might have some bias. Maybe more disconcerting is that the data used to train systems is likely biased as well.

    There is also the concern that as technology advances, it can be put to new uses, perhaps in ways that the inventor regrets. Oppenheimer regretted the violent use of his work, and I wonder if technology inventors will feel the same way. Surveillance technology is controversial. It can help retails companies prevent theft, but it can also be used in ways that might enhance and reinforce bias in police work. This can be controversial, and no matter how you may feel about the technology, there are moral questions of privacy and prejudgment that are worth debating.

    The last couple weeks have saddened, upset, and angered me at different times. I am also confused and concerned, unsure of how to discuss and debate these topics. I find my position moving slightly with different stories and different information, as I should. I learn more and my views grow and change, shaped by what touches me. I do worry about how we use data in the future, and how it can be abused. There are ways in which more data can help improve our world, but the potential for abuse is high, and I do believe we need governance, transparency, and an independent appeal process for those wrongly impacted.

    Steve Jones

     

  • Do You Think About CheckDB?

    Many of you are administrators, maybe accidental ones, but you have some responsibility for ensuring your databases run smoothly. Part of ensuring this happens is monitoring resource usage, configuring security, and patching your system. However, the long term health of your database requires some proactive work to ensure things continue to run smoothly. One way of doing this is using checkdb to assess the health of your database’s internal structure.

    Those of us that are full time focused DBAs likely run checkdb, though potentially not in the best way. There are implications to “offloading” this work to another machine. Those that are accidental DBAs, developers, or someone else with other duties might not think about checkdb as necessary.

    Do you think about how you should run checkdb? Do you think about licensing issues? Do you think about the frequency and breadth of where you should run checkdb? I’m wondering what some of you do after I ran across a post from Brent Ozar on offloading this work. If you haven’t dug into how checkdb works, you might not realize some of the things that Brent brings up. Even if you think you know how this works, read the post.

    I’ve usually been able to run checkdb in production, but I recognize that more and more environments can’t do that. Usually because of the resource contention. When I’ve had that issue, I’ve accepted a time lag to getting results. I don’t worry about finding out about database corruption a day later. I can probably deal with that. I worry about finding out a month later, when reconstructing data is much, much harder.

    This isn’t to imply or recommend that you need to run checkdb on each production instance, but rather to get you to think about how checkdb works and choose a strategy that works well for your environment. Even if you have this set up, ensure your configuration still makes sense for your organization. Take a few minutes and read the post and then schedule a review with colleagues of your checkdb philosophy.

    Steve Jones
    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Licensing Audit Advice

    I’ve never been through  a licensing audit at work, but I have been worried about them a few times in my career. A few bosses have warned me about them possibly coming. While I’ve tried to ensure that the organizations I worked for were compliant, I’ve always worried about losing track, making a mistake, or mis-interpreting the EULA rules. Those EULA rules and licensing guidelines are not written for most people to understand, and the verbiage is ambiguous at times.

    I saw an article containing advice on going through a licensing audit that caught my eye. This was for an Oracle audit, but I suspect the advice would be similar if this were for SQL Server or any other product. Since an audit is a legal proceeding, it’s worth treating any licensing audit as you would a legal matter.

    I am not a lawyer, and don’t take this to be advice or a recommendation. These are just my thoughts. For me, I would try to go slow with everything. Not to delay, but to be careful and sure of what I was doing. I would concentrate and read all documents carefully, being sure that I know what they mean, asking for clarification if there is any doubt, and ensuring my organization’s legal representative was available for questions.

    I’d especially be careful about only answering questions and not being overly talkative and volunteering information. I’ve seen plenty of people get into trouble because they talk more than necessary. That might be good advice for life in general: listen more; talk less.

    SQL Server, unlike many products, can be tricky because no license key is really checked. I’ve seen scripting and manual processes use the same product key for ever installation. There’s nothing fundamentally wrong with this, but it does mean that someone is still responsible for ensuring that licenses are being tracked against installations and upgrades.

    While I have no desire to deal with licensing, I know that if I act as a DBA in any way, it’s likely part of my job. I would (and have) tried to get someone in an Accounting role to keep track of purchases and usage of licensing, updating them whenever I install or decommission an instance. At least then we have more than one person tracking the data and potentially another person that might be in charge of handling the audit ;).

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.