数据库质疑处理过程

《数据库质疑处理过程》由会员分享，可在线阅读，更多相关《数据库质疑处理过程（10页珍藏版）》请在装配图网上搜索。

1、文档供参考，可复制、编制，期待您的好评与关注！ 解决过程：（用你的数据库实体名替换newdb）1.建一个新库newdb，最好目录是SQL的默认目录。2.停掉数据库。删除新库的log文件,用metadb.mdf覆盖newdb.mdf。（这里的metadb就是出问题的帐套实体名，其实和我们新建的帐套一样，才会替换啊）3.启动数据库服务器。数据库newdb的状态为“置疑”。4. 允许对系统目录直接修改use mastergosp_configure allow updates,1go reconfigure with overridegoupdate sysdatabases set status=

2、-32768 where dbid=DB_ID(newdb)5停掉服务，删掉覆盖过来的日志，重建logdbcc rebuild_log(newdb,C:Program FilesMicrosoft SQL ServerMSSQLDatanewdb_log.ldf)6.dbcc检查dbcc checkdb(newdb)7.设置数据库为正常状态sp_dboption newdb,dbo use only,false8 不允许对系统目录直接修改sp_configure allow updates,0go reconfigure with overridego整个运行语句：use mastergosp

3、_configure allow updates,1go reconfigure with overridegoupdate sysdatabases set status=-32768 where dbid=DB_ID(AIS20080821091903)dbcc rebuild_log(AIS20080821091903,C:Program FilesMicrosoft SQL ServerMSSQLDataAIS20080821091903_log.ldf)dbcc checkdb(AIS20080821091903)sp_dboption AIS20080821091903,dbo u

4、se only,falsesp_configure allow updates,0go reconfigure with overridego又出现多次置疑，到最后，存货核算、入库查询功能都不能用了。下面就用了两个语句：DBCC CHECKdb 检查数据库的dbcc checktable(ICPurchase) 检查数据表的DBCC CHECKdb 检查，发现都是类似这样的错误：REC_Code_PositionCategory 的 DBCC 结果。服务器: 消息 8951，级别 16，状态 1，行 1表错误: 表 ICPurchaseEntry（ID 108631530）。索引 IDX_IC

5、PurchaseEntry_FGuid（ID 10）中下列行的键缺少或无效:服务器: 消息 8955，级别 16，状态 1，行 1数据行（1:29384:4）（由 RID = (1:29384:4) FInterID = 1325 and FEntryID = 3 and ? = NULL 标识）的索引值为 FGUID = C70F9FD2-6DA2-4295-B3E5-1043B4790855 and FInterID = 1325 and FEntryID = 3 and ? = NULL。服务器: 消息 8951，级别 16，状态 1，行 1表错误: 表 ICPurchaseEntry（

6、ID 108631530）。索引 IDX_ICPurchaseEntry_FGuid（ID 10）中下列行的键缺少或无效:服务器: 消息 8955，级别 16，状态 1，行 1发现主要是索引错误,那么修改索引就行了。1.找到索引2.3.4.只要分析、执行成功，回头再检查表，没有问题又出现以下错误：CB_TableFieldInfo 的 DBCC 结果。服务器: 消息 8929，级别 16，状态 1，行 1对象 ID 479392827: 在文本 ID 29247275008 中发现错误，该文本的所有者是由 RID = (1:27867:82) FSchemeID = 42 and FKey =

7、 HideColumns 标识的数据记录。服务器: 消息 8964，级别 16，状态 1，行 1表错误: 对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:22238)，槽 22，文本 ID 26887847936）未被引用。服务器: 消息 8964，级别 16，状态 1，行 1表错误: 对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:22238)，槽 23，文本 ID 26887913472）未被引用。服务器: 消息 8964，级别 16，状态 1，行 1表错误: 对象 ID 479392827。text、nt

8、ext 或 image 节点（位于页 (1:22238)，槽 24，文本 ID 26887979008）未被引用。服务器: 消息 8964，级别 16，状态 1，行 1表错误: 对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:22238)，槽 25，文本 ID 26888044544）未被引用。服务器: 消息 8964，级别 16，状态 1，行 1表错误: 对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:22238)，槽 26，文本 ID 26888110080）未被引用。服务器: 消息 8964，级别 16，

9、状态 1，行 1表错误: 对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:22238)，槽 27，文本 ID 26888175616）未被引用。服务器: 消息 8961，级别 16，状态 1，行 1表错误: 对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:28704)，槽 1，文本 ID 29247275008）与该节点位于页 (1:22238)，槽 27 处的引用不匹配。服务器: 消息 8974，级别 16，状态 1，行 1对象 HR_CMP_CompetencyLevel 有 6 行，这些行位于 1 页中。

10、DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。服务器: 消息 8929，级别 16，状态 1，行 1对象 ID 479392827: 在文本 ID 29247275008 中发现错误，该文本的所有者是由 RID = (1:27867:82) FSchemeID = 42 and FKey = HideColumns 标识的数据记录。服务器: 消息 8964，级别 16，状态 1，行 1表错误: 对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:22238)，槽 22，文本 ID 26887847936）未被引用。服务器: 消息

11、8964，级别 16，状态 1，行 1表错误: 对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:22238)，槽 23，文本 ID 26887913472）未被引用。服务器: 消息 8964，级别 16，状态 1，行 1表错误: 对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:22238)，槽 24，文本 ID 26887979008）未被引用。服务器: 消息 8964，级别 16，状态 1，行 1表错误: 对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:22238)，

12、槽 25，文本 ID 26888044544）未被引用。服务器: 消息 8964，级别 16，状态 1，行 1表错误: 对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:22238)，槽 26，文本 ID 26888110080）未被引用。服务器: 消息 8964，级别 16，状态 1，行 1表错误: 对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:22238)，槽 27，文本 ID 26888175616）未被引用。服务器: 消息 8961，级别 16，状态 1，行 1表错误: 对象 ID 479392827。

13、text、ntext 或 image 节点（位于页 (1:28704)，槽 1，文本 ID 29247275008）与该节点位于页 (1:22238)，槽 27 处的引用不匹配。服务器: 消息 8974，级别 16，状态 1，行 1不止一个节点引用了文本节点。对象 ID 479392827。text、ntext 或 image 节点（位于页 (1:28704)，槽 1，文本 ID 29247275008）被页 (1:22238)，槽 27 指向，同时又被页 (1:22233)，槽 21 指向。ICSchemeProfileEntry 的 DBCC 结果。解决方法：USE MASTER GO s

14、p_dboption AIS20081201123537, single user, true Go DBCC CHECKDB(AIS20081201123537, REPAIR_ALLOW_DATA_LOSS) Go USE AIS20081201123537 go exec sp_msforeachtable DBCC CHECKTABLE(?,REPAIR_ALLOW_DATA_LOSS) exec sp_msforeachtable DBCC DBREINDEX(?) go sp_dboption AIS20081201123537, single user, false回头再检查数据库，没有发现任何错误。完了，恢复帐套的时候还是会出错，分离数据库，删掉日志，然后附件数据库，备份后再恢复就没有问题了。10 / 10