April 29, 2008 at 5:09 am
I'm troubleshooting a performance issue , Looking at Profiler - for the given statement, I'm getting the following figures , why would there be such a disparity between the figures. ? How can I go about finding out why there is such difference?
SQL:Stmt Completed:CPU = 31, Reads = 129 , Duration = 32
SQL:Batch Completed: CPU = 2531, Reads = 6087 , Duration = 2593
http://www.ITjobfeed.com
April 29, 2008 at 5:48 am
A statement is a single piece of work, whereas a batch is a whole set of work.
So, for example:
DECLARE @Id INT;
SET @ID = 52;
SELECT *
FROM dbo.MyTable
WHERE Id = @Id;
That is one batch with three statements. You'll see a difference in execution results between the batch as a whole and the SET statement. Usually, unless you've got very specific troubleshooting going on, you don't want to collect statement level information using Profiler. It's very processor intensive.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 29, 2008 at 5:53 am
Thanks for the reply , with the figures I sent across there is just the 1 sql server statement , which I'm confused about the disparity between the the statement completing and then the Batch completing.
http://www.ITjobfeed.com
April 29, 2008 at 6:45 am
I'd have to see the procedure to understand why you're getting a difference. But I think, and I could be wrong about this, the batch includes the commit, but the statement doesn't.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 29, 2008 at 7:32 am
The statement I'm running from Query Analyzer is :
SELECT myCo1,myCol2 FROM myTable
INNER JOIN MyTable2 ON myTable.thecol = myTable2.thecol
Is there a specific event that would display the COMMIT ?
http://www.ITjobfeed.com
April 29, 2008 at 9:12 am
No, it's an implicit commit. I just got the same results. I ran this query against Adventureworks:
SELECT soh.[SalesOrderID]
,sod.[SalesOrderDetailID]
FROM Sales.[SalesOrderHeader] soh
INNER JOIN [Sales].[SalesOrderDetail] sod
ON soh.[SalesOrderID] = sod.[SalesOrderID]
I captured the batch and the statement. In the example, the statement had CPU = 16 and the batch had CPU = 31. The batch, I believe (I've looked at the documentation and can't find anything supporting that or denying it), simply includes all the time & cost to commit of the query where as the statement only has the minimal entries for the statement. Regardless, I would only use the statements if you had particular issues within a procedure or batch that you couldn't identify without having the full set of statements. The batch or rpc call events usually have all the data you need.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 30, 2008 at 9:29 am
Would the batch-level include parsing and query plan determination / selection?
April 30, 2008 at 9:34 am
Probably. I couldn't find good documentation on the detail of this, but my understanding is, the batch or rpc complete events include all the server side processing, beginning to end. Statement on the other hand only measures for that individual statement. I still wish I had a definitive answer, but that's my understanding.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply