THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Kevin Kline

Microsoft Marketing Throws SQL Server Under the Bus

"A spokesperson for Microsoft said that the problem was not bandwidth but that its SQL Server database had reached excessive fragmentation levels caused by the tremendous surge of queries".  Read about it here:,windows-7-rc-download-crashes.aspx


and also here:


Why didn't anyone involved bother to think thru the fact that competitors and various elements of anti-Microsoft factions can make a lot of hay about Microsoft's own product?!?


Just as politicians only ever admit to "wanting to spend more time with family", a technology company shouldn't point to their own product as the culprit of a major technology failure, especially when there are thousands of other reasons that the meltdown might've happened.


What are your thoughts?




Addendum:  Thanks to Andy Kelly for pointing out the actual human error behind the website problem.  Andy reveals the smoking gun in his post at, which in turn points to the analysis done by my favorite guys on the SQLCAT team.  Read their analysis at

Published Wednesday, May 6, 2009 2:24 PM by KKline
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



aspiringgeek said:

Those Marketeers say the darndest things.

Maybe the db should have been on Oracle.  Or Access.  Or Excel.

May 6, 2009 2:40 PM

Linchi Shea said:

Just tell the truth whatever it may be. If it was SQL Server fragmentation, it was SQL Server fragmentation.

May 6, 2009 2:54 PM

Cindy Gross said:

Fragmentation is not a failure of the product, it is a failure of the DBAs.

May 6, 2009 3:15 PM

Michael Swart said:

However, Microsoft *Could* make it easier to detect this sort of thing. I think this is a great opportunity to go over to Microsoft Connect and vote on this item:


Include page split information in sys.dm_db_index_physical_stats

May 6, 2009 3:21 PM

Mark A said:

Makes me REAL glad that I work on a DB and OS that doesn't have those issues......EVER!!!!

May 6, 2009 3:29 PM

Anonymous said:

Mark: It's not possible to have a DB or OS that couldn't have this kind of issue.  All current database products are similar in this regard.

May 6, 2009 7:47 PM

Linchi Shea said:


I'd argue that it's quite possible. The fact some human can go in there to defrag it or run index maintenance regularly to fix the problem is an indication that it can be done automatically. In fact, this is a job much better suited for a program than for a human operator. Furthermore, the disk structure can be made more dynamic so that it constantly maintains itself to avoid the problem entirely without any requirement on regular index maintenance.

It's just a matter of time to see this in a product.

I don't know whether Oracle has it already as I have not looked at Oracle for some time now.

So I'm quite puzzled by the discussions around this incident here and elsewhere that many people are so quick to point out this is not the fault of the product. I'm not saying it is, and it is definitely a human error given what you have in the product. But one can argue that the product can be made better to help reduce the impact of this type of issues, or perhaps the advance in storage technology will soon make this a moot issue at the DBMS level.

May 6, 2009 11:26 PM

Glenn Berry said:

It would be nice to know what the real story is behind this. "Excessive fragmentation" does not seem likely in this case.

MSDN Subscribers have to have a Windows Live ID to get into the site. Validating someone's credentials seems like a read-only operation that would be highly cacheable in the middle-tier. Generating and recording license keys, and recording download statistics would generate some writes, but surely not that much.

I have no idea what their architechure or work load is like, so this is pure speculation on my part.

May 7, 2009 1:11 AM

GrumpyOldDBA said:

Not a good statement and helps the SQL Server critics, but a typical response to a  problem: I use LloydsTSB on-line share dealing service; when the market is busy it usually becomes impossible to make transactions: I complained: Lloyds said that when the market was volatile their system became busy - yes and?

May 7, 2009 4:44 AM

Mark A said:

Sorry Adam, but yes it is.  Our i5 running DB2/400 has NEVER had a corrupted/too fragmented database issue EVER in 8 + yrs.

May 7, 2009 9:30 AM

Anonymous said:

Mark: Absence of an example is not proof of its impossibility.  Even if we were to poll all DB2/400 users and we found out that NONE of them had ever had a corruption (highly unlikely), it would still not be proof of the impossibility of a corruption occurring sometime in the future.

Linchi: Whether or not there are automatic processes and safeguards in place, we're working in the physical world and problems can and will occur.  There is, given current technology, no way to protect against all evils.

May 7, 2009 10:05 AM

Linchi Shea said:

Yes, there will always be system failures, human errors, and other evils. But some problems can be mitigated with more robust features. All DBMS vendors are chasing the nirvana of self-healing systems (e.g. self-repairing minor corruption, self-correcting minor hardware deficiencies, and yes self-defraging, etc). After all, as we are scaling forward with Moore's law, we are dedicating more computing cycles to do this type of work to give end user better experience.

May 7, 2009 11:10 AM

RussellH said:

In Oracle the need to rebuild fragmented indexes is quite rare (for many years).  

This discussion starts out with regard to Oracle 8.1, but applies to modern versions.

There are many other kinds of "fragmentation" that can happen in Oracle.  For example, failure to leave enough free space in blocks for row updates that cause of the size of the row to increase can cause rows to "chain", or to have pieces in more that one block.  Chained rows can impact performance, but usually not to a great degree.  Setting PCTFREE for a table in Oracle too high can leave to much blank space on the block.

Modern versions of Oracle (9i - 11g) do have lots of features (such as auto segment space management, and locally managed tablspaces with auto extent sizing that make table or index fragmentation less likely.

The is also an automatic segment advisor that will send out alerts for tables and indexes that could benefit from a re-organization, and the reorg can be done online.

Were there any details about what kind of fragmentation caused the slowdown for SQL Server with regard to this Windows 7 download incident?

May 7, 2009 11:59 AM

Mark A said:

Adam, I'll take corruption once every 10+ years (and not HAVING to re-boot the server in at least a year as opposed to monthly at best for any kind of Windows server

May 7, 2009 2:19 PM

Denis Gobo said:

Mark A,

I haven't rebooted my windows SQL Server box in at least 3 years so I don't know what you are talking about. If you need to reboot once a month then maybe you need to have someone take a look at the box itself. I also have a staging box which was not rebooted in 6 years (until someone shut down the whole development cage)

We have plenty of Solaris boxes that needed to be rebooted at least monthly

May 7, 2009 2:47 PM

Linchi Shea said:

Scheduled reboots seem to be practiced differently in different places. Some never schedule a reboot unless there is an issue. Others schedule weekly, yes weekly, reboots. Whether or not a server can stay up for months or years depend a lot on what runs on that server. If you have craps running on a server, it doesn't matter what OS it is.

May 7, 2009 4:35 PM

Rajib Bahar said:

It could be a mixed blessing... :)

If I recall correctly, mozilla's server crashed when they released firefox version 3.0. However, I don't recall whether they laid the blame on a db platform or not.

In another spin, this news serve to tell us that the demand is rising in the MS world...

May 7, 2009 5:54 PM

Andrew Kelly said:

May 9, 2009 5:02 PM

Andrew Kelly said:

May 9, 2009 5:04 PM

David Lean said:

Database don't get fragmented due to heavy read activity. As seen in the SQLCAT.COM article, the real issue was the growth in load was >500% more than anticipated & they'd sized the systems too small.

Unfortunately very few people take a holistic picture. Most desire to either deflect blame or take credit without thinking of the ramifications. Which is why we often see other stupid behaviour like MS staff, comming in & fixing an issue in hours when a partner has been stuck on it for weeks. Instaed of the giving message "I'm here in conjunction with the partner, backing them up to ensure you get a great experience". Their implicit message becomes "I'm a hero, your partner is an idiot, you should deal directly with Microsoft in the future". Precicely the opposite of what they are goaled on which is growing & supporting our partner ecosystem. But in that brief moment they we basking in their own self importance & lost sightof the big picture.

So someone in IT guessed at the problem (, possibly because they'd seen similar poor perf when they'd not maintained (defragmented) a system in the past) & felt proud that they'd deflected the blame from their team. Doh!

The good news is that Windows 7 performs really well, as does its sibling Windows 2008 R2. The fact that demand & interest is far higher than Microsoft expected is a very good sign.

May 9, 2009 6:45 PM

Mickey Mouse said:

How interesting.

May 9, 2009 7:07 PM

Paul White said:

It is sad that this misinformation spread so quickly.  Many people will have concluded that SQL Server cannot handle high volume.  The facts of the matter will not change that.  Sigh.

@Mark A:

Thank you for posting, I found your comments extremely valuable and insightful.  I will be transferring all our data and systems to DB2/400 on an i5 immediately!  So nice to finally find hardware and software which is perfect in every way!!!


May 10, 2009 6:45 AM

Charles Wilt said:

I'll admit Mark A. didn't contribute much to the discussion. However, is he is correct in saying IBM DB2 for i (way back when called DB2/400) doesn't have issues with fragmentation.

A couple reasons:

We don't have (or need) clustered indexes. Indexes spaces (an internal OS object) are separate from the data spaces.

The entire OS is built around and optimized for what is basically RAID0. The system expects and wants objects to be broken up and scattered around.

As a developer, I don't know a whole lot about the internals of the OS; nor do I need to on the IBM i.  I'd hazard a guess I know more than the majority of IBM i developers, but that's the geek in me ;)

If you're interested in the bits & bytes, check out the book "Fortress Rochester - The Inside Story of the IBM iSeries" by Dr. Frank Soltis and/or it's predecessor, "Inside the IBM AS/400" also by Dr. Soltis.

The technology in the IBM i OS is pretty impressive, even more so when you remember that it's been around for 20+ years.

Charles Wilt

May 11, 2009 9:28 AM

Alexander Kuznetsov said:

I worked with DB2 for some time. I think that it used to have the most intelligent optimizer and some other nice features. Yet as a whole package it did not impress me much - I would not choose it to build a new system even if it were free, IMO it is too inconvenient to work with, too much time would be spent doing mundane tasks.

May 11, 2009 11:33 AM

Charles Wilt said:


Were you working with DB2 for i or DB2 for Linux,UNIX, & Windows (LUW)?

While IBM has chosen to name the RDBMS software the same, they are 2 separate products each with its own code base.  Thus the reason there can be incompatibilities and missing features/functions between the two.  Though IBM has done a pretty good job at minimizing the incompatibilities.

My guess is you're talking about DB2 LUW.  For the simple fact that DB2 i has the requires the least amount of "mundane" tasks compared to any other RDBMS.  


May 11, 2009 12:39 PM

SqlSquirrel said:

Exactly what does this SQL Server Database contain?

Its not like its a super market selling a brand of really good Cereal in aisle 27 that everyone was gueuing for since 10 hours before the store opened and then when the door finally came open all 5 million customers headed to aisle everyone trying to grab one of the 500 boxes available thus causing gridlock in the aisle and at the one checkout till operated by someone using the till machine for the first time without training.

And what were these overwhelming queries that caused fragmentation? Are we assuming that before the release was made available that the database was not fragmented and that a surge of download requests caused fragmentation of static data?

Marketeers know absolutely nothing about technology capabalities and get their gob stuck in. Ask one of the Server Engineers or DBA's what went wrong and you would get the truth without the spin.

May 13, 2009 6:17 AM

Luke Jian said:

I think the truth is somewhere in the middle. I have worked with both Oracle and SQL Server and while I agree that in a lot of regards Oracle is a superior product it is also because of their experience.

Let's face it ...Oracle started in 1979 while Microsoft bought Sybase in '89.

In my opinion the first great product they had were Oracle 8 in 1997 and SQL Server 2005 in  2005. Right now Oracle has a stable multi tiered scalable clustered architecture (including app server) whereas Microsoft is still discussing about deployment dates.

Also ... Oracle query optimizer is IMO one of the best in the industry since Oracle 8. Microsoft has finally developed a good (should I say ... comparable)query optimizer in 2008.

So while SQL Server is a good product  we should compare apples to apples because IMO Oracle and Microsoft play in different leagues.

Alternating active node and passive node is a best practice ... and that does not count as reboot IMHO.

Setting the fill factor is a feature on all RDBMS And I believe that is overlooked a lot of times especially on SQL Server.

And I totally agree with Cindy: This was human failure!!!

I hope the marketing spokesman was fired for this press release.

May 13, 2009 8:45 AM

Alexander Kuznetsov said:


DB2 for Linux

May 13, 2009 6:12 PM

Kevin Kline said:

Before I jump onto the Goals and Themeword meme started by my buddy, Thomas LaRock ( blog | twitter ),

January 5, 2010 9:43 PM

Leave a Comment


About KKline

Kevin Kline is a well-known database industry expert, author, and speaker. Kevin is a long-time Microsoft MVP and was one of the founders of PASS,

This Blog



Privacy Statement