有的时候发现查询数据库会出现以下类似的提示：
[Microsoft][ODBC SQL Server Driver][SQL Server]text、ntext 或 image 节点的页 (1:220)，槽 14 不存在。
[Microsoft][ODBC SQL Server Driver][SQL Server]通讯链接失败
[Microsoft][ODBC SQL Server Driver][SQL Server]警告: 严重错误 7105 发生于 10 7 2008 10:15AM
这就说明数据表出现了问题了，需要进行修复了，修复的方法很简单，在sql 查询分析器里执行以下一段程序就可以了，不过要记得不要选中要修复的数据库，因为该操作是再单用户下进行的。
USE MASTER
GO
sp_dboption '数据库名', 'single user', 'true'
Go
DBCC CHECKDB('数据库名', REPAIR_ALLOW_DATA_LOSS)
Go
USE 数据库名
go
exec sp_msforeachtable 'DBCC CHECKTABLE("表名",REPAIR_ALLOW_DATA_LOSS)'
exec sp_msforeachtable 'DBCC DBREINDEX("表名")'
go
sp_dboption '数据库名', 'single user', 'false'
Go
执行完你就会发现一切都ok了，呵呵。
--------------------------------------------------------------------------------------
DBCC CHECKTABLE
DBCCCHECKTABLE('table_name'|'view_name'[,{NOINDEX|index_id}|,{REPAIR_ALLOW_DATA_LOSS|REPAIR_FAST|REPAIR_REBUILD}])[WITH{ALL_ERRORMSGS][,NO_INFOMSGS][,TABLOCK][,ESTIMATEONLY][,{PHYSICAL_ONLY|DATA_PURITY}]}]
参数：
NOINDEX
指定不应对用户表的非聚集索引执行会占用很大系统开销的检查。这将减少总执行时间。NOINDEX 不会影响系统表，因为完整性检查的执行对象始终是所有系统表索引。
index_id
要进行完整性检查的索引标识 (ID) 号。如果指定了 index_id，则 DBCC CHECKTABLE 只对该索引以及堆或聚集索引执行完整性检查。
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
指定 DBCC CHECKTABLE 修复发现的错误。若要使用修复选项，数据库必须处于单用户模式。
REPAIR_ALLOW_DATA_LOSS (最严格的修复方法，会修复所有的索引，还会重建数据页的存储分配和指针，并且还会从数据页中删去残缺的数据。 )
尝试修复报告的所有错误。这些修复可能会导致一些数据丢失。
REPAIR_FAST (最简单的修复模式，只修得非聚集索引的键，不会对数据页进行操作。)
保留语法只是为了向后兼容。未执行修复操作。
REPAIR_REBUILD (中等级别的修复方法，对于所有的非聚集索引和索引指针进行完全的检查和重建。不会对数据页进行写入操作。)
既执行次要且不耗时的修复操作（如修复非聚集索引中的额外关键字），也执行耗时的修复操作（如重建索引）。执行这些修复时不会有丢失数据的危险。
ALL_ERRORMSGS
显示不受限制的错误数。如果未指定 ALL_ERRORMSGS，则只显示前 200 个错误消息。
NO_INFOMSGS
取消显示所有信息性消息。
TABLOCK
可使 DBCC CHECKTABLE 获得一个共享表锁，而不使用内部数据库快照。TABLOCK 可使 DBCC CHECKTABLE 在负荷较重的表上运行得更快，但 DBCC CHECKTABLE 运行时会减少表上可获得的并发性。
ESTIMATEONLY
显示运行 DBCC CHECKTABLE 和所有其他指定选项时，所需的 tempdb 空间的估计大小。
PHYSICAL_ONLY
限 制为检查页、记录标头的物理结构以及 B 树物理结构的完整性。此选项旨在以较低的开销检查表的物理一致性，同时，此项检查还可以检测可能危及用户数据安全的残缺页和常见的硬件故障。在 SQL Server 2005 中，DBCC CHECKTABLE 完整运行的时间可能比早期版本要长得多。导致此行为发生的原因如下：
逻辑检查比较全面。
要检查的某些基础结构更为复杂。
在 SQL Server 2005 中引入了许多新的检查，以包含新增功能。
因 此，使用 PHYSICAL_ONLY 选项可能会使 DBCC CHECKTABLE 在大型表上运行的时间短得多，所以对需要频繁检查的生产系统，建议使用 DBCC CHECKTABLE。我们仍然建议定期执行 DBCC CHECKTABLE 的完整运行。这些运行的执行频率取决于各业务和生产环境特定的因素。PHYSICAL_ONLY 始终表示 NO_INFOMSGS，不能与任何修复选项一同使用。
DATA_PURITY
使 DBCC CHECKTABLE 检查表中是否存在无效或越界的列值。例如，DBCC CHECKTABLE 检测到日期和时间值大于或小于 datetime 数据类型的可接受范围的列，或者小数位数或精度值无效的 decimal 或近似 numeric 数据类型列。
对于在 SQL Server 2005 中创建的数据库，默认情况下将启用列值完整性检查，并且不需要使用 DATA_PURITY 选项。对于从 SQL Server 的早期版本升级的数据库，您可以使用 DBCC CHECKTABLE WITH DATA_PURITY 查找和更正特定表中的错误，但是默认情况下不会对该表启用列值检查，直到 DBCC CHECKDB WITH DATA_PURITY 在数据库中正确运行时为止。然后，DBCC CHECKDB 和 DBCC CHECKTABLE 将默认检查列值完整性。
申明
非源创博文中的内容均收集自网上，若有侵权之处，请及时联络，我会在第一时间内删除．再次说声抱歉!!!
博文欢迎转载，但请给出原文连接。
