SQL2005中的事务与锁定（九）--2

SQL2005中的事务与锁定（九）

(二)

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

-- Author : HappyFlyStone

-- Date   : 2010-01-18 22：00

-- Version: Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86)

--      Apr 14 2006 01:12:25

--           Copyright (c) 1988-2005 Microsoft Corporation

--           Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

--       转载请注明出处，更多请关注：http://blog.csdn.net/happyflystone

--       关键字：行版本存储二、tempdb

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

   

16、详述行版本存储区二

 

    好，下面具体来看行版数据的结构。建议大家先关注这几个动态管理视图(DWV)。

 

select * from sys.dm_tran_version_store

select * from sys.dm_tran_current_transaction

select * from sys.dm_tran_transactions_snapshot

go

 

sys.dm_tran_version_store 返回一个可显示版本存储区中所有版本记录的虚拟表。其中有几个字段要了解一下：

列名	说明
transaction_sequence_num	生成该记录版本的事务的序列号
version_sequence_num	版本记录序列号。此值在生成事务的版本中是唯一的。
status	指示有版本控制的记录是否已拆分为两个记录。如果此值为 0，则记录存储在一页中。如果此值为 1，则记录拆分为两个记录，且存储在两个不同页上。
min_length_in_bytes	记录的最小长度（字节）。
record_image_first_part	版本记录的第一部分的二进制图像。
record_image_second_part	版本记录的第二部分的二进制图像。

dm_tran_current_transaction显示当前会话中的事务状态信息。

    首先我们来看一下当前库快照状态：

select name,snapshot_isolation_state_desc,is_read_committed_snapshot_on

from sys.databases

where name = 'dblock'

/*

name               snapshot_isolation_state_desc           is_read_committed_snapshot_on

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

dblock              OFF                                                          1

(1 行受影响)

*/

 

 

    好吧，我下面准备部分数据并用前面但要查看页面信息的命令先看看页面内容：

 

drop table ta

 

create table ta(id int,col char(10))

insert into ta select 1,'aaaaaaaaaa'

insert into ta select 1,'bbbbbbbbbb'

dbcc ind(dblock,'ta',-1) --73

dbcc traceon(3604)

dbcc page('dblock',1,89,1)

00000000:   50001200 01000000 63636363 63636363 †P.......cccccccc        

00000010:   63200200 fcc80000 00010000 00120000 †c ..............        

00000020:   000000†††††††††††††††††††††††††††††††...                     

 

Slot 1, Offset 0x83, Length 35, DumpStyle BYTE

 

Record Type = PRIMARY_RECORD         Record Attributes =  NULL_BITMAP VERSIONING_INFO

 

Memory Dump @0x433BC083

 

00000000:   50001200 01000000 63636363 63636363 †P.......cccccccc        

00000010:   63200200 fcc80000 00010001 00120000 †c ..............        

00000020:   000000†††††††††††††††††††††††††††††††...         

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

Slot 0, Offset 0x60, Length 35, DumpStyle BYTE

 

Record Type = PRIMARY_RECORD         Record Attributes =  NULL_BITMAP VERSIONING_INFO

 

Memory Dump @0x444CC060

 

00000000:   50001200 01000000 64646464 64646464 †P.......dddddddd        

00000010:   64640200 fcd00000 00010000 00130000 †dd..............        

00000020:   000000†††††††††††††††††††††††††††††††...                      

 

Slot 1, Offset 0x83, Length 35, DumpStyle BYTE

 

Record Type = PRIMARY_RECORD         Record Attributes =  NULL_BITMAP VERSIONING_INFO

 

Memory Dump @0x444CC083

 

00000000:   50001200 01000000 64646464 64646464 †P.......dddddddd         

00000010:   64640200 fcd00000 00010001 00130000 †dd..............        

00000020:   000000†††††††††††††††††††††††††††††††...                     

           

 

至少上面显示的行信息不用我介绍了吧，直接用我上面介绍的，因为当前没有产生版本信息，我们用两个select来验证：

select * from sys.dm_tran_version_store

select * from sys.dm_tran_current_transaction

两个SQL没有返回任何信息，下面更新记录生成版本信息。

 

update ta

set col = 'ddddddddd' where id = 1

select * from sys.dm_tran_version_store

select * from sys.dm_tran_current_transaction

 

transaction_sequence_num version_sequence_num database_id rowset_id            status min_length_in_bytes record_length_first_part_in_bytes record_image_first_part                                                                                                                                                                                                                                            record_length_second_part_in_bytes record_image_second_part

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

29     1  8      72057594038714368    0      18     35 0x5000120001000000616161616161616161610200FC0000000000000000100000000000        0        NULL

 

(1 行受影响)

 

transaction_id       transaction_sequence_num transaction_is_snapshot first_snapshot_sequence_num last_transaction_sequence_num first_useful_sequence_num

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

4872     18           0             NULL            29                21

 

(1 行受影响)

如果这时我们再查看原来的TA里的slot0信息：

 

Slot 0, Offset 0x60, Length 35, DumpStyle BYTE

 

Record Type = PRIMARY_RECORD         Record Attributes =  NULL_BITMAP VERSIONING_INFO

 

Memory Dump @0x445EC060

 

00000000:   50001200 01000000 64646464 64646464 †P.......dddddddd        

00000010:   64200200 fcc00000 00010001 001d0000 †d ..............        

00000020:   000000†††††††††††††††††††††††††††††††...   

    前面26个字节不用解释了吧，那这(c00000 00010001 001d0000 000000)14个字节是什么意思呢？大家是记得前面介绍过XSN啦，这就是14个字节指针信息，用于跟踪行版本信息的。sys.dm_tran_current_transaction 表返回的first_useful_sequence_num列就是是大XSN行版本。XSN的如下：

第一部分 8bytes	第二部分 6bytes
c00000 00010001 00	1d0000 000000
在tempdb中的文件号、页面号、slot号	记录版本的事务的序列号
exec sp_us_FPSinfo 0xc000000001000100 FILE_NUM:PAGE_ID:SLOT_ID ---------------------------- 1       : 192   : 1	1d è 29 每一个事务都会分配一个独立并不断增加的XSN值

    验证一下在tempdb中的内容 (注意红色部分)：

 

dbcc page('tempdb',1,192,1)

 

Slot 1, Offset 0xc8, Length 104, DumpStyle BYTE

Record Type = INDEX_RECORD           Record Attributes =  VARIABLE_COLUMNS

Memory Dump @0x441FC0C8

 

00000000:   26010068 0000851f 44f77f1b 01140000 †&..h....D.......    

00000010:   00000000 00010000 00000000 0008001f †................    

00000020:   44000005 a000000c 00000000 0112001f †D...............    

00000030:   441c5b1b 0180861f 441c0800 00000000 †D.[.....D.......    

00000040:   00000000 00500012 00010000 00616161 †.....P.......aaa    

00000050:   61616161 61616102 00fc0000 00000000 †aaaaaaa.........    

00000060:   00001000 00000000 †††††††††††††††††††........

 

17、版本区大小的管理

       首先版本区的大小是SQLSERVER自行管理的，它有一个清理线程在活动，确保版本保留的时效。对于SI模式来说版本保留到事务结束，对于RCSI模式来说在Select结束线程就会移除版本数据。

       清理线程活动周期以分钟计，但是有一个例外，那就是如果周期未到而tempdb没有可用空间时，清理线程就会提前调用。在极端的情况下如果磁盘已经满，版本就无法生成，查询即失败，这是使用版本控制的一个注意事项。

 

请大家继续关注我的blog: http://blog.csdn.net/happyflystone