我相信Checksum是在sql Server 2005中引入的,并且从先前版本升级或恢复数据库将保持其先前的页面验证方法.即没有隐式升级.
所涉及的问题是我们有一个使用sql Server 2000投入生产的生产数据库,后来又转移到了sql Server 2008 R2服务器.当我认为它是Torn Page Detection时,页面验证设置为无.回过头来看,我们似乎认为数据库最初是在sql Server 7.0中开发的,然后迁移到sql Server 2000,这可以解释观察到的结果.
我想知道Torn Page Detection和Checksum何时成为sql Server的一个功能,以及它们在迁移或升级到更新版本时的表现.
编辑：总结一些答案：
对Torn Page Detection进入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中默认关闭.
解决方法
但是在sql 2005及更高版本中,新设置PAGE_VERIFY取代了旧的TORN_PAGE_DETECTION,它允许从两种不同类型的页面验证中进行选择：TORN_PAGE_DETECTION和CHECKSUM.
现在问题是要设置哪一个 – TORN_PAGE_DETECTION或CHECKSUM？
TORN_PAGE_DETECTION – 在页面中每512个字节写一个位,允许您检测页面未成功写入磁盘的时间.问题是它不会告诉你存储在那些512个bye中的数据是否实际上是正确的,因为几个字节可能被错误地写入.
CHECKSUM – 在写入页面和读取页面时,将对页面的校验和进行计算,假设它具有校验和.
The sql Server computes the checksum based on the bit pattern on the page,stores it in the page header and then issues an I/O to write the page. When the sql Server reads the page,it re-computes the checksum using the same logic and then compares it with the value available in the page header. If the checksum value matches then it is assumes the page did not get corrupted during the write-read cycle.
Since the cost of computing the checksum is incurred on each page read and write,it can add to the cpu overhead and can possibly impact the throughput of your workload. Another thing to keep in mind is that the checksum is not unique for a specific bit pattern on the page. Two pages can possibly map to the same checksum value. So there is remote possibility that page corruption may go undetected.
要专门回答你的问题：
I believe Checksum was introduced in sql2005 and that upgrading or restoring a DB from a prior version would maintain it’s prevIoUs page verify method. i.e. there was no implicit upgrade.
是CHECKSUM是在sql Server 2005中引入的,是DEFAULT.从2000升级到2005时,必须显式更改数据库选项Page Verify以使用CHECKSUM.
如果将已在sql 2005上创建的数据库还原到运行sql 2005的另一台服务器,则无需进行设置.它将持续存在于您将页面验证选项设置为的位置.
I’ve not succeeded in researching when Torn Page Detection came in
来自：http://support.microsoft.com/kb/230785
Versions of sql Server earlier than 7.0
Versions of sql Server earlier than 7.0 did not provide log parity or
torn bit detection facilities. In fact,those versions can write the
same log page multiple times until the log records fill the 2-KB log
page. This can expose transactions that have successfully committed.
If the log page is being rewritten during a failure,a sector with the
committed transaction may not get rewritten properly.
因此,自sql Server 7.0以来,TORN_PAGE_DETECTION一直存在.即便如此,默认情况是它是not enabled (same link).
Note Torn page detection is not enabled by default in sql Server 7.0. See sp_dboption for how to enable the detection on your system.
因此,如果数据库是针对7.0实例开发的并且随后进行了升级,那么它将使用NONE的现有PAGE VERIFY选项进行升级(如@ThomasStringer在其答案中所述).
编辑次数：09/24/2013改善答案：
参考我的sql Server sqlSkills的内部注释,我发现使用页面转储,您可以验证是否已启用撕裂位检测 – 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,0) dbcc traceoff (3604) -- turn off the trace flag go
m_tornBits：它保存页面校验和或被撕裂页保护位替换的位 – 取决于为数据库打开的页面保护形式.
注意：我没有运行任何旧的sql Server版本.下面是从sql server 2000及以上版本确认的.如果你有一个7.0或6.5跑来跑去,你也可以确认它:-)
