SQL Server中TempDB管理(version store的逻辑结构)

前面几篇博文已经初步介绍了版本存储区，现在我们来了解一下它的逻辑结构，看看它究竟是如何储存不同结构的表格和索引行的。其实我们只要看一下DMV sys.dm_tran_version_store这个DMV就够了. 这个DVM视图显示了版本存储区全部逻辑结构。有两点值得注意。第一

前面几篇博文已经初步介绍了版本存储区，现在我们来了解一下它的逻辑结构，看看它究竟是如何储存不同结构的表格和索引行的。其实我们只要看一下DMV
sys.dm_tran_version_store这个DMV就够了.

这个DVM视图显示了版本存储区全部逻辑结构。有两点值得注意。第一，版本存储区也和数据页面索引页面一样由8k大小的页组成。这些页存在缓冲池中，可以在TempDB面临内存压力时被写入磁盘。第二，版本存储区存储的是完整的二进制文件，就像在数据页存储的一样。这种二进制文件分为前后两个部分，然后在SQL
Server内部会对其进行组合。这使得行版本存储独立于它所属的对象的架构，即一个储存区的页可以存储来自不同表不同索引的行，甚至可能来自同一实例下的不同。换句话说，版本存储区是一个SQL
Server实例下公用的。和数据页和索引页一样，在内存紧张的时候版本存储页也会从缓冲池中被清除。

如果查看名为sys.dm_tran_version_store的DMV会发现，我们会发现版本行有很多原始数据或索引页面所没有的的新属性，如database-id,行长度等。您可能会问，行版本同样受到SQL
Server最大行长度8060的限制，那么它是如何存储原始数据行（最大行长度也是8060）并增长新属性的呢。答案是，数据行在版本存储页实际上被分成了2行，只是在DMV视图中表现成一大行。

下面是一个版本存储的例子。事务57已经更新了三个不同的行，同时事务58只更新1行内容。请注意，如果一个事务中多次更新同一行，只会创建一个行版本，因为对其他事务来说，它从一开始就持有了X锁。

transaction_sequence_num
version_sequence_num database_id

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

57                      1                    9          

57                      2                    9          

57                      3                    9          

58                      1                    9          

 

rowset_id            status min_length_in_bytes

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

72057594038321152    0     
12                 

72057594038321152    0     
12                

72057594038321152    0     
12                

72057594038386688    0     
16                

 

record_length_first_part_in_bytes

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

29                              

29                              

29                              

33                              

 

record_image_first_part                                            

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

0x50000C0073000000010000000200FCB000000001000000270000000000       

0x50000C0073000000020000000200FCB000000001000100270000000000       

0x50000C0073000000030000000200FCB000000001000200270000000000       

0x500010000100000002000000030000000300F800000000000000002E0000000000

 

record_length_second_part_in_bytes    record_image_second_part

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

0                                  NULL

0                                  NULL

0                                  NULL

0                                  NULL