修复数据库和表

DBCCCHECKDB用法手工修复数据库快速修复DBCCCHECKDB('数据库名',REPAIR_FAST)重建索引并修复DBCCCHECKDB('数据库名',REPAIR_REBUILD)如果必要允许丢失数据修复DBCCCHECKDB('数据库名'',REPAIR_ALLOW_DATA_LOSS)如果出现错误：未处理修复语句。数据库需处于单用户模式下。可以先启用单用户模式，方法如下执行存储过程：Usemastergosp_dboption数据库名,single,true--更改成单用户alterdatabaseams2setsingle_userwithrollbackimmediate--还原数据库为多用户模式alterdatabaseams2setmulti_userwithrollbackimmediate########################################################################################################################手工修复数据库试例操作步骤:----------------------------------------------------------------------------------------------进入SQL查询分析器,执行语句:--检查数据库完整性dbcccheckdb('ams1')执行结果:---------------------------------------------------------------CHECKDB发现了0个分配错误和11个一致性错误（在数据库'ams1'中）。repair_allow_data_loss是最低的修复级别（对于由DBCCCHECKDB(ams1)发现的错误而言）。DBCC执行完毕。如果DBCC输出了错误信息，请与系统管理员联系。说明数据库确实有问题,11个错误,找到错误地方:-------------------------------------------------------------------------------对象'Tb_Archives_File_1'有3777行，这些行位于172页中。CHECKDB发现了0个分配错误和2个一致性错误（在表'Tb_Archives_File_1'中，该表的对象ID为907150277）。表明'Tb_Archives_File_1'表确实有2个错误,难怪一查询就要死机,于是运行语句进行表修复:----------------------------------------------------------------------------------------以repair_allow_data_loss级别修复表dbccchecktable('Tb_Archives_File_1',repair_allow_data_loss)go执行结果:服务器:消息7919，级别16，状态3，行2未处理修复语句。数据库需要处于单用户模式下。DBCC执行完毕。如果DBCC输出了错误信息，请与系统管理员联系。---------------------------------------------------------------------------------------------------需要将数据库改为单用户模式,于是再执行:--更改成单用户alterdatabaseams2setsingle_userwithrollbackimmediatego--已repair_allow_data_loss级别修复表dbccchecktable('Tb_Archives_File_1',repair_allow_data_loss)go--若还有问题，修复索引表DBCCDBREINDEX('Tb_Archives_File_1')--再修复表DBCCCHECKTABLE('Tb_Archives_File_1')直到返回的结果没有错误!--查询是否正常select*fromTb_Archives_File_1再查询那张错误表,不报错,也不死机了,数据也完好无损.....哈哈....--还原数据库为多用户模式alterdatabaseams2setmulti_userwithrollbackimmediate