Browse by Tags

All Tags » Code Tuning (RSS)
30 January 2008 19:18

Things I learned today

I'm involved with some tuning as usually tends to be the case and amongst the work I've been doing a couple of interesting points arose. Firstly we upgraded the memory in the production cluster, what was unusual for me was that we added more memory than...
Posted by GrumpyOldDBA | 1 comment(s)
Filed under: , , ,
22 October 2007 20:54

sys.dm_db_index_physical_stats

It seems my comments in my SQLBits presentation about dropping sys.dm_db_index_physical_stats into a table valued function so it can be used within queries caught the eye of an important person. Now I'd not really given much thought to what I did, I was...
Posted by GrumpyOldDBA | 3 comment(s)
Filed under: ,
22 July 2007 22:38

Analysing Indexes Part 2

Here's the next instalment, expect there to at least another two or three. I’m still only working with basic indexing No partitioning I’m not looking at xml indexes. 14.0 Collecting Raw Index usage data Collects table name, index name , reads and writes...
Posted by GrumpyOldDBA | 3 comment(s)
Filed under: , ,
12 July 2007 16:17

Analysing Indexes Part 1

Actually what started as a small document has continued to grow. I'm working on performance tuning a well known application and as I document as I work so others can follow what I'm doing I thought I'd add it to my blog. There's nothing particularly startling...
Posted by GrumpyOldDBA | 3 comment(s)
Filed under: ,
15 June 2007 10:24

Maxdop hint for Views

With the advent of multi core processors the issue of parallelism is likely to cause more problems than before – the usual posted answer on forums to resolve parallelism ( CXPACKET ) locks is to disable or severely restrict processors. I’m sure this is...
Posted by GrumpyOldDBA | with no comments
Filed under: ,
05 October 2006 09:48

Secondary Index Quick Fix

Sometimes it is necessary to take a blanket approach to tuning when initially faced with a poorly performing production system, for example just adding lots of memory! The rationale behind this is that it is more risky to modify code than the database...
Posted by GrumpyOldDBA | with no comments
Filed under: