sql server checkdb真的很重要

  由于整体规划的需要，需要将目前公司的 MOSS 服务器迁移到工地去。 13 台服务器要从深圳市区搬迁到 100 多公里的外郊区。搬迁前我们应用方面已经将风险和相应的需要备份的东西提了出了。就我原来的理解，服务器变迁不就搬过去，再启起来就 ok 了。为了确保整个过程的安全和稳定，公司还特意请了微软的同事来做风险评估。迁移整个过程中让人感觉还是比较顺利，迁移过去后只进行了简单的测试。

往往噩梦就是在这样的平淡中产生，第二天下午收到用户反馈某个站点中的某些文档出现无法打开，去掉ie的错误友好提示后显示的是500内部错误。

通过文件名在[AllDocs]中找到出错文档ID

然后直接在数据库中查询

SELECT [Id]

      ,[SiteId]

      ,[DeleteTransactionId]

      ,[ParentId]

      ,[Size]

      ,[Level]

  ,[Content]

  FROM [WSS_Content_8500].[dbo].[AllDocStreams]

  where id ='A80AE532-AC04-4978-BA1A-01ABCCC397AE'

  --where id ='F8632684-3AE7-42B1-AA80-B90AF513FFE1'

测试了搜索两条记录，一条是能正常打开的文档，一条在应用层无法打开的文档。

正常打开的正常返回数据，不正常打开的返回错误

网络故障

 

基本上可以排除应用层面的问题，应该从数据库、硬件、网络、防火墙上去排查。

后在数据的日志中发现checkdb 出现1880多个数据不一致性错误。当天已经将情况汇报给了我们的服务器管理人员。

第二天管理人员开了微软的case，当天晚上与微软人员进行了检查，最终发现目前我们有三个站点的数据出现了数据库损坏，与微软同事、领导进行了长达2个小时的讨论，最终还是只能还原，检查搬迁前的备份，没有问题，可以确定是搬迁过程导致的。那就只能恢复到周五数据，这两天的数据就只能做增量的迁移。微软不建议直接操作数据库，也没有很好的方案。对于数据量少的两个站点决定采用手工的方式。有一个站点天内更新了超过1200条记录，600条为列表、600个位文档。立刻call我们的开发人员来写一个应急的迁移程序。

然后是两个通宵的，留有一下经验反馈以供参考

 

服务器搬迁等等操作的具体步骤如下

1、先在数据库指向dbcc checkdb(数据库名) 确保搬迁前的数据库是好的

2、搬迁前做好相应的数据库全备

3、搬迁后对数据库进行 dbcc checkdb 确保数据库在搬迁后的数据库是好的

4、如果出现不一致性错误就算是一个，不建议通过checkdb 的修复命令修复，建议直接还原备份

5、在日常的巡检中吧checkdb作为一个必备的操作步骤

 

 

文件作为数据流保存在数据库容易导致这样的不一致性错误，据微软的sql工程师说最近已经处理了3单类似的故障。所以还是尽早升级sql 2008 使用文件流的方式来保存文件数据吧

转载于:https://www.cnblogs.com/Hitclock/archive/2010/08/22/SqlServer.html