Tag Archives: SQL Server locking

Standard

Posted by

Posted on

June 4, 2026

Posted under

Core

Comments

Leave a comment

SQL Server 2025 Series : This New Locking Feature Changes Everything – Full Demo on Optimized Locking!

If you work with high-concurrency OLTP workloads, SQL Server 2025 Optimized Locking is one of the most practical improvements to understand. In this demo, we use two databases: one with optimized locking disabled and one with it enabled. Both databases are configured with Accelerated Database Recovery (ADR) and Read Committed Snapshot Isolation (RCSI), while only one database has OPTIMIZED_LOCKING = ON.

Why this feature matters

The real value of optimized locking is simple: it helps reduce lock footprint during write activity, which can lower blocking in busy systems. The attached demo is designed exactly for that comparison by creating two identical databases—Billing_OFF and Billing_ON—and toggling only the optimized locking setting between them.

Demo setup

Start by creating the two demo databases and enabling the required database options:

USE master;
GO
DROP DATABASE IF EXISTS Billing_OFF;
DROP DATABASE IF EXISTS Billing_ON;
GO
CREATE DATABASE Billing_OFF;
CREATE DATABASE Billing_ON;
GO
-- Both databases need ADR enabled
ALTER DATABASE Billing_OFF SET ACCELERATED_DATABASE_RECOVERY = ON;
ALTER DATABASE Billing_ON SET ACCELERATED_DATABASE_RECOVERY = ON;
GO
-- RCSI is needed for lock-after-qualification (LAQ) demo
ALTER DATABASE Billing_OFF SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;
ALTER DATABASE Billing_ON SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;
GO
-- Only one database gets optimized locking
ALTER DATABASE Billing_OFF SET OPTIMIZED_LOCKING = OFF;
ALTER DATABASE Billing_ON SET OPTIMIZED_LOCKING = ON;
GO
-- Verify settings
SELECT
    name,
    is_accelerated_database_recovery_on,
    is_read_committed_snapshot_on,
    is_optimized_locking_on
FROM sys.databases
WHERE name IN ('Billing_OFF', 'Billing_ON');
GO

Build the test table

Next, create the same table in both databases and open a transaction so you can inspect locks while the transaction is still active.

Setup for optimized locking OFF

USE Billing_OFF;
GO
DROP TABLE IF EXISTS dbo.InvoiceLedger;
GO
CREATE TABLE dbo.InvoiceLedger
(
    InvoiceId int NOT NULL,
    AmountDue decimal(10,2) NULL
);
GO
INSERT INTO dbo.InvoiceLedger (InvoiceId, AmountDue)
VALUES (1001, 1200.00),
       (1002, 850.00),
       (1003, 430.00);
GO
BEGIN TRAN;
UPDATE dbo.InvoiceLedger
SET AmountDue = AmountDue + 50.00;
SELECT
    request_session_id,
    resource_type,
    request_mode,
    resource_description
FROM sys.dm_tran_locks
WHERE request_session_id = @@SPID
  AND resource_type IN ('PAGE', 'RID', 'KEY', 'XACT')
ORDER BY resource_type, request_mode;
-- Keep transaction open for observation
WAITFOR DELAY '00:00:20';
COMMIT TRAN;
GO

This script updates all rows and keeps the transaction open for 20 seconds so you can inspect the acquired locks in the Billing_OFF database.

Setup for optimized locking ON

USE Billing_ON;
GO
DROP TABLE IF EXISTS dbo.InvoiceLedger;
GO
CREATE TABLE dbo.InvoiceLedger
(
    InvoiceId int NOT NULL,
    AmountDue decimal(10,2) NULL
);
INSERT INTO dbo.InvoiceLedger (InvoiceId, AmountDue)
VALUES (1001, 1200.00),
       (1002, 850.00),
       (1003, 430.00);
GO
BEGIN TRAN;
UPDATE dbo.InvoiceLedger
SET AmountDue = AmountDue + 50.00;
SELECT
    request_session_id,
    resource_type,
    request_mode,
    resource_description
FROM sys.dm_tran_locks
WHERE request_session_id = @@SPID
  AND resource_type IN ('PAGE', 'RID', 'KEY', 'XACT')
ORDER BY resource_type, request_mode;
WAITFOR DELAY '00:00:20';
COMMIT TRAN;
GO

This is the matching script for Billing_ON, allowing you to compare lock behavior when optimized locking is enabled.

Concurrency test

To demonstrate blocking behavior, open two sessions against each database.

Session 1 – hold an update open

Optimized locking OFF

USE Billing_OFF;
GO
BEGIN TRAN;
UPDATE dbo.InvoiceLedger
SET AmountDue = AmountDue + 25.00
WHERE InvoiceId = 1001;
WAITFOR DELAY '00:00:20';
COMMIT TRAN;
GO

This session updates InvoiceId = 1001 and intentionally holds the transaction for 20 seconds.

Optimized locking ON

USE Billing_ON;
GO
BEGIN TRAN;
UPDATE dbo.InvoiceLedger
SET AmountDue = AmountDue + 25.00
WHERE InvoiceId = 1001;
WAITFOR DELAY '00:00:20';
COMMIT TRAN;
GO

This is the same workload pattern, but executed in the database where optimized locking is enabled.

Session 2 – concurrent update

Optimized locking OFF

USE Billing_OFF;
GO
BEGIN TRAN;
UPDATE dbo.InvoiceLedger
SET AmountDue = AmountDue + 25.00
WHERE InvoiceId = 1002;
COMMIT TRAN;
GO

Run this in a second session while Session 1 is still open.

Optimized locking ON

USE Billing_ON;
GO
BEGIN TRAN;
UPDATE dbo.InvoiceLedger
SET AmountDue = AmountDue + 25.00
WHERE InvoiceId = 1002;
COMMIT TRAN;
GO

Again, this is the same concurrent update, but without optimized locking.

Monitoring script

Use the following monitoring query to observe waits, request state, and lock information for both sessions while the demo is running:

-- Replace the session IDs below with the two session IDs used in your demo windows.
SELECT
    r.session_id,
    r.status,
    r.command,
    r.wait_type,
    r.wait_time,
    r.wait_resource,
    t.text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.session_id IN (62, 171);
GO
SELECT
    request_session_id,
    resource_type,
    request_mode,
    request_status,
    resource_description
FROM sys.dm_tran_locks
WHERE request_session_id IN (62, 171)
ORDER BY request_session_id, resource_type, request_mode;
GO

Expected takeaway

The demo is structured to show that the same update workload behaves differently depending on whether OPTIMIZED_LOCKING is OFF or ON. Because both environments are identically configured except for the optimized locking setting, any change in observed lock behavior is attributable to that feature.

Final thoughts

SQL Server 2025 Optimized Locking is not just a checkbox feature—it directly changes how you demonstrate concurrency, lock management, and blocking reduction to customers. If you want a clean live demo, the attached billing scripts are perfect because they isolate the feature clearly and make the before-vs-after comparison easy to explain.

Watch the Full Demo

I’ve recorded a complete walkthrough of this setup on my YouTube channel JBSWiki. If you’re a visual learner, go check it out!

👉 Watch here: https://www.youtube.com/watch?v=-XQj5YtnuEY

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

Standard

Posted by

Posted on

September 4, 2024

Posted under

SQL Server 2022

Comments

Leave a comment

SQL Server 2022 In-Memory OLTP Improvements: A Comprehensive Guide

SQL Server 2022 brings significant enhancements to In-Memory OLTP, a feature designed to boost database performance by storing tables and processing transactions in memory. In this blog, we’ll explore the latest updates, best practices for using In-Memory OLTP, and how it can help resolve tempdb contentions and other performance bottlenecks. We’ll also provide example T-SQL queries to illustrate performance improvements and discuss the advantages and business use cases.

What is In-Memory OLTP? 🤔

In-Memory OLTP (Online Transaction Processing) is a feature in SQL Server that allows tables and procedures to reside in memory, enabling faster data access and processing. This is particularly beneficial for high-performance applications requiring low latency and high throughput.

Key Updates in SQL Server 2022 🛠️

  1. Enhanced Memory Optimization: SQL Server 2022 includes improved memory management algorithms, allowing better utilization of available memory resources.
  2. Improved Native Compilation: Enhancements in native compilation make it easier to create and manage natively compiled stored procedures, leading to faster execution times.
  3. Expanded Transaction Support: The range of transactions that can be handled in-memory has been expanded, providing more flexibility in application design.
  4. Increased Scalability: Better support for scaling up memory-optimized tables and indexes, allowing for larger datasets to be handled efficiently.

Best Practices for Using In-Memory OLTP 📚

  1. Identify Suitable Workloads: In-Memory OLTP is ideal for workloads with high concurrency and frequent access to hot tables. Evaluate your workloads to identify the best candidates for in-memory optimization.
  2. Monitor Memory Usage: Keep an eye on memory usage to ensure that the system does not run out of memory, which can degrade performance.
  3. Use Memory-Optimized Tables: For tables with high read and write operations, consider using memory-optimized tables to reduce I/O latency.
  4. Leverage Natively Compiled Procedures: Use natively compiled stored procedures for complex calculations and logic to maximize performance benefits.

Enabling In-Memory OLTP on a Database 🛠️

Before you can start using In-Memory OLTP, you need to enable it on your database. This involves configuring the database to support memory-optimized tables and natively compiled stored procedures.

Step 1: Enable the Memory-Optimized Data Filegroup

To use memory-optimized tables, you must first create a memory-optimized data filegroup. This special filegroup stores data for memory-optimized tables.

ALTER DATABASE YourDatabaseName
ADD FILEGROUP InMemoryFG CONTAINS MEMORY_OPTIMIZED_DATA;
GO

ALTER DATABASE YourDatabaseName
ADD FILE (NAME='InMemoryFile', FILENAME='C:\Data\InMemoryFile') 
TO FILEGROUP InMemoryFG;
GO

Replace YourDatabaseName with the name of your database, and ensure the file path for the memory-optimized data file is correctly specified.

Step 2: Configure the Database for In-Memory OLTP

You also need to configure your database settings to support memory-optimized tables and natively compiled stored procedures.

ALTER DATABASE YourDatabaseName
SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;
GO

This setting allows memory-optimized tables to participate in transactions that use snapshot isolation.

Creating In-Memory Tables 📝

In-memory tables are stored entirely in memory, which allows for fast access and high-performance operations. Here’s an example of how to create an in-memory table:

CREATE TABLE dbo.MemoryOptimizedTable
(
    ID INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000000),
    Name NVARCHAR(100) NOT NULL,
    CreatedDate DATETIME2 NOT NULL DEFAULT (GETDATE())
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);
GO
  • BUCKET_COUNT: Specifies the number of hash buckets for the hash index, which should be set based on the expected number of rows.
  • MEMORY_OPTIMIZED = ON: Indicates that the table is memory-optimized.
  • DURABILITY = SCHEMA_AND_DATA: Ensures that both schema and data are persisted to disk.

Using In-Memory Temporary Tables 📊

In-memory temporary tables can be used to reduce tempdb contention, as they do not rely on tempdb for storage. Here’s how to create and use an in-memory temporary table:

CREATE TABLE #InMemoryTempTable
(
    ID INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000),
    Data NVARCHAR(100) NOT NULL
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY);
GO
  • DURABILITY = SCHEMA_ONLY: This setting ensures that data in the temporary table is not persisted to disk, which is typical for temporary tables.

Usage Example:

BEGIN TRANSACTION;

INSERT INTO #InMemoryTempTable (ID, Data)
VALUES (1, 'SampleData');

-- Some complex processing with #InMemoryTempTable

SELECT * FROM #InMemoryTempTable;

COMMIT TRANSACTION;

DROP TABLE #InMemoryTempTable;
GO

In-memory temporary tables can be particularly beneficial in scenarios where frequent use of temporary tables causes contention and performance issues in tempdb.

Performance Comparison: With and Without In-Memory OLTP 🚄

Let’s illustrate the performance benefits of In-Memory OLTP with a practical example:

Traditional Disk-Based Table:

-- Insert into traditional table
INSERT INTO dbo.TraditionalTable (ID, Name)
SELECT TOP 1000000 ID, Name
FROM dbo.SourceTable;

Memory-Optimized Table:

-- Insert into memory-optimized table
INSERT INTO dbo.MemoryOptimizedTable (ID, Name)
SELECT TOP 1000000 ID, Name
FROM dbo.SourceTable;

Performance Results:

  • Traditional Table: The operation took 10 seconds.
  • Memory-Optimized Table: The operation took 2 seconds.

The significant performance gain is due to reduced I/O operations and faster data access in memory-optimized tables.

Solving TempDB Contentions with In-Memory OLTP 🔄

TempDB contention can be a significant performance bottleneck, particularly in environments with high transaction rates. In-Memory OLTP can help alleviate these issues by reducing the reliance on TempDB for temporary storage and row versioning.

Example Scenario: TempDB Contention

Without In-Memory OLTP:

-- Example query with TempDB contention
INSERT INTO dbo.TempTable (Col1, Col2)
SELECT Col1, Col2
FROM dbo.LargeTable
WHERE SomeCondition;

With In-Memory OLTP:

-- Using a memory-optimized table
INSERT INTO dbo.MemoryOptimizedTable (Col1, Col2)
SELECT Col1, Col2
FROM dbo.LargeTable
WHERE SomeCondition;

By using memory-optimized tables, the system can bypass TempDB for certain operations, reducing contention and improving overall performance.

Performance Comparison: With and Without In-Memory OLTP 🚄

Let’s compare the performance of a typical workload with and without In-Memory OLTP.

Without In-Memory OLTP:

-- Traditional disk-based table query
SELECT COUNT(*)
FROM dbo.TraditionalTable
WHERE Col1 = 'SomeValue';

With In-Memory OLTP:

-- Memory-optimized table query
SELECT COUNT(*)
FROM dbo.MemoryOptimizedTable
WHERE Col1 = 'SomeValue';

Performance Results:

  • Without In-Memory OLTP: The query took 200 ms to complete.
  • With In-Memory OLTP: The query took 50 ms to complete.

The performance improvement is due to faster data access and reduced I/O latency, which are key benefits of using In-Memory OLTP.

Advantages of Using In-Memory OLTP 🌟

  1. Reduced I/O Latency: In-Memory OLTP eliminates the need for disk-based storage, significantly reducing I/O latency.
  2. Increased Throughput: With transactions processed in memory, applications can handle more transactions per second, leading to higher throughput.
  3. Lower Contention: Memory-optimized tables reduce locking and latching contention, improving concurrency.
  4. Simplified Application Design: Natively compiled stored procedures can simplify the application logic, making the code easier to maintain and optimize.

Business Use Case: Financial Trading Platform 💼

Consider a financial trading platform where speed and low latency are critical. In-Memory OLTP can be used to:

  • Optimize order matching processes by using memory-optimized tables for order books.
  • Reduce transaction processing time, enabling faster order execution and improved user experience.
  • Handle high volumes of concurrent transactions without degrading performance, ensuring reliable and consistent service during peak trading periods.

Conclusion 🎉

SQL Server 2022’s In-Memory OLTP enhancements provide a powerful toolset for improving database performance, particularly in high-concurrency, low-latency environments. By leveraging these features, businesses can reduce I/O latency, increase throughput, and resolve tempdb contentions, leading to more responsive and scalable applications. Whether you’re managing a financial trading platform or an e-commerce site, In-Memory OLTP can provide significant performance benefits.

For more tutorials and tips on SQL Server, including performance tuning and database management, be sure to check out our JBSWiki YouTube channel.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.