最近一段时间接到很多客户咨询SQL数据库损坏，附加数据库报错的一些问题，在这里整理一下SQLSEVER数据库常见的一些故障现象及注意事项。

      目前中小型企业使用SQLSEVER应用的非常多，但由于各种原因，也会经常出现一些不同的故障，常见的有一下几种：

      一，附加数据库文件MDF及日志文件LDF时，报“823”错误。

      故障出现原因：

      （1）在数据库读写过程中突然死机或者断电。

      （2）服务器重启，重启后数据库出现“置疑”状态。 

      （3）磁盘I/O错误

      在以上可能的三种突发故障下，由于缓冲数据丢失，数据库无法写入正确的数据，导致数据结构紊乱，重启后数据库无法正常附加。

       二，通过之前备份的数据库进行数据库还原时，出现“内部一致性错误”。这通常也是数据库管理人员最大的梦魇了，明明是做了备份，却在还原时发现备份文件是损坏的。这意味着数据库的丢失，后果是非常严重的。

      故障出现原因：

      （1）备份文件和数据库放在同一个物理硬盘上，硬盘出故障，备份也损坏。

      （2）备份介质损坏；或者做的是网络备份，数据在网络传输中发生了损坏。

      （3）数据库在做完整备份、文件备份或者文件组备份的时候，里面的内容就已经有了损坏。这是因为SQL Server在做数据备份的时候为了节省时间，基本只是很简单地把数据页面拷贝下来，不会做一致性检查的。但是在恢复的时候，需要将数据库恢复（Recover）到事务一致的一个时间点。如果备份中的损坏妨碍了SQL Server的前滚后滚(Redo和Undo)，恢复动作就会遇到错误。

      （4）在备份数据库时由于磁盘中有坏道，备份出来的MDF文件不完整时也会出现这种错误。

      当数据库出现以上的故障时，需要修复数据库文件当中的坏页面，如果对MDF文件结构不是很清楚的话，请不要对原文件进行胡乱修改，这样会适得其反，会造成更大的损失。我们可以先将数据库文件备份一份，然后对备份文件用命令来修复，常常这种情况用命令修复完后，数据会丢失部分！

      三，附加还原数据库后，检测数据库是出现一致性错误和分配错误。

      数据库附加或者还远成功后，DBCC CHECKDB 通不过，报一系列错误。如下所示：

      CHECKDB 发现了 5 个分配错误和 2 个一致性错误（在数据库 'test' 中）。

      repair_allow_data_loss 是最低的修复级别（对于由 DBCC CHECKDB (test ) 发现的错误而言）。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系.

      故障出现原因：数据库的某个页面被更改或者清0，所以产生一致性错误和分配错误。

      四， 最为常见的“未能读取并闩锁页 (1:4234)（用闩锁类型 SH）”

      在检测数据库，会常见到下面的错误： “服务器: 消息 8966，级别 16，状态 1，行 1 未能读取并闩锁页 (1:4234)（用闩锁类型 SH）。sysobjects 失败”。这种“未能读取并闩锁页 (1:4234)（用闩锁类型 SH）”错误常常会出现在系统表中：sysobjects、sysindexes、syscolumns等中，这种错误出现的原因是因为系统表被破坏，这种错误是很麻烦地，因为SQL的效验比较严密，只要稍改一个关键字节，都出报这个错误，但有时可以导出部分数据。

      五， 误删除或误格式化。

      出现这种情况后，很多用户会用市面上的一些软件来恢复数据库，虽然用这些数据库软件可以恢复出MDF和LDF文件来，但几乎都会无法附加，即使附加成功，错误也会很多，因为数据库在日常中经常增加和删除记录，这样就会出数据库文件存储不连续的情况，而市面上的软件都是连续取数据，所以会造成数据库无法附加。出现这种错误时，用户应尽量不要使用本计算机，更不要安装软件和写任何数据。

      针对最后两种情况的数据库损坏，恢复起来是比较复杂的，简单的一些命令恢复是达不到恢复的目的，这需要对数据库的结构有非常深入的了解。目前市面上，能够智能恢复数据库的工具非常之少，用户遇到这种问题可以尝试使用D-Recovery for MS Sql sever数据库恢复专用软件通过碎片提取的方式更完整的恢复数据库表内记录。