May 5, 2010 at 4:36 pm
This is a strange one. I'm tracing a proc in profiler and it seems that it's double counting reads for a specific set of statements.
In my proc, I have the following two lines:
select @sql = 'insert into lookups (fieldname) select distinct '+QUOTENAME(@fieldname)+' from '+QUOTENAME(@tablename)+' where '+QUOTENAME(@fieldname)+' IS NOT NULL and ltrim(rtrim(convert(nvarchar(max),'+QUOTENAME(@fieldname)+'))) <> ''\'''
exec /*test*/ sp_executesql @sql
Now, in profiler I see the following two lines:
TextData
insert into lookups (fieldname) select distinct [languages] from
where [languages] IS NOT NULL and ltrim(rtrim(convert(nvarchar(max),[languages]))) <> '\'
exec /*test*/ sp_executesql @sql
Reads
58161
58161
I used /*test*/ in my exec line to be sure I was seeing the correct sp_executesql call. I'm not sure where to look for answers to this, or even how I would google this... So I turn to you folks.
Any help is hugely appreciated!
May 5, 2010 at 8:16 pm
what events are you tracing? You could see this if you were tracing statement and rpc complete, for example.
"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
May 5, 2010 at 11:30 pm
Contrary to popular belief, the reads are usually the result of an index or two on the table you're inserting into. There could also be a trigger on the table.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 6, 2010 at 5:20 am
Jeff Moden (5/5/2010)
Contrary to popular belief, the reads are usually the result of an index or two on the table you're inserting into. There could also be a trigger on the table.
Not to mention any referential integrity checks that could go against other tables.
But based on what they said, and the way it was said, it almost sounded like they were seeing two rows worth of information in the trace output. That sounds like multiple events to me.
"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
May 6, 2010 at 8:04 am
I double checked to make sure I wasn't looking at two different event classes, and both are SP:StmtCompleted.
HTH
May 6, 2010 at 8:09 am
SwedishOrr (5/6/2010)
I double checked to make sure I wasn't looking at two different event classes, and both are SP:StmtCompleted.HTH
If you're seeing two SP:StmtCompleted entries, then you've got two statements that are completing. Double-check the code.
"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
May 6, 2010 at 8:18 am
Its not double counting...
Its telling you that to do the insert command it has done 58k reads.
Also it is telling you that the total amount of reads for the "exec sp_executesql" statement is 58k.
The "parent" statements are always the sum of the child statements.
May 6, 2010 at 8:24 am
In my proc, I have the following two lines:
select @sql = 'insert into lookups (fieldname) select distinct '+QUOTENAME(@fieldname)+' from '+QUOTENAME(@tablename)+' where '+QUOTENAME(@fieldname)+' IS NOT NULL and ltrim(rtrim(convert(nvarchar(max),'+QUOTENAME(@fieldname)+'))) <> ''\'''
exec /*test*/ sp_executesql @sql
How many StmtCompleted events are logged if you remove the "insert into lookups (fieldname)" portion of the statement and just execute the "select distinct ..." ?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 14, 2010 at 10:04 am
Sorry for the delay in reply. It looks like Dave is correct for my situation. Adding up each line and comparing to the total shows that Profiler is not double counting the reads.
Thanks all!
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply