Browse by Tags

All Tags » Code Tuning (RSS)
28 January 2010 20:38

Index Rebuild Observations

As part of a series of migration tests carrying out an all index rebuild on a user database has been used to compare relative performance. As the application is a true 7 x 24, there are no maintenance windows so index rebuilds are very intrusive and elicit...
Posted by GrumpyOldDBA | with no comments
Filed under: , , ,
27 October 2009 07:40

Well there's a thing

Just noticed this post from the PSS Team http://blogs.msdn.com/psssql/archive/2009/10/26/reduce-locking-and-other-needs-when-updating-data-better-performance.aspx never knew you could do double assignment x = y = z.
Posted by GrumpyOldDBA | with no comments
Filed under: ,
16 March 2009 20:38

Reasons to move to SQL 2008 MERGE pt 2

In my previous post with the MERGE statement it was assumed that the pairs of data would be unique and the second set would not already exist. I can’t say that I’d actually put together a really good example and I’m not saying that this is the most brilliant...
Posted by GrumpyOldDBA | with no comments
Filed under: , ,
11 March 2009 23:08

Reasons to move to SQL 2008 - MERGE

One of the great things for me currently is that my client is x64 SQL 2008, which means I can use all those features that make SQL Server 2008 such a great product. Anyway I have a very poor example of resolving a batch insert problem – you should realise...
Posted by GrumpyOldDBA | with no comments
Filed under: , ,
11 March 2009 22:14

Does a GUID make a good clustered key?

I've covered the use of unique identifiers ( guids ) in my presentations and in my articles on anlysing indexes; however I probably wasn't quite as succinct as I could have been. So do I like unique identifiers as clustered keys? Absolutely not...
Posted by GrumpyOldDBA | 1 comment(s)
Filed under: , ,
05 February 2009 20:24

Can I Index a bit ? ( Part 1 )

The final part wil follow and a fully illustrated pdf will be on my website - I'll post the location when it's complete. Can I index a bit? VBUG Presentation 27th January 2009 Bracknell. Here's a brief summary of subject matter and the points...
Posted by GrumpyOldDBA | 1 comment(s)
Filed under: , ,
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 | 4 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 | 4 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: