• 修复数据库的终极之战


    1、以前修复数据库都使用最低级别的修复,使用如下语句

    alter database yc_smartcard2 set single_user -----将数据库置于单用户模式下

    use yc_smartcard2

    dbcc checkdb('yc_smartcard2',repair_allow_data_loss) --修复数据库

    dbcc checkdb ('yc_smartcard2',REPAIR_REBUILD)        --修复数据库索引

    alter database yc_smartcard2 set multi_user   -----将数据库置于多用户模式下

    一般当掉的数据库用此方式能修复回来。

    2、可是,历史性的时刻到来了,昨天遇到一个用前面方法无法修复的数据库,CHECKDB后发现有20个一致性错误,其实我们数据库有200多个表,经常用到的无非也就那20来个表。

    A、所以直接针对数据表CHECKTABLE,弹出了如下图所示的错误。

     

    B、查询该表的所有信息(select * from te_consumedetailxf)弹出了如下图所示的错误信息

    服务器: 消息 8908,级别 22,状态 6,行 1

    表错误: 数据库 ID 18,对象 ID 1314103722,索引 ID 0。链的链接不匹配。(1:16892)->next = (1:17648),但 (1:17648)->prev = (1:14909)

    连接中断

    C、据以上两点查询来看,肯定是因为索引的问题引起的,直接删除掉索引,再进行select * from te_consumedetailxf则查询正常,CHECKDB也一切正常。

    再仔细核查这些数据,居然有重复数据,此数据库当掉是因为当时数据正在大量入库时突然断电引起的。却引发了如此多的索引并不允许的重复数据的存在,故出现此一致性错误,将重新数据查询出来DELETE掉,再将索引重新建立回去,再CHECKDB一下,一切恢复正常,Yeah!!!!

    3、其实我们也可以直接使用重建索引也可以解决相当多的数据库一致性错误的。其格式:

    DBCC DBREINDEX ('dbo.te_consumedetailxf', 'pk_TE_ConsumeDetailXF_ConsumeDetailId',90)

    若重建以后正常就不必要再去大费周章去查询数据了。

    当然如果重建后仍然解决不了问题,则需要你删除索引后,去仔细核实一下数据是否都是正常数据等,找到病因,寻求解决办法。

    今天在这里记录一下,看到的朋友有需要的要尽量拿去参数哈,嘻嘻~~~~数据库当掉不是问题,找到解决办法就好,哈哈~~~

     

  • 相关阅读:
    对于函数中多个返回值的处理
    Docker-compose 安裝单机版redis
    设计模式七大设计原则
    UML 设计技巧
    使用Docker 容器配置nexus3.29 私有仓库
    分布式消息Kafka通信原理分析
    分布式消息Kafka通信
    使用docker 搭建nexus3.29
    分布式消息Kafka初步认识及基本应用
    Dubbo 常用配置及源码分析
  • 原文地址:https://www.cnblogs.com/medci/p/1592851.html
Copyright © 2020-2023  润新知