Posted by

Posted on

June 4, 2026

Posted under

Core

Comments

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:

A normal compressed backup
A ZSTD backup with the default compression level
A ZSTD backup with MEDIUM compression level
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.

Posted by

Vivek Janakiraman

Posted on

August 3, 2024

Posted under

SQL Server 2022

Comments

Deploying and Managing SQL Server 2022 on Kubernetes: A Comprehensive Guide

Kubernetes has become a popular choice for managing containerized applications, and SQL Server 2022 is no exception. This guide will walk you through deploying and managing SQL Server 2022 on Kubernetes, offering examples and screenshots to illustrate the process.

🛠️ Prerequisites

Before diving into the deployment, ensure you have the following:

Kubernetes Cluster: A running Kubernetes cluster (e.g., Minikube, Azure Kubernetes Service, Amazon EKS).
kubectl: The Kubernetes command-line tool, installed and configured.
Docker: Installed for container image management.

🏗️ Step-by-Step Deployment

1. Create a Namespace

Namespaces in Kubernetes help organize your resources. Let’s create one for SQL Server:

kubectl create namespace sqlserver

2. Persistent Storage Setup

SQL Server requires persistent storage for data. We’ll use Persistent Volume (PV) and Persistent Volume Claim (PVC).

Persistent Volume (PV) Definition:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: sql-pv
  namespace: sqlserver
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/sqlserver

Persistent Volume Claim (PVC) Definition:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sql-pvc
  namespace: sqlserver
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

Apply these configurations:

kubectl apply -f sql-pv.yaml
kubectl apply -f sql-pvc.yaml

3. Deploying SQL Server 2022

Create a Deployment manifest for SQL Server:

Deployment YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sqlserver-deployment
  namespace: sqlserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sqlserver
  template:
    metadata:
      labels:
        app: sqlserver
    spec:
      containers:
      - name: sqlserver
        image: mcr.microsoft.com/mssql/server:2022-latest
        ports:
        - containerPort: 1433
        env:
        - name: ACCEPT_EULA
          value: "Y"
        - name: MSSQL_SA_PASSWORD
          value: "YourStrongPassword!"
        volumeMounts:
        - name: mssql-data
          mountPath: /var/opt/mssql
      volumes:
      - name: mssql-data
        persistentVolumeClaim:
          claimName: sql-pvc

Apply the deployment:

kubectl apply -f sqlserver-deployment.yaml

4. Exposing SQL Server

To access SQL Server externally, create a Service:

Service YAML:

apiVersion: v1
kind: Service
metadata:
  name: sqlserver-service
  namespace: sqlserver
spec:
  type: LoadBalancer
  ports:
  - port: 1433
    targetPort: 1433
  selector:
    app: sqlserver

Apply the service configuration:

kubectl apply -f sqlserver-service.yaml

🔍 Managing SQL Server on Kubernetes

1. Scaling

To scale SQL Server instances, modify the replicas field in the Deployment YAML:

spec:
  replicas: 3

Apply the changes:

kubectl apply -f sqlserver-deployment.yaml

2. Monitoring

Monitor the SQL Server pods and services using kubectl:

kubectl get pods -n sqlserver
kubectl get svc -n sqlserver

For detailed logs:

kubectl logs <pod-name> -n sqlserver

3. Updating SQL Server Image

To update the SQL Server container image, modify the image field in the Deployment YAML and apply the changes:

image: mcr.microsoft.com/mssql/server:2022-latest

kubectl apply -f sqlserver-deployment.yaml

4. Backup and Restore

Backup: Use the sqlcmd tool or any SQL Server Management tool to perform a backup.

Restore: Similarly, use sqlcmd or another tool to restore from a backup.

Example backup command:

BACKUP DATABASE [YourDatabase] TO DISK = '/var/opt/mssql/backup/YourDatabase.bak'

🏁 Conclusion

Deploying and managing SQL Server 2022 on Kubernetes provides flexibility and scalability for your containerized environments. By following the steps outlined in this guide, you can set up SQL Server, scale it, monitor performance, and perform backups and updates with ease.

Kubernetes and SQL Server 2022 together form a powerful combination for modern cloud-native applications. If you have any questions or run into issues, feel free to explore the official documentation or community forums. Happy deploying! 🚀

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

Posted by

Vivek Janakiraman

Posted on

July 24, 2024

Posted under

Core

Comments

Understanding Max Server Memory and Minimum Server Memory in SQL Server

SQL Server’s memory management is a crucial aspect of its performance and stability. Two important settings in this context are Max Server Memory and Minimum Server Memory. These settings help SQL Server efficiently manage its memory usage, ensuring optimal performance and avoiding system instability.

What is Max Server Memory?

Max Server Memory limits the amount of memory that SQL Server can use for its operations. This setting helps prevent SQL Server from consuming too much memory, which could negatively impact the operating system and other applications running on the same server.

Importance of Max Server Memory

System Stability: By capping the memory usage, you ensure that enough memory is available for the OS and other applications, preventing system-wide slowdowns or crashes.
Performance Optimization: Properly configuring Max Server Memory allows SQL Server to use memory efficiently, reducing the need for frequent data disk reads and writes, which can significantly slow down performance.
Resource Allocation: In environments where SQL Server shares resources with other applications, setting an appropriate Max Server Memory ensures fair resource distribution.

Calculating and Setting Max Server Memory

To start, you should leave enough memory for the operating system and any other applications. A common approach is to allocate at least 4 GB or 10% of total system memory (whichever is larger) to the OS. The rest can be allocated to SQL Server as Max Server Memory.

Example Calculation: Suppose you have a server with 32 GB of RAM:

Allocate memory for the OS and other applications:
- 4 GB (minimum recommended) or 10% of 32 GB = 3.2 GB
- Choosing the larger value: 4 GB
Subtract this from the total RAM:
- 32 GB – 4 GB = 28 GB
Set Max Server Memory to 28 GB.

Setting Max Server Memory in SQL Server: You can set Max Server Memory using SQL Server Management Studio (SSMS) or T-SQL commands:

Using SSMS:
1. Open SSMS and connect to your SQL Server instance.
2. Right-click on the server name and select “Properties.”
3. Navigate to the “Memory” tab.
4. Set the “Maximum server memory (in MB)” to the calculated value.
Using T-SQL:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max server memory', 28672; -- Set to 28 GB (28 * 1024 MB)
RECONFIGURE;

What is Minimum Server Memory?

Minimum Server Memory specifies the minimum amount of memory SQL Server should attempt to reserve after it has started. However, it’s worth noting that SQL Server doesn’t start with this memory allocation; instead, it gradually grows its memory usage up to this amount as needed.

Importance of Minimum Server Memory

Ensuring Performance: Setting a minimum ensures that SQL Server has enough memory for its operations, which is crucial for maintaining performance under varying workloads.
Avoiding Memory Pressure: It helps avoid situations where SQL Server might have to give up memory under pressure, which could degrade performance.

Potential Issues with Incorrect Settings

Setting Max Server Memory Too High: This can lead to insufficient memory for the OS and other applications, causing system instability, swapping, and even crashes.
Setting Max Server Memory Too Low: SQL Server might not have enough memory for optimal performance, leading to excessive disk I/O, slower queries, and reduced throughput.
Incorrect Minimum Server Memory: If set too high, it can reserve more memory than necessary, potentially starving other processes. If set too low, SQL Server might not have enough resources to function efficiently under load.

Best Practices

Monitor and Adjust: Regularly monitor memory usage and adjust settings based on the workload and system performance.
Consider the Entire System: Take into account the memory requirements of the OS and other applications on the server.
Start Conservative: Begin with a conservative estimate and gradually increase Max Server Memory as needed, observing the system’s behavior.

In conclusion, correctly configuring Max Server Memory and Minimum Server Memory is vital for SQL Server’s performance and the overall system’s stability. By carefully calculating and setting these values, you can ensure a balanced and efficient use of resources, providing a stable and high-performing environment for your SQL Server workloads.

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