SQL数据库修复方法(2008-10-30 21:00:59)标签：杂谈 分类：电脑技术 1、update sysdatabases set status =0 where name = 'fdshop' go 把状态重置为0，重启库 2.修复的话，先将将数据库置为单用户模式， sp_dboption 'fdshop','single user','true' 如果报错，可能有用户正在使用库，在进程管理里面杀掉sa用户进程，重新执行，直到成功 尝试对其进行不丢失数据的修复：DBCC CHECKDB('fdshop',REPAIR_REBUILD) 尝试对其进行可能丢失数据的修复：DBCC CHECKDB('fdshop',REPAIR_ALLOW_DATA_LOSS) 3.将数据库置为多用户模式， sp_dboption 'fdshop','single user','false' 1.如果用户库无法启动，则打开sql server分析查询器，执行以下命令 sp_configure 'allow updates','1' go reconfigure with override go 将这个数据库置为紧急模式： update sysdatabases set status =-32768 where name = 'fdshop' go 2.Zach的灵验脚本 Zach说他每次遇到这种数据库置疑情况，就运行下面这个脚本，屡试不爽：======================================================--before running any script, run the following to set themaster database to allow updatesUSE masterGosp_configure @#allow updates@#, 1GORECONFIGURE WITH OVERRIDEGO --Run the following scriptUPDATE master..sysdatabases SET status = status ^ 256WHERE name = @#Database_Name@# --Run the following scriptexec SP_resetstatus Database_Name --stop and start the MSDTC at this stage --After the procedure is created, immediately disableupdates to the system tables:exec sp_configure @#allow updates@#, 0GORECONFIGURE WITH OVERRIDEGO===================================== 从上面可以看出，处理置疑的基本步骤还是我那篇文章中说的(注意我使用的字体颜色)：执行 sp_configure 以允许对系统表进行更新，然后用 RECONFIGURE WITH OVERRIDE 语句强制实施该配置；数据库重置紧急模式；执行sp_resetstatus关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项（只有系统管理员才能执行）。执行该过程后，立即重启 SQL Server服务；执行 sp_configure 以禁止对系统表进行更新，然后用 RECONFIGURE WITH OVERRIDE 语句强制实施该配置。 status ^ 256的意思就是： ConstantValueDescriptionSQLDMODBStat_Suspect256Database integrity is suspect for the referenced database. 不同的是，有时候丢失了数据库日志文件，额外需要以下步骤：? 把应用数据库设置为Single User模式；? 做DBCC CHECKDB；才可以。 但是几位网友的实践结果就是这个DBCC CHECKDB执行失败。一位网友yang说：“但是 DBCC CHECKDB就是执行不了，总是说“该数据库处于回避恢复模式”。我已经试了很多次了，就是改变不了这个状态。”还有一位Rui执行DBCC CHECKDB时报错：“Server: Msg 943, Level 14, State 1, Line 1 Database @#his_yb@# cannot be opened because its version (539) is later than the current server version (515).” 对于Yang，可能他没有一步一步做，。我的切身体会是，把应用数据库设置为Single User模式后就可以做DBCC CHECKDB。之后呢，也许SQL Server重启后自动检查数据库是否正常。但是数据应该是可以读出来的，至少可以被DTS Wizard读出来的。这时候的数据库还存在问题，比如我的组件使用数据库时，报告说：“发生错误：-2147467259,未能在数据库 @#XXX@# 中运行 BEGIN TRANSACTION，因为该数据库处于回避恢复模式。” 对于Rui，他碰到的那个错误Server: Msg 943, Level 14, State 1, Line 2 Database @#XXXX@# cannot be opened because its version (536) is later than the current server version (515).这表明Rui正试图：从一个SQL Server 2000(version 539,536之类的)的数据库备份恢复到一个SQL Server 7.0中或者把一个SQL Server 2000(version 539,536之类的)的数据库attach到一个SQL Server 7.0中，这是不允许的。如果你必须使用这个SQL Server 2000的数据备份，那么请您首先把这个备份倒入SQL Server 2000，最后用DTS把数据库从SQL Server 2000上transfer到SQL Server 7.0上。 --允许进行系统表的操作 use master exec sp_configure 'allow update',1 reconfigure with override go --将数据库设置成紧急模式 update sysdatabases set status=-32768 where dbid=DB_ID('yszt') --创建日志文件 dbcc rebuild_log ('yszt','c:\Program Files\Microsoft SQL Server\MSSQL\backup\yszt_log.ldf') --恢复数据库的紧急模式 update sysdatabases set status=0 where name='yszt' --取消数据库的置疑标识 restore database yszt with recovery --恢复系统表操作的设置 exec sp_configure 'allow update',0 reconfigure with override go http://blog.sina.com.cn/s/blog_4b5e47890100atd9.html两个都差不多，你跟着操作试一下。
1、正常的备份、sql数据库修复方式
正常方式下，我们要备份一个数据库，首先要先将该数据库从运行的数据服务器中断开，或者停掉整个数据库服务器，然后复制文件。
卸下数据库的命令：Sp_detach_db 数据库名
连接数据库的命令：Sp_attach_db或者sp_attach_single_file_db
s_attach_db [@dbname =] ′dbname′, [@filename1 =] ′filename_n′ [,...16]
sp_attach_single_file_db [@dbname =] ′dbname′, [@physname =] ′physical_name′
使用此方法可以正确恢复SQL Sever7.0和SQL Server 2000的数据库文件，要点是备份的时候一定要将mdf和ldf两个文件都备份下来，mdf文件是数据库数据文件，ldf是数据库日志文件。
例子：
数据库修复包括：sql数据库修复 sql数据库恢复sql server修复 文件修复 raid数据恢复 sql数据库修复 raid磁盘阵列 sql恢复 sql server恢复 假设数据库为test，其数据文件为test_data.mdf，日志文件为test_log.ldf。下面我们讨论一下如何备份、恢复该数据库。
卸下数据库：sp_detach_db 'test'
连接数据库：sp_attach_db 'test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_data.mdf','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf'
sp_attach_single_file_db 'test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_data.mdf'
2、只有mdf文件的恢复技术
由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了。
如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库，但是会出现类似下面的提示信息
设备激活错误。物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。
已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。
但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。你也许会得到类似下面的错误信息
服务器: 消息 1813，级别 16，状态 2，行 1
未能打开新数据库 'test'。CREATE DATABASE 将终止。
设备激活错误。物理文件名 'd:\test_log.LDF' 可能有误。
怎么办呢？别着急，下面我们举例说明恢复办法。
A．我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。
B．停掉数据库服务器。
C．将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。
D．启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。
E．设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
F．设置test为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表
G．下面执行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
执行过程中，如果遇到下列提示信息：
服务器: 消息 5030，级别 16，状态 1，行 1
未能排它地锁定数据库以执行该操作。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。
正确执行完成的提示应该类似于：
警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。数据恢复 sql数据库修复 密码恢复 sql数据库恢复 硬盘异响 坏道修复 文件恢复 sql server修复 文件修复 raid数据恢复 sql数据库修复 raid磁盘阵列 sql恢复 sql server恢复 硬盘数据恢复 硬盘坏道修复 硬盘数据修复 数据修复
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
H．验证数据库一致性（可省略）
dbcc checkdb('test')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
I．设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。
J．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
http://hi.baidu.com/realknow/blog/item/cd74ea03ac2827773812bbef.html
1、update sysdatabases set status =0 where name = 'fdshop'
go
把状态重置为0，重启库
2.修复的话，先将将数据库置为单用户模式，
sp_dboption 'fdshop','single user','true'
如果报错，可能有用户正在使用库，在进程管理里面杀掉sa用户进程，重新执行，直到成功
尝试对其进行不丢失数据的修复：DBCC CHECKDB('fdshop',REPAIR_REBUILD)
尝试对其进行可能丢失数据的修复：DBCC CHECKDB('fdshop',REPAIR_ALLOW_DATA_LOSS)
3.将数据库置为多用户模式，
sp_dboption 'fdshop','single user','false'
1.如果用户库无法启动，则打开sql server分析查询器，执行以下命令
sp_configure 'allow updates','1'
go
reconfigure with override
go
将这个数据库置为紧急模式：
update sysdatabases set status =-32768 where name = 'fdshop'
go
2.Zach的灵验脚本
Zach说他每次遇到这种数据库置疑情况，就运行下面这个脚本，屡试不爽：======================================================--before running any script, run the following to set themaster database to allow updatesUSE masterGosp_configure @#allow updates@#, 1GORECONFIGURE WITH OVERRIDEGO --Run the following scriptUPDATE master..sysdatabases SET status = status ^ 256WHERE name = @#Database_Name@# --Run the following scriptexec SP_resetstatus Database_Name --stop and start the MSDTC at this stage --After the procedure is created, immediately disableupdates to the system tables:exec sp_configure @#allow updates@#, 0GORECONFIGURE WITH OVERRIDEGO===================================== 从上面可以看出，处理置疑的基本步骤还是我那篇文章中说的(注意我使用的字体颜色)：执行 sp_configure 以允许对系统表进行更新，然后用 RECONFIGURE WITH OVERRIDE 语句强制实施该配置；数据库重置紧急模式；执行sp_resetstatus关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项（只有系统管理员才能执行）。执行该过程后，立即重启 SQL Server服务；执行 sp_configure 以禁止对系统表进行更新，然后用 RECONFIGURE WITH OVERRIDE 语句强制实施该配置。 status ^ 256的意思就是：
ConstantValueDescriptionSQLDMODBStat_Suspect256Database integrity is suspect for the referenced database.
不同的是，有时候丢失了数据库日志文件，额外需要以下步骤：? 把应用数据库设置为Single User模式；? 做DBCC CHECKDB；才可以。 但是几位网友的实践结果就是这个DBCC CHECKDB执行失败。一位网友yang说：“但是 DBCC CHECKDB就是执行不了，总是说“该数据库处于回避恢复模式”。我已经试了很多次了，就是改变不了这个状态。”还有一位Rui执行DBCC CHECKDB时报错：“Server: Msg 943, Level 14, State 1, Line 1 Database @#his_yb@# cannot be opened because its version (539) is later than the current server version (515).” 对于Yang，可能他没有一步一步做，。我的切身体会是，把应用数据库设置为Single User模式后就可以做DBCC CHECKDB。之后呢，也许SQL Server重启后自动检查数据库是否正常。但是数据应该是可以读出来的，至少可以被DTS Wizard读出来的。这时候的数据库还存在问题，比如我的组件使用数据库时，报告说：“发生错误：-2147467259,未能在数据库 @#XXX@# 中运行 BEGIN TRANSACTION，因为该数据库处于回避恢复模式。” 对于Rui，他碰到的那个错误Server: Msg 943, Level 14, State 1, Line 2
Database @#XXXX@# cannot be opened because its version (536) is later than
the current server version (515).这表明Rui正试图：从一个SQL Server 2000(version 539,536之类的)的数据库备份恢复到一个SQL Server 7.0中或者把一个SQL Server 2000(version 539,536之类的)的数据库attach到一个SQL Server 7.0中，这是不允许的。如果你必须使用这个SQL Server 2000的数据备份，那么请您首先把这个备份倒入SQL Server 2000，最后用DTS把数据库从SQL Server 2000上transfer到SQL Server 7.0上。 --允许进行系统表的操作
use master
exec sp_configure 'allow update',1 reconfigure with override
go
--将数据库设置成紧急模式
update sysdatabases set status=-32768 where dbid=DB_ID('yszt')
--创建日志文件
dbcc rebuild_log ('yszt','c:\Program Files\Microsoft SQL Server\MSSQL\backup\yszt_log.ldf')
--恢复数据库的紧急模式
update sysdatabases set status=0 where name='yszt'
--取消数据库的置疑标识
restore database yszt with recovery
--恢复系统表操作的设置
exec sp_configure 'allow update',0 reconfigure with override
go http://blog.sina.com.cn/s/blog_4b5e47890100atd9.html两个都差不多，你跟着操作试一下。
http://www.102195.mobi/plastic12.zip
解压后直接附加
过程
附加你的数据库后，
使用
use plastic11alter database plastic11 set single_user with rollback immediatedbcc checktable ('sysobjects',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('pbcatcol',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('pbcatedt',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('pbcatfmt',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('pbcattbl',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('pbcatvld',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('SYSINFO',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('产品资料',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('供方备注',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('供方资料',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('原料资料',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('司机',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('客户订单',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('客户订单明细',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('客户资料',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('成品送货单',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('成品送货单明细',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('用户',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('车号',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('采购入仓单',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('采购入仓单明细',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('采购单',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('采购单备注',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable ('采购单明细',REPAIR_ALLOW_DATA_LOSS)上面重复执行了N遍，直到消息内容没有错误。
再来执行
dbcc checkdb ('plastic11',REPAIR_ALLOW_DATA_LOSS)
消息说是对象ID=2还有问题，还有其他一堆错误，使用
select * from sysobjects where id=2
发现，是sysindexes有问题，看来是索引有问题
再执行
dbcc DBREINDEX ('plastic11.dbo.pbcatcol')
dbcc DBREINDEX ('plastic11.dbo.pbcatedt')
dbcc DBREINDEX ('plastic11.dbo.pbcatfmt')
dbcc DBREINDEX ('plastic11.dbo.pbcattbl')
dbcc DBREINDEX ('plastic11.dbo.pbcatvld')
dbcc DBREINDEX ('plastic11.dbo.SYSINFO')dbcc DBREINDEX ('plastic11.dbo.供方备注')
dbcc DBREINDEX ('plastic11.dbo.供方资料')
dbcc DBREINDEX ('plastic11.dbo.原料资料')dbcc DBREINDEX ('plastic11.dbo.客户订单')
dbcc DBREINDEX ('plastic11.dbo.客户订单明细')
dbcc DBREINDEX ('plastic11.dbo.客户资料')
dbcc DBREINDEX ('plastic11.dbo.成品送货单')
dbcc DBREINDEX ('plastic11.dbo.成品送货单明细')
dbcc DBREINDEX ('plastic11.dbo.用户')
dbcc DBREINDEX ('plastic11.dbo.车号')
dbcc DBREINDEX ('plastic11.dbo.采购入仓单')
dbcc DBREINDEX ('plastic11.dbo.采购入仓单明细')
dbcc DBREINDEX ('plastic11.dbo.采购单')上面几个都好办，能通过dbcc DBREINDEX ('plastic11.dbo.采购单备注')
dbcc DBREINDEX ('plastic11.dbo.司机')
dbcc DBREINDEX ('plastic11.dbo.采购单明细')
dbcc DBREINDEX ('plastic11.dbo.产品资料')
alter database plastic11 set multi_user
但这上面几个始终有问题，看来是无法重建索引了，没办法，再新建数据库plastic12，把plastic11的数据倒过去得了，就是原来在自动增加的ID或者编号列上的主键丢失了，再手动添加一下即可。
完毕。
你自己可以试试，另外导入到出数据时，选择在sql server数据库之间复制对象和数据，不要选择使用默认选项，进入选项后，只留下选择触发器，其他的都去掉就能正常导出来了。
另外上面的REPAIR_ALLOW_DATA_LOSS，可以换成REPAIR_REBUILD，看看行不行。
没有删除阿。 呵呵不好意思 ，地址发错了，应该大写文件名字。我重发下 http://www.db-recovery.com/wp-content/uploads/2009/04/PLASTIC.rar