Press "Enter" to skip to content

Category: Administration

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

Accelerated Database Recovery and NOLOCK

Published 2025-09-11 by Kevin Feasel

Brent Ozar has a new episode of Customers Say the Darndest Things:

I have never seen a T-SQL feature that people love as much as NOLOCK.

I keep thinking I’ve written enough blog posts about it, but a client came up with a new one:

We use SQL Server 2022’s Accelerated Database Recovery, which keeps copies of versions inside the table. Plus, we don’t use transactions – our inserts, updates, and deletes are done one table at a time, and your demos always have transactions in them, so we’re not affected.

That’s not how this works. That’s not how any of this works.

It might be because it’s early in the morning when I type this out, but I’m having a hard time even conceptualizing what the customer could be thinking here. Brent does lay it out in the comments below, however, and yeah, I’d still raise an eyebrow if someone said that out loud to me.

But the moral of the story is, find someone who loves you like T-SQL developers love NOLOCK.

Comments closed