Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
scuzymoto
Starting Member
17 Posts |
 Posted - 2009-09-02 : 13:39:11
|
| I was researching the performance counter stat Batch Requests/sec and found some interesting documentation. http://support.microsoft.com/kb/936637This article states that if multiple RPC arrive in a single batch then most versions of SQL Server will count the RPCs individually even though they are in a single batch.Now, help me out here. Wouldn't a single RPC also be capable of containing more than one batch when you consider that according to books online a batch is simply more than one sql statement.So... an RPC can contain more than one batch but a batch may also contain more than one RPC correct? Please correct me if I am wrong here. I realize this question may lead to another discussion, the true difference between a procedure and a remote procedure call. |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2009-09-02 : 13:48:51
|
quote:
Wouldn't a single RPC also be capable of containing more than one batch when you consider that according to books online a batch is simply more than one sql statement.
Technically no. It's a stored procedure call, or the equivalent. A stored procedure may have multiple statements, but they wouldn't count as a new batch because the procedure call is done once. For RPCs, a new batch is inferred by enlisting a remote or linked server, once for each RPC. I'm not sure that's the actual reason but it sounds sensible to me.quote:
So... an RPC can contain more than one batch
Not if my theory is correct.quote:
but a batch may also contain more than one RPC correct?
Correct. |
 |
|
|
scuzymoto
Starting Member
17 Posts |
Posted - 2009-09-02 : 14:14:46
|
| Your theory sounds very logical which is why I posed the original question. But what if your stored procedure has a 'go' statement which according to books online separates your statements into unique batches. The behavior of certain statements precludes them from being submitted in the same batch, yet from an application functionality standpoint you may want them in the same stored procedure. So if a procedure has a go wouldn't this cause a single RPC to contain more than one batch?? |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2009-09-02 : 15:11:50
|
quote:
But what if your stored procedure has a 'go' statement which according to books online separates your statements into unique batches.
GO is not a command, and cannot be contained in a procedure. If you put GO in a stored procedure it would signal the end of the CREATE PROCEDURE definition. Any statements that appear afterward are not part of the sproc. |
|
|
|
scuzymoto
Starting Member
17 Posts |
Posted - 2009-09-02 : 15:32:26
|
| That clears it up! Thanks |
|
|
|
scuzymoto
Starting Member
17 Posts |
Posted - 2009-09-02 : 15:49:57
|
| So not to beat a dead horse but to close the topic. If I were to nest CLR code or other procs within my proc (recursion for example) in order to achieve specific application functionality. The profiler would see these nested procs as unique RPC. So in truth, while a batch may contain multiple RPC, a single RPC will never contain more than one batch. Thanks again, for helping me think that through. The following blog post triggered my original question. http://zombieware.blogspot.com/2009/08/whats-good-depends-on-whats-normal.html |
|
|
|
|
|
|
|
|
RPC vs Batch vs Procedure