<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://sqlblogcasts.com/utility/FeedStylesheets/atom.xsl" media="screen"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en"><title type="html">Grumpy Old DBA</title><subtitle type="html">The Grumpy Old DBA is an independent DBA who usually specialises in production support 
and the performance, tuning and optimisation of databases and applications.</subtitle><id>http://sqlblogcasts.com/blogs/grumpyolddba/atom.aspx</id><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/default.aspx" /><link rel="self" type="application/atom+xml" href="http://sqlblogcasts.com/blogs/grumpyolddba/atom.aspx" /><generator uri="http://communityserver.org" version="3.1.20917.1142">Community Server</generator><updated>2008-02-18T19:53:00Z</updated><entry><title>Performance Dashboard for SQL 2008</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/06/23/performance-dashboard-for-sql-2008.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/06/23/performance-dashboard-for-sql-2008.aspx</id><published>2008-06-23T08:19:00Z</published><updated>2008-06-23T08:19:00Z</updated><content type="html">Just in case you haven&amp;#39;t seen this http://sqlblogcasts.com/blogs/thepremiers/archive/2008/06/20/sql-server-2008-performance-studio.aspx then have a read. As I actually create dashboards and performance reporting for sql 2000 and sql 2008, and have been for many years, I&amp;#39;m seeing some of my work made redundant but there&amp;#39;s other new features in 2008 I can concentrate on so it&amp;#39;s not all bad &amp;lt; grin &amp;gt;...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/06/23/performance-dashboard-for-sql-2008.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=10506" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="Diagnostics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Diagnostics/default.aspx" /><category term="Trending and Statistics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Trending+and+Statistics/default.aspx" /><category term="SQL2008" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/SQL2008/default.aspx" /></entry><entry><title>Tracking problem indexes in SQL 2000</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/06/10/tracking-problem-indexes-in-sql-2000.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/06/10/tracking-problem-indexes-in-sql-2000.aspx</id><published>2008-06-10T19:30:00Z</published><updated>2008-06-10T19:30:00Z</updated><content type="html">It’s all so easy(ish) to work within SQL 2005 but the reality is that there are still more SQL 2000 databases than SQL 2005, so I’m told, and I’m supporting one of them right now. I’ve been contemplating on how to get a handle on which of my indexes are fragmenting too quickly and where the high levels of page splits are occurring. So I know you’ll all say well you can run dbcc showcontig and of course this is true, but not on a very busy production server when it’s running hot – and it’s at times...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/06/10/tracking-problem-indexes-in-sql-2000.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=10464" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="Diagnostics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Diagnostics/default.aspx" /><category term="General Tuning" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/General+Tuning/default.aspx" /><category term="Indexes" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Indexes/default.aspx" /></entry><entry><title>Dates - especially when SQL Server can't be British!</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/06/09/dates-especially-when-sql-server-can-t-be-british.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/06/09/dates-especially-when-sql-server-can-t-be-british.aspx</id><published>2008-06-09T17:54:00Z</published><updated>2008-06-09T17:54:00Z</updated><content type="html">Just like memory config dates never seem to go away and I&amp;#39;ve had some discussions with our BI team recently on why things were not working quite as expected, especially on the 13th of the month; and I noticed the same issue had arisen for a member of the UK SSUG - Anyway rather than spend time writing a doc for the guys here Tibor has a really good post on this http://www.karaszi.com/SQLServer/info_datetime.asp it&amp;#39;s really good paper and I&amp;#39;d advise anyone to print it out and add it to...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/06/09/dates-especially-when-sql-server-can-t-be-british.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=10462" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="Diagnostics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Diagnostics/default.aspx" /><category term="Best Practice" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Best+Practice/default.aspx" /><category term="operating systems" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/operating+systems/default.aspx" /></entry><entry><title>Covering Clustered Indexes</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/05/26/covering-clustered-indexes.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/05/26/covering-clustered-indexes.aspx</id><published>2008-05-26T14:07:00Z</published><updated>2008-05-26T14:07:00Z</updated><content type="html">I’ve noticed that of late I’ve become a bit more critical of a well known publication that I suspect many DBA’s read. I have subscriptions to a number of publications and for the ones that I pay for I’m generally quite content. I like paper / hard copy because I can make use of time where it’s just not practical to have a laptop or PC – and I spend my working day in front of a screen so sometimes it’s nice to escape to the garden or the pub or on the train, say travelling to a SSUG meeting without...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/05/26/covering-clustered-indexes.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=10436" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="File Under Grumpy" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/File+Under+Grumpy/default.aspx" /><category term="Indexes" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Indexes/default.aspx" /></entry><entry><title>Information Overload ??</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/05/01/information-overload.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/05/01/information-overload.aspx</id><published>2008-05-01T09:44:00Z</published><updated>2008-05-01T09:44:00Z</updated><content type="html">As I&amp;#39;ve remarked before the profusion of Blogs ( from the various Microsoft teams and individuals ) whilst exposing so much more information then we ever had before also requires you to almost spend all your time just checking every blog you can find every day, and that&amp;#39;s assuming you actually found the blog in the first place. In SQL Server World we tend to direct our attentions to SQL Server blogs, I&amp;#39;ll list most of the ones I have bookmarked, however as I&amp;#39;ve also pointed out before...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/05/01/information-overload.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=10362" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="Technical Links" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Technical+Links/default.aspx" /><category term="operating systems" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/operating+systems/default.aspx" /><category term="x64" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/x64/default.aspx" /></entry><entry><title>Come to the UK SSUG</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/04/18/come-to-the-uk-ssug.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/04/18/come-to-the-uk-ssug.aspx</id><published>2008-04-18T11:53:00Z</published><updated>2008-04-18T11:53:00Z</updated><content type="html">Support your local user group! If you missed out on attending the UK SSUG Meeting in London last night then you missed an excellent evening, OK if you can&amp;#39;t get to London Victoria beacuse you&amp;#39;re in Scotland fair enough, but with the close proximity to Victoria station and underground it&amp;#39;s an easy to get to location and you get free food and drink. Subjects covered last night were x64 and cursors, so thanks to Christian and Eric. There should be another meeting in London in two months...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/04/18/come-to-the-uk-ssug.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=10334" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="Training &amp;amp; Certification" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Training+_2600_amp_3B00_+Certification/default.aspx" /><category term="Best Practice" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Best+Practice/default.aspx" /><category term="Technical Links" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Technical+Links/default.aspx" /></entry><entry><title>Disappointing Review.</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/04/17/disappointing-review.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/04/17/disappointing-review.aspx</id><published>2008-04-17T11:26:00Z</published><updated>2008-04-17T11:26:00Z</updated><content type="html">It&amp;#39;s not very often I&amp;#39;m provoked into making a criticism of a respected publication, however there&amp;#39;s nothing like being grumpy! I&amp;#39;ve published a number of posts about baselines, trending and performance analysis and I&amp;#39;ve been quick to remark when published examples don&amp;#39;t really match real world, so I was surprised to read a review of compressed backup software for SQL Server and the conclusions drawn in a leading publication. I&amp;#39;m a keen user of such a product, which wasn&amp;#39;t...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/04/17/disappointing-review.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=10330" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="Things I hate" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Things+I+hate/default.aspx" /><category term="File Under Grumpy" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/File+Under+Grumpy/default.aspx" /><category term="Trending and Statistics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Trending+and+Statistics/default.aspx" /></entry><entry><title>Disk Partition Alignment  ( SANs and Diskpart )</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/04/03/disk-partition-alignment-sans-and-diskpart.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/04/03/disk-partition-alignment-sans-and-diskpart.aspx</id><published>2008-04-03T11:53:00Z</published><updated>2008-04-03T11:53:00Z</updated><content type="html">As a further post to my series on what else can affect SQL Server Performance here’s the thorny issue of disk partition alignment. Disclaimer : I don’t get to configure SANs, places I work have dedicated teams and it’s unlikely a DBA would be considered a reference point regarding storage. What I can say is that in my experiences SAN storage has usually shown as a performance bottleneck. I’ve recently had the experience of being involved in the migration of storage for a clustered production system...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/04/03/disk-partition-alignment-sans-and-diskpart.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=10289" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="Diagnostics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Diagnostics/default.aspx" /><category term="General Tuning" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/General+Tuning/default.aspx" /><category term="SAN" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/SAN/default.aspx" /><category term="operating systems" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/operating+systems/default.aspx" /></entry><entry><title>Configuring x64 SQL Server </title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/03/26/configuring-x64-sql-server.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/03/26/configuring-x64-sql-server.aspx</id><published>2008-03-26T08:02:00Z</published><updated>2008-03-26T08:02:00Z</updated><content type="html">I often read a number of forum posts concerning performance / configuration issues with x64 SQL Server. I&amp;#39;ve also found some interesting views on how much memory you can allocate to SQL Server on a x64 install ( I don&amp;#39;t have any experience of ia64 - sorry ). Sort of cross purposes I&amp;#39;ve been trying to identify paging in x32 systems and I found this KB about x64. There&amp;#39;s a note that this KB is currently being rewritten so you might want to keep track of it. I&amp;#39;ve also got to add...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/03/26/configuring-x64-sql-server.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=10237" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="Diagnostics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Diagnostics/default.aspx" /><category term="General Tuning" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/General+Tuning/default.aspx" /><category term="operating systems" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/operating+systems/default.aspx" /><category term="x64" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/x64/default.aspx" /></entry><entry><title>Do you really need those services?</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/03/25/do-you-really-need-those-services.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/03/25/do-you-really-need-those-services.aspx</id><published>2008-03-25T22:11:00Z</published><updated>2008-03-25T22:11:00Z</updated><content type="html">As a continuation of my series of posts which look at Windows Server rather than SQL Server here&amp;#39;s one about services. o When your SQL Server is under pressure stopping or disabling unnecessary services may free up resource. o This is especially true of x32 systems where bottom memory allocation is critical. o Just because x64 has a flat memory model there is still no reason to not pay attention to services, some of which may actually be weak spots in your defenses. o Important: Do not just disable...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/03/25/do-you-really-need-those-services.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=10236" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="General Tuning" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/General+Tuning/default.aspx" /><category term="operating systems" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/operating+systems/default.aspx" /></entry><entry><title>Bug in UK SSUG 2008</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/03/19/bug-in-uk-ssug-2008.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/03/19/bug-in-uk-ssug-2008.aspx</id><published>2008-03-19T19:17:00Z</published><updated>2008-03-19T19:17:00Z</updated><content type="html">It was discovered earlier today that SSUG 2008 was unable to distinguish a Thursday when it fell before a bank holiday friday and as a consequence SSUG would be unable to function on March 20th. It's not thought that other Thursdays that fall before a Friday bank holiday will cause similar problems, mainly as they only occur every six years or so, Christmas, and the date of Christmas remains static at 25th December, unlike Good Friday whose due date can only be calculated by getting up at night and...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/03/19/bug-in-uk-ssug-2008.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=9649" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="Diagnostics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Diagnostics/default.aspx" /><category term="Trending and Statistics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Trending+and+Statistics/default.aspx" /></entry><entry><title>Things that may not be right on your  SQL server.</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/03/12/things-that-may-not-be-right-on-your-sql-server.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/03/12/things-that-may-not-be-right-on-your-sql-server.aspx</id><published>2008-03-12T19:57:00Z</published><updated>2008-03-12T19:57:00Z</updated><content type="html">Ø When performance is under the spotlight most often the finger is pointed at SQL Server, here’s a short list of things that may impact your server performance. Disclaimer : This is my personal hit list and in no particular order. Out of date drivers Look mainly for HBA, NIC and storage controllers Incorrect NIC settings Your NIC(s) should have the speed and duplex fixed. Cards set to AUTO are bad news. Make sure your NIC is running full duplex HBA Buffer/Queue depth This is tricky to define exactly...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/03/12/things-that-may-not-be-right-on-your-sql-server.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=9353" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="Diagnostics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Diagnostics/default.aspx" /><category term="General Tuning" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/General+Tuning/default.aspx" /><category term="operating systems" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/operating+systems/default.aspx" /></entry><entry><title>Only once every four years thank goodness!</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/02/29/only-once-every-four-years-thank-goodness.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/02/29/only-once-every-four-years-thank-goodness.aspx</id><published>2008-02-29T19:57:00Z</published><updated>2008-02-29T19:57:00Z</updated><content type="html">I never cease to be amazed by what I discover within IT, mostly these days I'm more disappointed than anything else, I'm not a lover of the let's bash Microsoft about security patches or we should all use Linux / Open source as in the latter I'm sure if the most popular o/s was linux it would be full of exploits. However I was faintly amused to discover there's a bug in SQL 2008 which doesn't let it run on Feb 29th. Common guys how can this be, I've just wasted some considerable time trying to understand...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/02/29/only-once-every-four-years-thank-goodness.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=8142" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="Things I hate" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Things+I+hate/default.aspx" /><category term="File Under Grumpy" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/File+Under+Grumpy/default.aspx" /><category term="Diagnostics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Diagnostics/default.aspx" /></entry><entry><title>dbcc dropcleanbuffers - or maybe not</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/02/22/dbcc-dropcleanbuffers-or-maybe-not.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/02/22/dbcc-dropcleanbuffers-or-maybe-not.aspx</id><published>2008-02-22T20:34:00Z</published><updated>2008-02-22T20:34:00Z</updated><content type="html">As a consequence of another action I was prompted to want to clear the buffer cache – or to be more precise I tried to clear the buffer cache. So stepping back, what happens if you install more memory than the combined size of your databases? Most would probably suggest that it’s a waste of time, however what I’ve found is that tempdb makes use of this memory, and it was my initial investigation of memory usage which prompted all this, in fact I was quite surprised as to how much cache tempdb would...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/02/22/dbcc-dropcleanbuffers-or-maybe-not.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=7669" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="File Under Grumpy" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/File+Under+Grumpy/default.aspx" /><category term="Diagnostics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Diagnostics/default.aspx" /><category term="General Tuning" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/General+Tuning/default.aspx" /><category term="memory" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/memory/default.aspx" /></entry><entry><title>Analysing Indexes Summary</title><link rel="alternate" type="text/html" href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/02/18/analysing-indexes-summary.aspx" /><id>http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/02/18/analysing-indexes-summary.aspx</id><published>2008-02-18T19:53:00Z</published><updated>2008-02-18T19:53:00Z</updated><content type="html">· I’ve put the work I’ve done on using the dmvs to analyse indexes onto my web site – the links to the pages are underneath. Trying to post large documents to the blog is very difficult, and probably not what a blog was intended for! · I need to do more work on the analysis of the operational stats and I will publish this in due course. The basic principles that apply to the analysis of sys.dm_db_index_usage_stats can be applied to sys.dm_db_index_operational_stats . · There have been a number of...(&lt;a href="http://sqlblogcasts.com/blogs/grumpyolddba/archive/2008/02/18/analysing-indexes-summary.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblogcasts.com/aggbug.aspx?PostID=7469" width="1" height="1"&gt;</content><author><name>GrumpyOldDBA</name><uri>http://sqlblogcasts.com/members/GrumpyOldDBA.aspx</uri></author><category term="Trending and Statistics" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Trending+and+Statistics/default.aspx" /><category term="Indexes" scheme="http://sqlblogcasts.com/blogs/grumpyolddba/archive/tags/Indexes/default.aspx" /></entry></feed>