Press "Enter" to skip to content

Day: September 10, 2026

Fixing a Problem from the Naval Yard

Published 2026-09-10 by Kevin Feasel

Andy Levy tells us a story:

A buddy of mine invited me to take a road trip and join him in Philadelphia, PA to take a tour of the USS New Jersey while she was in drydock for its required museum ship maintenance. Quite possibly a once in a lifetime opportunity – we wouldn’t be touring the inside of the ship, we would be walking around underneath her, on the floor of the drydock. I hit the road on Friday, and picked him up at the airport. We got dinner, unwound from our respective travels, and planned out the following day.

Click through to see what happened next.

Leave a Comment

DiskANN and Beam Search

Published 2026-09-10 by Kevin Feasel

Mala Mahadevan continues a series on vector search:

At this point, the consideration becomes – ‘What if the graph and all of its vectors don’t fit in memory?’

If every step of graph traversal had to wait for an arbitrary SSD read, the navigation could become painfully slow.

This is the plus and the minus of an index like HNSW. If you can fit everything into memory, it’s faster than DiskANN. Once you start paging in and out of disk, DiskANN becomes considerably faster.

Leave a Comment

To Make a DBA

Published 2026-09-10 by Kevin Feasel

Andy Brownsword tells his origin story:

I enjoy a good war story.

But no, this isn’t the time Azure blindsided me, when service accounts were locked, or when I left a transaction open and halted a production system (easily fixed by closing SSMS 😅). Mine is a pivotal personal moment.

Andy humbly leaves out the part where he was hand-to-hand kung fu fighting a series of ninjas while doing all of this, but you can just assume that in there.

Leave a Comment

The Importance of Application Names

Published 2026-09-10 by Kevin Feasel

Brent Ozar explains how powerful application names can be:

When you run monitoring queries like sp_BlitzWho and sp_WhoIsActive, you wanna see the program names that are running the queries. It’s super useful when you’ve got multiple apps running on the same servers, or when you’ve got apps scattered across end user computers.

If you don’t set the program names, you’ll either end up with empty strings, or your dev tool’s default name, like Core .Net SqlClient Data Provider, which doesn’t tell you jack.

And, once you do have application names established for everything, you can also set up Resource Governor to use those application names for the purpose of routing to Resource Governor pools.

Leave a Comment

A Tale of Time

Published 2026-09-10 by Kevin Feasel

Chad Callihan gives us a rundown:

I’ve written about a few outages and issues in the past and wanted to write about a different one for this post. One that came to mind was from awhile ago when a code deployment appeared to be successful on the surface, but in reality turned into a time consuming mess.

Click through for the story. This is why I strongly recommend always storing dates and times in UTC format in SQL Server, so using GETUTCDATE() and its brethren versus GETDATE() and co. You can always translate from UTC into the relevant time zone, you don’t have to worry about daylight savings time fouling things up twice a year, and you always have a known starting point, regardless of where your server is located. This ties in with DR scenarios: if your main server is on the US east coast and your DR site is on the US west coast and both are using GETDATE() to store times, you’ll see problems after a failover.

Leave a Comment

Schema Locks and Time Travel in Fabric Data Warehouse

Published 2026-09-10 by Kevin Feasel

Louis Davidson continues a comparative analysis:

When reading that title, you probably want to get to concept of time travel first, because if you could really do that, you wouldn’t have any more backup and recovery problems. The time travel I will cover is about getting to past versions of data in your data warehouse tables. This is done in a similar way to what you can do with temporal tables in SQL Server, but also VERY different.

The schema locks section is a wee bit of a follow on to Part 4 where I covered isolation where I showed how updating data was handled concurrently. In this post I wanted to briefly finish that conversation and note how it works when you have schema locks.

Most of this behavior is similar to what we have in SQL Server on-premises, though time travel does have a couple of nuances to it versus the box product.

Leave a Comment