系统资料库msdb置疑或者不可用的解决方法
2010-01-19 10:10
501 查看
从网上转过来的 http://www.chengzhidan.com.cn/read.php/533.htm
我试用的是第一种方法,问题顺利解决,但在执行这段脚本时,会爆很多的错误,不需理会,执行脚本之后,重新刷新资料库,你会发现问题已经被成功解决了。。
解决方法一:你可以采用以下的代码进行修复:
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1
RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='msdb'
Go
sp_dboption 'msdb', 'single user', 'true'
Go
DBCC CHECKDB('msdb')
Go
update sysdatabases set status =28 where name='msdb'
Go
sp_configure 'allow updates', 0
reconfigure with override
Go
sp_dboption 'msdb', 'single user', 'false'
Go
解决方法二:
MSDB数据库解决过程
难点:由于MSDB数据库不能删除,将其文件拷出来,再次附加数据库,但新的附加数据库不能叫MSDB,也就是不能同名,遇到了困难。
1:先停止整个数据库,将该数据库的文件msdbdata.mdf和msdblog.ldf拷贝粘贴出来到另一个目录下。
2:将以上的文件再拷贝到另一个目录下,也就是说复制两次。
3:选择 数据库右击鼠标 --》所有任务--》附加数据库 将复制出的一个备份文件附加上去,其中,数据库名称叫MSDB1,用户是SA或ADMINISTRATOR。
4:将MSDB1数据库备份,备份成一个文件,当时我的叫MSDB。BAK。
5:选择置疑的数据库MSDB,选择恢复数据库,将刚才备份出来的数据库强行恢复到MSDB。
6:问题解决,MSDB库又能正常使用。
完成后赶快将数据库再次备份一次。呵呵。
另附:数据库置疑解决办法
第一次遇到数据库质疑这样的问题,把我给吓坏了,重要数据啊~~大家知道为什么会发生这种情况么?是不是不正常关机的情况下会发生这种情况?
还有,现在修复好了,但昨天的数据丢失了,以前的数据倒还在。难道昨天发生了什么异常情况?
我这里一篇解决数据库质疑的文档,提供给大家,日后备用:
SQL SERVER数据库置疑后恢复步骤
1. 恢复步骤:
a.将smlog_log.ldf文件备份到其它目录下;
b.将源目录下的smlog_log.ldf文件改名为smlog_log_bak.ldf;
c.执行以下语句修改数据库的状态:
use Master
go
update sysdatabases set status=32768 where name=’数据库名称’ --修改状态
go
shutdown with nowait --停止数据库服务器
go
d.退出SQL并在命令行模式中通过下面的代码重新启动SQL:
sqlservr -c -T3608 -T4022 --安全模式启动SQL SERVER
e.在查询分析器中执行以下语句来查看刚刚修改过状态的数据库状态:
select Name,Status from sysdatabases where Name=’ 数据库名称’
f.执行以下代码新建日志文件:
dbcc traceon(3604) --跟踪
dbcc rebuild_log(‘数据库名称’,’日志文件名称’) --文件名要有全路径和扩展名
g.将数据库置回正常状态:
update sysdatabases set status=0 where name=’数据库名称’
h.重新启动数据库后执行以下语句检查数据库:
DBCC CHECKDB --如果执行完有错误用以下语句修复
i.要修复数据库必需将数据库改为单用户模式:
Exce sp_dboption ‘数据库名称’,’single user’,’true’(‘false’恢复多用户)
j.执行以下语句修复数据库:
DBCC CHECKDB(‘数据库名称’,REPAIR_ALLOW_DATA_LOSS)
REPAIR_ALLOW_DATA_LOSS:是比较高级的修复方式
REPAIR_FAST:是简单快速的修复方式
相似问题:系统重装,忘记了备份SQL,然后又通过数据恢复工具找回了mcdb_data.mdf 和mcdb_Log.LDF,在企业管理器上用附加数据库时提示错误9004,日志错误,在网上找了诸多方法,也试过建个同名空数据库然后停止SQL SERVER然后覆盖掉MDF。但多不行,哪个大哥救救
这是详细步骤.
1.先建一个与你要恢复的数据库名称一样的数据库。
2.停止sql server,把你的数据库替换这个数据库。
3.重启sql server,把数据库设置为紧急状态。
sp_configure 'allow',1
reconfigure with overirde
update sysdatabases set status=32768 where name='yourdata'
4.重建日志文件。
dbcc rebuild_log('yourdata','your data path\newdata_log.ldf')
5.取消紧急模式。
update sysdatabases set status=0 where name='yourdata'
restore sysdatabases yourdata with recovery
sp_configure 'allow',0
reconfigure with override
6.重起sql server
7.ok
我试用的是第一种方法,问题顺利解决,但在执行这段脚本时,会爆很多的错误,不需理会,执行脚本之后,重新刷新资料库,你会发现问题已经被成功解决了。。
解决方法一:你可以采用以下的代码进行修复:
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1
RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='msdb'
Go
sp_dboption 'msdb', 'single user', 'true'
Go
DBCC CHECKDB('msdb')
Go
update sysdatabases set status =28 where name='msdb'
Go
sp_configure 'allow updates', 0
reconfigure with override
Go
sp_dboption 'msdb', 'single user', 'false'
Go
解决方法二:
MSDB数据库解决过程
难点:由于MSDB数据库不能删除,将其文件拷出来,再次附加数据库,但新的附加数据库不能叫MSDB,也就是不能同名,遇到了困难。
1:先停止整个数据库,将该数据库的文件msdbdata.mdf和msdblog.ldf拷贝粘贴出来到另一个目录下。
2:将以上的文件再拷贝到另一个目录下,也就是说复制两次。
3:选择 数据库右击鼠标 --》所有任务--》附加数据库 将复制出的一个备份文件附加上去,其中,数据库名称叫MSDB1,用户是SA或ADMINISTRATOR。
4:将MSDB1数据库备份,备份成一个文件,当时我的叫MSDB。BAK。
5:选择置疑的数据库MSDB,选择恢复数据库,将刚才备份出来的数据库强行恢复到MSDB。
6:问题解决,MSDB库又能正常使用。
完成后赶快将数据库再次备份一次。呵呵。
另附:数据库置疑解决办法
第一次遇到数据库质疑这样的问题,把我给吓坏了,重要数据啊~~大家知道为什么会发生这种情况么?是不是不正常关机的情况下会发生这种情况?
还有,现在修复好了,但昨天的数据丢失了,以前的数据倒还在。难道昨天发生了什么异常情况?
我这里一篇解决数据库质疑的文档,提供给大家,日后备用:
SQL SERVER数据库置疑后恢复步骤
1. 恢复步骤:
a.将smlog_log.ldf文件备份到其它目录下;
b.将源目录下的smlog_log.ldf文件改名为smlog_log_bak.ldf;
c.执行以下语句修改数据库的状态:
use Master
go
update sysdatabases set status=32768 where name=’数据库名称’ --修改状态
go
shutdown with nowait --停止数据库服务器
go
d.退出SQL并在命令行模式中通过下面的代码重新启动SQL:
sqlservr -c -T3608 -T4022 --安全模式启动SQL SERVER
e.在查询分析器中执行以下语句来查看刚刚修改过状态的数据库状态:
select Name,Status from sysdatabases where Name=’ 数据库名称’
f.执行以下代码新建日志文件:
dbcc traceon(3604) --跟踪
dbcc rebuild_log(‘数据库名称’,’日志文件名称’) --文件名要有全路径和扩展名
g.将数据库置回正常状态:
update sysdatabases set status=0 where name=’数据库名称’
h.重新启动数据库后执行以下语句检查数据库:
DBCC CHECKDB --如果执行完有错误用以下语句修复
i.要修复数据库必需将数据库改为单用户模式:
Exce sp_dboption ‘数据库名称’,’single user’,’true’(‘false’恢复多用户)
j.执行以下语句修复数据库:
DBCC CHECKDB(‘数据库名称’,REPAIR_ALLOW_DATA_LOSS)
REPAIR_ALLOW_DATA_LOSS:是比较高级的修复方式
REPAIR_FAST:是简单快速的修复方式
相似问题:系统重装,忘记了备份SQL,然后又通过数据恢复工具找回了mcdb_data.mdf 和mcdb_Log.LDF,在企业管理器上用附加数据库时提示错误9004,日志错误,在网上找了诸多方法,也试过建个同名空数据库然后停止SQL SERVER然后覆盖掉MDF。但多不行,哪个大哥救救
这是详细步骤.
1.先建一个与你要恢复的数据库名称一样的数据库。
2.停止sql server,把你的数据库替换这个数据库。
3.重启sql server,把数据库设置为紧急状态。
sp_configure 'allow',1
reconfigure with overirde
update sysdatabases set status=32768 where name='yourdata'
4.重建日志文件。
dbcc rebuild_log('yourdata','your data path\newdata_log.ldf')
5.取消紧急模式。
update sysdatabases set status=0 where name='yourdata'
restore sysdatabases yourdata with recovery
sp_configure 'allow',0
reconfigure with override
6.重起sql server
7.ok
相关文章推荐
- 加入域提示“设备不识别此命令 或者提示:指定的网络名不可用”解决方法
- MSDB数据库置疑状态的解决方法
- Win10系统“获取会员版本”选项不可用怎么办?“获取会员版本”选项不可用的解决方法
- Ubuntu系统下Sudo命令不可用的解决方法
- windows系统下VS2013或者VS2017的C4996错误解决方法
- 丢失Android系统库或者Conversion to Dalvik format failed with error 1错误的解决方法
- 重装系统时出现<windows root>\system32\ntoskrnl.exe 损坏或者丢失?解决方法。。。。。。
- android 调用系统相机或者系统相册功能时,onActivityResult方法不执行问题的解决过程
- XP系统下IIS服务器程序不可用解决方法
- 给Easyui-Datebox设置隐藏或者不可用的解决方法
- 宿主机( win 7 系统) ping 虚拟机VMware( cent os 6.6 ) 出现“请求超时”或者“无法访问目标主机”的解决方法
- Win10系统电脑发不了短信提示"无可用手机"的解决方法
- Ubuntu16.04系统下 解决“无法获得锁 /var/lib/dpkg/lock -open (11:资源暂时不可用)、无法锁定管理目录(/var/lib/dpkg/),是否有其他进程正占用它?”的方法
- 硬盘、U盘起死回生的方法:文件系统显示为RAW文件系统,总共字节为0,可用字节为0且无法读取 的解决办法
- 我的系统用户账户出现红叉(中毒或者中木马)的3种解决方法
- 宿主机( win 7 系统) ping 虚拟机VMware( cent os 6.6 ) 出现“请求超时”或者“无法访问目标主机”的解决方法
- Exchange2003 “跟踪的数据库不可用,或者邮件已经离开Exchange组织”解决方法
- 无法运行宏,可能是因为该宏在此工作簿中不可用,或者所有的宏都被禁用的解决方法
- 【ubuntu】系统崩溃(系统空间满了,sudo不可用,不能联网等)解决方法
- Jlink_V8灯不亮USB无法识别及克隆版问题解决方法(win7 64位系统下亲测可用)