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
  1. 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.
  2. 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.
  3. 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:

  1. 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
  2. Subtract this from the total RAM:
    • 32 GB – 4 GB = 28 GB
  3. 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
  1. Ensuring Performance: Setting a minimum ensures that SQL Server has enough memory for its operations, which is crucial for maintaining performance under varying workloads.
  2. 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

  1. 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.
  2. 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.
  3. 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

  1. Monitor and Adjust: Regularly monitor memory usage and adjust settings based on the workload and system performance.
  2. Consider the Entire System: Take into account the memory requirements of the OS and other applications on the server.
  3. 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

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.

SQL Server Always On Series: Availability group DDL operations are permitted only when you are using the master database


Introduction

During a recent attempt to perform a manual failover from Always On Availability Group from JBSAG1 to JBSAG2 using Microsoft SQL Server Management Studio (SSMS), an unexpected error disrupted the process. The error, specifically identified as Microsoft SQL Server Error 35208, posed a challenge to the manual failover operation. In this detailed account, we’ll explore the encountered issue, outline the steps taken to address it, and ultimately achieve a successful manual failover.

Issue
Upon initiating the Always On Availability Group manual failover, the process encountered a hurdle with the following error:

TITLE: Microsoft SQL Server Management Studio
Manual Failover failed (Microsoft.SqlServer.Management.HadrTasks)

ADDITIONAL INFORMATION:
Failed to perform a manual failover of the availability group ‘JBSWiki’ to server instance ‘JBSAG2’. (Microsoft.SqlServer.Management.HadrModel)

For help, click: https://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=16.100.47021.0&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&LinkId=20476

An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)

Availability group DDL operations are permitted only when you are using the master database. Run the ‘USE master’ statement, and retry your availability group DDL statement. (Microsoft SQL Server, Error: 35208)
For help, click: https://docs.microsoft.com/sql/relational-databases/errors-events/mssqlserver-35208-database-engine-error

Navigating through this error was the initial challenge, particularly when attempting the failover using the SSMS graphical user interface (GUI). Executing the ‘USE master’ statement in this context presented uncertainties, prompting a reevaluation of the failover approach.

Solution
To address the dilemma, the following steps were taken:

GUI Failover Attempt:

  • Initially, the failover was attempted through the SSMS GUI, raising questions about how to execute the ‘USE master’ statement within the graphical interface.

Scripted Failover Action:

  • The failover wizard was restarted, and instead of concluding the process through the GUI, the failover action was scripted for manual execution. I started the failover wizard again and this time instead of clicking finish at the end, tried scripting the failover action.

Manual Execution of Failover Command:

  • The failover command was manually executed from the SSMS SQLCMD query window, successfully completing the failover process.

Database Context Discovery:

  • Investigation revealed that the database context for a new query window was set to a user database (JBDB) instead of ‘master,’ leading to a pivotal realization. I tried clicking on a new query window and I saw that the database context for that query window was set to an user database JBDB and not master.

Connection Options Adjustment:

  • This is when I realized that I might have connected to the SQL Server instance with an User Database specified on the “Connect to database” in “Options <<” as part of making a connection from SSMS. Please check screenshot below,

After realizing this, I disconnected the existing sessions on SSMS and changed “Connect to database” in “Options <<” to “Master” and connected to SQL server JBSAG1 and JBSAG2.

Success After Correction:

  • Following these corrective actions, subsequent manual failover and failback attempts via SSMS were executed seamlessly.

Summary
In summary, this journey through troubleshooting manual failover with error 35208 underscored the importance of the database context, especially when initiating DDL operations. The solution involved a meticulous adjustment of connection options within SSMS, ensuring a connection to the ‘master’ database before attempting manual failover. This article provides a detailed account of the encountered challenge, the thought process behind the solution, and the successful resolution achieved through careful steps and insights.

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.