Press "Enter" to skip to content

Day: February 21, 2025

Failover Groups in Azure SQL Database

Published 2025-02-21 by Kevin Feasel

Mika Sutinen looks at some interesting functionality:

One of the interesting features in Azure SQL Database is the Failover Groups. It allows you to manage replication of an Azure SQL database, or group of databases, to another logical server. The reason I’ve bolded the manage replication is, that the replication itself is handled by active geo-replication, which is also a feature of Azure SQL Database.

Read on to see how these are different and why you might want to use failover groups.

Leave a Comment

Error Code 0x851A0043 on SQL Server 2022 Updates

Published 2025-02-21 by Kevin Feasel

Ben Johnston runs into an error:

I’ve been working in the Azure space for the last few years and less with full server installations. Azure leaves file locations out of my control, but I recently had a client upgrading an on-prem server to SQL 2022.It was a fresh installation on a new VM. I installed SQL, restored all the data, then I moved files to their optimal locations. This was a fresh installation of SQL Server and I wanted to move all of the data files, log files and tempdb files to their own drives. I also wanted to move the system databases. The documentation cautions that cumulative updates (CU) could fail if a specific registry key isn’t updated after moving the master files, so I wanted to test this before I spent too much time configuring the server.

An excerpt of that warning follows here.

Click through for the warning, as well as how to fix the problem.

Leave a Comment

Concerns with Azure Data Studio’s Deprecation

Published 2025-02-21 by Kevin Feasel

Thom Andrews raises a valid concern:

Some of you may, or may not know, Microsoft announced the deprecation of the Azure Data Studio (ADS) on 06 February, with support ending next year on 28 February. For those of using ADS Microsoft recommends migrating to VSCode and using the mssql extension.

Honestly, I’m really concerned about this. I tried the mssql extension for VSCode (mssql going forwards) some time ago, and compared to ADS it was incredibly feature lacking. A lot of stuff I want to do as a DBA was completely missing, so I went straight back to ADS and didn’t look back. I like ADS, and I’ve got good use out of it; especially as (as those who know me well) a Linux user at home, where I can’t use SSMS.

Anyway, I thought “Ok, I’ll give mssql another go, maybe it’s come a long way since I tried last”. Oh boy has it not; at least for someone like myself.

The upshot of Thom’s post is that the mssql extension is definitely not ready for prime time, and there’s going to be an uphill slog to get it, within one year, back to where Azure Data Studio is today. My hope on this is that, because the mssql extension team (who may be the same people as the Azure Data Studio team) doesn’t need to continuously fork and work around changes to Visual Studio Code, that it will allow them to re-use and re-implement relevant code quicker than otherwise. But if not, that’s a tough story to tell.

Leave a Comment

Dynamic Retrieval of Microsoft Fabric Item IDs

Published 2025-02-21 by Kevin Feasel

Paul Andrew takes a peek:

When building dynamic pipelines and other artifacts in Microsoft Fabric we are currently forced to reference everything using the underlying item IDs, rather than the more useful names (display names).

In the UI, setting a item value is fine when selecting items from the respective drop down lists. But they will of course be static and can’t be changed at runtime. However, as soon as an expression is required (which in the real world, always is) those UI labels change to be the ID values. AKA the item GUIDs in the context of the workspace and wider solution.

Paul has an answer, though it’s not pretty.

Leave a Comment

A List of PostgreSQL Parameters

Published 2025-02-21 by Kevin Feasel

Semab Tariq has a list:

Have you ever experienced your database slowing down as the amount of data increases? If so, one important factor to consider is tuning PostgreSQL parameters to match your specific workload and requirements. 

PostgreSQL has many parameters because it is designed to be highly flexible and customizable to meet a wide range of use cases and workloads. Each parameter allows you to fine-tune different aspects of the database, such as memory management, query optimization, connection handling, and more. This flexibility helps database administrators to optimize performance based on hardware resources, workload requirements, and specific business needs.

In this blog, I will cover some of the important PostgreSQL parameters, explain their role, and provide recommended values to help you fine-tune your database for better performance and scalability. 

Click through for those parameters, including descriptions, default values, and recommendations.

Leave a Comment