In this article, we explored the role and importance of SET NOCOUNT in SQL Server, discussing how it reduces the processing load on the client side and improves query execution time. In addition, we examine scenarios that require the use of SET NOCOUNT OFF, and highlight potential problems that can arise when SET NOCOUNT is not used.
Understanding SET NOCOUNT in SQL Server
Explanation of what SET NOCOUNT is
Each time a DML command is executed, a short message is sent back to the client indicating the number of rows affected by the query.
The SET NOCOUNT statement is used in SQL Server to control the generation of the "X rows affected" message returned by default after executing the SQL statement. When SET NOCOUNT ON is enabled, it disables the message from being returned in the result set, and when SET NOCOUNT OFF is set or not specified, the message will be included in the result set.
The role of SET NOCOUNT ON in SQL Server
The main purpose of using SET NOCOUNT ON is to improve the performance and efficiency of SQL Server queries and stored procedures. SET NOCOUNT ON is commonly used for several reasons:
- Reduced network traffic: When executing SQL statements from a client application, the row count message may generate additional network traffic because it needs to be transmitted from the server to the client. By using SET NOCOUNT ON, you can reduce the amount of data transferred and improve overall network performance.
- Reduced load on client applications: By using SET NOCOUNT ON, these row count messages can be suppressed, simplifying communication between SQL Server and client applications. This way, the client application can focus only on retrieving the actual result data without parsing or processing the row count information.
- Improved execution time: Returning a row count for each affected row can increase processing overhead, especially for queries or operations involving large numbers of rows. By suppressing row count messages, you can improve execution time by eliminating this extra processing.
- Enhanced readability of result sets: When executing multiple T-SQL statements or stored procedures in a batch or script, row count messages can clutter the result set and make interpretation of the actual result more difficult. By using SET NOCOUNT ON, you can keep the result set clean and focus on the relevant data.
Note that
setting SET NOCOUNT ON does not disable the actual execution of the T-SQL statement or affect the accuracy of the results. It only suppresses row count messages.
Effect of not using SET NOCOUNT ON
When SET NOCOUNT is not used in SQL Server, row count messages are included in the result set of every executed statement, which increases network traffic, clutters the result set, and complicates data processing. Also, not using SET NOCOUNT can cause buffer overflow problems.
buffer overflow problem
Row count messages must be handled by the client application. When row count messages are generated and transmitted for each T-SQL statement, and a large number of statements are executed or large result sets are processed, the accumulation of these messages may reach the capacity limit of the buffer.
As a result, the buffer cannot handle incoming row count messages, causing query execution to stall until the client has read all accumulated row count messages. Once the client has consumed all of the accumulated row count messages, SQL Server resumes execution because memory is now available in the output buffer.
To work around this, you can use the SET NOCOUNT ON option to suppress the generation of row count messages. This effectively reduces the memory required to buffer results, thereby significantly reducing the risk of buffer overflows.
Situations where SET NOCOUNT ON must be set
In some cases, using SET NOCOUNT ON is absolutely necessary. Let us consider the case of designing a high-performance middle-tier system that relies on asynchronous processing, utilizing the thread pool through SqlClient's BeginExecuteXXX methods. In this case, a key issue arises with row counts.
Here's how it works: The BeginExecute method is designed to complete as soon as the server returns the first response packet. However, when we call the EndExecuteXXX method, it waits for the non-query request to complete before considering the call complete. It is important to note that each row count response is considered a separate response.
Now, let's consider a case with a program of moderate complexity. The first row count may be received within 10 milliseconds, while the entire call can take up to 500 milliseconds to complete. Herein lies the problem: instead of the asynchronously submitted request callback happening after 500 milliseconds, it happens after just 5 milliseconds. However, the callback gets stuck in the EndExecuteXXX method for the remaining 495 milliseconds. As a result, the asynchronous call completes prematurely and ends up blocking the thread in the thread pool in the EndExecuteNonQuery call. This unfortunate chain of events can lead to thread pool starvation.
The good news is that SET NOCOUNT ON implemented in these specific scenarios can make a big difference. It has been reported that high performance systems can increase throughput from hundreds to thousands of calls per second with just proper utilization of SET NOCOUNT ON. This small but important change ensures that asynchronous calls are handled optimally, avoiding premature completion and thread blocking, ultimately leading to a more efficient and scalable system.
Situations where SET NOCOUNT OFF may be required
While SET NOCOUNT ON is generally recommended for performance optimization and reducing network traffic, in some cases setting SET NOCOUNT OFF becomes critical. Here are some examples:
- Compatibility with legacy code: If you are using legacy applications or code that relies on receiving row count messages in result sets, you may want to set SET NOCOUNT OFF to maintain compatibility and ensure that your application behaves as expected.
- Required Row Count Information: In some cases, client applications or downstream processes may rely on row count information provided by row count messages. If this information is critical to your application's logic or reporting purposes, you may want to set SET NOCOUNT OFF to include row count messages in the result set.
- Debugging and Troubleshooting: When investigating performance issues or troubleshooting specific queries, it can be helpful to access row count messages to understand the impact of each executed statement. In this case, setting SET NOCOUNT OFF allows you to analyze row count information for diagnostic purposes.
- Specific reporting requirements: If your reporting framework or tool relies on row count messages to generate accurate reports or metrics, you may want to use SET NOCOUNT OFF to ensure the required row count information is available for reporting purposes.
In the past, setting NOCOUNT OFF had to be forced in some cases, especially in older technologies like BDE (Borland Database Engine).
Best Practices for Using SET NOCOUNT
To optimize performance, Microsoft recommends using SET NOCOUNT ON optionally at the session level to prevent transmission of these row count messages. This is especially useful for stored procedures that contain multiple statements that do not return much actual data. By eliminating these messages, performance can be significantly improved because network traffic and client load are greatly reduced.
In general, it is recommended to avoid sending row count messages unless required. However, adapting to legacy applications that rely on and sometimes misuse these messages can present challenges.
What are the performance benefits of using SET NOCOUNT ON?
The performance advantage of using SET NOCOUNT ON can vary on a case-by-case basis. The extent of the performance benefit depends on factors such as the number and frequency of queries executed during the process. For example, if a procedure uses a cursor to execute a large number of queries and combine their results into the final query output, or if the procedure contains multiple statements that do not produce large amounts of data, performance can be improved by up to ten times compared to using a cursor with NOCOUNT OFF. This improvement is primarily due to a reduction in network traffic.
However, if the procedure contains only one or two queries, the performance gain achieved by using SET NOCOUNT ON will be less noticeable, usually less than five percent.
Why enabling NOCOUNT at the instance level is not a good solution
These days, you can enable NOCOUNT at the instance level, and modern ORM (object-relational mapping) frameworks are perfectly capable of handling it efficiently. The following query sets the behavior of SET NOCOUNT ON at the instance level.
EXEC sys.sp_configure 'user options', '512'; RECONFIGURE
Note
that the user options setting is a bitmask, please handle accordingly.
However, enabling NOCOUNT at the instance level may be considered a bad idea for several reasons:
Possibility to override settings: If users specify NOCOUNT ON/OFF in a single session, they can override the behavior configured at the instance level.
Compatibility issue: Enabling NOCOUNT at the instance level may have an impact on legacy applications or components that rely on row count messages. Changing the instance-level setting may cause compatibility issues or unexpected behavior if these applications expect and rely on the returned row count messages.
UNINTENDED CONSEQUENCES: Changing the instance-level setting to enable NOCOUNT may affect all user sessions started after the modification. Unintended consequences may occur if certain components or procedures are not designed to handle the absence of row count messages. It is critical to thoroughly test and evaluate the impact of this change on existing systems.
ORM or framework compatibility: ORM frameworks or other database-related tools may have specific requirements or assumptions about the availability of row count messages. Enabling NOCOUNT at the instance level may break the functionality of these frameworks and cause compatibility issues.
Limited control for specific scenarios: Enabling NOCOUNT at the instance level affects all sessions and databases on that instance. This lack of granularity can create problems when dealing with specific scenarios or databases that require or require row count messages for reporting, monitoring, or other purposes.
our suggestion
We recommend not enabling NOCOUNT at the instance level, but selectively SET NOCOUNT ON in related stored procedures, triggers, or queries. This allows finer-grained control over when row count messages are suppressed, ensuring compatibility, maintaining expected behavior, and avoiding potential problems caused by global instance-level changes. Explicitly setting NOCOUNT ON adds additional guarantees for efficient query execution and client-side processing.
By adding SET NOCOUNT ON at the beginning of every stored procedure, trigger, and dynamic execution batch, you follow a consistent approach and help avoid any potential problems that might arise from not explicitly setting it. This is a proactive approach to optimizing SQL Server queries, improving performance and ensuring a smooth experience for applications and users.
dbForge Studio for SQL Server provides a built-in T-SQL analyzer that checks SQL code for potential problems, errors, or violations of best practices. It includes two static code analysis rules specifically designed to identify potential misuses of the SET NOCOUNT command:
- PF008: DML in stored procedures and triggers not preceded by SET NOCOUNT ON
This rule checks for instances of DML statements in stored procedures and triggers not preceded by the SET NOCOUNT ON command. It helps to ensure that the appropriate SET NOCOUNT ON command is applied before performing a DML operation. - PF009: SET NOCOUNT OFF option used
This rule verifies that the SET NOCOUNT OFF option is used correctly. It ensures that the SET NOCOUNT OFF command is used only when necessary, taking into account its potential impact on network traffic and performance.
These T-SQL analysis rules provide invaluable assistance in identifying and resolving any potential problems associated with the use of SET NOCOUNT in SQL Server code.
in conclusion
The SET NOCOUNT ON command plays a vital role in optimizing SQL Server performance by reducing network traffic, reducing client load, and enhancing query execution. With its built-in T-SQL Analyzer, dbForge Studio for SQL Server can provide valuable insights into potential misuse of the SET NOCOUNT command, ensuring code compliance and performance optimization.