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’
Go
如果你的文件确保没有损坏可以试一下以下方法:可以试着重新建立一个log,先把数据库设置为emergency mode,sysdatabases的status为32768 就表示数据库处于此状态。
不过系统表是不能随便改的,设置一下先
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
然后
update sysdatabases set status = 32768 where name = '<db_name>'
现在,祈求满天神佛的保佑吧,重新建立一个log文件。成功的机会还是相当大的,系统一般都会认可你新建立的日志。如果没有报告什么错误,现在就可以松一口气了。
虽然数据是恢复了,可是别以为事情就算完成了,正在进行的事务肯定是丢失了,原来的数据也可能受到一些损坏。
先把SQL Server 重新启动一下,然后检查你的数据库吧。
先设置成单用户模式,然后做dbcc
sp_dboption '<db_name>', 'single user', 'true'
DBCC CHECKDB('<db_name>')
如果没有什么大问题就可以把数据库状态改回去了,记得别忘了把系统表的修改选项关掉。
update sysdatabases set status = 28 where name = '<db_name>' --当然你的数据库状态可能不是这个,自己改为合适的值吧。也可以用sp_resetstatus
go
sp_configure 'allow updates', 0
reconfigure with override
Go
checkdb的时候可能报告有一些错误,这些错误的数据你可能就只好丢弃了。
checkdb有几种修复选项,自己看着用吧,不过最后你可能还是得用REPAIR_ALLOW_DATA_LOSS,完成所有修复。
chekcdb并不能完成所有的修复,我们需要更进一步的修复,用DBCC CHECKTABLE对每一个表做检查吧。
表的列表可以用sysobjects里面得到,把OBJECTPROPERTY是IsTable的全部找出来检查一下吧,这样能够基本上解决问题了,如果还报告错误,试着把数据select into到另一张表检查一下。
这些都做完了之后,把所有索引、视图、存储过程、触发器等重新建立一下。DBCC DBREINDEX也许可以帮你一些忙。
附加数据库的必要条件:· 附加数据库时,所有数据文件(MDF 文件和 LDF 文件)都必须可用。
· 在附加数据库时,如果 MDF 和 LDF 文件位于不同目录,该 *** 作将失败。
我们可以使用SQL Server Management Studio附加数据库:
1. 在 SQL Server Management Studio 对象资源管理器中,连接到 SQL Server 数据库引擎的实例,然后展开该实例。
2. 右键单击“数据库”,然后单击“附加”。
3. 在“附加数据库”对话框中,指定要附加的数据库,单击“添加”,然后在“定位数据库文件”对话框中选择数据库所在的磁盘驱动器并展开目录树,以查找并选择数据库的 .mdf 文件。因为数据库日志已经丢失,点击.ldf文件,并点击“移除”。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)