Merry Christmas and a Happy New Year!

I hope you've had ample time to both prepare for the Christmas holiday and then recover from it.  If your household is anything like mine, then you're cleaning up the living room over the next couple days with a snowshovel.  Yes, my four kids generated so much torn wrappings, discarded bows, tangled ribbons, and shredded tissue that I was tempted to clean house with my trusty Toro leaf blower.  In the end, common-sense won the day and so I've been slowly picking up the old fashion way - using hard work and elbow grease.  Still, we generated at least five large garbage sacks of trash.  Whew!  Holidays are hard work!

Let's take a moment to look forward a bit on a professional and personal level.  Friday is New Year's Eve.  It is a time to reflect up on the year gone past and contemplate how we'd like to improve ourselves and/or our lot for the coming year.  Professionally, I'm planning a blog entry that talks about 2005 and what I'm guessing will happen in 2006 in the database world.

As we get closer to New Year's Day, I'll enter a very non-SQL Server oriented blog just in case you're interested in hearing any of my more personal thoughts.  I'm sure it'll bore you to tears.  On the other hand, please don't miss this traditional opportunity for self-evaluation.  Our society moves very fast and doesn't make much space for introspection.  Sometimes we can lose sight of ourselves and what's most important to us.  So take a moment and pause.  And if you feel it's right, then celebrate!  I hope you all have a very Happy New Year.

So before I sign off, let me leave you with an interesting little tidbit about TCP benchmarks and service packs that I learned in a conversation between Greg Linwood and Tom Moreau, both of whom are SQL Server MVPs I hold in high regard.

Strange as this might seem, Microsoft posted a new SQL Server 2005 TPC-C benchmark just a few days ago showing SP1 in the product name, to be available on 5th June, 2006.

This posting might lead you to think that SP1 has already been built but will take 6 months to ship.  The results are posted at  Now just because SQL Server 2005 was delayed a couple times doesn't lead me to think the service pack was already built and is delayed for some reason. 

So what gives?  Does the Transaction Processing Council allow vendors to post a benchmark, then alter the code between the posting & release dates?  Would that allow optimizations to be slipped into benchmarks that ultimately might not get shipped?

As it turns out, vendors are allowed to publish benchmarks as long as what they tested will be released in less than six months.  So SP1 for SQL Server 2005 is probably no where near completion, but it probably has some good performance tweaks that make it worth using in the TCP benchmark.  And since the tests were conducted with post-RTM code, the vendor must use their next official version for the TPC tests.  In Microsoft's case, that means SQL Server 2005 SP1. 

Be sure to read the TPC reports if you have time.  You can learn some interesting tricks about building high-speed systems as well as details about various platforms.  For example, SQL Server is posting the best transaction/cost ratio of any database platforms with a transaction cost below $1 per transaction.

I hope this has been informative!  Cheers,


Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.