自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。我们来看一个简单的例子：

 USE master

 GO

 -- Create a new database

 CREATE DATABASE VersionStoreRestrictions

 GO

 -- Enable RCSI

 ALTER DATABASE VersionStoreRestrictions SET READ_COMMITTED_SNAPSHOT ON

 GO

 -- Use it

 USE VersionStoreRestrictions

 GO

 -- Create a table where each record is 8047 bytes large

 CREATE TABLE TableB

 (

    Column1 CHAR(40),

    Column2 CHAR(8000)

 )

 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条记录看看：

 -- Insert a initial row

 INSERT INTO TableB VALUES (REPLICATE('A', 40), REPLICATE('A', 8000))

 GO

现在当你尝试去更新这个记录（SQL Server尝试在TempDb里对这条记录进行版本控制），SQL Server会报下列错误：

 UPDATE TableB

 SET Column1 = REPLICATE('B', 40)

 GO

这个错误信息非常有意义，因为数据库上下文信息是错误的（SSMS显示你还在master数据库）。但是当你在UPDATE语句加上表架构时，你就能拿回实际的错误信息：

 UPDATE VersionStoreRestrictions.dbo.TableB

 SET Column1 = REPLICATE('B', 40)

 GO
  

哇噢，这是个内部错误，因为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内部架构和内部如何存储数据是多么重要！！

参考文章：

https://www.sqlpassion.at/archive/2011/05/06/rcsisi-doesnt-work-with-rows-larger-than-8046-bytes/