mssql数据库修复
无法打开数据库'MyDB'。恢复操作已将该数据库标记为 SUSPECT。
原因是断电导致DB文件损坏
通过SQL Server Management Studio链接到故障数据库的服务器
执行下面的操作
复制代码
-- 执行前先把下面数据库的名字MyDB更改为“可疑”的数据库名字
-- 1.修改数据库为紧急模式
ALTER DATABASE MyDB SET EMERGENCY
-- 2.使数据库变为单用户模式
ALTER DATABASE MyDB SET SINGLE_USER
-- 3.修复数据库日志重新生成，此命令检查的分配，结构，逻辑完整性和所有数据库中的对象错误。当您指定“REPAIR_ALLOW_DATA_LOSS”作为DBCC CHECKDB命令参数，该程序将检查和修复报告的错误。但是，这些修复可能会导致一些数据丢失。
-- 这一步执行时间也比较长
DBCC CheckDB (MyDB, REPAIR_ALLOW_DATA_LOSS)
-- 4.使数据库变回为多用户模式
ALTER DATABASE MyDB SET MULTI_USER
⑵ 如何修复sql数据库master
在网上搜索了一下，发现了一篇介绍比较详细的，而且也确实解决了这一问题（我在VM上测试过可以），特将其全文转贴如下：
关于系统数据库的恢复总结如下:
在SQL Server数据库中，系统信息存储在系统数据库中，主要的系统数据库包括：
master-从整体上控制用户数据库和SQL Server操作，在创建了任何用户定义的对象后，都要备份它
model-为新数据库提供模版和原型
msdb-包含了有关作业、报警及操作员等信息
如果包含系统数据库的介质变了，那么必须重建系统数据库，如果你仍然可以启动SQL Server服务，则可以通过RESTORE语句从系统数据库的备份中恢复数据库。
如果master坏了，不能启动系统,可以按照下面步骤进行恢复
1.重建系统数据库 运行c:/mssql7/binn/rebuildm.exe，按照提示进行即可，
过程中需要系统数据库样本的路径，可在安装光盘中找到；
2 重建系统数据库后，启动SQL Server服务，用系统数据库的备份恢复数据库
就行了通常恢复顺序为master->msdb->model
在恢复master的备份时要注意：必须在单用户(single user)模式下进行
a.进入单用户模式的方法：
1.在命令行模式下输入sqlservr -c -f -m或者输入sqlservr -m
其中：-c 可以缩短启动时间，SQL Server 不作为Windows NT的服务启动
-f 用最小配置启动SQL Server
-m 单用户模式启动SQL Server
2.可以在控制面板-服务-MSSQLServer的启动参数中输入-c -f -m或者输入-m,点击开始
3.进行master数据库的恢复
a.直接进入查询分析器,有个提示不要理会它
输入恢复语句进行数据库恢复:
RESTORE DATABASE master from disk='c:/具体的备份文件名'
b.或者用这个,在命令提示符下输入,注意大小写
使用"windows身份验证"的,输入:isql /E
使用"sql server和windows身份验证"的,输入:isql /U"用户名" /P"密码"
然后在出现的提示符下输入(注意1>,2>是提示符):
⑶ 怎样修复已经损坏的SQL数据库
1.停止SQL Server的服务,备份SQL Server安装目录下的\data子目录
下故障数据库的两个文件,一个数据文件hbposv6_branch_data.mdf,
一个hbposv6_branch_log.ldf(也有可能非此命名),同时查看磁盘
空间是否有足够的空间；
2.启动SQL Server服务(如已停止),创建一个新的数据库，命名为
原来数据库的名字。
3.停止SQL Server
4.把老数据库的MDF文件(hbposv6_branch_data.mdf)替换
新数据库的相应的MDF文件，
并把LDF文件(hbposv6_branch_log.ldg)删除。
5.重新启动SQL Server服务，然后运行如下命令：
Use Master
go
sp_configure 'allow updates', 1
reconfigure with override
go
begin tran
update sysdatabases set status = 32768 where name = 'hbposv6_branch'
--Verify one row is updated before committing
commit tran
go
6.停止SQL然后重新启动SQL Server服务，然后运行如下命令
(更换日志文件路径地址)：
use master
go
DBCC TRACEON(3604)
DBCC REBUILD_LOG
('hbposv6_branch',
'c:\Program Files\Microsoft SQL Server\MSSQL\Data\hbposv6_branch_log.ldf')
--在这里，请输入你的数据库的路径
go
7.停止SQL然后重新启动SQL Server服务，然后运行：
use master
go
update sysdatabases set status = 8 where name = 'hbposv6_branch'
go
sp_configure 'allow updates', 0
reconfigure with override
go
8.运行dbcc checkdb(db_name) 检查数据库的完整性
9.修复数库
--请在查询分析器中执行下列语句.执行前断开其它
所有数据库连接，最好是断开网线
--如果不是该数据库名，请将数据库
--hbposv6_branch
--改为要修复的数据库
USE master
Go
--单用户模式
EXEC sp_dboption 'hbposv6_branch', 'single user', 'TRUE'
go
--数据库检查
DBCC CHECKDB ('hbposv6_branch')
Go
--如果返回结果出现了红色的提示文字，说明数据库中存在错误，需要修复
--数据库修复
DBCC CHECKDB ('hbposv6_branch','repair_rebuild')
Go
--再次数据库检查，如果返回结果中没有了红色的提示文字，
说明修复成功；
DBCC CHECKDB ('hbposv6_branch')
Go
--否则意味着还需要更高级别的修复；尝试将上面修复语句的
'repair_rebuild'换为'repair_allow_data_loss'再试，
之后再次检查数据库。
--如果还有错误未修复，请把这些信息以文字的方式发给我们
--退出前请一定要执行以下语句返回到多用户模式
EXEC sp_dboption 'hbposv6_branch', 'single user','FALSE'
go
注：都要把 dbname 替换成真实的数据库名字。
⑷ sql数据库置疑，错误代码926，请问要如何修复
请输入你的答案...
数据库926错误解决方案在做任何操作前首先备份数据库的数据文件和日志文件！以及最新的备份文件！第一种解决方法：先删除报错数据库，再新建一同名数据库，然后暂停Service
manager（及sql
server
服务）
，删除库文件和日志文件再启动Service
manager
，使用单数据文件恢复数据库命令恢复数据库。例：打开sql
server/tools/sql
server
query
analyzer
执行下面操作
EXEC
sp_attach_single_file_db
@dbname
=
'pubs',
@physname
=
'c:\mssql7\data\pubs.mdf'
说明：‘pubs’为要恢复的数据库名称，‘c:\mssql7\data\pubs.mdf’为要恢复的数据库的库文件的具体路径和文件名称。再重新启动一下service
manager
，看能否正常打开处理后的数据库；如果不可以再使用第二种方案。第二种解决方法：打开sql
server/tools/sql
server
query
analyzer
执行下面操作
USE
MASTER
GO
sp_configure
'allow
update',1
RECONFIGURE
WITH
OVERRIDE
GO
UPDATE
sysdatabases
set
status
=
32768
WHERE
name
=
'db_pos363'
GO
sp_configure
'allow
update',0
RECONFIGURE
WITH
OVERRIDE
GO
说明：'db_pos363'是要修复的数据库名称。执行完毕再重启一下Service
manager打开数据库看是否处于紧急状态！再从另一装有sql
2000的机器上连接报错的数据库，然后再在sql
2000的机器上新建一数据库，再使用sql
2000自带的数据库导入导出功能（在新建的数据库上单击右键/所有任务/数据导入、数据导出）从报错数据库导入数据到新建的数据库中！在导入选项中注意以下几项：
1，
导入方式选择分‘从源数据库复制表和视图’以及‘从sql
server数据库间复制对象和数据’。当选择从源数据库复制表和视图时一定要选择全部表！
2，
当选择‘从sql
server数据库间复制对象和数据’时，在‘导入导出向导’对话框中去除‘使用默认选项’的选中标志；再在打开‘选项’对话框，去除以下三项的选中标志。A,复制数据用户和数据库角色；B，复制sql
server
登陆；C，复制对象及权限。
3，
在使用‘从sql
server数据库间复制对象和数据’时，有时会出现单张表导入失败，这时有时会在导入结束时提示那几张表导入失败有时不提示，如果提示，就再使用‘从源数据库复制表和视图’并选中导入失败的表重新导入一遍；如果不提示就只能在一张张表打开查看了，发现空表后再使用‘从源数据库复制表和视图’导入需要导入的表！导入成功后再删除sql
server
7.0机器上处于紧急状态的数据库，再新建一个同名数据库，建好后再使用sql
2000的数据库导出功能导出到此数据库中，在导出过程中同样要注意导入时的注意事项！
⑸ 怎样恢复损坏的SQL Server数据文件
1、确保备份下的master数据库与要恢复的SQL SERVER的版本一致性。
⑹ sql2005删除数据库怎么恢复
sql2005数据库修复方法如下：
1、停止数据库服务。
2、将需要恢复的数据库文件复制到另外的位置。
3、启动数据库服务。
4、确认要恢复的数据库文件已经成功复制到另外的位置，然后在sql
server
management
studio中删除要恢复的数据库。
5、新建同名的数据库(数据库文件名也要相同)。
6、停止数据库服务。
7、用第2步中备份的.mdf文件覆盖新数据库的同名文件。
8、启动数据库服务。
9、运行alter
database
dbname
set
emergency，将数据库设置为emergency
mode
10、运行下面的命令就可以恢复数据库：titleuse
masterdeclare
@databasename
varchar(255)
set
@databasename='要恢复的数据库名称'
⑺ SQL数据库文件损坏，怎么修复
如果只是BLACK.LST丢失或损坏应该可以进行更新来修复,因为更新的时候一部分就是在更新此文件...如果无法更新,无须完全卸载,直接重新装下,覆盖下即可
⑻ 如何修复 SQL 数据库置疑
修复sql2000数据库置疑
在实际的操作中由于突然断电或者突然断网造成数据库置疑（在企业管理器中数据库后面出现置疑两个字），下面我们通过以下方法来进行修复置疑的数据库。
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 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
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
⑼ SQL 2000 数据库备份文件损坏如何修复
如果你的备份文件损坏了，那就不能恢复这个备份了，如果是你的数据库文件.MDF损坏了，那你可以把原来的数据库分离了，把数据库文件先考到别的目录下，然后在企业管理器里新建立个数据库和原来的名字一样的，文件位置也放到原来的位置，建立完这个数据库以后再恢复数据库，在选项里，把强制还原数据库选上，然后确认恢复，应该就可以了
⑽ SQL数据库置疑数据怎么恢复
备份数据文件,然后按下面的步骤处理:
1.新建一个同名的数据库(数据文件与原来的要一致)
2.再停掉sql server(注意不要分离数据库)
3.用原数据库的数据文件覆盖掉这个新建的数据库
4.再重启sql server
5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)
6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用
数据库的脚本创建一个新的数据库,并将数据导进去就行了.
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'
Go
sp_dboption '置疑的数据库名', 'single user', 'true'
Go
DBCC CHECKDB('置疑的数据库名')
Go
update sysdatabases set status =28 where name='置疑的数据库名'
Go
sp_configure 'allow updates', 0 reconfigure with override
Go
sp_dboption '置疑的数据库名', 'single user', 'false
假设数据库为TEST：
按以下步骤执行
A．设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
B．设置test为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表
C．下面执行真正的恢复操作，重建数据库日志文件
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 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
D．验证数据库一致性（可省略）
dbcc checkdb('test')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
E．设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。
F．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
上面的语句操作步骤有点问题：
应该如下：
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 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
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