This blogging thing sucks you in, doesn't it? Not content with having an ongoing series on disaster recovery and CHECKDB (with another 6 and 25 more posts planned respectively), I'm starting a new series on fragmentation. This will begin from first principles and work up, in approximately 18 posts over the next few months. The first few posts could be skipped by some people and will cover:
Bear with me as I build up the terminology. You could also check out Kalen's excellent book Inside SQL Server 2000 for details on these topics. (Her upcoming volume on the Storage Engine for Inside SQL Server 2005 should be out sometime this summer - buy it!).
The idea for this series came to mind last Friday at TechEd when I spent about 3 hours repeating a deck on fragmentation I gave to the North Texas SSUG in April 2004, people kept wandering by and stopping to listen. If that many people are interested in this stuff, it should make good blog material, and it also seems to be frequently misunderstood. The level of sophistication here ranges from not having any idea what fragmentation is up to defragging or rebuilding all indexes every night. I didn't see anyone there who knew just when it was worth removing fragmentation so I decided to explain here. The first 6 posts will also be useful as background for the CHECKDB internals series I'm doing.
So, what are records? At the simplest level, a record is the physical storage associated with a table or index row. Of course, it gets much more complicated than that...
Other record types
All records have the same structure, regardless of their type and use, but the number and type of columns will be different. For instance, a data record from a table with a complex schema may have hundreds of columns of various types whereas an allocation bitmap record will have a single column, filling up the whole page.
The record structure isn't relevant to a discussion on fragmentation but is for CHECKDB internals, so here it is:
If you have any questions on this stuff - put them in the comments of drop me an email.
Next time - what are pages?
Have you ever tried updating a variable length column and fail? Well, it can happen if the modified row
On day-to-day basis a DBA might come across with the issues on the fragmentation on the database, it
SQL Server deploys two strategies to compress the data · First, it stores all fixed length data types
PingBack from http://sqlserverpedia.com/blog/?p=204
The CTP6 release of SQL Server 2008 includes row and page compression. It’s a feature that will only
We have recently been looking at database fragmentation for real usage of the "Oslo" repository. However, since database fragmentation is a major cause of poor performance I thought a discussion of how to minimize and deal with database fragmentation
PingBack from http://www.keyongtech.com/2168470-null-takes-place