It is that time of year again.  Time for Fantasy Football.  Last year, we had a big surprise in the playoffs!

To join, visit http://football.fantasysports.yahoo.com/f1

League ID:  540668

Password:  rssfeed

 

We already have 4 teams!  Sign up now so that the draft can occur ASAP.

Earlier tonight I co-presented to the Greensboro VMWare User Group.  A former colleague of mine heads the group and we thought it would be an excellent topic.  Another Consultant, Dan Weiss from Varrow, was the co-presenter.  The venue was a party deck at the Greensboro Grasshoppers game.  It was a little windy and bright, but we were able to engineer secure the screen and whiteboard with some make shift ties (USB cables) and weights (laptop bags).  This is the first time that I presented at such a venue, but it was a great time.

I started off the presentation focusing on SQL Server Consolidation.  As you could gather from the group, there is lots of interest in consolidation using VMWare.  I shared my experiences with VMWare and other virtualization technologies and also stories that I have gathered from other MVPs and colleagues.  The bottm line of my presentation: Don't virtualize to consolidate SQL Server if your workload has any "girth".  I explained other methods of consolidation at a very high level.  Dan talked to the group of his experiences and how he has been able to virtualize SQL Server on VMWare with good results.  He had a list of best practices to go by - I will attempt to get his deck.

After the meeting, several folks came up to me and said "Thank you for stating your firm opinion on virtualizing SQL Server." because they have heard so many wishy-washy discussions about it. We then enjoyed the baseball game and a buffet.  I was also picked to SUMO Wrestle one of the other organizers.  Those SUMO suits are very hot.

Somebody also told me that MSFT put out a KB article stating that VMWare was now going to be supported for SQL Server.  I have not had a chance yet to view that article.  It is obvious that virtualization is playing a key role in many organizations; MSFT is moving to reflect this ongoing change.

 

Microsoft has publicly stated that SQL Server 2008 will RTM in Q3.  It is Quarter 3 now.  Where is it?  :-)

I'm sure that the final touches will now get taken care of now that Bill Gates is no longer a full-time MSFT employee.  I'm sure that his "short-timer" attitude trickled down to the develpers working on the product and that the final dev work will be completed.  (Just kidding!)  Perhaps this will be an answer to a MSFT triva question some day - What was the first product to be released without Bill Gates as part of MSFT?

Now that we have already had the party for 2008, I am really looking forward to its release.  It will be interesting to see how fast 2008 is adopted vs. 2005 and 2000.

 

Whenever I do a webcast or presentation, I always ask the audience to indicate where their organization is in relation to running SQL Server 2000 or running SQL 2005.  Recently, in an audience of about 40 people, more than half of the audience still had more than 50% of their production servers running SQL Server 2000.  One of the main bottlenecks are the vendors of third-party apps.  This has forced businesses to choose their risk.

SQL Server Support Risk - The application will not run/be supported on SQL 2005 by the vendor.  The decision has been made to keep the aaplication running and "hope" that there is no need for support from MSFT

Application Support Risk - The DB is upgraded by the customer (perhaps keeping the DB in '80' compatibility mode).  The decision has been made to keep the data platform updated and under support from MSFT point of view while taking a chance of not getting support from the third-party vendor.

There are many factors that go into this type of decision.  In fact, some organizations may choose to assume different types of risk for different applications/DBs.  This is not a comfortable choice for any organization.  Why don't vendors upgrade their DBs/Apps?  SQL Server 2000 is a solid DB platform; 2005 is better.  As time goes on, their will be more pressure for customers to avoid the SQL Server Support Risk (and associated costs).  Customers will pressure the vendors to upgrade their DBs/Apps or lose a customer.  

This now puts the risk on the vendors for not "keeping up".  There is some advice for vendors who have not kept up....  Plan to Upgrade your DB/App to SQL 2005 now.  While you are "under the hood", run the Upgrade Advisor for SQL Server 2008 and take care of that at the same time.  This way, the application/DB will be ready when SQL Server 2008 is released and even more importantly when it becomes a standard/approved data platform for many organizations.  Sticking with SQl Server 2000 may not have cost you business over the past couple of years, but it will cost you as the April 8, 2008 date gets smaller in the rearview mirror.

 

Again, I wanted to blog about something that still does not change between 2005 and 2008. At a recent conference, there were some great questions/ideas that should make it to Connect if they haven't already.

When DB Snapshots were first introduced, one of the questions that I always heard was "Can I perform a Backup on the Snapshot?".

Well - does this mean tht you can actually perform a SQL Backup of the DB Snapshot?  No - you can't do that.  Can I backup the DB Snapshot file with Windows Backup?  Yes, you can do that, but there is no way to "re-attach" a DB Snapshot file to a database.  So why bother?

DB Snapshots are still available on a Mirrored DB.  We find that many people like this feature because of the ease of setup/management, but they do not like the fact that it is still an Enterprise Edition feature.

After spending the past couple of weeks at the MVP Summit in Seattle and at SQL Connections in Orlando, I thought I should blog about things that do not change in 2008 (at least partially).

One of the reason s to partition your tables is to make it more managable.  Although there has been some enhancements in the manner that partitions are processed when queried, there are still some conerns that need to be addressed.  In SQL 2005, one of the big features announced was the ability to partition your tables into smaller segments so that it could be managed easier.  In SQL 2008 this is also true as you would expect.  One constraint from SQL 2005 is still there in 2008.  This is the ability to reindex a partition online.  This is still missing in SQL 2008.  The ability to reindex a partition exists in SQL 2005.  The ability to reindex online exists in SQL 2005 as well, But putting these two things together does not function in SQL 2005/2008.

I am not slamming SQL Server, but I hope the ability to reindex a partition online will be available in the next release.  There are many other reasons to upgrade to SQL 2008.  I was hoping that this would have been addressed.

 

 

It came up on me fast.  Mainstream support ends tomorrow for SQL Server 2000.  There is still a lot of SQL Server 2000 out there running.  Customers still can get support with a price.  As I do my speaking engagements, I always ask the audience how much SQL 2000 is still LIVE in their production environments.  It is still currently over 50% from my unscientific reading of the audiences.  The question that many people have asked is "Should I Upgrade Now to 2005 or wait for 2008?".  While the ultimate answer is "It depends", it looks like a lot of people are still comfortable waiting for 2008.  I still run into a customer with 7.0 or even an occasional 6.5 running.  With the launch parties of SQL Server 2008 already going on, there are a lot of great reasons to upgrade to the 2005/2008 generation of database, but SQL Server 2000 can still get the job done in many environments even in its waning moments.