/*************************** ** START CUSTOM HIGHLIGHTING ****************************/ // tsql language not available by CDN /************************ * END CUSTOM HIGHLIGHTING *************************/ Page Free Space: Locking

About This Blog

Including content from SQLperformance.com & SQLblog.com
Showing posts with label Locking. Show all posts
Showing posts with label Locking. Show all posts

Tuesday 10 September 2024

A Small Sample of SQL Server Chaos

 

Summary

Update processing is extremely complicated, much more so than is commonly appreciated. SQL Server generally takes great care to ensure correct operation at all times. It does this partly by protecting physical structures with appropriate latches and locks in accordance with the requirements of the current transaction isolation level.

Even an apparently simple operation like deleting a single row from an index requires a great deal of precise coordination between the query processor and storage engine. Much of the low-level code has been around for decades, so it is well-tested and robust.

It was a huge surprise then, to discover a case where SQL Server gets things wrong. This failure can result in errors, internal assertion failures, stack dumps, and connection termination.

Read the full article on 𝕏.

Monday 1 November 2010

The Case of the Missing Shared Locks

The Case of the Missing Shared Locks

This post covers a little-known locking optimization that provides a surprising answer to the question:

If I hold an exclusive lock on a row, can another transaction running at the default read committed isolation level read it?

Most people would answer ‘no’, on the basis that the read would block when it tried to acquire a shared lock. Others might respond that it depends on whether the READ_COMMITTED_SNAPSHOT database option was in effect, but let’s assume that is not the case, and we are dealing simply with the default (locking) read committed isolation level.