自SQL Server 2005起，我们有了READ COMMITTED SNAPSHOT ISOLATION level (RCSI) 和SNAPSHOT ISOLATION level (SI)两个事务隔离级别。当你使用这些事务隔离级别时，读操作（SELECT语句）在读的时候不需要S锁（共享锁），写操作（UPDATE，DELETE语句）会对记录进行版本控制，这些改变会写入TempDb。它们就会生成一个版本链，记录的最新版本（存在数据库里的数据页里）指向存在TempDb里的页，下图可以帮助我们理解这个情况。
![]()
为了使这个机制有效，SQL Server需要在数据库内部的数据页上的每条记录，增加14 bytes长的指针。这就是说，每条记录增加了14 bytes的长度。或许你已经知道，当你使用定长数据类型时，SQL Server内部的记录长度不能超过8060 bytes。这就意味着，当你启用RCSI/SI隔离级别时，会导致记录超过现有的8060 bytes。我们来看一个简单的例子：
1 USE master
2 GO
3
4 -- Create a new database
5 CREATE DATABASE VersionStoreRestrictions
6 GO
7
8 -- Enable RCSI
9 ALTER DATABASE VersionStoreRestrictions SET READ_COMMITTED_SNAPSHOT ON
10 GO
11
12 -- Use it
13 USE VersionStoreRestrictions
14 GO
15
16 -- Create a table where each record is 8047 bytes large
17 CREATE TABLE TableB
18 (
19 Column1 CHAR(40),
20 Column2 CHAR(8000)
21 )
22 GO
从代码里我们可以看到，这里我创建了带2个CHAR列，总长为8040 bytes的表。SQL Server为每条记录内部需要至少7 bytes的开销。这里数据页上的1条记录需要8047 bytes。因为我们在数据库级别启用了RCSI数据隔离级别，SQL Server需要增加额外的14 bytes作为行版本指针（Row Version Pointe），这就把表里的每条记录长度扩展到8061 bytes。对于SQL Server来说，这就意味着每条记录太长了（多出1 byte）。我们在表里插入1条记录看看：
1 -- Insert a initial row
2 INSERT INTO TableB VALUES (REPLICATE('A', 40), REPLICATE('A', 8000))
3 GO
现在当你尝试去更新这个记录（SQL Server尝试在TempDb里对这条记录进行版本控制），SQL Server会报下列错误：
1 UPDATE TableB
2 SET Column1 = REPLICATE('B', 40)
3 GO
![]()
这个错误信息非常有意义，因为数据库上下文信息是错误的（SSMS显示你还在master数据库）。但是当你在UPDATE语句加上表架构时，你就能拿回实际的错误信息：
1 UPDATE VersionStoreRestrictions.dbo.TableB
2 SET Column1 = REPLICATE('B', 40)
3 GO
4
![]()
哇噢，这是个内部错误，因为SQL Server使用的缓存只有8060 bytes 大，现在我们尝试在那个缓存里保存8061 bytes——瞧！这在SQL Server内部是个bug！你可以在自SQL SERVER 2005以后的版本里验证这个BUG，也就说，这个BUG已经存在好几年了（SQL Server 2012已经修正这个BUG,但在页里面的确存储了预期的8061 bytes，我测试的版本是SQL Server 2008R2）。
当你对数据库启用RCSI/SI数据隔离级别时，你就要留意这个BUG了，因为这意味这RCSI/SI在任何情况下都无效了。当在你的数据库里有1个表超过8046 bytes限制，那你真的是有麻烦了！通过这个危险的BUG（nasty bug），你也会理解，知道SQL Serve内部架构和内部如何存储数据是多么重要！！
本文转自Woodytu博客园博客，原文链接：http://www.cnblogs.com/woodytu/p/4578564.html，如需转载请自行联系原作者
