SQLserver201*数据库修复办法总结
SQLserver201*数据库修复办法总结
Praymid戴华倪
总结步骤如下：1、检测数据库，
使用命令（Dbcccheckdb）
拿到数据库后附加到本地SQLserver使其运行，打开企业管理器，查看它。同时打开查询分析器，在里面输入
Dbcccheckdb检测数据库命令然后回车即可以看到数据库的分析资料看到问题，
评注：拿到问题先不要盲目的卸载SQLServer，本次因为新手，上手后就把数据库卸载，这样就耗费了一天的时间，过没有任何作用，测试服务器的完整性可以拿一个好的数据库做对比，自己可以建一个“test”，如果测试数据库运行正常，则不需要对服务器做任何改动。千万不要改动系统，麻烦会更大。
提示：错误会以红色显示。2、简单修复：命令：dbcccheckdb输入以下两句尝试修复。
DBCCCHECKDB("AIS201*01201*2605",repair_allow_data_loss)DBCCCHECKDB("AIS201*01201*2605",repair_rebuild)
不管他究竟哪里错了，先用这两句试试一般的索引系统文件丢失，SQLserver都可以解决这个问题，基本就差不多了。但是对于主键索引损坏，这个命令基本修不好，所以对一个满身是伤的数据库，他可以修复70%。
注：修复时系统提示必须要在单用户模式下才可以生效，用户可以去企业管理器，对要修理的数据库：右击属性选项限制访问单用户。也可以使用以下语句实现：
ALTERDATABASEAIS201*04201*1143SETsingle_USERGO改为单用户
ALTERDATABASEAIS201*04201*1143SETMULTI_USERGO改为多用户。
继续使用dbcccheckdb检测，如果继续报错。再次运行：
DBCCCHECKDB("DataBasename")withNO_INFOMSGS,PHYSICAL_ONLY然后再运行：
DBCCCHECKDB("DataBasename",repair_allow_data_loss)WITHTABLOCK再次运行:DBCCCHECKDB("DBname")系统显示修复成功，说明本次问题主要由索引等数据库系统本身问题引起，这样的修复可能会导致数据丢失，但是绝对不会是大批丢失，基本没有影响。
2、检测表：命令：dbccchecktable(‘tablename’)
接上述检测提示：我们可以看到一个id号，这个基本就是这个错误的表在系统表“sysobjects”里面的注册信息。
输入如下语句即可以看见：
select*fromsysobjectswhereid=1205579333（错误提示号码）接下来检测这张表究竟是什么问题。输入：dbccchecktable(‘tablename’)
接下来将会得到一些错误提示，基本上就是检测表的时候那些，提示什么B树错误，父节点，子节点错误，这些都别管，因为这个可能就是索引引起的错误：
尝试用下列语句修复：
DBCCCHECKtable("Tablename",repair_rebuild)执行完后查看提示：如果出现下面的提示
CREATEUNIQUEINDEX终止，因为发现了索引ID1的重复键。最重要的主键为"3"。这里基本上就可以确定就是索引出的问题，而且数据表没有被修复的可能很可能就是内容产生的问题。根据提示，我们得出的结论就是主键重复。
这是我们使用select查询语句是看不到的甚至表里面打开也没有反映。此时，关闭查询分析器，打开企业管理器，找到那个数据表，然后右击选择设计表，选择主键，右击，取消主键，回到查询分析器，找到该表，右击选择索引，这时候表以前所有的索引都能看见了，但是上面的唯一性选项很明显没有了，然后给表里面添加一个新的字段，字段名id需要生成编号：
语句如下：altertablet_itemaddidintegeridentity该字段用完后删除，语句如下：altertablet_itemdropcolumnid
在查询分析器这里右击索引，选择唯一性选项，然后点击确定，系统会提示重复键，和最重要的主键ID，根据id数字，进行查询
如提示最重要的键值是3则，
select*fromt_itemwherefitemid=3
有时候查询的结果，是合法的，比如这个3可能只有一条，这个时候，就右击索引，点击编辑勾选唯一性，在列上面去掉一个，从上往下第一个开始，但是必须记住他的名字，最好写下来，这时候，你会发现错误信息里面的ID换成了另外一个数字，继续用select语句查询该数字，字段仍然是该表的第一个字段，你会发现他有两条，仔细对比这两条，什么都是一样的，每一个字段的值都一样，这显然不符合逻辑，用刚才添加的id记录删除一条，语句如下：
Deletetablenamewhereid=两着任何一个，删除完后，
右击恢复刚才被点掉的那一条列名，勾选上唯一性，点击确定，则正常，回到企业管理器，打开表设计，设置主键。完成。
回到查询分析器，输入dbccchecktable显示正常，再次检测数据库，显示正常。删除刚才增加的列，修复完成。
结论：修复这类数据表，别急着导出数据，新建库文件，这个应该还不到那一步，最好就是能这样修复，少动干戈，如果是主键重复，你导出数据，在把这个错误的数据倒进来（这里假设能正常导入），表的错误会依然存在。
扩展阅读：SQL Server 201*数据库LDF损坏,只有mdf的恢复
SQLServer201*数据库LDF损坏,只有mdf的恢复
SQLServer201*数据库文件遭到破坏的现象经常出现，数据库出错是否可以修复呢？答案是可以的，本日志以一个sqlserver201*数据库，数据库日志文件ldf损坏了，mdf正常，数据库附加失败的修复方法总结一下，数据库数据恢复在很多时候比较复杂，当数据库存在大量错误的时候，使用DBCC修复也是不可以的，需要拆解数据库来抢救重要的数据，下面是较为常见的一种SQLServer201*数据库修复方式：
1）先及时把原来的数据库文件（如test.mdf)备份到其他地方2）停掉服务器3）删除这个test.mdf
4)重新建立一个test同名数据库
5）删除这个新建立的test数据库的test.ldf文件，并用开始备份好的test.mdf文件覆盖这个新建立的test.mdf文件
6）启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。.设置数据库允许直接操作系统表。此操作可以在SQLServerEnterpriseManager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”7）设置test为紧急修复模式
updatesysdatabasessetstatus=-32768wheredbid=DB_ID("test")
此时可以在SQLServerEnterpriseManager里面看到该数据库处于“只读\\置疑\\脱机\\紧急模式”可以看到数据库里面的表，但是仅仅有系统表
8下面执行真正的恢复操作，重建数据库日志文件
dbccrebuild_log("test","C:\\ProgramFiles\\MicrosoftSQLServer\\MSSQL\\Data\\test_log.ldf")
执行过程中，如果遇到下列提示信息：
服务器:消息5030，级别16，状态1，行1未能排它地锁定数据库以执行该操作。
DBCC执行完毕。如果DBCC输出了错误信息，请与系统管理员联系。
说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQLServerEnterpriseManager打开了test库的系统表，那么退出SQLServerEnterpriseManager就可以了。
正确执行完成的提示应该类似于：
警告:数据库"test"的日志已重建。已失去事务的一致性。应运行DBCCCHECKDB以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC执行完毕。如果DBCC输出了错误信息，请与系统管理员联系。
此时打开在SQLServerEnterpriseManager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
9.验证数据库一致性dbcccheckdb("test")10.设置数据库为正常状态
sp_dboption"test","dbouseonly","false"
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。11最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复；
友情提示：本文中关于《SQLserver201*数据库修复办法总结》给出的范例仅供您参考拓展思维使用，SQLserver201*数据库修复办法总结：该篇文章建议您自主创作。
来源：网络整理 免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。
公文素材库友情提示：本网站所有内容为共享上传提供，不涉及任何商业利益，本站对此不承担任何保证责任！
Copyright © www.bsmz.net Corporation, All Rights Reserved 共享时代 共享你我他 版权所有