<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://www2.sqlblog.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Linchi Shea</title><link>http://www2.sqlblog.com/blogs/linchi_shea/default.aspx</link><description>Checking out SQL Server via empirical data points</description><dc:language>en</dc:language><generator>CommunityServer 2.1 SP2 (Build: 61129.1)</generator><item><title>Clustering every SQL Server instance</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/02/10/clustering-every-sql-server-instance.aspx</link><pubDate>Sat, 11 Feb 2012 03:32:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41692</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>32</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/41692.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=41692</wfw:commentRss><description>You may disagree, but I believe it is a good practice to cluster all the SQL Server instances. That is, even when you plan to run a SQL Server instance on a single machine, you should install it in a single node cluster. The primary advantage is that...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/02/10/clustering-every-sql-server-instance.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=41692" width="1" height="1"&gt;</description><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Cluster/default.aspx">Cluster</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Kerberos/default.aspx">Kerberos</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Network+Aliases/default.aspx">Network Aliases</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Server+location+transparency/default.aspx">Server location transparency</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/single-node+cluster/default.aspx">single-node cluster</category></item><item><title>Performance impact: the cost of NUMA remote memory access</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/30/performance-impact-the-cost-of-numa-remote-memory-access.aspx</link><pubDate>Mon, 30 Jan 2012 23:17:20 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41450</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>10</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/41450.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=41450</wfw:commentRss><description>These days if you get a new server-class machine to run SQL Server, you can almost be 100% sure that it’ll be running on NUMA hardware. The recent AMD Opteron and Intel Nehalem-based processors are all built on some form of NUMA architecture. The current...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/30/performance-impact-the-cost-of-numa-remote-memory-access.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=41450" width="1" height="1"&gt;</description><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Benchmark/default.aspx">Benchmark</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Local+memory+access/default.aspx">Local memory access</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Memory+speed/default.aspx">Memory speed</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/NUMA/default.aspx">NUMA</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/NUMA+affinity/default.aspx">NUMA affinity</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Remote+memory+access/default.aspx">Remote memory access</category></item><item><title>No respect: NUMA affinity meets query parallelism</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/28/no-respect-numa-affinity-meets-query-parallelism.aspx</link><pubDate>Sat, 28 Jan 2012 05:32:51 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41396</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>6</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/41396.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=41396</wfw:commentRss><description>What happens when NUMA affinity meets query parallelism? It gets no respect! SQL Server allows you to affinitize a TCP port to a specific NUMA node or a group of NUMA nodes. Books Online has an article on How to: Map TCP/IP ports to NUMA Nodes . And this...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/28/no-respect-numa-affinity-meets-query-parallelism.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=41396" width="1" height="1"&gt;</description><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/bug/default.aspx">bug</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/NUMA/default.aspx">NUMA</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/NUMA+affinity/default.aspx">NUMA affinity</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/parallelism/default.aspx">parallelism</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/port+affinity/default.aspx">port affinity</category></item><item><title>T-SQL stored procedure for finding/replacing strings in a text file. Really?</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/27/t-sql-stored-procedure-for-finding-replacing-strings-in-a-text-file-really.aspx</link><pubDate>Fri, 27 Jan 2012 05:33:11 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41375</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>4</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/41375.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=41375</wfw:commentRss><description>I know people have been doing all sorts of things with T-SQL, and I have absolutely no issue with people trying to push the limit of what T-SQL can do, or what you can use it to accomplish, especially when it’s for demonstration or pedagogical purposes,...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/27/t-sql-stored-procedure-for-finding-replacing-strings-in-a-text-file-really.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=41375" width="1" height="1"&gt;</description></item><item><title>Performance impact: SQL2008 R2 audit and trace</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/24/performance-impact-sql2008-r2-audit-and-trace.aspx</link><pubDate>Wed, 25 Jan 2012 03:29:27 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41287</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>4</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/41287.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=41287</wfw:commentRss><description>We are told that SQL Server 2008 R2 Audit (and SQL Server 2008 Audit) has much less performance overhead than SQL Trace when we try to capture the same information. Knowing how SQL Server R2 Audit is implemented (i.e. on top of the extended events infrastructure),...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/24/performance-impact-sql2008-r2-audit-and-trace.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=41287" width="1" height="1"&gt;</description></item><item><title>Performance impact: hyperthreading on Intel Westmere-EP processors (X5690)</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/22/performance-impact-hyperthreading-on-intel-westmere-ep-processors-x5690.aspx</link><pubDate>Sun, 22 Jan 2012 06:41:23 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41215</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>3</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/41215.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=41215</wfw:commentRss><description>Recently, I have been looking into the performance impact of enabling hyperthreading on various platforms with various SQL Server workloads. All the results I have shared so far are from a DL580 G7 with four Westmere-EX&amp;#160; (E7-4870) processors. Overall,...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/22/performance-impact-hyperthreading-on-intel-westmere-ep-processors-x5690.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=41215" width="1" height="1"&gt;</description></item><item><title>Performance impact: not all is better with hyperthreading</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/17/performance-impact-not-all-is-better-with-hyperthreading.aspx</link><pubDate>Tue, 17 Jan 2012 22:57:32 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41147</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>6</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/41147.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=41147</wfw:commentRss><description>In the comments to my previous post on the performance impact of enabling hyperthreading on reporting queries, Serguei Tarassov indicated that it might be interesting to try different reporting queries, and suggested a specific parameterized test query....(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/17/performance-impact-not-all-is-better-with-hyperthreading.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=41147" width="1" height="1"&gt;</description></item><item><title>Performance impact: driving up context switches/sec</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/12/performance-impact-driving-up-context-switches-sec.aspx</link><pubDate>Thu, 12 Jan 2012 05:23:52 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:40981</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>13</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/40981.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=40981</wfw:commentRss><description>Too many context switches per second are considered bad for your database performance. But how many is too many has never been clear. With the core count of new servers going up rapidly, it becomes even less clear how we should evaluate this counter to...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/12/performance-impact-driving-up-context-switches-sec.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=40981" width="1" height="1"&gt;</description><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Benchmark/default.aspx">Benchmark</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Context+Switches/default.aspx">Context Switches</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Testing/default.aspx">Testing</category></item><item><title>Performance impact: hyperthreading for OLTP queries -- II</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/11/performance-impact-hyperthreading-for-oltp-queries-ii.aspx</link><pubDate>Wed, 11 Jan 2012 18:51:17 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:40959</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>8</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/40959.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=40959</wfw:commentRss><description>This is in part a response to a comment by Paul White ( @SQL_Kiwi ) to my previous post on the performance impact of enabling hyperthreading (HT) on OLTP queries , and in part due to my desire to capture a more complete set of test data for future investigation...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/11/performance-impact-hyperthreading-for-oltp-queries-ii.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=40959" width="1" height="1"&gt;</description><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Benchmark/default.aspx">Benchmark</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/hyperthreading/default.aspx">hyperthreading</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Query+Processing/default.aspx">Query Processing</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Testing/default.aspx">Testing</category></item><item><title>Elephant in the room: TPC-E</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/07/elephant-in-the-room-tpc-e.aspx</link><pubDate>Sat, 07 Jan 2012 05:21:44 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:40876</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>11</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/40876.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=40876</wfw:commentRss><description>Over the past few months in several semi-formal occasions, I ran into folks from your well-known vendors (minus Microsoft). Some of the folks were from the vendors’ performance labs and were involved in conducting benchmark tests and publishing benchmark...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/07/elephant-in-the-room-tpc-e.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=40876" width="1" height="1"&gt;</description><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Benchmark/default.aspx">Benchmark</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Rant/default.aspx">Rant</category></item><item><title>Performance impact: hyperthreading for OLTP queries</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/06/performance-impact-hyperthreading-for-oltp-queries.aspx</link><pubDate>Fri, 06 Jan 2012 04:44:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:40853</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>24</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/40853.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=40853</wfw:commentRss><description>My previous post focuses on the performance impact of enabling hyperthreading (HT) on a machine with four Intel Westmere-EX processors on reporting queries. Let’s turn our attention to OLTP queries. To oversimplify it, reporting queries are generally...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/06/performance-impact-hyperthreading-for-oltp-queries.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=40853" width="1" height="1"&gt;</description><enclosure url="http://www2.sqlblog.com/blogs/linchi_shea/attachment/40853.ashx" length="1455" type="application/x-zip-compressed" /><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Benchmark/default.aspx">Benchmark</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/hyperthreading/default.aspx">hyperthreading</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Query+Processing/default.aspx">Query Processing</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Testing/default.aspx">Testing</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/TPC-C/default.aspx">TPC-C</category></item><item><title>Performance impact: hyperthreading for reporting queries</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/05/performance-impact-hyperthreading-for-reporting-queries.aspx</link><pubDate>Thu, 05 Jan 2012 05:36:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:40817</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>16</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/40817.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=40817</wfw:commentRss><description>There are a lot of questions on hyperthreading, but not a lot of answers. There is no shortage of opinions, but very few are based on significant first hand experience or solid test data. We know that the hyperthreading technology in the older generations...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/05/performance-impact-hyperthreading-for-reporting-queries.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=40817" width="1" height="1"&gt;</description><enclosure url="http://www2.sqlblog.com/blogs/linchi_shea/attachment/40817.ashx" length="1381" type="application/x-zip-compressed" /><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Benchmark/default.aspx">Benchmark</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/HT/default.aspx">HT</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/hyperthreading/default.aspx">hyperthreading</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/parallelism/default.aspx">parallelism</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Reporting+queries/default.aspx">Reporting queries</category></item><item><title>Evaluating server hardware: a sign of the times</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/03/evaluating-server-hardware-a-sign-of-the-times.aspx</link><pubDate>Tue, 03 Jan 2012 05:02:20 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:40750</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>7</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/40750.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=40750</wfw:commentRss><description>For nearly ten years, I have had success in using a specifically modified version of the TPC-C benchmark for evaluating server hardware running SQL Server. Depending on your purpose, you can evaluate computer hardware in numerous ways with numerous benchmarks....(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2012/01/03/evaluating-server-hardware-a-sign-of-the-times.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=40750" width="1" height="1"&gt;</description><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Benchmark/default.aspx">Benchmark</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Many-core/default.aspx">Many-core</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/TPC-C/default.aspx">TPC-C</category></item><item><title>Where is SQL Server running in a cluster?</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2011/12/27/where-is-sql-server-running-in-a-cluster.aspx</link><pubDate>Wed, 28 Dec 2011 03:55:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:40663</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>9</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/40663.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=40663</wfw:commentRss><description>There are numerous ways to find where a SQL Server instance is running in a cluster. The most convenient tool was cluster.exe . Unfortunately, I have to say it was the most convenient tool, and no longer is because no single cluster.exe works with all...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2011/12/27/where-is-sql-server-running-in-a-cluster.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=40663" width="1" height="1"&gt;</description><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Cluster/default.aspx">Cluster</category></item><item><title>Performance impact: a little business logic goes a long way</title><link>http://www2.sqlblog.com/blogs/linchi_shea/archive/2011/12/23/performance-impact-a-little-business-logic-goes-a-long-way.aspx</link><pubDate>Fri, 23 Dec 2011 05:13:21 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:40606</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>2</slash:comments><comments>http://www2.sqlblog.com/blogs/linchi_shea/comments/40606.aspx</comments><wfw:commentRss>http://www2.sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=40606</wfw:commentRss><description>I’m running into this little performance tuning pattern enough number of times that it is worth a special mention. As it often happens, the app folks complain about a proc call being very slow, and I track it down to a specific line in the proc. The line...(&lt;a href="http://www2.sqlblog.com/blogs/linchi_shea/archive/2011/12/23/performance-impact-a-little-business-logic-goes-a-long-way.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www2.sqlblog.com/aggbug.aspx?PostID=40606" width="1" height="1"&gt;</description><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Business+logic/default.aspx">Business logic</category><category domain="http://www2.sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category></item></channel></rss>