Author: way0utwest

  • Reducing Cloud Cost

    Cloud costs are high and growing. Some orgs think they’re out of control and are trying to limit spend. Some orgs are looking to leave the cloud. A lot of IT spend over the years has been seen as a cost center, with many executives trying to limit the growth or spend, even while they aim for digital transformations of their businesses. Throughout my career, it’s been interesting seeing the tension of groups trying to take advantage of technology and the finance departments trying to manage costs.

    The cloud brings some of the same debates/arguments/concerns to the forefront. Partially because of scale, as we can add cloud resources much quicker than we can with a CapEx purchase. Partially because we’ve also often lost some control over budgeting with the move to OpEx and the subscription paradigm.

    However, the bigger problem is that we get a true chargeback for all the resources we use. This is done in a way that exceeds what I used to see with mainframes. In those days each department got a monthly report of their usage, applied against their budget. In the cloud world, finance gets a real bill they have to pay, and the chargeback is not a made-up number for internal use.

    How can you reduce the cost in the cloud for your database (or all data) resources? The easy answer to start is to get rid of those resources that aren’t being used. How many databases have been created for dev/test and aren’t actively used? That’s often an easy chore, and one that could be scripted. Though I’d want to include backups of anything I get rid of that might be reused. That might include dev systems rarely used. Keeping a backup that I can use to restore to a new resource later is always a good idea.

    In line with this, you might look for underutilized instances, especially for VMs or expensive services like Managed Instances. There can be a cost overhead for these systems, and if every application/department/etc. uses a separate system, there might be cost savings from consolidation. However, don’t just move databases. Ensure you aren’t creating a security risk or overloading the system with moves. That requires some analysis of the current systems and buy-in from those with security concerns.

    However, the biggest win in reducing cloud cost is to performance tune your code. This is something many DBAs request on a regular basis, but often there isn’t any push to write better code, or utilize better patterns of querying that might reduce the amount of CPU, memory, and network traffic. Learn how to write better performing queries, limit the data returned (no SELECT *), watching out for datatype conversions, and using other techniques that people write about at SQL Server Central every day. We constantly answer questions and publish articles on better ways to write code, so invest the time to ensure your teams can and do write better code. Make sure you train your staff and they use their training.

    Lastly, you are in the cloud because you’re willing to change how you work. Don’t be afraid of changing your existing code. If you refactor and break something, change it back. The cloud makes this easy, so take advantage of that and keep improving your code.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • A Small LLM Fail

    Another test with Copilot in SSMS (v22 P3) that didn’t go so well. This one surprised me.

    This is part of a series of experiments with AI systems.

    Looking for Known Data with Copilot

    One of the things I wanted to do recently was do some checkdb checking of a system. As a result, I was looking for the last time this was run on a database. I decided to ask Copilot.

    2025-10_0169

    This made perfect sense, as this was a new restore, and I hadn’t run it. So I asked for the query.

    2025-10_0170

    This doesn’t work, but I’ve gotten used to pasting in errors and letting the LLM sort this out. So I did this.

    2025-10_0177

    OK better, but this still doesn’t work.

    2025-10_0178

    I apply this and run it, and it works, but doesn’t return data. I wouldn’t expect this to for this database, so I try to clue in the AI.

    2025-10_0179

    Seems wrong. On this page, DatabasePropertyEX, I see this:

    2025-10_0180

    Not sure why this doesn’t work well. I don’t see a way to change the model, so I’m not sure what’s being used or when it was trained, but I’d expect it to know what is in DatabasePropertyEX().

    Prompt AI

    Prompt AI was a little better, though not at first. I asked the question:

    2025-10_0181

    I got this:

    2025-10_0183

    I can’t select this code (submitted a bug), but this isn’t bad. The result of my next query failed as well.

    2025-10_0184

    At least I had a clue what to do. I started then with this:

    2025-10_0185

    I got the “with TableResults” added. I then asked it to modify this to find the last time DBCC CHECKDB ran. I got this:

    2025-10_0187

    Summary

    To be fair I futzed with both of these a few times. An LLM isn’t deterministic, so I got different results, but I never got the correct result from Copilot. I did get this from PromptAI at one point, which does work.

    2025-10_0188

    GenAI’s are funny beasts. You definitely need to spend some time learning how to use them.

  • T-SQL Tuesday #191 Round Up

    I hosted this month, late as it turns out, but we still had a few entries. Here’s a look at the blogs people published.

    First as always, Rob Farley writes about the complexity of string parsing, using TVFs. He also shows some of the performance implications of complex parsing. Thanks to Rob for reminding me to get the invite out.

    Louis Davidson wrote about parsing HTML, which is definitely a challenge in T-SQL given the nature of the language and how embedded different tags can be. I’ve done this a little, and I prefer using Python to do this Winking smile

    Courtney Woolum writes about working with the IMDB database and needing to parse comma separated data with STRING_SPLIT and APPLY.

    Lucas Kartawidjaja brings us a look at a data outside SQL Server using the Log Parser, a free CLI tool from Microsoft that works well with data outside of SQL Server.

    Andy Brownsword tries out the new RegEx functions in SQL Server 2025.

    Hugo Kornelis hates intelligent keys because they store different types of data in the same column. He also shows some PARSENAME and CHARINDEX tricks.

  • DevOps is DevOps

    DevOps can mean a lot of things, but I find in practice that this results in a team using Continuous Integration and Continuous Deployment/Delivery using automation to check and evaluate your software in some way. This should result in quicker delivery of updates and changes to customers, better agility, and higher quality of code.

    That last one only comes if you use testing and try to ensure your code is well-written. It’s easy to just use DevOps to throw out more poorly written code that doesn’t perform well.

    Recently, I went to a presentation on Fabric CI/CD, looking to see if I could learn something about how you might handle Fabric in a DevOps software development flow. What I came away with was the idea that DevOps is really just DevOps. In this case, Azure DevOps was being used to orchestrate the CI/CD flow, and the pipeline looked the same way as one I had set up for a relational database.

    There are differences, such as the need to have multiple Fabric workspaces and a need to understand how the code is stored and managed in Git, but the idea is the same. We use a build step to verify that any code changes can be successfully compiled and that those changes can be deployed to a new location. A workspace instead of a database, which means the automation doing the work is slightly different, but the process is the same.

    Testing? You want tests to verify that the code does what is expected. A lot of people skip testing with data, but I’d argue it’s as important in Power BI or SQL Server as it is in C#. We ought to include tests, not because we don’t know how to write code, but because others might maintain/extend/refactor our code, and we want their changes to pass our tests. Again, the details are different, but including a step to run tests is still there. The same idea.

    Using a flow to approve and deploy changes between environments? This is no different, and having an automated process reduces the effort, time, and risk of mistakes. This is again the same, though the details are different specifics because the automation is different. Deploying a semantic model is different than pushing out a new .exe or running database changes, but the idea of an automated deployment is the same.

    We, as an industry, have learned over time how to better move code through a software development life cycle. The ideas work for data-based projects as well, and we ought to be learning and adapting these to ensure we can be just as agile as application software developers.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.