<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://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://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>Killing a SQL Server thread? Don’t!</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2010/02/04/killing-a-sql-server-thread-don-t.aspx</link><pubDate>Thu, 04 Feb 2010 20:09:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:21853</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>4</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/21853.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=21853</wfw:commentRss><description>Sometimes, when you kill a session (i.e. a spid) in a SQL Server instance, the spid just refuses to go away not because it’s doing a rollback. Perhaps, it’s stuck on a certain dependency on something external to SQL Server or it’s just simply stuck for...(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2010/02/04/killing-a-sql-server-thread-don-t.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=21853" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Testing/default.aspx">Testing</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Best+Practices/default.aspx">Best Practices</category></item><item><title>What server is it trying to connect to?</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2010/01/22/what-server-is-it-trying-to-connect-to.aspx</link><pubDate>Sat, 23 Jan 2010 01:54:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:21370</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>5</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/21370.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=21370</wfw:commentRss><description>It’s common to be called to find out why an app cannot connect to one of your database servers. So you start by checking the server, and it’s working just fine. Then, you check the client machine and its database connectivity to the server, and that is...(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2010/01/22/what-server-is-it-trying-to-connect-to.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=21370" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Tools/default.aspx">Tools</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Troubleshooting/default.aspx">Troubleshooting</category></item><item><title>Would you optimize SQL for less performance?</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2010/01/08/would-you-optimize-sql-for-less-performance.aspx</link><pubDate>Fri, 08 Jan 2010 13:56:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:20716</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>19</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/20716.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=20716</wfw:commentRss><description>What do you mean? Okay, that does sound like an oxymoron, doesn't it? Let's say you are trying to optimize a stored procedure, and your proposed change results in the stored procedure running not faster, but perhaps a bit slower than it currently does....(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2010/01/08/would-you-optimize-sql-for-less-performance.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=20716" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Benchmark/default.aspx">Benchmark</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Performance+tuning/default.aspx">Performance tuning</category></item><item><title>Add-Content and Out-File are not for performance</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2010/01/04/add-content-and-out-file-are-not-for-performance.aspx</link><pubDate>Mon, 04 Jan 2010 21:31:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:20508</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>2</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/20508.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=20508</wfw:commentRss><description>When you write Powershell scripts and need to write a text file, you have a number of ways to accomplish that. The often suggested approach is to use cmdlets Add-Content or Out-File. Well, this is not news. But some may not notice that these cmdlets are...(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2010/01/04/add-content-and-out-file-are-not-for-performance.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=20508" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Scripts/default.aspx">Scripts</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Scripting/default.aspx">Scripting</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Powershell/default.aspx">Powershell</category></item><item><title>Bad database practices: allowing apps to connect to the server hostname</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2009/12/28/bad-database-practices-allowing-apps-to-connect-to-the-hostname.aspx</link><pubDate>Mon, 28 Dec 2009 20:32:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:20284</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>12</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/20284.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=20284</wfw:commentRss><description>It’s common to see a client application referencing the hostname of a SQL Server instance in its connection string. For instance, assume that you have a server whose hostname is NYCSQL01, and you install a default SQL Server instance on it. Naturally,...(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2009/12/28/bad-database-practices-allowing-apps-to-connect-to-the-hostname.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=20284" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Best+Practices/default.aspx">Best Practices</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Bad+database+practices/default.aspx">Bad database practices</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Network+Aliases/default.aspx">Network Aliases</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Connection+Strings/default.aspx">Connection Strings</category></item><item><title>Get an overview report on your log shipping setups</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2009/12/21/get-an-overview-report-on-your-log-shipping-setups.aspx</link><pubDate>Tue, 22 Dec 2009 02:45:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:20163</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>5</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/20163.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=20163</wfw:commentRss><description>[Updated Dec 23 to include a T-SQL script at the bottom of the post]. You may have an environment where log shipping is set up on various databases between various servers. Would it be handy to have an overview report highlighting which database is being...(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2009/12/21/get-an-overview-report-on-your-log-shipping-setups.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=20163" width="1" height="1"&gt;</description><enclosure url="http://sqlblog.com/blogs/linchi_shea/attachment/20163.ashx" length="1746" type="application/x-zip-compressed" /><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Perl/default.aspx">Perl</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Scripting/default.aspx">Scripting</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Automation/default.aspx">Automation</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Log+shipping/default.aspx">Log shipping</category></item><item><title>The Transact-SQL Prime Directive – a bad example</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2009/12/18/the-transact-sql-prime-directive-a-bad-example.aspx</link><pubDate>Fri, 18 Dec 2009 17:12:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:20110</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>2</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/20110.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=20110</wfw:commentRss><description>A while back, I ranted that the design and implementation of Transact-SQL should be guided by a prime directive that guarantees no interference with the flow of set-based data in Transact-SQL. That was primarily motivated by the fact that no such guarantee...(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2009/12/18/the-transact-sql-prime-directive-a-bad-example.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=20110" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/T-SQL/default.aspx">T-SQL</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Rant/default.aspx">Rant</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/General+trends/default.aspx">General trends</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Language+Design/default.aspx">Language Design</category></item><item><title>Performance impact: Speeding up SMO script generation – the test code</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2009/12/15/performance-impact-speeding-up-smo-script-generation-the-test-code.aspx</link><pubDate>Tue, 15 Dec 2009 19:10:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:19982</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>2</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/19982.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=19982</wfw:commentRss><description>The attached is the C# code that I used for generating the test results charted in my previous post . Note that for testing no generated script is actually persisted into a file by this program. The Script() method is applied, but the resulting script...(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2009/12/15/performance-impact-speeding-up-smo-script-generation-the-test-code.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=19982" width="1" height="1"&gt;</description><enclosure url="http://sqlblog.com/blogs/linchi_shea/attachment/19982.ashx" length="1926" type="application/x-zip-compressed" /><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Scripts/default.aspx">Scripts</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/SMO/default.aspx">SMO</category></item><item><title>Performance impact: Speeding up SMO script generation</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2009/12/13/performance-impact-speeding-up-smo-script-generation.aspx</link><pubDate>Sun, 13 Dec 2009 22:18:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:19824</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>5</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/19824.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=19824</wfw:commentRss><description>Generating scripts through SMO can be as simple as walking down the database object tree and applying the Script() method to each scriptable object. Well, that is until you start to try it on a database that has a large number of objects (say a few thousands),...(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2009/12/13/performance-impact-speeding-up-smo-script-generation.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=19824" width="1" height="1"&gt;</description><enclosure url="http://sqlblog.com/blogs/linchi_shea/attachment/19824.ashx" length="13726" type="image/gif" /><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Scripts/default.aspx">Scripts</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Scripting/default.aspx">Scripting</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/SMO/default.aspx">SMO</category></item><item><title>Performance impact: UNION ALL views, ANSI_PADDING, and bad query plans</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2009/12/04/performance-impact-union-all-views-ansi-padding-and-bad-query-plans.aspx</link><pubDate>Fri, 04 Dec 2009 19:43:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:19514</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>11</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/19514.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=19514</wfw:commentRss><description>Whether or not you specify it explicitly, ANSI_PADDING setting is there when you create a table, and can have an impact on the performance of some queries. If you are not careful, it can even hurt performance big time! Let’s demonstrate that with an extremely...(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2009/12/04/performance-impact-union-all-views-ansi-padding-and-bad-query-plans.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=19514" width="1" height="1"&gt;</description><enclosure url="http://sqlblog.com/blogs/linchi_shea/attachment/19514.ashx" length="1147" type="application/x-zip-compressed" /><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Query+Processing/default.aspx">Query Processing</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Performance+tuning/default.aspx">Performance tuning</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Optimizer+Bug/default.aspx">Optimizer Bug</category></item><item><title>Bad database practices: abusing linked servers</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2009/11/06/bad-database-practices-abusing-linked-servers.aspx</link><pubDate>Sat, 07 Nov 2009 00:56:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:18596</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>5</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/18596.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=18596</wfw:commentRss><description>In SQL Server, it is rather handy to retrieve data from a different SQL Server instance and use the result locally in another SQL statement for further processing. In theory and in the set purists’ fantasy land, it shouldn’t matter where you get your...(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2009/11/06/bad-database-practices-abusing-linked-servers.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=18596" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Best+Practices/default.aspx">Best Practices</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Query+Processing/default.aspx">Query Processing</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Distributed+join/default.aspx">Distributed join</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Bad+database+practices/default.aspx">Bad database practices</category></item><item><title>I didn't know you could do this!</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2009/11/06/i-didn-t-know-you-could-do-this.aspx</link><pubDate>Fri, 06 Nov 2009 16:50:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:18582</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>6</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/18582.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=18582</wfw:commentRss><description>create proc p_test as -- multiple resultsets select @@servername as ServerName; select 'abc'; select srvname from sysservers; go create table #tmp ( ServerName sysname ) go INSERT #tmp EXECUTE p_test; I did not know that the last statement above (i.e....(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2009/11/06/i-didn-t-know-you-could-do-this.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=18582" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Random+thoughts/default.aspx">Random thoughts</category></item><item><title>Bad database practices: moving data to procedures vs. moving procedures to data</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2009/10/30/database-bad-practices-moving-data-to-the-procedures-vs-moving-procedures-to-data.aspx</link><pubDate>Fri, 30 Oct 2009 04:00:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:18365</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>4</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/18365.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=18365</wfw:commentRss><description>Is it better to move data to procedures or move procedures to data? The answer is, of course, “it depends.” Let’s consider a scenario where you have two SQL Server instances: ServerA and ServerB, and you have a procedure on ServerB (call it procB), but...(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2009/10/30/database-bad-practices-moving-data-to-the-procedures-vs-moving-procedures-to-data.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=18365" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Performance/default.aspx">Performance</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Architecture/default.aspx">Architecture</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Best+Practices/default.aspx">Best Practices</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Distributed+query/default.aspx">Distributed query</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Linked+server/default.aspx">Linked server</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Bad+database+practices/default.aspx">Bad database practices</category></item><item><title>Find the complete call tree for a stored procedure</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2009/10/23/find-the-complete-call-tree-for-a-stored-procedure.aspx</link><pubDate>Fri, 23 Oct 2009 03:11:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:18173</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>6</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/18173.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=18173</wfw:commentRss><description>Would it be nice to print out the complete call tree of a stored procedure? By complete call tree , I mean the following: · At the very top level, the call tree should identify all the procedures that are called directly. · For any given level, the next...(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2009/10/23/find-the-complete-call-tree-for-a-stored-procedure.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=18173" width="1" height="1"&gt;</description><enclosure url="http://sqlblog.com/blogs/linchi_shea/attachment/18173.ashx" length="1328" type="application/x-zip-compressed" /><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Scripts/default.aspx">Scripts</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Perl/default.aspx">Perl</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Tools/default.aspx">Tools</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/T-SQL/default.aspx">T-SQL</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Scripting/default.aspx">Scripting</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Automation/default.aspx">Automation</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Linked+server/default.aspx">Linked server</category></item><item><title>Bad database practices: managing databases without a DBA central inventory</title><link>http://sqlblog.com/blogs/linchi_shea/archive/2009/10/20/bad-database-practices-managing-databases-without-a-dba-central-inventory.aspx</link><pubDate>Tue, 20 Oct 2009 17:26:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:18013</guid><dc:creator>Linchi Shea</dc:creator><slash:comments>7</slash:comments><comments>http://sqlblog.com/blogs/linchi_shea/comments/18013.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/linchi_shea/commentrss.aspx?PostID=18013</wfw:commentRss><description>Aaron Bertrand has been writing an excellent series about Bad habits to kick , highlighting some of the bad practices, primarily, in the areas of T-SQL coding. I’m going to steal his idea and comment on the bad practices I have seen in managing databases....(&lt;a href="http://sqlblog.com/blogs/linchi_shea/archive/2009/10/20/bad-database-practices-managing-databases-without-a-dba-central-inventory.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=18013" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Best+Practices/default.aspx">Best Practices</category><category domain="http://sqlblog.com/blogs/linchi_shea/archive/tags/Bad+database+practices/default.aspx">Bad database practices</category></item></channel></rss>