Press "Enter" to skip to content

Category: Administration

An Overview of pgNow

Published 2026-03-18 by Kevin Feasel

Hamza Sajawal looks at a Redgate product:

pgNow is a lightweight PostgreSQL diagnostic tool developed by Redgate that provides quick visibility into database performance without requiring agents or complex setup. It connects directly to a PostgreSQL instance and delivers real-time insights into query workloads, active sessions, index usage, configuration health, and vacuum activity, helping DBAs quickly identify performance bottlenecks. Because it runs as a simple desktop application, pgNow is particularly useful for quick troubleshooting and point-in-time diagnostics when a full monitoring platform is not available. 

The tool is currently free to use, and its development is actively maintained by Redgate, with potential future enhancements expected as the project evolves. It analyzes workload behavior using PostgreSQL system views and extensions such as pg_stat_activity and pg_stat_statements.

Click through for setup instructions and an overview of what it currently can do.

Leave a Comment

Dealing with Multiple Fabric Capacities

Published 2026-03-17 by Kevin Feasel

Jon Lunn provides some guidance:

You know you can have more that one capacity? Most of the clients I’ve interacted with, even since the Power BI capacity days, they have just purchased one big old capacity, and assigned it to every workspace they needed. There have been a few clients that have had multi-region capacities, spun up across the globe for thing likes, billing to specific cost centres and regions and data ownership and sovereignty issues, but for those that don’t have those issue, they just get a big capacity.

Jon provides some guidance on environment-based capacity planning. Even within an environment, there may be cases for carving out explicit capacity, such as data science activities that are occasional but potentially disruptive.

Leave a Comment

Major Security Update for SQL Server

Published 2026-03-12 by Kevin Feasel

Rebecca Lewis digs into an important patch:

Yesterday was Patch Tuesday, and this month we’ve got a good one. CVE-2026-21262 was already publicly disclosed before Microsoft shipped the fix – and it lets an authenticated SQL Server user escalate straight to sysadmin. SQL Server 2016 through 2025, Windows and Linux. No physical access required. No user interaction required. Just a valid login and a network path to your instance. Go patch!

If you’re a SQL Server DBA or consultant and you’re reading this before patching, stop reading and go patch.

Read on for more information about the vulnerability and how to make sure you’re on the latest CU or GDR for SQL Server.

Also, the fact that there are fixes going back to 2016 doesn’t mean that 2014 and earlier are fine. It just means that Microsoft is serious about not patching versions 10+ years out of date.

Leave a Comment

The Transaction Log as a Circle

Published 2026-03-10 by Kevin Feasel

Paul Randal explains to the officer that the transaction log is a flat circle:

In the second part of this series, I described the structural hierarchy of the transaction log. As this post is chiefly concerned with the Virtual Log Files (VLFs) I described, I recommend you read the second part before continuing.

When all is well, the transaction log will endlessly loop, reusing the existing VLFs. This behavior is what I call the circular nature of the log. Sometimes, however, something will happen to prevent this, and the transaction log grows and grows, adding more and more VLFs. In this post, I’ll explain how all this works, or sometimes doesn’t.

Read on for a depiction of the transaction log and what can cause it to foul up.

Leave a Comment

What’s New for tempdb in SQL Server 2025

Published 2026-03-10 by Kevin Feasel

Johan Deardurff lists the updates:

TempDB has consistently been regarded as one of the most essential and, historically, overlooked components within SQL Server. When TempDB goes wrong, it rarely fails quietly. A single runaway query, poorly designed report, or unexpected workload spike can consume TempDB space and bring an entire instance to its knees.

With SQL Server 2025, Microsoft has made meaningful investments to change that story. TempDB is no longer just something you monitor and hope behaves; it’s now something you can govern, recover quickly from, and observe with far greater clarity.

Click through for a breakdown of how Microsoft has tackled some classic tempdb problems in SQL Server 2025.

Leave a Comment

Avoid Hard-Coding Linked Server Names

Published 2026-03-09 by Kevin Feasel

Greg Low provides some good advice:

I’m not a great fan of linked servers in SQL Server but they are often necessary. If I’m working with the latest version of SQL Server, I really prefer to use External Data Sources and External Tables. But not everyone is on the latest version. In the meantime, what I see all the time, is people hardcoding server names like this:

SDUPROD2022.WWIDB.Payroll.Employees

That makes your code really hard to manage.

Read on for several options. At a prior company quite a while ago, we went with DNS entries and they worked reasonably well.

Leave a Comment

Alerting People in Microsoft Teams from Data Factory Pipelines

Published 2026-03-06 by Kevin Feasel

Andy Brownsword sends a message:

Whether running Data Factory, Synapse, or Fabric pipelines, things go wrong – and the de facto response is to send an email. We’ve looked at sending emails from pipelines before, but at scale they can become noise and are easy to ignore.

A more effective option is to surface alerts where collaboration already exists, such as Teams.

In this post we’re going to start looking at using Teams and consolidate notifications into a channel. This functionality gives team members visibility, the ability to update in threads, and the option to tag people for a tighter response loop than typical emails bring.

Click through for the process.

Leave a Comment

Getting Help in MicrosoftFabricMgmt

Published 2026-03-05 by Kevin Feasel

Rob Sewell continues a series on the Microsoft Fabric management Powershell module:

Most of this blog post is going to be more about PowerShell in general than this specific module. The MicrosoftFabricMgmt module has over 295 cmdlets, which can be overwhelming at first glance. But PowerShell’s built-in discovery tools make it easy to find what you need. Knowing how to use a command is always available in the shell itself. You can find out how to use a function, what parameters it takes, and see examples of its usage without ever leaving the command line.

I have been using PowerShell for over a decade, and I still rely heavily on Get-Command and Get-Help to explore new modules and refresh my memory on ones I haven’t used in a while. In this post, I’ll show you how to use these tools effectively to navigate the MicrosoftFabricMgmt module.

Read on to see how you can get help. At least, on that front.

Leave a Comment

Fast Failover in SQL Server 2025

Published 2026-03-04 by Kevin Feasel

John Deardurff lays out some changes in SQL Server 2025:

A client requested a presentation discussing key improvements to Always On Availability Group fast failover in SQL Server 2025. I decided that a summary would be appropriate for a blog post. So, here I discuss Enhanced Telemetry, Persistent Health, and Intelligent Fast Failover 

John has a very positive take on fast failover. I haven’t tried any of this functionality, but some of this does sound promising.

Leave a Comment

Connection Pooling in PostgreSQL vs SQL Server

Published 2026-02-27 by Kevin Feasel

Haripriya Naidu compares two systems:

If you speak SQL Server as your first language, then you might be aware that connections are thread-based by design. That means each session/connection in SQL Server gets a worker thread. That thread is tied to that session from start to finish of execution.
If there are no available threads, new connections wait in queue until threads become available. This is called a thread-based model.

Postgres is different, it uses a process-based model. Every single connection spawns a separate backend OS process and each of it consumes RAM (>5MB per connection).

It’s interesting that the RDBMS that really “needs” connection pooling doesn’t have it built in, whereas the one that doesn’t “need” connection pooling (but can still benefit greatly from it) does.

Comments closed