Press "Enter" to skip to content

Category: Administration

Linking Fabric Warehouse SQL Query Results to the Capacity Metrics App

Published 2025-09-30 by Kevin Feasel

Chris Webb follows up on a previous post:

Following on from my post two weeks ago about how to get the details of Power BI operations seen in the Capacity Metrics App using the OperationId column on the Timepoint Detail page, I thought it was important to point out that you can do the same thing with TSQL queries against a Fabric Warehouse/SQL Endpoint and with Spark jobs. These two areas of Fabric are outside my area of expertise so please excuse any mistakes or simplifications, but I know a lot of you are Fabric capacity admins so I hope you’ll find this useful.

Read on to learn more.

Comments closed

Inspecting the Postgres Write-Ahead Log

Published 2025-09-29 by Kevin Feasel

Henrietta Dombrovskaya digs into the write-ahead log:

First, when the users fixed one of the primary suspects jobs, the situation with WAL growth didn’t change. Second, the rate of the growth couldn’t be explained by these suboptimal jobs: the data volumes they were removing and reloading were still magnitudes smaller than the WAL size we were dealing with. Finally, I decided to do what I should have done from the start – to take a look at what exactly was in these super-fast growing WALs.

Read on to learn what Henrietta found. Also check out the comments for some additional context.

Comments closed

Losing Data with PostgreSQL and Jepsen

Published 2025-09-29 by Kevin Feasel

Jeremy Schneider performs some tests:

This is a follow‑up to the last article: Run Jepsen against CloudNativePG to see sync replication prevent data loss. In that post, we set up a Jepsen lab to make data loss visible when synchronous replication was disabled — and to show that enabling synchronous replication prevents it under crash‑induced failovers.

Since then, I’ve been trying to make data loss happen more reliably in the “async” configuration so students can observe it on their own hardware and in the cloud. Along the way, I learned that losing data on purpose is trickier than I expected.

Click through to learn more. Jepsen has been the gold standard in testing distributed database systems for data loss.

Comments closed

Memory Grant Feedback Woes

Published 2025-09-26 by Kevin Feasel

Rebecca Lewis explains an issue with memory grant feedback in SQL Server:

Before SQL Server runs a query, it estimates how much memory it needs for sorting and joining. But what if it gets it wrong?

  • Too little memory → Spills to tempdb (slow)
  • Too much memory → Starves other queries

SQL Server 2017+ tries to fix bad estimates based on previous calls with ‘Memory Grant Feedback’.  Kinda like:  ‘Last time I gave you 2GB but you only used 50MB. Next time I’m giving you less.’

This is great in theory, though Rebecca shows a case in which the end result might not be great.

Comments closed

An Outside-In Triage for SQL Server Performance

Published 2025-09-25 by Kevin Feasel

Kevin Hill triages an issue:

It’s 9:05 AM and your helpdesk lights up: “The SQL Server is down. Nothing works.”

By 9:07, everyone is staring at you.

The trap: you open SSMS and start digging for blocking queries. But what if the database isn’t the problem at all?

I think my biggest gripe about the list is the challenge of being allowed to get several of these metrics. But it is good, in the face of a “Everything is slow fix it now!” style of request, to look at extrinsic factors before digging into SQL Server, as that’s just following the old joke about the drunken man searching for his keys under the streetlamp, despite not having lost them there, because it’s easier to see that area.

Comments closed

SQL Firewall in Oracle

Published 2025-09-19 by Kevin Feasel

Brendan Tierney tries out the SQL Firewall feature in Oracle:

SQL Firewall allows you to implement a firewall within the database to control what commands are allowed to be run on the data. With SQL Firewall you can:

  • Monitor the SQL (and PL/SQL) activity to learn what the normal or typical SQL commands are being run on the data
  • Captures all commands and logs them
  • Manage a list of allowed commands, etc, using Policies
  • Block and log all commands that are not allowed. Some commands might be allowed to run

Read on to see how it works. It’s an interesting approach that can supplement traditional firewall and web application firewall systems.

Comments closed

Finding Row Counts in Tables

Published 2025-09-18 by Kevin Feasel

Andy Brownsword wants a quick answer:

A question I ask myself often when exploring unfamiliar data sets. So here’s a quickie:

Click through for the script. This is a lot faster than SELECT COUNT(*), something that can really burn you when there are a few trillion rows in a table and your index scan interferes with ongoing operations. I’ve noticed that reading these counts from statistics is usually pretty solid, but generally, we’re interested in orders of magnitude, in which case 39,308,149 and 39,308,206 are close enough for purposes of understanding which tables are heftier.

Comments closed

Responding to “The Server is Slow”

Published 2025-09-18 by Kevin Feasel

Kevin Hill shares some consulting advice:

Stop. Don’t Open SSMS Yet.

You’ve heard it before: “The server is slow.”

What does that actually mean?

If you jump straight into SQL Server looking for blocking, bad queries, or a missing index, you’re working with bad input. And bad input = wasted time.

The real work starts before you ever connect to SQL Server.

Click through for some guidance on how to frame the conversation. Even if you aren’t a consultant, I think it’s a good idea to scope and triage the problem in a similar fashion before trying to dive in and see what you can find.

Comments closed

TDE and Checksum Performance Penalties in PostgreSQL

Published 2025-09-15 by Kevin Feasel

Christoph Berg performs some tests:

It’s been a while since the last performance check of Transparent Data Encryption (TDE) in Cybertec’s PGEE distribution – that was in 2016. Of course, the question is still interesting, so I did some benchmarks.

Since the difference is really small between running without any extras, with data checksums turned on, and with both encryption and checksums turned on, we need to pick a configuration that will stress-test these features the most.

Read on to see the test setup and how things perform. I’m a bit surprised that there’s so little throughput difference here.

Comments closed