SQL Server误区30日谈 第21天 数据损坏可以通过重启SQL Server来修复
误区 #21:数据库损坏可以通过重启SQL Server或是Windows,或是附加和分离数据库解决
错误
SQL Server中没有任何一项操作可以修复数据损坏。损坏的页当然需要通过某种机制进行修复或是恢复-但绝不是通过重启动SQL Server,Windows亦或是分离附加数据库。
而实际上，如果你的数据库的损坏程度无法进行Crash Recovery的话(质疑状态)，那么分离附加数据库将会是你做的最糟糕的决定。这个原理是由于附加数据库中包含Crash Recovery步骤，如果Crash Recovery失败的话，那么附加也会失败。所以下面的技巧才是你所需要的:TechEd Demo: Creating, detaching, re-attaching, and fixing a suspect database。记住，永远不要分离损坏的数据库。
下面这类错误才是有可能通过重启解决:
- 如果在内存中的页损坏，但在磁盘上的页完好时，重启能够解决损坏问题
- 如果损坏发生了,但是重启过程中的某个步骤导致这个页不再被分配，则貌似损坏通过重启解决了，这个问题我之前已经有一篇博文进行阐述了:Misconceptions around corruptions: can they disappear?
- 如果IO子系统也重启,之前SQL Server对IO的需求被IO子系统“卡”住，则重启貌似能解决问题，但实际上这并不是修复损坏，而只是让出问题的IO子系统恢复。我只碰见过三四次这类情况。
不管怎么说，你起码要做到有对应的备份策略或是容易系统进行恢复和故障转移。重启可不是一个解决方案，这只会浪费时间。
您可能感兴趣的文章:- SQL Server误区30日谈 第29天 有关堆碎片的误区
- SQL Server误区30日谈 第28天 有关大容量事务日志恢复模式的误区
- SQL Server误区30日谈 第27天 使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB
- SQL Server误区30日谈 第26天 SQL Server中存在真正的“事务嵌套”
- SQL Server误区30日谈 第25天 有关填充因子的误区
- SQL Server误区30日谈 第24天 26个有关还原(Restore)的误区
- SQL Server误区30日谈 第23天 有关锁升级的误区
- SQL Server误区30日谈 第22天 资源调控器可以调控IO
- SQL Server误区30日谈 第20天 破坏日志备份链之后，需要一个完整备份来重新开始日志链
- SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志
- SQL Server误区30日谈 第18天 有关FileStream的存储，垃圾回收以及其它
- SQL Server误区30日谈 第17天 有关页校验和的误区
- SQL Server误区30日谈 第16天 数据的损坏和修复
- SQL Server误区30日谈 第15天 CheckPoint只会将已提交的事务写入磁盘
- SQL Server误区30日谈 第14天 清除日志后会将相关的LSN填零初始化
- SQL Server误区30日谈 第13天 在SQL Server 2000兼容模式下不能使用DMV
- SQL Server误区30日谈 第12天 TempDB的文件数和需要和CPU数目保持一致
- SQL Server误区30日谈 第11天 镜像在检测到故障后瞬间就能故障转移
- SQL Server误区30日谈 第10天 数据库镜像在故障发生后 马上就能发现
- SQL Server误区30日谈 第9天 数据库文件收缩不会影响性能
- SQL Server误区30日谈 第8天 有关对索引进行在线操作的误区
- SQL Server误区30日谈 第7天 一个实例多个镜像和日志传送延迟
- SQL Server误区30日谈 第6天 有关NULL位图的三个误区
- SQL Server误区30日谈 第5天 AWE在64位SQL SERVER中必须开启
- SQL Server误区30日谈 第4天 DDL触发器就是INSTEAD OF触发器
- SQL Server误区30日谈 第3天 即时文件初始化特性可以在SQL Server中开启和关闭
- SQL Server误区30日谈 第2天 DBCC CHECKDB会导致阻塞
- SQL Server误区30日谈 第1天 正在运行的事务在服务器故障转移后继续执行
- SQL Server误区30日谈 第30天 有关备份的30个误区
咨 询 客 服