The Batches Received (Per Second) metric counts the total number of batch requests that the SQL Server computer receives per second. This rate is a measurement of throughput on the processor.

This metric uses the counter Batch requests/sec from the SQL Server SQL Statistics counter object. On SQL Server 2000 instances, this counter is available through sysperfinfo. On SQL Server 2005 or later instances, this counter is available through sys.dm_os_performance_counters.

To track this metric, use the CPU Call Rates chart in the CPU dashboard of the Server Overview tab.

While this counter has no good or bad value, each of these T-SQL batches must be:

1. Transmitted to the server using the network.
2. Parsed by SQL Server to check syntax.
3. Have an execution plan compiled.
4. Executed according to the execution plan.
5. Have the results transmitted back to the client computer or Web site.

Reduce the number and impact of T-SQL batches

In this situation, you should reduce the number of T-SQL batches and the impact of each as much as possible by:

• Reducing the size and complexity of the T-SQL by creating a stored procedure containing the commands you want executed and then simply calling it in the T-SQL batch. This approach reduces the size and complexity of the T-SQL batch, which means less network traffic and less CPU time consumed producing a complex execution plan.

• Once you move most of the T-SQL code into stored procedures, consider grouping as many of those calling T-SQL commands into a single network batch, if possible. Also consider redesigning the application to call only those stored procedures you need to complete an application function all from within one batch rather than sending each EXECUTE statement to execute separately in its own batch. This strategy reduces network queues dramatically as better use is made of the default 4 KB network packet size.