A Fine Slice Of SQL Server
Sebastiao Pereira performs an analysis:
Regression analysis is a statistical technique to identify relationships between a dependent variable (outcome) and one or more independent variables (features). Is it possible to do this in SQL Server without using any external tools?
Read on for the answer. I’d file this under “neat but probably not something I’d want to rely upon.”
Comments closedInteresting news dropped – Microsoft announced that Azure Data Studio is going to be retired in 2026. You can read the official announcement here. In some ways, I have to admit that I was a little surprised to see this.
I’ve been a very regular user of Azure Data Studio over the past several years, especially because it was the option for Linux. I believe the most likely reason they’re deprecating the product is because there’s a lot of effort in keeping up with Visual Studio Code’s changes and forking that code base every month for Azure Data Studio.
My concern is that the mssql extension for Visual Studio Code is nowhere near ready for prime time, and I wonder if it will be sufficiently capable by the time Azure Data Studio is gone for good.
1 CommentAlexis Tekin and Jeremy Ber handle an error:
Data streaming applications continuously process incoming data, much like a never-ending query against a database. Unlike traditional database queries where you request data one time and receive a single response, streaming data applications constantly receive new data in real time. This introduces some complexity, particularly around error handling. This post discusses the strategies for handling errors in Apache Flink applications. However, the general principles discussed here apply to stream processing applications at large.
Read on to see how this all works when you’re hosting a Flink application. This directly relates to Flink applications that live in AWS, though very little in the article is AWS-specific.
Comments closedSteve Stedman handles an error:
SQL Server uses error severity levels to indicate the nature and seriousness of an error. These severity levels range from 0 to 25, with each level indicating a different type of issue, from informational messages to catastrophic failures. In this post, we’ll focus on severity levels 19 through 25, which are typically the most critical errors that can occur in SQL Server.
Fortunately, given how devastating they are, severity level 21 and higher are extremely rare in my experience.
Comments closedJoey D’Antoni shares some thoughts on error messages:
I’ve been working in technology for entirely too long—but one of the first, and most important lessons I learned was try to identify the correct error message, in the right log file, and then it can be generally trivial to resolve that error message. The challenge to forever and ever always has been “finding the right error message”, as what typically happens is that once there is one failure in a computer program, there is a series of cascading errors, which makes it harder to identify the right error message that you need to copy and paste into google/stack overflow/chatgpt/copilot.
Read on for more. I think it’s easy for us to rag on bad error messages, though even opaque error codes can still be reasonable if there’s a comprehensive guide. This was a classic problem with blue screens: oh, I have an error code 0x2378f83f. So what does 0x2378f83f mean? Dunno, nobody else on the internet has apparently ever had that code. And Joey also brings up my favorite error message to rag on: “String or binary data would be truncated.” Sadly, although they did finally add column name and message text to the error, they never fixed the most galling mistake in that error message: the passive voice.
Comments closedDennes Torres checks some stats:
We already discovered how to investigate Kusto query history. Let’s discover how to analyse query performance considering the information on this history.
The query history returns 3 fields we can use to make a more detailed analysis of the queries: CachedStatistics, ScannedExtentsStatistics and ResultsetStatistics.
Disclaimer: There are low to no documentation about this content. In this way, the content below may not be 100% precise but will give you good guidance.
Click through to learn more about these three.
Comments closedAndrew Pruski builds a diagram:
The other day I came across an interesting repo on github, KubeDiagrams.
What this repo does is generate Kubernetes architecture diagrams from Kubernetes manifest files…nice!
Deploying applications to Kubernetes can get complicated fast…especially with stateful applications such as SQL Server.
So having the ability to easily generate diagrams is really helpful…because we all should be documenting everything, right?
Click through for instructions and a couple of gotchas Andrew ran into along the way.
Comments closedYvonne Vanslageren builds a high availability solution for containerized SQL Server instances:
For enterprise SQL Server DBAs, high availability is essential for maintaining seamless database operations—particularly in scenarios involving Change Data Capture (CDC) or other mission-critical functionalities. Docker containers can streamline the setup and management of development or testing environments for Always On Availability Groups (AOAG). By bundling configuration files, scripts, and dependencies into containers, teams gain a reproducible, portable, and efficient deployment mechanism.
This guide explains how to build an Always On environment inside Docker containers using Docker Desktop, Docker Compose, and a series of setup scripts. It walks through the creation of two containers (primary and secondary) configured in a clusterless Always On Availability Group scenario.
Click through for the process.
Comments closedThis post demos a script I put together to help move SQL Server database files to another drive and folder by generating PowerShell and T-SQL commands.
I’ve decided to make this script for situations where installing the dbatools PowerShell module wouldn’t be possible.
Otherwise, I highly recommend using dbatools’ Move-DbaDbFile command.
Click through for the script, and I second Vlad’s recommendation of dbatools for this kind of effort.
Comments closedBecause it doesn’t require a common cluster, a distributed availability group allows us to link servers in situations were a cluster isn’t possible. Servers could be in remote locations, members or different domains, different OS levels or even different operating systems (yes, we can link Windows and Linux based AGs).
The ability to link servers in this way gives us a very nice and easy way to replicate data between servers when thinking about a migration.
David’s scenario involves a SQL Server upgrade. I’ve seen this work really well in practice for a 2017 to 2019 upgrade. With applications pointing to the listener agent and everything in place, you can have as little as a few seconds of downtime for that upgrade, which is amazing when you think about how we’ve historically migrated to new versions of SQL Server.
Comments closed