Tag Archives: SQL Server storage optimization

Standard

Posted by

Posted on

June 4, 2026

Posted under

Core

Comments

Leave a comment

SQL Server 2025 Series : SQL Backups Just Got Smaller and Faster – ZSTD Compression Live Demo!

Database backups are one of the most critical parts of any data platform strategy. Whether you are protecting transactional systems, reporting environments, or large enterprise workloads, backups directly influence storage consumption, recovery objectives, operational overhead, and even infrastructure cost.

With SQL Server 2025, backup compression gets a major upgrade through support for ZSTD (Zstandard) compression. This is a significant enhancement for database administrators and architects looking to reduce backup size, improve efficiency, and gain more flexibility in how backup workloads are tuned.

In this post, I will walk through what ZSTD compression is, why it matters, and how to test it using a simple end-to-end backup and restore demo.

What is ZSTD Compression?

ZSTD, or Zstandard, is a modern lossless compression algorithm designed to deliver an excellent balance between:

  • High compression ratio
  • Fast compression speed
  • Very fast decompression
  • Flexible tuning through compression levels

For years, backup compression has helped reduce storage usage and improve I/O efficiency. But as database sizes continue to grow, traditional compression methods may not always provide the best balance between speed and storage savings.

That is where ZSTD becomes exciting.

SQL Server 2025 now allows backups to use the ZSTD algorithm, giving DBAs a newer and more efficient option for compressing database backups.

Why This Matters

As backup volumes increase, organizations typically face a common set of challenges:

  • Backup files consume too much space
  • Backup windows become longer
  • Restore operations need to stay fast and reliable
  • Storage and archival costs continue growing
  • Sending backups across environments or regions becomes more expensive

ZSTD helps address these challenges by improving backup compression efficiency while still maintaining strong decompression performance.

In practical terms, this means you may be able to:

  • Store more backups using less space
  • Improve backup storage utilization
  • Reduce backup repository growth
  • Optimize retention strategies
  • Improve overall operational efficiency

Key Benefits of ZSTD Backup Compression

1. Better Compression Efficiency

One of the biggest advantages of ZSTD is its ability to compress data more efficiently than older approaches in many scenarios. This can result in noticeably smaller backup files, especially for large databases with compressible data patterns.

2. Faster Decompression

Backup is only one half of the story. Restore performance is equally important. ZSTD is known for fast decompression, which is valuable during restore operations when time matters most.

3. Compression Levels for Flexibility

SQL Server 2025 introduces the ability to choose different compression levels when using ZSTD. This is useful because not every environment has the same priorities.

For example:

  • If your priority is faster backup completion, a lower level may be enough
  • If your priority is maximum storage reduction, a higher level may be better
  • If you want a balance, medium can be a good starting point

4. Familiar Backup Workflow

Another great advantage is that ZSTD integrates directly into the backup syntax DBAs are already familiar with. There is no need to redesign the backup process from scratch. You simply use the appropriate compression options while taking the backup.

Demo Objective

In this walkthrough, the goal is to compare:

  1. A normal compressed backup
  2. A ZSTD backup with the default compression level
  3. A ZSTD backup with MEDIUM compression level
  4. A ZSTD backup with HIGH compression level

After each backup, we also validate the backup metadata and restore the database to separate target names and file paths. This gives us a complete end-to-end validation of both backup creation and restore success.

For this demo, we will use the JBFinance database and the exact script provided below.

What We Will Validate

This demo helps validate several things:

  • Backup command executes successfully
  • Backup header can be read
  • Backup file can be restored successfully
  • Different ZSTD compression levels can be tested easily
  • Separate restored copies can be created for comparison and verification

Step 1: Review the Source Database

Before taking backups, it is always useful to review the source database size and file layout.

USE [master]
GO
sp_helpdb JBFinance
GO

This gives you a quick overview of the database structure and helps confirm the logical file names that will later be used during restore.

Step 2: Take a Regular Compressed Backup

First, take a standard compressed backup using the familiar compression option.

BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_normal.bak' with COMPRESSION,STATS=1;
GO

What this does

This command creates a compressed backup of the JBFinance database and writes it to the specified backup location.

Why this matters

This serves as your baseline. You can compare this backup later with the ZSTD-based backups to understand whether ZSTD offers better storage efficiency or operational benefits in your environment.

Step 3: Inspect the Backup Metadata

After the backup completes, inspect the backup header.

RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_normal.bak';
GO

Why this step is useful

This confirms that:

  • The backup file is valid
  • SQL Server can read the backup metadata
  • The backup can be used in restore operations

It is also a good verification step before running a restore.

Step 4: Restore the Regular Compressed Backup

Now restore that baseline backup to a separate database name.

RESTORE DATABASE [JBFinance_Normal] FROM  DISK = N'c:\temp\zstd\JBFinance_normal.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO

Why restore it?

A backup is only useful if it can be restored successfully. This step validates the full backup-and-restore chain.

Step 5: Take a ZSTD Backup Using the Default Compression Level

Now let’s move to the new feature.

BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_ZSTD.bak' with COMPRESSION(ALGORITHM = ZSTD),STATS=1; --Default compression Level is LOW
GO

Important note

When only ALGORITHM = ZSTD is specified, the default compression level is LOW.

Why this is interesting

This gives you a first look at how ZSTD behaves with minimal additional tuning. It is a good starting point for most first-time tests.

Step 6: Validate the ZSTD Backup Header

RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_ZSTD.bak';
GO

Again, this confirms the backup is readable and valid.

Step 7: Restore the ZSTD LOW Backup

RESTORE DATABASE [JBFinance_Low] FROM  DISK = N'c:\temp\zstd\JBFinance_ZSTD.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO

This confirms that a backup created using ZSTD can be restored just as expected.

Step 8: Take a ZSTD Backup with MEDIUM Compression Level

Now let’s test the MEDIUM compression level.

BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_ZSTD_MEDIUM.bak' with COMPRESSION(ALGORITHM = ZSTD, LEVEL = MEDIUM),STATS=1;
GO

Why MEDIUM matters

This is often the level many teams will be interested in because it may provide a stronger balance between:

  • Backup size reduction
  • CPU cost
  • Backup duration

Step 9: Validate the MEDIUM Backup Header

RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_ZSTD_MEDIUM.bak';
GO

Step 10: Restore the MEDIUM Backup

RESTORE DATABASE [JBFinance_Medium] FROM  DISK = N'c:\temp\zstd\JBFinance_ZSTD_MEDIUM.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO

This gives you a restored copy from the ZSTD MEDIUM backup for validation and comparison.

Step 11: Take a ZSTD Backup with HIGH Compression Level

Now let’s test the HIGH compression level.

BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_ZSTD_HIGH.bak' with COMPRESSION(ALGORITHM = ZSTD, LEVEL = HIGH),STATS=1;
GO

Why HIGH matters

If your main goal is maximum backup size reduction, this option is worth testing. In some environments, HIGH can offer the most aggressive storage savings, though it may also require more CPU resources during backup creation.

Step 12: Validate the HIGH Backup Header

RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_ZSTD_HIGH.bak';
GO

Step 13: Restore the HIGH Backup

RESTORE DATABASE [JBFinance_High] FROM  DISK = N'c:\temp\zstd\JBFinance_ZSTD_HIGH.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO

This completes the end-to-end validation of all backup variants in the test.

Full Demo Script

For convenience, here is the complete script exactly as provided for the demo.

--- ZSTD Compression
USE [master]
GO
sp_helpdb JBFinance
GO
BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_normal.bak' with COMPRESSION,STATS=1; 
GO  
RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_normal.bak';  
GO 
RESTORE DATABASE [JBFinance_Normal] FROM  DISK = N'c:\temp\zstd\JBFinance_normal.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO  
-------
BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_ZSTD.bak' with COMPRESSION(ALGORITHM = ZSTD),STATS=1; --Default compression Level is LOW
GO  
RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_ZSTD.bak';
GO  
RESTORE DATABASE [JBFinance_Low] FROM  DISK = N'c:\temp\zstd\JBFinance_ZSTD.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO   
-------
BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_ZSTD_MEDIUM.bak' with COMPRESSION(ALGORITHM = ZSTD, LEVEL = MEDIUM),STATS=1;
GO 
RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_ZSTD_MEDIUM.bak';
GO 
RESTORE DATABASE [JBFinance_Medium] FROM  DISK = N'c:\temp\zstd\JBFinance_ZSTD_MEDIUM.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO  
------
BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_ZSTD_HIGH.bak' with COMPRESSION(ALGORITHM = ZSTD, LEVEL = HIGH),STATS=1;
GO 
RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_ZSTD_HIGH.bak';
GO
RESTORE DATABASE [JBFinance_High] FROM  DISK = N'c:\temp\zstd\JBFinance_ZSTD_HIGH.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO

What to Observe During the Demo

When you run this demo in your environment, pay close attention to the following:

1. Backup File Size

Compare the sizes of:

  • JBFinance_normal.bak
  • JBFinance_ZSTD.bak
  • JBFinance_ZSTD_MEDIUM.bak
  • JBFinance_ZSTD_HIGH.bak

This helps you understand how each compression option affects storage savings.

2. Backup Completion Time

Capture how long each backup takes to complete. Higher compression levels may reduce backup size further, but they can also use more CPU.

3. Restore Success

Each backup should restore successfully into its own database copy. This confirms backup reliability and end-to-end usability.

4. Compression Trade-Offs

The best compression level is not always the smallest file. In many real-world environments, the right choice depends on:

  • Backup window
  • CPU availability
  • Storage cost
  • Restore expectations
  • Workload sensitivity

4. My Test details

Table showing backup types, their corresponding backup times, restore times, and backup sizes in GB.

Practical Guidance

Here are a few practical recommendations when evaluating ZSTD backup compression in your environment.

Start with LOW or MEDIUM

If you are testing this feature for the first time, LOW or MEDIUM is a practical place to begin.

Measure Before Standardizing

Do not assume one level is best for every database. Compression results vary depending on:

  • Data types
  • Existing data compression
  • Row patterns
  • Repetitive versus random data
  • Binary or already compressed content

Test Restore Performance Too

Do not focus only on backup size. Make sure you also validate restore workflows, especially for recovery-critical systems.

Use Realistic Data

Whenever possible, test this against an actual workload or database that resembles production.

Final Thoughts

ZSTD compression in SQL Server 2025 is a meaningful enhancement for modern backup strategies. It gives database professionals more flexibility in how they balance storage efficiency, backup throughput, and operational cost.

The biggest advantage is not just smaller backup files. It is the ability to tune compression behavior based on your environment and priorities.

If your organization manages large backups, retention-heavy workloads, or storage-sensitive environments, this feature is definitely worth testing.

The script used in this post provides a simple and effective way to compare:

  • Standard compressed backup
  • ZSTD LOW
  • ZSTD MEDIUM
  • ZSTD HIGH

and validate the complete backup-and-restore workflow.

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=gFzRdmz13xQ

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

August 30, 2024

Posted under

SQL Server 2022

Comments

Leave a comment

SQL Server 2022 UTF-8 Support Enhancements in Collation

In SQL Server 2022, UTF-8 support has been enhanced, offering more efficient storage and better performance for text data. This blog will explore these enhancements using the JBDB database and provide a detailed business use case to illustrate the benefits of adopting UTF-8 collation.

🌍Business Use Case: International E-commerce Platform 🌍

Imagine an international e-commerce platform that serves customers worldwide, offering products in multiple languages. The database needs to handle diverse character sets efficiently, from English to Japanese, Arabic, and more. Previously, using Unicode (UTF-16) required more storage space, leading to increased costs and slower performance. With SQL Server 2022’s improved UTF-8 support, the platform can now store multilingual text data more compactly, reducing storage costs and enhancing query performance.

UTF-8 Support in SQL Server 2022

SQL Server 2019 introduced UTF-8 as a new encoding option, allowing for more efficient storage of character data. SQL Server 2022 builds on this foundation by enhancing collation support, making it easier to work with UTF-8 encoded data. Let’s explore these enhancements using the JBDB database.

Setting Up the JBDB Database

First, we’ll set up the JBDB database and create a table to store product information in multiple languages.

CREATE DATABASE JBDB;
GO

USE JBDB;
GO

CREATE TABLE Products (
    ProductID INT PRIMARY KEY,
    ProductName NVARCHAR(100),
    ProductDescription NVARCHAR(1000),
    ProductDescription_UTF8 VARCHAR(1000) COLLATE Latin1_General_100_BIN2_UTF8
);
GO

In this example, ProductDescription uses the traditional NVARCHAR data type with UTF-16 encoding, while ProductDescription_UTF8 uses VARCHAR with the Latin1_General_100_BIN2_UTF8 collation for UTF-8 encoding.

Inserting Data with UTF-8 Collation 🚀

Let’s insert some sample data into the Products table, showcasing different languages.

INSERT INTO Products (ProductID, ProductName, ProductDescription, ProductDescription_UTF8)
VALUES
(1, 'Laptop', N'高性能ノートパソコン', '高性能ノートパソコン'), -- Japanese
(2, 'Smartphone', N'الهاتف الذكي الأكثر تقدمًا', 'الهاتف الذكي الأكثر تقدمًا'), -- Arabic
(3, 'Tablet', N'Nueva tableta con características avanzadas', 'Nueva tableta con características avanzadas'); -- Spanish
GO

Here, we use N'...' to denote Unicode literals for the NVARCHAR column and regular string literals for the VARCHAR column with UTF-8 encoding.

Querying and Comparing Storage Size 📊

To see the benefits of UTF-8 encoding, we’ll compare the storage size of the ProductDescription and ProductDescription_UTF8 columns.

SELECT
    ProductID,
    DATALENGTH(ProductDescription) AS UnicodeStorage,
    DATALENGTH(ProductDescription_UTF8) AS UTF8Storage
FROM Products;
GO

This query returns the number of bytes used to store each product description, illustrating the storage savings with UTF-8.

Working with UTF-8 Data 🔍

Let’s perform some queries and operations on the UTF-8 encoded data.

Searching for Products in Japanese:

SELECT ProductID, ProductName, ProductDescription_UTF8
FROM Products
WHERE ProductDescription_UTF8 LIKE '%ノートパソコン%';
GO

Updating UTF-8 Data:

UPDATE Products
SET ProductDescription_UTF8 = '高性能なノートパソコン'
WHERE ProductID = 1;
GO

Ordering Data with UTF-8 Collation:

SELECT ProductID, ProductName, ProductDescription_UTF8
FROM Products
ORDER BY ProductDescription_UTF8 COLLATE Latin1_General_100_BIN2_UTF8;
GO

Advantages of UTF-8 in SQL Server 2022 🏆

  1. Reduced Storage Costs: UTF-8 encoding is more space-efficient than UTF-16, especially for languages using the Latin alphabet.
  2. Improved Performance: Smaller data size leads to faster reads and writes, enhancing overall performance.
  3. Enhanced Compatibility: UTF-8 is a widely-used encoding standard, making it easier to integrate with other systems and technologies.

Conclusion ✨

SQL Server 2022’s enhanced UTF-8 support in collation offers significant advantages for businesses dealing with multilingual data. By leveraging these enhancements, the international e-commerce platform in our use case can optimize storage, improve performance, and provide a seamless user experience across diverse languages.

Whether you’re dealing with global customer data or localized content, adopting UTF-8 collation in SQL Server 2022 can be a game-changer for your database management strategy.

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.

Standard

Posted by

Posted on

August 10, 2024

Posted under

SQL Server 2022

Comments

Leave a comment

SQL Server 2022 Performance Tuning Tips: Optimizing for Peak Efficiency

SQL Server 2022 introduces numerous enhancements aimed at improving performance and efficiency. Whether you’re dealing with query optimization, index management, or memory allocation, these new features and best practices can help you achieve significant performance gains. In this blog, we’ll explore specific tuning tips and tricks for SQL Server 2022, highlighting changes that enhance query performance without requiring any code changes. We’ll also address how these improvements solve longstanding issues from previous versions. Practical T-SQL examples will be provided to help you implement these tips. Let’s dive in! 🎉

Key SQL Server 2022 Enhancements for Performance Tuning ⚙️

  1. Intelligent Query Processing (IQP) Enhancements: SQL Server 2022 continues to enhance IQP features, including Adaptive Joins, Batch Mode on Rowstore, and more.
  2. Automatic Plan Correction: This feature helps to identify and fix suboptimal execution plans automatically.
  3. Increased Parallelism: SQL Server 2022 offers more granular control over parallelism, improving the performance of complex queries.
  4. Optimized TempDB Usage: Improvements in TempDB management reduce contention and improve query performance.

Specific Tuning Tips and Tricks 🔧

1. Leverage Intelligent Query Processing (IQP) 🧠

SQL Server 2022 builds on the IQP feature set, which adapts to your workload to optimize performance. Here are some specific IQP features to take advantage of:

  • Batch Mode on Rowstore: This feature allows batch mode processing on traditional rowstore tables, providing significant performance improvements for analytical workloads.

Example Query:

-- Without Batch Mode on Rowstore
SELECT SUM(SalesAmount) 
FROM Sales.SalesOrderDetail
WHERE ProductID = 707;

-- With Batch Mode on Rowstore (SQL Server 2022)
SELECT SUM(SalesAmount) 
FROM Sales.SalesOrderDetail WITH (USE HINT ('ENABLE_BATCH_MODE'))
WHERE ProductID = 707;
  • Adaptive Joins: SQL Server dynamically chooses the best join strategy (nested loop, hash join, etc.) during query execution, optimizing performance based on actual data distribution.

Example Query:

-- Without Adaptive Joins
SELECT p.ProductID, p.Name, SUM(s.Quantity) AS TotalSold
FROM Production.Product p
JOIN Sales.SalesOrderDetail s ON p.ProductID = s.ProductID
GROUP BY p.ProductID, p.Name;

-- With Adaptive Joins (SQL Server 2022)
SELECT p.ProductID, p.Name, SUM(s.Quantity) AS TotalSold
FROM Production.Product p
JOIN Sales.SalesOrderDetail s ON p.ProductID = s.ProductID
GROUP BY p.ProductID, p.Name;

2. Utilize Automatic Plan Correction 🛠️

Automatic Plan Correction helps to identify and fix inefficient execution plans. This feature automatically captures query performance baselines and identifies regressions, correcting them as needed.

Enabling Automatic Plan Correction:

ALTER DATABASE SCOPED CONFIGURATION 
SET AUTOMATIC_TUNING = AUTO_PLAN_CORRECTION = ON;

3. Optimize TempDB Usage 🗄️

TempDB can often become a bottleneck in SQL Server. SQL Server 2022 introduces several enhancements to manage TempDB more efficiently:

  • Memory-Optimized TempDB Metadata: Reduces contention on system tables in TempDB, particularly beneficial for workloads with heavy use of temporary tables.

Enabling Memory-Optimized TempDB Metadata:

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED_TEMPDB_METADATA = ON;

4. Fine-Tune Parallelism Settings 🏃‍♂️

SQL Server 2022 offers more granular control over parallelism, which can improve the performance of complex queries by better utilizing CPU resources.

Setting MAXDOP (Maximum Degree of Parallelism):

-- Setting MAXDOP for the server
EXEC sys.sp_configure 'max degree of parallelism', 8;
RECONFIGURE;

-- Setting MAXDOP for a specific query
SELECT * 
FROM LargeTable 
OPTION (MAXDOP 4);

Solving Previous Issues with SQL Server 2022 🔄

1. Resolving Parameter Sniffing Issues 🎯

Parameter sniffing can lead to suboptimal plans being reused, causing performance issues. SQL Server 2022’s Parameter Sensitive Plan Optimization addresses this by creating multiple plans for different parameter values.

Example T-SQL Query:

-- Enabling Parameter Sensitive Plan Optimization
ALTER DATABASE SCOPED CONFIGURATION 
SET PARAMETER_SENSITIVE_PLAN_OPTIMIZATION = ON;

2. Handling Query Store Performance Overhead 📈

The Query Store feature in SQL Server 2022 has been enhanced to minimize performance overhead while still capturing valuable query performance data.

Best Practices:

  • Limit Data Capture: Configure Query Store to capture only significant queries to reduce overhead.
  • Use Read-Only Secondary Replicas: Leverage Always On Availability Groups to offload Query Store data collection to read-only replicas.

Business Use Case: E-Commerce Platform 🛒

Consider an e-commerce platform experiencing slow query performance during peak shopping seasons. By implementing SQL Server 2022’s performance tuning features, the platform can:

  • Improve Checkout Process Speed: Use IQP features like Batch Mode on Rowstore to optimize complex analytical queries that calculate discounts and shipping costs.
  • Enhance Product Search Efficiency: Utilize Adaptive Joins to dynamically optimize search queries based on the data distribution of products.
  • Reduce Database Contention: Apply TempDB optimization techniques to handle the high volume of temporary data generated during transactions.

Conclusion 🎉

SQL Server 2022 offers a wealth of new features and enhancements designed to optimize performance and solve long-standing issues. By leveraging Intelligent Query Processing, Automatic Plan Correction, and other tuning tips, you can achieve significant performance gains without extensive code changes. Whether you’re running a high-traffic e-commerce platform or a complex analytical workload, these tuning tips can help you get the most out of your SQL Server 2022 environment.

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.