<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: The Ultimate Strategy of Tuning Store Procedure Performance</title>
	<atom:link href="http://www.siusic.com/wphchen/the-ultimate-strategy-of-tuning-store-procedure-performance-46.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.siusic.com/wphchen/the-ultimate-strategy-of-tuning-store-procedure-performance-46.html</link>
	<description>Random thoughts and news by Andrew Chen and friends</description>
	<pubDate>Fri, 30 Jul 2010 21:51:47 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Andrew  Chen</title>
		<link>http://www.siusic.com/wphchen/the-ultimate-strategy-of-tuning-store-procedure-performance-46.html#comment-31</link>
		<dc:creator>Andrew  Chen</dc:creator>
		<pubDate>Thu, 25 Jan 2007 18:27:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.siusic.com/wphchen/the-ultimate-strategy-of-tuning-store-procedure-performance-46.html#comment-31</guid>
		<description>I finally found a chance to test out the way to use profiler trace that you suggest. I actually try that way long time ago and I even forgot about why I didn’t may use of it. 

But I still come to the same conclusion. I don’t think that kind of tracing is helpful for complex store procedure tuning. In fact in that kind of trace profiler displays every single statement executed within the store procedure. So if your store procedure has cursor operations, loops and nested call to other store procedures and functions then the trace result could be many thousands lines of text. It could be a lot more in fact. How are you going to make use of it? 

I am not talking about simple store procedures. The result is that you could not get a big picture of how the store procedure is written and which piece of code should be rewritten to improve performance. 

I still believe in my ultimate strategy. It have help me solved numerous performance tuning problems.</description>
		<content:encoded><![CDATA[<p>I finally found a chance to test out the way to use profiler trace that you suggest. I actually try that way long time ago and I even forgot about why I didn’t may use of it. </p>
<p>But I still come to the same conclusion. I don’t think that kind of tracing is helpful for complex store procedure tuning. In fact in that kind of trace profiler displays every single statement executed within the store procedure. So if your store procedure has cursor operations, loops and nested call to other store procedures and functions then the trace result could be many thousands lines of text. It could be a lot more in fact. How are you going to make use of it? </p>
<p>I am not talking about simple store procedures. The result is that you could not get a big picture of how the store procedure is written and which piece of code should be rewritten to improve performance. </p>
<p>I still believe in my ultimate strategy. It have help me solved numerous performance tuning problems.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew Chen</title>
		<link>http://www.siusic.com/wphchen/the-ultimate-strategy-of-tuning-store-procedure-performance-46.html#comment-24</link>
		<dc:creator>Andrew Chen</dc:creator>
		<pubDate>Sat, 06 Jan 2007 21:48:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.siusic.com/wphchen/the-ultimate-strategy-of-tuning-store-procedure-performance-46.html#comment-24</guid>
		<description>I don't remember for what reason I have this thought or maybe a misconception that the duration given on the statements tracing didn't really reflects the real time that a client experience. Your post certainly opens my eye. Thanks for the response.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t remember for what reason I have this thought or maybe a misconception that the duration given on the statements tracing didn&#8217;t really reflects the real time that a client experience. Your post certainly opens my eye. Thanks for the response.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Whigham</title>
		<link>http://www.siusic.com/wphchen/the-ultimate-strategy-of-tuning-store-procedure-performance-46.html#comment-23</link>
		<dc:creator>Scott Whigham</dc:creator>
		<pubDate>Sat, 06 Jan 2007 15:54:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.siusic.com/wphchen/the-ultimate-strategy-of-tuning-store-procedure-performance-46.html#comment-23</guid>
		<description>Interesting approach but it sure seems you're going about this the "long way." If you want to eliminate this step of copy/pasting the source code and having to find all the myraid calls to the proc, I would suggest that you set Profiler to trace the SP:Statement(s) events instead of the SP:Completed or RPC:Completed events. Once you do that, save the trace as a table, and then query the "Duration" column (or the StartTime/EndTime). Problem solved without any code writing!</description>
		<content:encoded><![CDATA[<p>Interesting approach but it sure seems you&#8217;re going about this the &#8220;long way.&#8221; If you want to eliminate this step of copy/pasting the source code and having to find all the myraid calls to the proc, I would suggest that you set Profiler to trace the SP:Statement(s) events instead of the SP:Completed or RPC:Completed events. Once you do that, save the trace as a table, and then query the &#8220;Duration&#8221; column (or the StartTime/EndTime). Problem solved without any code writing!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
