Voice of the DBA

Category: Editorial

  • What Do We Want to See in SQL Server?

    I like the feedback system that Microsoft built for SQL Server. This used to be the Connect system, but all the bug reports and feature requests are now at feedback.azure.com. That’s the place where you can send notes to Microsoft or vote on those that others have submitted.

    In case you are wondering if this makes a difference, it does. Years ago, there pushback for Service Packs from Microsoft, and after a lot of lobbying from myself and others, and a number of votes, Microsoft released more Service Packs for a few versions. They’ve also made a few other changes in the product, or fixed bugs when enough people vote. Not always, but it does happen at times.

    When this system was first released, I wondered if Microsoft would email a digest or some list of items that they had triaged of how the various items were rated. I could see this as a way customers might learn what others think is important, as well as what Microsoft sees as feasible. Maybe where would be some repeat voting that could influence the products’ direction.

    Recently I saw Brent Ozar posted the top 10 items by votes with a few comments. Of the items on this list, I found some interesting ones. I know STRING_SPLIT gets an ordinal in Azure and SQL Server 2022, so that’s one item that MS responded to. I see a few SSMS ones, which are always interesting to me. I’d hope that MS would include a dark theme and the (maybe) the debugger back in as many people request those features. I’m not sold on the debugger, and it wasn’t always stable for me, so I wouldn’t use it, but lots of people like the idea of a debugger. Maybe if it were limited to the dev edition?

    Microsoft looks at the feedback, but the feedback isn’t a vote in their mind. It’s a metric that helps them triage and decides when things are important enough to work on, assuming the effort isn’t extremely high. Working in a software company gives me a better appreciation for the decisions made on which features to include or not, especially given the long-term support effort for any features.

    It can feel hopeless when you vote for something and Microsoft doesn’t build it, but when enough people, especially big customers, want something, it gets built. If you look through the top items, a few have been added to SQL Server 2022. Personally, I want a FOR CSV along with a BULK EXPORT command. I appreciate some difficulties here and possible permission/security issues, but this would be very handy.

    What changes do you want today? Is the dark theme or the debugger at the top of your list or is there something else?

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Digging into an AI Algorithm

    One of the more successful uses of AI (artificial intelligence) has been in the medical field. It seems that there is a tremendous amount of data, high variability in some aspects of the target of the data (the patient), and a need to constantly review very tedious volumes of data. A place where AI might, and has, made a difference to help humans, not replace them.

    There’s a neat article that dives into a bit of how a medical algorithm works for detecting sepsis. As you scroll, the article tries to explain in layman’s terms what the AI system(s) are doing. It goes through the necessity of regular data, which I think is a good design to push humans to gather data. It then talks about a variety of neural networks being used to analyze data, based on previous training from humans and past results.

    It’s interesting to think of multiple nodes coming to their own conclusions are different times of the day and then later nodes looking at the results of previous nodes. That’s what a human would often do, looking back at recent history and giving that some weight. The system comes up with a number that a human can use to consider in their diagnosis.

    It is interesting that the article talks about the need for humans to better communicate to use this system. I think that’s often a key with any computer assistance. The humans still need to use the computer as a tool and not as the final decision maker. However, at least in this instance, the tool seems to be helping reduce deaths in the hospital. I would hope that this is because the algorithm is detecting some patterns that are easy for a doctor to miss. It could be because the new system is focusing people’s attention better, and possibly this is a combination of both of these possibilities.

    I do think that AI systems can be very helpful in assisting humans in many tasks, and medicine might be one of the places where AI will be most useful. The sheer volumes of data, the complexity of the cases, and the load placed on medical workers to monitor many people can overwhelm any one doctor or nurse. Having a system that might remind them of a small detail will hopefully save lives.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • How Often Do You Update During Issues?

    I use Libsyn to store podcast files. They’ve been a reliable service for me for years. Once in awhile uploads are slow, but things seem to work. The other day I went to upload a file and got a status message that there was an issue with database maintenance. When I looked at the status page, I saw a few updates. This was for a platform issue, and I saw this set of updates. I have the timing that I saw on the page with my own comments added:

    • 1139 – reports of issues. We’re looking into this
    • Three hours ago – Identified the issue related to db maintenance, working on it, other services affected.
    • Three hours ago – all services affected, working, update soon
    • Three hours ago – emergency maintenance on db systems, we will provide regular updates
    • One hour ago – db maintenance in progress, now healthy nodes, turning things on.

    That was what I saw at around 3:30 my time. I went back the next day and saw a more detailed set of times listed and a note that the cluster was fixed and then all services were restored. While I couldn’t upload things that day, I did check that downloads for listeners were working, and they were at that time.

    I have no idea what happened, and I did appreciate an email the next day that apologized and noted this outage was not the result of malicious attacks and that no data breach had taken place. The latter item hadn’t occurred to me, but I thought that was a good reassurance sentence in the email. I’m sure it was a rough day for DBAs and the Ops staff, and hopefully, they were able to restore all data.

    My concern, however, was that multiple times they noted they would post updates soon, but there were some pretty good gaps in the status messages. While I liked a few quick messages together (3 in 30 minutes), the long gaps are disconcerting to me as a customer. I expect management would feel the same way and hopefully, management was updated more often.

    If you’ve been in an outage, sometimes there isn’t a change in status. A long restore or rebuild of some sort can take time, with platforms not always reporting progress or an estimate of time remaining. Even when you get some progress, we all know that the time to go from 25% to 50% could be shorter than the time to go from 90% to 95%.

    When I have had to report to management, or to an incident team, usually we have regular updates. Even if these are “no change, we’re still working,” it’s good to let others know what you know. I think that’s important for customers as well, especially those that might have time-sensitive expectations for using your application. Without an update, anyone checking a status might not know if anything has changed, if things are worse, or maybe that you forgot to post an update.

    My recommendation is that there is someone dedicated to logging what is happening and taking notes for later review. This person is also someone that ought to be responsible for updating others on a regular basis. Every hour, every two hours, something regular. If you have external customers, then they should expect and get regular updates, even if these are “no change, the cluster is still rebuilding.”

    A little transparency goes a long way for your customers.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • GitHub vs. Azure DevOps

    I work often with Azure DevOps. I have enjoyed the platform and it does what I need. I also work regularly with GitHub and GitHub Actions. Those rebuild SQL Saturday and SQL Memorial when I need to make changes. It also works very well.

    This week I saw a post on choosing between Azure DevOps and GitHub, which is something I get asked at times. The post goes into some of the differences and provides a lot of links that you can use to read about features. There also are plenty of links on using the two products together, which is something I see regularly. Code in GitHub and the build/test/release in Azure DevOps.

    On the question of which one, the author doesn’t give a recommendation, but rather some questions on things you might think about. The author asks about the features you use or think you will need and using that information to help guide your decision. I think that’s fair, but here’s what I’d say.

    If you have no automated version control or build/test/release tool in your organization, then choose Azure DevOps. It has a lot built in that I like and it’s simple to use. I think it’s visually pleasing and I think it is easier to teach people how to use it for this reason. GitHub is fine, but I find it slightly more confusing to move around in, though to be clear, I spend more time in Azure DevOps, so I’m likely biased.

    I’ll also separate out version control. I assume your organization has someone using version control. Whatever system they use is the one to adopt. There’s no reason to argue or get them to change. Most people use Git and all Git host services are essentially the same. We could argue some small thing you want, but really Git is Git. Use what others use.

    I would say the same thing for build, test, and release. Use what software developers use. These systems are all good, and they all have pros and cons. They all do some things well and have some disadvantages, but they are really interchangeable. I wouldn’t move build systems or release systems without a really good set of reasons to do so. Just because the new lead or CTO likes another system or has experience there isn’t a good reason. If you don’t have any system in your organization, then see my recommendation above.

    Modern software development needs a team, and for teams to work well and efficiently, you need version control and an automated build/release system. Use what others use, or have some people conduct a few pilots and then take vote and go with the results. Really, all these systems are similar enough that it’s not worth more than a few minutes of discussion.

    Steve Jones