SQL Server何时引入了残缺页面检测和校验和，升级行为是什么？

现代SQL Server中有两种不同的页面验证选项：被撕页检测和校验和。当然也没有选择。

我相信Checksum是在SQL Server 2005中引入的，并且从早期版本升级或还原数据库将保持其先前的页面验证方法。即没有隐式升级。

涉及的问题是我们有一个使用SQL Server 2000投入生产的生产数据库，此后已移至SQL Server 2008 R2服务器。当我期望将其作为“ 残缺页面检测”时，“ 页面验证”设置为“ 无”。回顾这段时间，我们似乎认为该数据库最初是在SQL Server 7.0中开发的，然后又迁移到SQL Server 2000，这也许可以解释观察到的结果。

我想知道“ 残缺页检测”和“ 校验和”何时成为SQL Server的功能，以及它们在迁移或升级到较新版本时的行为。

编辑：总结一些答案：

关于“残缺页面检测”进入SQL Server的某些日期存在一些差异。
链接1：http : //support.microsoft.com/kb/230785
链接2：http : //technet.microsoft.com/en-us/library/aa337525(v=sql.90).aspx

第一个链接指示SQL 7.0，第二个链接指示SQL2000。我倾向于相信SQL7.0的建议，并且由于在SQL7.0中默认关闭和在SQL2000中默认打开而对链接2感到困惑。

在SQL Server 2000中，如果要标识损坏的页面，则应将数据库选项TORN_PAGE_DETECTION设置为TRUE。

但是在SQL 2005及更高版本中，新设置PAGE_VERIFY代替了旧的TORN_PAGE_DETECTION，该设置可以从两种不同的页面验证类型中进行选择：TORN_PAGE_DETECTION和CHECKSUM。

现在的问题是要设置哪一个-TORN_PAGE_DETECTION或CHECKSUM？

TORN_PAGE_DETECTION-在页面中每512字节写入一个位，使您可以检测何时页面未成功写入磁盘。问题是它不会告诉您存储在这512个字节中的数据是否正确，这是由于几个字节可能被错误地写入的事实。

CHECKSUM-将在写入页面和读取页面时计算页面的校验和，假设页面上有校验和。

SQL Server根据页面上的位模式计算校验和，并将其存储在页面标题中，然后发出I / O来写入页面。当SQL Server读取页面时，它将使用相同的逻辑重新计算校验和，然后将其与页面标题中的可用值进行比较。如果校验和值匹配，则假定在读写周期内页面未损坏。

由于计算校验和的成本是在读取和写入每个页面时产生的，因此它可能会增加CPU开销，并可能影响工作负载的吞吐量。要记住的另一件事是，校验和对于页面上的特定位模式不是唯一的。两个页面可能可以映射到相同的校验和值。因此，极有可能无法检测到页面损坏。

参考：SQL2005中的校验和

要专门回答您的问题：

我相信Checksum是在SQL2005中引入的，从先前版本升级或还原数据库将保持其先前的页面验证方法。即没有隐式升级。

是的，CHECKSUM是SQL Server 2005中引入的，并且是DEFAULT。从2000升级到2005时，必须显式更改数据库选项“页面验证”以使用CHECKSUM。

如果将已经在sql 2005上创建的数据库还原到另一台运行sql 2005的服务器，则不必进行设置。它将一直保持到您将“页面验证”选项设置为的状态。

进入“残破页面检测”时，我尚未成功进行研究

来自：http : //support.microsoft.com/kb/230785

SQL Server 7.0之前的版本

7.0之前的SQL Server版本不提供日志奇偶校验或位破损检测功能。实际上，这些版本可以多次写入同一日志页面，直到日志记录填满2 KB的日志页面为止。这可以暴露已成功提交的事务。如果在失败期间正在重写日志页面，则具有已提交事务的扇区可能无法正确重写。

因此，从SQL Server 7.0开始，TORN_PAGE_DETECTION就存在了。即使那样，默认值是未启用（相同链接）。

注意默认情况下，SQL Server 7.0中不启用残缺页检测。有关如何在系统上启用检测的信息，请参见sp_dboption。

因此，如果数据库是针对7.0实例开发的，随后又进行了升级，则该数据库将使用现有的PAGE VERIFY选项NONE进行升级（如@ThomasStringer在其回答中所述）。

编辑：09/24/2013 要改善答案：

参考我的SQLSkills的SQL Server内部注释，我发现使用页面转储，您可以验证是否启用了破位检测-TORN_PAGE_DETECTION或CHECKSUM：

use database_name -- change here for your database !!
checkpoint
go 
dbcc traceon (3604)   -- send output to screen
go
dbcc page (dbaalert, 1,1,0)
dbcc traceoff (3604)  -- turn off the trace flag
go

m_tornBits：它保留页面校验和或被页面撕裂保护位所取代的位-取决于为数据库启用哪种形式的页面保护。

注意：我没有任何较旧的sql server版本正在运行。从sql server 2000及更高版本中确认以下内容。如果您运行的是7.0或6.5，也可以确认它:-)

看一下BOL的参考资料：

将用户或系统数据库升级到SQL Server 2005或更高版本时，将保留PAGE_VERIFY值（NONE或TORN_PAGE_DETECTION）。我们建议您使用CHECKSUM

这表明在SQL Server 2005之前该选项TORN_PAGE_DETECTION存在，但不存在CHECKSUM。

并回答您的第二点：

...并且从先前版本升级或还原数据库将保持其上一页验证方法。

对，那是正确的。您需要明确设置数据库以利用CHECKSUM页面验证方法。

现代SQL Server中有两个不同的选项用于页面验证

如您所说，共有三个：TORN_PAGE_DETECTION，CHECKSUM和NONE。

我相信CHECKSUM是在SQL Server 2005中引入的

如引自 该 MSDN文章标题为“缓冲区管理”：残缺页检测，在SQL Server 2000中引入的校验和在SQL Server 2005中引入的。

本文提到的其他内容的摘要是在数据库创建时指定了页面验证机制。因此，这取决于谁以及如何创建数据库以及将数据库设置为什么，还可以通过配置模型数据库来控制。还要注意的有趣一点是，如果更改设置，则仅在将页面写入下一页时，它才不会影响整个数据库。同样，根据Paul Randal所说，只有在将页面读入内存，进行更改然后再写回磁盘时，才可以完成此操作。该信息在这里。

我有一个使用SQL Server 2000投入生产的生产数据库，尽管可能是针对SQL Server 7.0开发的，但此后已移至SQL Server 2008 R2服务器。“页面验证”设置为“无”，尽管我希望它是“残缺页面检测”。

有权访问数据库实例的任何人都可以修改该值。它可以通过升级已经持续为MSDN上说这里：

当用户或系统数据库升级到SQL Server 2005或更高版本时，将保留PAGE_VERIFY值（NONE或TORN_PAGE_DETECTION）

也可能在以后修改它，因为有人误解了配置，并且在黑暗中拍摄以尝试解决问题。

我想知道何时“ TORN PAGE DETECTION”成为“页面验证”功能

如上所述的SQL Server 2000。

迁移或升级到较新版本时的行为。

如上所述，升级期间会保留以前的设置。

现在，我想指出一个事实，人们提供的其他链接指出，SQL Server 7.0是残缺页检测可用的时间。这些文章中所述的说法是正确的，但是已经多次证明，Microsoft文档不应在所有情况下都视为事实。他们错了很多地方。如此说来，您如何确定哪个答案可以接受？我们都提供了Microsoft提供的文档来支持我们的答案。

还要注意的是，从SQL Server 2012开始，折旧页检测在折旧列表中，因此在数据库上设置它的方式有什么关系？如果我看到它设置为CHECKSUM以外的任何其他内容，我会立即将其更改并继续执行其他更重要的任务。我不关心如何配置错误的配置，更重要的是更正它，然后确保那些有权更改它的人被告知为何不应将该配置项更改为其他任何内容。 我的$ 0.02

正如@Thomas Stringer和@Kin所说，它是在SQL Server 2005中引入的，我相信它可以在所有版本的SQL Server中使用。对于TempDB，尽管SQL Server 2008中引入了CHECKSUM

http://blogs.msdn.com/b/sqlserverstorageengine/archive/2008/03/23/checksum-and-tempdb.aspx