SQL数据库紧急修复.docVIP

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 Files\Microsoft SQL Server\MSSQL\Data\ 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 @dbname,single user,false 这样应该就可以修复该数据库了,但是修复之后也可能会出现部分数据丢失,这也是没办法的事,总比不能使用好得多了,所以还是建议各位同仁做好数据库实时备份. .