Voice of the DBA

Category: Editorial

  • What’s a Normal SQL Server?

    Many of us have worked in environments that have a number of SQL Server instances. Different versions, editions, and mostly different hardware profiles. We deal with different applications and software that places different demands and requirements on our database systems. Some of us are even dealing with multiple datastores, trying to integrate SQL Server with Oracle, PostgreSQL, Elasticsearch, Redis and more.

    Keeping an inventory of instances and patches can be a challenge. I hadn’t thought this was a big problem, but I’ve been surprised how many people like the Estate Management Versions page in SQL Monitor. This gets a lot of use, as people work to keep track of their systems. With that in mind, I wonder how many people have to support the “average” SQL Server that Brent Ozar supports. He runs the SQL ConstantCare® service for his customers, and regularly reports on average data every quarter.

    In his latest report, which contains data from over 3000 servers, we get a picture of what various organizations run for their instances. The version breakdown is what I expect, and I’m not surprised that 2016 is the most popular. This was a major release, with lots of changes. I think 2008 R2, 2014, 2017 were relatively minor releases. Few changes, and not good timing relative to other releases.

    The data shows most people have supported versions, and I think some of the licensing rules and breaks to lead many people to think about getting Software Assurance to upgrade once in awhile. I also think it makes sense that many people manage relatively small databases, well under 125GB. If you do the math, 47% of these instances are these relatively small sizes. However, it is interesting to see nearly 15% of his clients are > 1TB. That’s quite a spread.

    With data sizes like this, you see lots of smaller hardware sizes. I don’t know how this might compare with your organization, but it’s interesting to think about how you might fit into these averages. Is your organization doing a better or worse job of giving you resources for your data size? Keep in mind, there isn’t correlation here, so you don’t know if the 30GB database has 4 cores or 24 cores.

    I think having data like this is interesting. I do wish Microsoft would release more specific stats, like the version counts and database sizes, with hardware averages for those data sizes. I know why this doesn’t make sense for them to release the data, but I still wish they would let us know more. As Brent says, they tend to present on really recent technology, which many of us might not use. I’m sure many of you have a variety of instances, but you’ll easily be able to see if your spread of instances looks like Brent’s client base.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

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