SQL数据库紧急修复.doc

SQL数据库紧急修复一.如果sql服务器因为异常断电或者磁盘空间不足很容易引起数据库出现置疑的问题.如下图.(图片网上搜的)出现这样的问题,其实不用慌张,利用sql自带的数据修复功能就能修复好,一般情况下只要不是因为磁盘坏道引起的置疑问题都是可以修复的.二.首先关闭所有的sql用户连接 该步骤应该都会吧.不会的话,我告诉你,有3个办法. 1. 拔掉此机器的网线. 呵呵, 这种方法立竿见影, 但是可能对其他的连接造成影响.2. 通知连接至此数据库的用户断开连接. 如果可能连接的用户很多或不知道哪个用户正在连接的话就不可行了.3. 在SQL Server中用命令StopLogin强行断开连接.详细说明如下:使用说明: StopLogin UFMeta_006该操作为强行断开连接的数据库ummeta_006, 如果您要断开所有数据库的连接进行维护的话则只要执行StopLogin 即可.三,停止sql服务,将置疑的数据库日志文件删掉就是那个ldf文件,然后将数据库文件剪切到其他地方去,然后启动sql服务,新建一个和置疑数据库名字一模一样的数据库.然后再次停止sql服务,将刚才置疑的数据库文件复制回去替换掉新建的.然后再次启动sql服务.四,这样启动sql服务之后在企业管理器里面看到该数据库还是置疑.但是因为ldf文件已经重建,我们可以开始对它进行修复了.首先设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。 use master go sp_configure allow updates,1 go reconfigure with override go 然后设置UFMeta_006紧急修复模式 update sysdatabases set status=-32768 where dbid=DB_ID(UFMeta_006) 此时可以在SQL Server Enterprise Manager里面看到该数据库为“紧急模式”。然后执行真正的恢复操作，重建数据库日志文件 dbcc rebuild_log( UFMeta_006,C:Program FilesMicrosoft SQL ServerMSSQLData UFMeta_006_log.ldf) “该路径视你当初新建的数据库而定”执行到该步骤之后如果发现数据库已经可以使用了,那么恭喜你,你的数据库问题不严重,以下的步骤都可以省略了.但是还是不能使用的话,请接着往下看.五,验证数据库的一致性dbcc checkdb(UFMeta_006)如果出现错误一大堆也不要慌张,手动打开几张表,如果大部分数据都还在的话,这个数据库还是可以修复的.首先use master declare databasename varchar(255) set databasename= UFMeta_006 exec sp_dboption databasename, Nsingle, Ntrue -将目标数据库置为单用户状态 dbcc checkdb(databasename,REPAIR_ALLOW_DATA_LOSS) dbcc checkdb(databasename,REPAIR_REBUILD) exec sp_dboption databasename, Nsingle, Nfalse-将目标数据库置为多用户状态 然后再次dbcc checkdb(UFMeta_006)如果还是有错误的话,就要先看看具体出现错误的是哪几张表了,然后接着使用use 需要修复的数据库实体的名称 declare dbname varchar(255) set dbname= UFMeta_006 exec sp_dboption dbname,single user,true dbcc checktable(需要修复的数据表的名称,REPAIR_ALLOW_DATA_LOSS) dbcc checktable(需要修复的数据表的名称,REPAIR_REBUILD) 把需要修复的数据表的名称更改为执行DBCC CHECKDB时报错的数据表的名称 exec sp_dboption dbna