SQL Server Storage Engine : Index Fragmentation Series

Changes to sp_estimate_data_compression_savings stored procedure in SQL2008R2

Sunil Agarwal — Wed, 16 Sep 2009 22:53:00 GMT

When you compress an object (index or table or partition), there are two components of space savings that you get. First component is fragmentaton (i.e. the original object might have been fragmented). The object gets degragmented as part of doing compression so you get some space savings. Second component is actual data compression savings. Many customers have asked the question 'Is there a way to know how much savings do I get from each of the two components?".

Interestingly, starting with SQL2008R2, you indeed have this capability. Here is one example where I create a table t1 and then simulate fragmentation by updating a column. Once the table is fragemented, I can use the sp_estimate_data_compression stored procedure to determine how much space savings I can get by defragmenting it.

drop table t1

-- Create the table

create table t1 (c1 int, c2 char(100), c3 varchar (300))

-- create a clustered index

create clustered index t1_ci on t1(c1)

-- load 10000 rows. Note, that for column C3, I am storing full-values that

-- take all 300 characters

declare @i int

select @i = 0

while (@i < 10000)

begin

insert into t1 values (@i, 'hello', replicate ('1', 300))

select @i = @i + 1

end

-- Now let us measure the average length of the row. It comes to 417 bytes.

-- This means that there are 19 rows per page

select avg_record_size_in_bytes

from sys.dm_db_index_physical_stats (db_id('TEMPDB'),

object_id('T1'),

null, null, 'SAMPLED')

where object_name (object_id) like 't1' AND index_id =1

-- check the space usage. This shows the space usage of 4296 KB

sp_spaceused t1

-- This update will cause fragmentation because I am changing the column C3 from 300

-- chars to 50 chars. With the result, the average row length

-- will now become 167 but the SQL Server will still keep 19 rows/page which

-- leaves more that 50% unused space on each page

update t1 set c3 = REPLICATE ('2', 50)

-- check the space usage. It shows that the allocated or reserved space

-- has not changed

sp_spaceused t1

-- estimate how much space you can save by defragmentation. Note

-- here I am executing the stored procedure on an 'uncompressed' table

-- with target compression setting is 'NONE',(i.e. no compression).

exec sp_estimate_data_compression_savings 'dbo',

'T1',1, NULL, 'none'

-- This stored proc returns

object_name schema_name index_id partition_number

------------ ----------- -------- ---------------

T1 dbo 1 1

size_with_current_compression_setting(KB) size_with_requested_compression_setting(KB)

---------------------------------------- ------------------------------------------

4480 1720

-- To verify this, I rebuild the index and see the space consumption

alter index t1_ci on t1 rebuild

-- check the space usage. It shows that the table now takes 1744KB

sp_spaceused t1

In SQL2008RTM, the stored procedure did not compute the space savings if the source and target compression settings were same. In otherwords, the stored proc would have returned the following instead

size_with_current_compression_setting(KB) size_with_requested_compression_setting(KB)

---------------------------------------- ------------------------------------------

4480 4480

Interestingly, you can use it to get tell-tale signs to know if ROW compressed table already takes advantage of unicode compression in SQL2008R2. Let us say customer was using ROW compression in SQL2008 and now upgrades to SQL10.5, s/he can use to the sp_estimate_data_compression_savings stored proc by specifying target compression to be ROW as well. Note, in this case, the compression savings will include the potential savings from data defragmentation as well so one can’t easily deduce that the savings are from Unicode compressions or due to both. However, customer can get some clues by referring to the sys.dm_db_index_physical_stats DMV to see if the object in question was fragmented or not.

Thanks

Sunil

Example: Index fragmentation with insert/updates, measuring it and fixing it

Sunil Agarwal — Sat, 01 Mar 2008 04:11:00 GMT

This blog shows a very simple example to illustrate data fragmentation, measuring it, seeing behind the scene data and steps to address it. I recommend reading the overall series on index fragementation at http://blogs.msdn.com/sqlserverstorageengine/archive/tags/Index+Fragmentation+Series/default.aspx

-- TSQL Script

create database indextest

use indextest

-- create the index after loading the data

drop table t_ci

create table t_ci (c1 int, c2 char (100), c3 int, c4 varchar(1000))

-- load the data

declare @i int

select @i = 0

while (@i < 1000)

begin

insert into t_ci values (@i, 'hello', @i+10000, replicate ('a', 100))

set @i = @i + 1

end

-- find fragmentation

select avg_fragmentation_in_percent, avg_fragment_size_in_pages, fragment_count, avg_page_space_used_in_percent

from sys.dm_db_index_physical_stats (DB_ID(), object_id('t_ci'), NULL, NULL, 'DETAILED')

OUTPUT

-- main cause of fragmentation is that initial page allocation is using mixed extent

avg_fragmentation_in_percent avg_fragment_size_in_pages fragment_count avg_page_space_used_in_percent

---------------------------- -------------------------- -------------------- ------------------------------

40 7.25 4 94.127625401532

(1 row(s) affected)

--find extent allocations. Note, first 8 pages are allocated from mixed extents

-- in the output below, I removed some columns that are not relevant here.

dbcc extentinfo (0, 't_ci', 0)

OUTPUT

file_id page_id pg_alloc ext_size object_id index_id partition_number

----------- ----------- ----------- ----------- ----------- ----------- ----------------

1 153 1 1 2137058649 0 1

1 155 1 1 2137058649 0 1

1 156 1 1 2137058649 0 1

1 157 1 1 2137058649 0 1

1 158 1 1 2137058649 0 1

1 159 1 1 2137058649 0 1

1 180 1 1 2137058649 0 1

1 181 1 1 2137058649 0 1

1 208 8 8 2137058649 0 1

1 216 8 8 2137058649 0 1

1 224 5 8 2137058649 0 1

-- this shows all the pages alllocated to t_ci

-- I looked at the pages and I found total of 30 pages with 4 fragements. So the average size is 7.5

dbcc ind ('indextest', 't_ci', 0)

-- create the clustered index

create clustered index ci on t_ci(c1)

-- measure the fragementation

select avg_fragmentation_in_percent, avg_fragment_size_in_pages, fragment_count, avg_page_space_used_in_percent

from sys.dm_db_index_physical_stats (DB_ID(), object_id('t_ci'), NULL, NULL, 'DETAILED')

OUTPUT

-- you don't see any fragementation because SQL Server allocates uniform extents.

-- In the output below, I removed the row for non-leaf index pages

avg_fragmentation_in_percent avg_fragment_size_in_pages fragment_count avg_page_space_used_in_percent

---------------------------- -------------------------- -------------------- ------------------------------

0 28 1 98.3726958240672

-- this shows all the pages alllocated to t_ci

-- I looked at the pages and I found that logical/physical order was perfactly alinged.

-- also, all pages were allocated from uniform extents except for PFS page.

dbcc ind ('indextest', 't_ci', 1)

-- here is the output of page allocations

dbcc extentinfo (0, 't_ci', 1)

file_id page_id pg_alloc ext_size object_id index_id partition_number

----------- ----------- ----------- ----------- ----------- ----------- ----------------

1 183 1 1 2137058649 1 1

1 232 8 8 2137058649 1 1

1 240 8 8 2137058649 1 1

1 248 8 8 2137058649 1 1

-- create the index and load the data. This is different from the previous example

-- as here we create the index on the empty table and then load the data.

drop table t_ci

create table t_ci (c1 int, c2 char (100), c3 int, c4 varchar(1000))

-- create the clustered index

create clustered index ci on t_ci(c1)

-- load the data

declare @i int

select @i = 0

while (@i < 1000)

begin

insert into t_ci values (@i, 'hello', @i+10000, replicate ('a', 100))

set @i = @i + 1

end

-- measure the fragementation

select avg_fragmentation_in_percent, avg_fragment_size_in_pages, fragment_count, avg_page_space_used_in_percent

from sys.dm_db_index_physical_stats (DB_ID(), object_id('t_ci'), NULL, NULL, 'DETAILED')

-- output: again, you see the fragementaion becuase first 8 page allcoations come from mixed page extents

-- This is because when you are loading into empty table, SQL Server cannot predict its size. So

-- it does mixed page allocations. This is different when you create the indec

-- after loading the data because at that time it knows the size of the index.

-- Also note that the average used percentage in pages was close to 100%. This means that

-- the pages were not split in half. This is one of the optimizations SQL Server does when

-- loading ordered data.

avg_fragmentation_in_percent avg_fragment_size_in_pages fragment_count avg_page_space_used_in_percent

---------------------------- -------------------------- -------------------- ------------------------------

14.2857142857143 5.6 5 98.3726958240672

--find extent allocations. Note, first 8 pages are allocated from mixed extents

dbcc extentinfo (0, 't_ci', 1)

file_id page_id pg_alloc ext_size object_id index_id partition_number

----------- ----------- ----------- ----------- ----------- ----------- ----------------

1 180 1 1 5575058 1 1

1 182 1 1 5575058 1 1

1 183 1 1 5575058 1 1

1 142 1 1 5575058 1 1

1 143 1 1 5575058 1 1

1 153 1 1 5575058 1 1

1 154 1 1 5575058 1 1

1 155 1 1 5575058 1 1

1 192 8 8 5575058 1 1

1 200 8 8 5575058 1 1

1 208 5 8 5575058 1 1

drop index ci on t_ci

-- create the clustered index to start with unfragmented data

create clustered index ci on t_ci(c1)

-- update all rows such that each row 900 bytes. This will cause page splits thereby

-- lead to fragmentation

update t_ci set c4 = replicate ('b', 1000)

-- measure the fragementation

select avg_fragmentation_in_percent, avg_fragment_size_in_pages, fragment_count, avg_page_space_used_in_percent

from sys.dm_db_index_physical_stats (DB_ID(), object_id('t_ci'), NULL, NULL, 'DETAILED')

-- Severe fragementation because of page splits. Also note that the space usage in each page is around 50%

-- This affects the performance in two ways (1) you will need to read more pages to get to the

-- same number of rows as pages are 1/2 full. (2) Since there are 117 fragements, it will cause

-- more physical IOs if we are scanning for a range of keys.

-- Just to emphasize, the fragmentation happens because of DML operations. So if there is very little

-- DML activity on a table, it may not get fragmented. Other important point to understand

-- is that fragementaion ONLY impacts range queries but NOT singleton selects.So again if

-- you determine that most access thru an index are singleton SELECT, there is no performance benefit

-- in defragmenting it except of course you will be able to space by compacting the data on the page.

avg_fragmentation_in_percent avg_fragment_size_in_pages fragment_count avg_page_space_used_in_percent

---------------------------- -------------------------- -------------------- ------------------------------

40.4332129963899 2.40869565217391 115 50.0636520879664

--find extent allocations. Note, that the pages are allocated from mixed extents only. This

-- is because the table is already bigger than the 8 page threshold

dbcc extentinfo (0, 't_ci', 1)

file_id page_id pg_alloc ext_size object_id index_id partition_number

----------- ----------- ----------- ----------- ----------- ----------- ----------------

1 183 1 1 5575058 1 1

1 440 8 8 5575058 1 1

1 448 8 8 5575058 1 1

1 456 8 8 5575058 1 1

1 464 8 8 5575058 1 1

1 472 8 8 5575058 1 1

1 480 8 8 5575058 1 1

1 488 8 8 5575058 1 1

1 496 8 8 5575058 1 1

1 504 8 8 5575058 1 1

1 512 8 8 5575058 1 1

1 520 8 8 5575058 1 1

1 528 8 8 5575058 1 1

1 536 8 8 5575058 1 1

1 544 8 8 5575058 1 1

1 552 8 8 5575058 1 1

1 560 8 8 5575058 1 1

1 568 8 8 5575058 1 1

1 576 7 8 5575058 1 1

-- you can use the following command to show all the pages alllocated to t_ci and their links.

dbcc ind ('indextest', 't_ci', 1)

-- Now do an index defrag.

alter index ci on t_ci reorganize

-- measure the fragementation

select avg_fragmentation_in_percent, avg_fragment_size_in_pages, fragment_count, avg_page_space_used_in_percent

from sys.dm_db_index_physical_stats (DB_ID(), object_id('t_ci'), NULL, NULL, 'DETAILED')

-- note that the fragmentation was reduced significantly and the space usage on pages is around 100%. In other

-- words, the defragementation makes the physical order same as the logical order and compacts the pages.

-- The reason you see the fragementation is that the 'Reorganize' command does not allocate new extents

-- as index rebuild command. It works with the already allocated pages and moves the data around and then

-- deallocates pages not needed. If you choose to 'rebuild' the index, then the fragmentation will be completely

-- removed but you must question if it is worth it? Index Reorganize takes very little space (one extra page) and

-- breaks the work into smaller transactions. So you minimze large log chain and space overhead.On the flip side,

-- it is single threaded and fully logged operation.

avg_fragmentation_in_percent avg_fragment_size_in_pages fragment_count avg_page_space_used_in_percent

---------------------------- -------------------------- -------------------- ------------------------------

3.4965034965035 10.2142857142857 14 98.3726958240672

How can you tell if an index is being used?

Paul Randal - MSFT — Fri, 20 Apr 2007 19:25:00 GMT

Whenever I’m discussing index maintenance, and specifically fragmentation, I always make a point of saying ‘Make sure the index is being used before doing anything about fragmentation’.

If an index isn’t being used very much, but has very low page density (lots of free space in the index pages), then it will be occupying a lot more disk space than it could do and it may be worth compacting (with a rebuild or a defrag) to get that disk space back. However, usually there’s not much point spending resources to remove any kind of fragmentation when an index isn’t being used. This is especially true of those people who rebuild all indexes every night or every week.

You could even go so far as to say if a non-clustered index isn’t being used, why is it there at all? Extra non-clustered indexes drag down performance in a number of ways. Consider a non-clustered index called IX_MyNCIndex on the table MyTable:

Any time a record is inserted into MyTable, a matching record is inserted into IX_MyNCIndex. This is a bunch of extra IOs, plus maybe even a page-split.
Any time a record is deleted from MyTable, the matching record in IX_MyNCIndex must be deleted. Extra IOs again.
Any time a record in MyTable is updated:

If MyTable has a clustered index, and the clustered index key value changes, then the matching record in IX_MyNCIndex must be updated. Extra IOs again.
If any of the non-clustered index key values changes, or any of the INCLUDEd column values changes, then the matching record in IX_MyNCIndex must be updated. Extra IOs again.

If a clustered index is created on MyTable, then IX_MyNCIndex has to be rebuilt to include the logical RIDs rather than the physical heap RIDs. Lot of extra IOs.

That’s a significant amount of extra IOs to maintain each extraneous non-clustered index.

So, how can you tell if an index is being used? There are a few different ways in SQL Server 2005 – the one I want to discuss in this post is using the sys.dm_db_index_usage_stats DMV.

This DMV exposes the information that is tracked about index usage (as the name suggests). It does not generate any information itself; it just returns info from a cache inside SQL Server. This cache is empty when the server instance starts, and is not persisted across instance restarts. All cache entries for indexes in a database are removed when that database is closed. So, the cache tracks usage information about indexes since the database they are part of was last opened (either manually or as part of instance start-up).

The cache tracks the following info for each index (for user queries and system queries):

· The number of times it was used in a seek operation (either looking up a single row, or doing a range scan) along with the time of the last seek.

· The number of times it was used in a scan operation (e.g. a select * operation) along with the time of the last scan

· The number of times it was used in a lookup operation (this means a bookmark lookup – where a non-clustered index does not fully cover a query and additional columns must be retrieved from the base table row) along with the time of the last lookup.

· The number of times it was used in an update operation (this counts inserts, updates, and deletes) along with the time of the last update.

Let’s have a look at its use.

SELECT * FROM sys.dm_db_index_usage_stats;

Unless you've just re-started your instance, you'll see a bunch of output from this, representing all index activity since the instance/databases started. If you're interested in whether an index is being used, you can filter the output. Let's focus in on a particular table - AdventureWorks.Person.Address.

SELECT * FROM sys.dm_db_index_usage_stats

WHERE database_id = DB_ID('AdventureWorks')

and object_id = OBJECT_ID('AdventureWorks.Person.Address');

You'll probably see nothing in the output, unless you've been playing around with that table. Let's force the clustered index on that table to be used, and look at the DMV output again.

SELECT * FROM AdventureWorks.Person.Address;

SELECT * FROM sys.dm_db_index_usage_stats

WHERE database_id = DB_ID('AdventureWorks')

and object_id = OBJECT_ID('AdventureWorks.Person.Address');

Now there's a single row, showing a scan on the clustered index. Let's do something else.

SELECT StateProvinceID FROM AdventureWorks.Person.Address

WHERE StateProvinceID > 4 AND StateProvinceId < 15;

SELECT * FROM sys.dm_db_index_usage_stats

WHERE database_id = DB_ID('AdventureWorks')

and object_id = OBJECT_ID('AdventureWorks.Person.Address');

And there's another row, showing a seek in one of the table's non-clustered indexes.

So, its easy to look at the index usage for particular tables and indexes. But how can you monitor this over time? This is easy too - let's see how.

First we need to create our own table to store snapshots of the DMV output.

IF OBJECTPROPERTY(object_id(N'master.dbo.MyIndexUsageStats'), 'IsUserTable') = 1

DROP TABLE dbo.MyIndexUsageStats;

SELECT GETDATE () AS ExecutionTime, *

INTO master.dbo.MyIndexUsageStats

FROM sys.dm_db_index_usage_stats WHERE database_id=0;

Next we need to take a baseline snapshot of the DMV output.

INSERT master.dbo.MyIndexUsageStats

SELECT getdate (), * FROM sys.dm_db_index_usage_stats;

And now simulate a few operations and take another snapshot of the DMV:

SELECT * FROM AdventureWorks.Person.Address;

SELECT StateProvinceID FROM AdventureWorks.Person.Address

WHERE StateProvinceID > 4 AND StateProvinceId < 15;

INSERT master.dbo.MyIndexUsageStats

SELECT getdate (), * FROM sys.dm_db_index_usage_stats;

And look at the filtered contents of our snapshot table:

SELECT * FROM master.dbo.MyIndexUsageStats

WHERE database_id = DB_ID('AdventureWorks')

and object_id = OBJECT_ID('AdventureWorks.Person.Address');

You should see four rows - two from the baseline snapshot and two from the final snapshot. If you ran just the statements above, you'll see that the user_scans count for the clustered index has increased by two, and the user_seeks count for the non-clustered index has increased by one.

So this is a pretty simple example of how you can track index usage. By putting something like this into a regularly run script you can tell which indexes aren't being used and could be candidates for less-regular index maintenance or removal altogether.

Let me know how you get on.

(Btw - still looking for more people to fill out my VLDB Maintenance survey...)

More undocumented fun: DBCC IND, DBCC PAGE, and off-row columns

Paul Randal - MSFT — Thu, 14 Dec 2006 01:46:00 GMT

(Final blog post of the year for me. Its been a bit of a wild ride the last 6 months - 7 TechEds on 3 continents, 46 blog posts and some major life changes - but now things have calmed down and I should be back to more regular posting in 2007. Tomorrow I fly out to Wakatobi in Indonesia to go diving with my partner until January, which is some long overdue R&R. I'll post a link to some photos in January - she's already been out there for two weeks on a live-aboard and has over 3000 photos... In the meantime, I have all my loose-ends tied up at work so time to squeeze in a post. Thanks for all your comments and emails this year - I hope you all have a great holiday and may your pagers be silent throughout!)

At TechEd in November, in one of the sessions I did with Kimberly we demo'd both DBCC IND and DBCC PAGE in the context of following links to columns that have been pushed off-row when the row size exceeds 8060 bytes. The point of the demo is to show that even if an index is perfectly defragmented, the performance of a query that does a range scan may suffer if off-row columns are part of the result set because getting to those off-row columns involves random IOs.

What I'd like to do in this post is run through the demo we did, and at the same time introduce you to the undocumented DBCC IND command. This is like DBCC PAGE - it's used extensively internally but isn't documented or supported - use at your own risk. You already know about using DBCC PAGE to investigate page contents from my previous posts (here and here) so I'm not going to go into details.

To start off, we create a table with a schema that can cause rows to be greater than 8060 bytes. In previous versions, creating a schema like this has always been possible, but actually getting rows larger then 8060 was not. Checkout my previous post on IAM chains and allocation units in SQL Server 2005 for more details of large rows (and a few other cool new features in 2005). I'll assume that you've got a database called dbccpagetest that you're using.

CREATE TABLE rowoverflowtest (c1 INT, c2 VARCHAR (8000), c3 VARCHAR (8000));

CREATE CLUSTERED INDEX row_cl ON rowoverflowtest (c1);

Now we need to populate the table so we have something to look at.

INSERT INTO rowoverflowtest VALUES (1, REPLICATE ('a', 100), REPLICATE ('b', 100));

INSERT INTO rowoverflowtest VALUES (2, REPLICATE ('a', 100), REPLICATE ('b', 100));

INSERT INTO rowoverflowtest VALUES (3, REPLICATE ('a', 100), REPLICATE ('b', 100));

INSERT INTO rowoverflowtest VALUES (4, REPLICATE ('a', 100), REPLICATE ('b', 100));

INSERT INTO rowoverflowtest VALUES (5, REPLICATE ('a', 100), REPLICATE ('b', 100));

And now the new command - use DBCC IND to find out which page IDs to look at with DBCC PAGE.

DBCC IND ('dbccpagetest', 'rowoverflowtest', 1);

The output is (prettified in Excel):

PageFID	PagePID	IAMFID	IAMPID	ObjectID	IndexID	PartitionNumber	PartitionID	iam_chain_type	PageType	IndexLevel
1	156	NULL	NULL	133575514	1	1	72057594039959552	In-row data	10	NULL
1	155	1	156	133575514	1	1	72057594039959552	In-row data	1	0

(I've stripped off the 4 trailing columns, NextPageFID, NextPagePID, PrevPageFID, PrevPagePID so it all fits in the window. They're all zero.)

The columns mean:

PageFID - the file ID of the page
PagePID - the page number in the file
IAMFID - the file ID of the IAM page that maps this page (this will be NULL for IAM pages themselves as they're not self-referential)
IAMPID - the page number in the file of the IAM page that maps this page
ObjectID - the ID of the object this page is part of
IndexID - the ID of the index this page is part of
PartitionNumber - the partition number (as defined by the partitioning scheme for the index) of the partition this page is part of
PartitionID - the internal ID of the partition this page is part of
iam_chain_type - see IAM chains and allocation units in SQL Server 2005
PageType - the page type. Some common ones are:

1 - data page
2 - index page
3 and 4 - text pages
8 - GAM page
9 - SGAM page
10 - IAM page
11 - PFS page

IndexLevel - what level the page is at in the index (if at all). Remember that index levels go from 0 at the leaf to N at the root page (except in clustered indexes in SQL Server 2000 and 7.0 - where there's a 0 at the leaf level (data pages) and a 0 at the next level up (first level of index pages))
NextPageFID and NextPagePID - the page ID of the next page in the doubly-linked list of pages at this level of the index
PrevPageFID and PrevPagePID - the page ID of the previous page in the doubly-linked list of pages at this level of the index

So you can see we've got a single page clustered index with an IAM page. Note that the page IDs returned may differ on your server. Let's look at the data page, focusing on the record for c1 = 3.

DBCC TRACEON (3604);

DBCC PAGE (dbccpagetest, 1, 155, 3);

Don't forget that we need to turn on T3604 first to get the output back to the console. The dump for the 3rd row is (remembering that slots are number from zero, so slot 2 is row 3):

Slot 2 Offset 0x216 Length 219

Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP VARIABLE_COLUMNS

Memory Dump @0x44DCC216

00000000: 30000800 03000000 04000003 00130077 †0..............w

00000010: 00db0061 61616161 61616161 61616161 †...aaaaaaaaaaaaa

00000020: 61616161 61616161 61616161 61616161 †aaaaaaaaaaaaaaaa

00000030: 61616161 61616161 61616161 61616161 †aaaaaaaaaaaaaaaa

00000040: 61616161 61616161 61616161 61616161 †aaaaaaaaaaaaaaaa

00000050: 61616161 61616161 61616161 61616161 †aaaaaaaaaaaaaaaa

00000060: 61616161 61616161 61616161 61616161 †aaaaaaaaaaaaaaaa

00000070: 61616161 61616162 62626262 62626262 †aaaaaaabbbbbbbbb

00000080: 62626262 62626262 62626262 62626262 †bbbbbbbbbbbbbbbb

00000090: 62626262 62626262 62626262 62626262 †bbbbbbbbbbbbbbbb

000000A0: 62626262 62626262 62626262 62626262 †bbbbbbbbbbbbbbbb

000000B0: 62626262 62626262 62626262 62626262 †bbbbbbbbbbbbbbbb

000000C0: 62626262 62626262 62626262 62626262 †bbbbbbbbbbbbbbbb

000000D0: 62626262 62626262 626262†††††††††††††bbbbbbbbbbb

UNIQUIFIER = [NULL]

Slot 2 Column 1 Offset 0x4 Length 4

c1 = 3

Slot 2 Column 2 Offset 0x13 Length 100

c2 = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Slot 2 Column 3 Offset 0x77 Length 100

c3 = bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

You can see that all the data is stored in-row. Now we update one of the columns so that the row size exceeds 8060 bytes.

UPDATE rowoverflowtest SET c3 = REPLICATE ('c', 8000) WHERE c1 = 3;

And run DBCC IND again to see if anything changed. The output is:

PageFID	PagePID	IAMFID	IAMPID	ObjectID	IndexID	PartitionNumber	PartitionID	iam_chain_type	PageType	IndexLevel
1	156	NULL	NULL	133575514	1	1	72057594039959552	In-row data	10	NULL
1	155	1	156	133575514	1	1	72057594039959552	In-row data	1	0
1	158	NULL	NULL	133575514	1	1	72057594039959552	Row-overflow data	10	NULL
1	157	1	158	133575514	1	1	72057594039959552	Row-overflow data	3	0

(Again, I've stripped off the trailing 4 columns - they're all zero)

Cool - we have another IAM page and a text page, in a row-overflow IAM chain. So something must have been pushed off-row into page (1:157). Let's have another look at the clustered-index data page, focusing on the 3rd row again:

Slot 2 Offset 0x4a7 Length 143

Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP VARIABLE_COLUMNS

Memory Dump @0x44DCC4A7

00000000: 30000800 03000000 04000003 00130077 †0..............w

00000010: 008f8061 61616161 61616161 61616161 †...aaaaaaaaaaaaa

00000020: 61616161 61616161 61616161 61616161 †aaaaaaaaaaaaaaaa

00000030: 61616161 61616161 61616161 61616161 †aaaaaaaaaaaaaaaa

00000040: 61616161 61616161 61616161 61616161 †aaaaaaaaaaaaaaaa

00000050: 61616161 61616161 61616161 61616161 †aaaaaaaaaaaaaaaa

00000060: 61616161 61616161 61616161 61616161 †aaaaaaaaaaaaaaaa

00000070: 61616161 61616102 00004401 000000a6 †aaaaaaa...D.....

00000080: 2e000040 1f00009d 00000001 000000††††...@...........

UNIQUIFIER = [NULL]

Slot 2 Column 1 Offset 0x4 Length 4

c1 = 3

Slot 2 Column 2 Offset 0x13 Length 100

c2 = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

c3 = [BLOB Inline Root] Slot 2 Column 3 Offset 0x77 Length 24

Level = 0 Unused = 68 UpdateSeq = 1

TimeStamp = 782630912

Link 0

Size = 8000 RowId = (1:157:0)

The 2nd varchar column is no longer stored on the page - instead the value have been replaced with an in-row blob root, pointing to an 8000 byte long blob fragment stored in slot 0 of page (1:157). If we dump it with DBCC PAGE we should see its got our value in:

DBCC PAGE (dbccpagetest, 1, 157, 3);

And the output is (slightly curtailed):

PAGE: (1:157)

BUFFER:

BUF @0x02BE8D84

bpage = 0x03FB6000 bhash = 0x00000000 bpageno = (1:157)

bdbid = 9 breferences = 0 bUse1 = 8105

bstat = 0xc0010b blog = 0x1432159b bnext = 0x00000000

PAGE HEADER:

Page @0x03FB6000

m_pageId = (1:157) m_headerVersion = 1 m_type = 3

m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x8000

m_objId (AllocUnitId.idObj) = 117 m_indexId (AllocUnitId.idInd) = 256

Metadata: AllocUnitId = 72057594045595648

Metadata: PartitionId = 72057594039959552 Metadata: IndexId = 1

Metadata: ObjectId = 133575514 m_prevPage = (0:0) m_nextPage = (0:0)

pminlen = 0 m_slotCnt = 1 m_freeCnt = 80

m_freeData = 8110 m_reservedCnt = 0 m_lsn = (21:107:19)

m_xactReserved = 0 m_xdesId = (0:0) m_ghostRecCnt = 0

m_tornBits = 0

Allocation Status

GAM (1:2) = ALLOCATED SGAM (1:3) = ALLOCATED

PFS (1:1) = 0x64 MIXED_EXT ALLOCATED 100_PCT_FULL DIFF (1:6) = CHANGED

ML (1:7) = NOT MIN_LOGGED

Blob row at: Page (1:157) Slot 0 Length: 8014 Type: 3 (DATA)

Blob Id:782630912

44DCC06E: 63636363 63636363 63636363 63636363 cccccccccccccccc

44DCC07E: 63636363 63636363 63636363 63636363 cccccccccccccccc

44DCC08E: 63636363 63636363 63636363 63636363 cccccccccccccccc

44DCDF7E: 63636363 63636363 63636363 63636363 cccccccccccccccc

44DCDF8E: 63636363 63636363 63636363 63636363 cccccccccccccccc

44DCDF9E: 63636363 63636363 63636363 63636363 cccccccccccccccc

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Yep - that's our updated column.

Now, this is a contrived example to force columns off-row, but you can imagine a case where a column is unexpectedly pushed off-row in some rows of a table and suddenly a query slows down. You look at the fragmentation and the query plan and everything looks good but don't realize that you're taking random IOs to return the columns you've asked for.

That's all - now it's time for me to go and pack my diving gear and head off towards the sun (20 1/2 hours of flights over 31 1/2 hours to get to Bali tomorrow - ugh!). Have fun playing with DBCC over the holidays and I'll be back in January.

When can allocation order scans be used?

Paul Randal - MSFT — Thu, 09 Nov 2006 05:31:00 GMT

I know this is jumping the gun a little as I haven't made it this far in my series on fragmentation, but this came up in a chalk-talk I did yesterday at TechEd Developers in Barcelona and is worth blogging about.

You'd expect a select * from mytable query on a table with a clustered index to use an allocation order scan to return the data, as that's the fastest way to read all the pages at the leaf-level of an index. In fact, the query plan will show an unordered clustered index scan. Well, guess again. What I didn't remember, and thanks to SQL Server MVP Maciej Pilecki for pointing this out during my talk (even though I didn't believe him at first), is that an allocation order scan can't be used when there's any possibility of the data changing beneath the scan.

Consider an example where an allocation order scan is progressing and a page that the scan has already read then splits - adding a newly allocated page at the end of the allocation-order list of pages. The scan will eventually come to the new page and then re-read some of the rows it has already read - producing duplicates in the scan output - clearly undesirable.

The only time such a scan will be used is when there's no possibility of the data changing (e.g. when the TABLOCK hint is specified, or when the table is in a read-only database) or when its explicitly stated that we don't care (e.g. when the NOLOCK hint is specifed or under READ UNCOMMITTED isolation level). As a further twist, there's a trade-off with setup cost of the allocation order scan against the number of pages that will b read - an allocation order scan will only be used if there's more than 64 pages to be read.

Below I've included a simple script that demonstrates the behavior. For me, the funny thing is that I should have remembered this behavior as it's exactly the same reason why DBCC SHOWCONTIG takes a shared table lock when in the default mode - it's using an allocation order scan and needs to ensure that the data doesn't change and produce duplicates. Oh well - you (re)learn something every day!

-- Drop and recreate the test database

USE master;

DROP DATABASE allocationordertest;

CREATE DATABASE allocationordertest;

USE allocationordertest;

-- Create a simple table that we can fill up quickly, plus a clustered index

CREATE TABLE t1 (c1 INT, c2 VARCHAR (8000));

CREATE CLUSTERED INDEX t1c1 ON t1 (c1);

-- Add some rows, making sure to produce an out-of-order dataset when scanned in allocation order.

DECLARE @a INT;

SELECT @a = 10;

WHILE (@a < 100)

BEGIN

INSERT INTO t1 VALUES (@a, replicate ('a', 5000))

SELECT @a = @a + 1

END;

SELECT @a = 1;

WHILE (@a < 10)

BEGIN

INSERT INTO t1 VALUES (@a, replicate ('a', 5000))

SELECT @a = @a + 1

END;

-- Now try to do an allocation order scan - doesn't work...

SELECT * FROM t1;

-- Until we add the right conditions.

SELECT * FROM t1 WITH (TABLOCK);

Fragmentation (part 4): what are heaps?

Paul Randal - MSFT — Tue, 19 Sep 2006 04:18:00 GMT

Ok - really catching up with the various blog post series I started back in June/July - time to bang out the next few posts in the series on index fragmentation. Remember I'm starting from first principles and covering

What are records?
What are pages?
What are extents?
What is a heap?
What is a clustered index?
What is a non-clustered index?

before getting into the details of fragmentation.

So what is a heap?

A heap is the simplest storage arrangement and is an unordered table (or you could think of it as a collection of unordered pages).
This means that rows will be inserted into the heap anywhere where there is space (don't let this statement confuse you - for a table that has nothing but inserts, records will always be appended to the last allocated page).
A heap consists entirely of data pages - as there is no b-tree, there are no index pages.
As a heap is unordered, the data pages are not linked in any way. (Ah - there are some exceptions. In SQL Server 2000 and 2005 (and maybe in 7.0 - I don't remember), the sysfiles1 table is a linked-heap. This table contains the locations of the files comprising the database and so for safety's sake we want the pages to be linked, but not with the complexity of having a b-tree because we read the pages directly at startup time. In SQL Server 2005, some other system tables are also linked-heaps).
If you want to do a singleton lookup from a heap, the whole heap has to be scanned to find the row(s) matching the search predicate.
Doing a select (*) of the contents of a heap will not guarantee to return the rows in the order they were inserted (as it did in 6.5 when all heaps were linked as sysfiles1 is and the space from singleton deletes was not reclaimed). This is because the pages are accessed in allocation order.
Non-clustered index records contain the physical RID (record ID or record locator) of the corresponding heap record.

Heaps have one interesting feature - forwarded records. If a record needs to be updated, the updated record size is greater than the current record size, and there is no space on the page to fit the new record in then we have two choices:

move the record to a new page and change all the non-clustered index records that point to it to point to the new location of the record
move the record to a new page and leave a forwarding record in the original location to point to the new location

Guess which approach we took? Right, #2. Approach #1 has enormous performance implications because of the extra IOs and logging involved. The forwarding record has the physical location of the new record and the forwarded record has a back-pointer to the forwarding record (so that if its deleted, the forwarding record can be deleted too).

This is one drawback of using heaps - all the extra space that's "wasted" with the forwarding/forwarded records. Another drawback is that when scanning through the heap, forwarding records have to followed immediately (as opposed to ignoring them and just reading the forwarded records when they're encountered). This is to vastly reduce the possiblity of read anomalies (such as non-repeatable reads or missed rows if a row moves before the scan point during a scan).

And that's it. Next up is clustered indexes...

Fragmentation (part 3): What are extents?

Paul Randal - MSFT — Wed, 28 Jun 2006 20:52:00 GMT

(Ok - another flight - another blog post. This time its Boston back to Seattle. The three of us who'd come over for the training course upgraded to 1st Class on Alaska for the flight back (great value at $100 for a 6-hour flight) and so there's oodles of room for laptops, newspapers, and long legs)

In the previous posts I explained about database pages - their structure and some page types. Now I'd like to explain how we group pages into units called extents.

An extent is a group of eight physically consecutive pages in a database data file. Extents are always aligned on 64KB boundaries (i.e. 8-page boundaries), starting at the beginning of each data file. Extents, and all their properties, are exactly the same in SQL Server 2000 and 2005.

There are two types of extents: mixed extents and dedicated (or uniform) extents.

Mixed extents

The first 8 pages that are allocated to any IAM chain (either for an index in SQL Server 2000 or allocation unit in SQL Server 2005) are single-page allocations, which we called mixed pages. This means that only a single page is allocated to the IAM chain at a time, rather than a whole extent. The rationale behind this is to allow very small tables to take up the minimum amount of space.

These mixed pages are allocated from mixed extents that are not allocated to any particular IAM chain. The extent is tracked as being allocated globally, so no IAM chain can allocate it.

As the mixed extent is not allocated to any particular IAM chain, this means that it may hold pages allocated to 8 separate IAM chains. IAM pages themselves are always mixed pages, regardless of how many pages have been allocated to an IAM chain. This means a mixed extent may hold a variety of page types too,including IAM, data, index, or text pages.

Two interesting facts:

once an IAM chain has passed the 8-page threshold and switched to allocating dedicated extents, it will never go back to allocating mixed pages again.
for the purposes of fragmentation, we completely ignore mixed pages and extents as there are so few of them in each IAM chain and it complicates the various algorithms involved.

Dedicated/Uniform extents

Once the magic 8-page threshold is passed, all further allocations are from dedicated extents. This means that an extent at a time is allocated to an IAM chain (and marked as such in one of the IAM pages in the IAM chain). This is also tracked globally.

All pages from a dedicated extent must be allocated to the same IAM chain, and they will all be the same type except in the case of clustered indexes, where there could be a mixture of data pages (from the leaf level) and index pages (from the upper b-tree levels).

Two more interesting facts:

just because an extent is allocated to an IAM chain, that doesn't mean that all the pages are. The pages are allocated as needed, so initially only one page will be allocated. There are some exceptions to this rule, including during an offline index build operation, but I'm not going to go into the algorithm details.
dedicated extents can be deallocated from an IAM chain if all the pages in the extent become deallocated.

You may ask "how do you know which pages are allocated in an extent?" and "how do you track the global allocation state of extents, especially mixed extents?". The answers are by using the PFS pages, and by using the GAM + SGAM pages respectively. I'll cover these in the next post.

(Passing over Montana now at 8pm - pretty clear skies and the sun's at an angle to throw the landscape into sharp relief - very cool. First class is great - actual crockery rather than plastic plates, cups and food...)

Fragmentation (part 2): What are pages?

Paul Randal - MSFT — Mon, 26 Jun 2006 04:56:00 GMT

(Boston continues its reputation - with me at least - for great seafood - calamari and pan-seared fresh halibut this evening. Yum! I was tempted to get on the T - Boston's subway system - and see what's happening downtown but with no jacket I'd get wet. So, instead I'll be boring and geeky and write another blog post - you guys are spoiled today.)

Hopefully I'm getting close to resolving the chicken-and-egg problem of being able to discuss topics without having to promise further posts to explain terms.

In the previous post in this series I explained what records are. Pages exist to store records. A database page is an 8192-byte (8KB) chunk of a database data file. They are aligned on 8KB boundaries within the data files, starting at byte-offset 0 in the file.

A page has a structure as shown below (all pages have the same basic structure):

Page header

The 96-byte page header is the same for every page. You can see an example of the fields that are stored within a page header in the last post on DBCC PAGE. When considering fragmentation, the most important fields are:

Next page pointer
- The pages in each level of the index are joined in a doubly-linked list according to the logical order (as defined by the index keys) of the index. The next page pointer does not necessarily point to the immediately adjacent physical page in the file (fragmentation...
- As these are doubly-linked lists, there is also a previous page pointer.
Page level
- The various algorithms I'll describe later have to know whether the page being examined is from the leaf-level of the index or not (i.e. page level = 0). Page level increases from the leaf-level to the root page at the top of the b-tree (except in clustered indexes in SQL Server 2000 where there are two level=0 levels - the leaf-level and the level above it - this is just for simplicity :-) How do you tell them apart? You need to look at the page type too - data pages are at the leaf-level, index pages in the level above)
Free space count
- This shows how much free space is available in the page. This is used to calculate the average page density - the less free space, the higher the page density.

Other interesting fields in the page header are:

object ID and index ID
- in SQL Server 2000, these correspond to the actual relationl object ID and index ID to which the page is allocated.
- in SQL Server 2005, this mapping no longer exists. The two IDs on each page correspond (through a calculation) to the allocation unit ID of the allocation unit the page is allocated to. A series of metadata lookups are necessary to determine the parent object and index.
page type
- There are a bunch of different page types, most of which I'll be explaining more about in subsequent posts over the next few weeks. Some interesting ones are (well, interesting to me anyway):
  - data page (holds data records)
  - index page (holds non-clustered index leaf records and non-leaf records from clustered and non-clustered indexes)
  - IAM page (holds allocation information about extents within a fixed 4GB GAM interval that are allocated to an index or allocation unit, in SQL Server 2000 and 2005 respectively. IAM = Index Allocation Map.)
  - GAM and SGAM pages (holds global allocation information about extents in a GAM interval. GAM = Global Allocation Map. SGAM = Shared GAM.)
  - PFS page (holds allocation and free space information about pages within a PFS interval - approx 64MB. PFS = Page Free Space.)
  - text page (actually two types that hold leaf and intermediates nodes in text trees)
  - sort page (holds sort records being used in active sort operations)
  - differential bitmap page (holds information about which extents in a GAM interval have changed since the last full or differential backup)
  - bulk-changed map page (holds information about which extents in a GAM interval have changed while in bulklogged mode since the last backup. This is what allows you to switch to bulk-logged mode for bulk-loads and index rebuilds without worrying about breaking a backup chain.)
  - boot page (holds information about the database - one page used per database)
  - fileheader page (holds information about the file - one page per file)
slot count
- This lists the number of occupied record slots on the page (including ghost records).
- It can also be described as giving the number of entries in the slot array.
ghost record count
- self-explanatory
page ID
- a page's ID is made up of the file ID and the page position within the file and is always written as (file:page)

Slot array

It is a very common misconception that records within a page are always stored in logical order. This is not true. There is another misconception that all the free-space in a page is always maintained in one contiguous chunk. This also is not true. (Yes, the image above shows the free space in one chunk and that very often is the case for pages that are being filled gradually.)

If a record is deleted from a page, everything remaining on the page is not suddenly compacted - inserters pay the cost of compaction when its necessary, not deleters.

Consider a completely full page - this means that record deletions cause free space holes within the page. If a new record needs to be inserted onto the page, and one of the holes is big enough to squeeze the record into, why go to the bother of comapcting it? Just stick the record in and carry on.

Ah - but hold on a minute, what if the record should logically have come at the end of all other records on the page, but we've just inserted it in the middle - doesn't that screw things up somewhat?

No, because the slot array is ordered and get reshuffled as records are inserted and deleted from pages. As long as the first slot array entry points to the logically first record on the page, everythings fine. Each slot entry is just a two-byte pointer into the page - so its far more efficient to manipulate the slot array than it is to manipulate a bunch of records on the page. Only when we know there's enough free space contained within the page to fit in a record, but its spread about the page do we compact the records on the page to make the free space into a contiguous chunk.

One interesting fact is that the slot array grows backwards from the end of the page, so the free space is squeezed from the top by new rows, and from the bottom by the slot array.

Records

You know what these are already - we talked about them last time!

Pages are the basic unit of IO that SQL server uses. The buffer pool maps individual pages and torn-page protection and page checksums are implemented per-page. Fragmentation is mostly concerned with pages, and the efficiency of being able to read them in logical order (as defined by their next page pointers).

They can be allocated individually or in extents, which we'll cover next time...

Fragmentation (part 1): What are records?

Paul Randal - MSFT — Fri, 23 Jun 2006 18:41:00 GMT

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:

What are records?
What are pages?
What are extents?
What is a heap?
What is a clustered index?
What is a non-clustered index?

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...

Data records

These store table rows in a heap, or in the leaf level of a clustered index. They store all the columns of the table row that will fit in a single 8Kb page.
Data records are stored on data pages.
If any columns are for LOB data types (text, ntext, image, and the new LOB types in SQL Server 2005 - varchar(max), nvarchar(max), varbinary(max), XML), then there's a pointer stored in the data record which points to a text record on a different page (the root of a loose tree that stores the LOB value). Exceptions to this are when schema has been set to store LOB columns 'in-row' when possible. This is when a LOB value is small enough to fit within the confines of the data page that holds the data record, and so is stored in the same data record. This is a performance benefit as selecting the LOB column does not require an extra IO to read the text record.
In SQL Server 2005, non-LOB variable length columns (e.g. varchar, sqlvariant) may also be stored 'off-row' as part of the new capability (called row-overflow) of having table rows longer than 8060 bytes. In this case the storage format is the same as for LOB values - a pointer in the data record pointing to a text record.
I'll go into how the columns are laid out differently between heaps and clustered indexes in parts 4 and 5. There are also some twists in the record types for heaps that I'll cover in part 4.

Index records

There are two types of index records (which differ only in what columns they store):

Those that store non-clustered index rows
Those that comprise the b-tree that make up clustered and non-clustered indexes.

I'll explain more about the differences between these in parts 5 and 6 - it can be quite complicated (especially the differences between SQL Server 2000 and 2005) and is worth doing in separate posts.
Index records are stored on index pages.
Index records typically do not contain all the column values in a table (although some do - called covering indexes).
In SQL Server 2005, non-clustered index records can include LOB values as included columns (with the storage details exactly the same as for data records) and also can have row-overflow data that is pushed off-row (again, in exactly the same way as for data records).

Text records

There are various types of text records that comprise the tree structure that stores LOB values, stored on two types of text page.
An in-depth explanation of the various types and how they hang together is beyond the scope of this post and discussion.
They are also used to store variable-length column values that have been pushed out of data or index records as part of the row-overflow capability.

Ghost records

These are records that have been logically deleted but not physically deleted from the leaf level of an index.
The reasons for this are complicated, but basically having ghost records simplfies key-range locking and transaction rollback.
The record is marked with a bit that indicates it's a ghost record and cannot be physically deleted until the transaction that caused it to be ghosted commits. Once this is done, it is deleted by an asynchronous background proces (called the ghost-cleanup task) or it is converted back to a real record by an insert of a record with the exact same set of keys.
Ghost records will be mentioned later in the series when I discuss page compaction.

Other record types

There are also records that are used to store various allocation bitmaps, intermediate results of sort operations, and file and database metadata (e.g. in the per-file fileheader page and database boot page).
These are not relevant to a discussion of fragmentation so won't be considered further here.

Record structure

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:

record header

4 bytes long
two bytes of record metadata (record type)
two bytes pointing forward in the record to the NULL bitmap

fixed length portion of the record, containing the columns storing data types that have fixed lengths (e.g. bigint, char(10), datetime)
NULL bitmap

two bytes for count of columns in the record
variable number of bytes to store one bit per column in the record, regardless of whether the column is nullable or not (this is different and simpler than SQL Server 2000 which had one bit per nullable column only)
this allows an optimization when reading columns that are NULL

variable-length column offset array

two bytes for the count of variable-length columns
two bytes per variable length column, giving the offset to the start of the column value

versioning tag

this is in SQL Server 2005 only
this is a 14-byte structure that contains a timestamp plus a pointer into the version store in tempdb

If you have any questions on this stuff - put them in the comments of drop me an email.

Next time - what are pages?