你遇到的最糟糕的事莫过于备份文件无法还原数据库了。我这里并不是说缺少磁盘空间或者类似的事导致的无法还原，而是一个100%确认已经被损坏的备份文件。你会问，那我怎么办呢？别着急，SQL Server有一个完善的还原功能来验证备份文件。

举个例子，当你第一次创建了一个备份文件，它应该是好的，但这仅仅是“应该”。每一次，这个文件被拷贝到另一个地方时，文件就会存在被损坏的风险。确认这个备份文件可以继续使用的最好的方法就是还原它，然后立即运行DBCC CHECKDB。如果当时条件不允许持续还原和检查，那么使用RESTORE VERIFYONLY命令就是你另一个最好的选择了。

不幸的是，这里面有个小问题。在SQL Server 2000里，在RESTORE VERIFYONLY会话期间，会发生下面这种情况：

现在，假如你使用一个16进制的编辑器(比如UE)，任意修改备份文件中存储的数据，然后再次运行RESTORE VERIFYONLY，SQL Server仍然会告诉你“备份设备有效(The backup set is valid)”。

在SQL Server 2000里，RESTORE VERIFYONLY仅仅检查文件是否符合Microsoft Tape Format (MTF)规范，是否可以从磁盘读取数据。所以你的备份数据可能含有垃圾数据。

现在在SQL Server 2005里面，缺省的备份设置和2000一样。也就是说，假如你的备份文件在数据备份区域有垃圾数据的话，SQL Server 2005依然会报告：备份设置有效。

那我们应该如何应对呢？答案就是使用备份时使用CHECKSUM选项，例如：

BACKUP DATABASE AdventureWorks TO DISK = 'G:\backups\AdventureWorks_full.bak' WITH CHECKSUM

现在，假如你更改文件数据备份区域的一个字节，然后在那个文件上运行RESTORE VERIFYONLY的话，会产生如下提示：

Server: Msg 3189, Level 16, State 1, Line 1
Damage to the backup set was detected.
Server: Msg 3013, Level 16, State 1, Line 1
VERIFY DATABASE is terminating abnormally.

下图显示了运行过程：

RESTORE VERIFYONLY终于按照我们期望的方式工作了。在备份期间使用CHECKSUM选项会引起SQL Server执行如下操作：

为备份数据计算校验和。这个校验和可来与RESTORE VERIFYONLY过程中产生的校验和进行对比。
校验页的校验和。如果校验失败，备份就会被中止。这也是一个好办法，用于确认你从一开始，就正在备份一个“良好”状态的数据库。
那么，使用CHECKSUM会给你带来什么负面影响呢？

备份和还原时，会占用大量处理器时间
增加备份和还原时间
总之，在SQL Server 2000和2005中，使用默认备份设置的话，RESTORE VERIFYONLY不能检查出来备份文件的数据是否已经被破坏。仅仅在SQL Server 2005中当创建备份时使用了CHECKSUM选项的话，才能验证备份数据的完整性。

但是也许你们部门预算有限，并没有另外购买SQL Server 2005的license，怎么办呢？当然我们可以使用SQL Server 2005的Express版本。虽然SQL Server 2005Express是免费的，但是它仅仅支持4GB以下的数据库。不过很少有人知道，当使用RESTORE VERIFYONLY命令时，Express版本可以工作在大于4GB的文件上。没问题，你可以在你的备份文件服务器上安装Express，然后尽情的验证你的备份文件是否有效。

文章如转载，请注明转载自：http://www.5iadmin.com/post/108.html