August 29, 2025 at 12:00 am
Comments posted to this topic are about the item What is Delayed Durability in SQL Server — And Should You Turn It On?
August 29, 2025 at 7:58 am
A useful and informative article, thanks 🙂
Observation only: I find it rather annoying that every element is repeated at least three times!
August 29, 2025 at 1:30 pm
Thanks for a great article on something I knew was there but thankfully haven't had to implement yet.
August 29, 2025 at 1:43 pm
This makes me curious - we have some 3rd party vendor software where the designers decided for the sake of data consistency to wrap large amounts of work into transactions. When the database is busy, this causes frequent blocking, which you'd have to say is by design. You mentioned small, fast writes would benefit from turning on this setting. Have you considered large transactions with many writes stacked inside?
Be still, and know that I am God - Psalm 46:10
August 29, 2025 at 7:43 pm
Thank you for the informative article. I think a diagram of the work flow would provide a better understanding.
----------------------------------------------------
August 30, 2025 at 1:21 pm
@david-2.gugg
Yeah that’s a really interesting point. You’re right — delayed durability is mainly a win for those rapid-fire, small commits where the log flush wait just kills throughput. With big transactions that wrap a ton of work, the commit still has to flush everything at once, so you don’t get quite the same benefit.
It can shave off that final pause at commit time, but the trade-off is heavier — if the server crashes in that window, you lose the whole chunk instead of just a few rows. In most cases I’d be more worried about blocking and log growth on those large transactions than about the log flush delay.
So yeah, small and frequent = good candidate. Large and heavy = not so much, unless you’re okay with the bigger risk window.
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply