|
马上注册,结交更多好友,享用更多功能^_^
您需要 登录 才可以下载或查看,没有账号?立即注册
x
任何数据库系统都无法避免崩溃的状况,即使你使用了Clustered,双机热备……仍然无法完全根除系统中的单点故障,何况对于大部分用户来说,无法承受这样昂贵的硬件投资。所以,在系统崩溃的时候,如何恢复原有的宝贵数据就成为一个极其重要的问题了。
通过我们多年的主机管理经验,总结了几种方法紧急恢复您的数据库,以下方法使用与万网的独立服务器用户,请参考:
1、 最理想的情况就是您的数据文件(*.mdf)和日志文件(*.ldf)都完好无损,这样只需要sp_attach_db,把数据文件附加到新的数据库上即可,或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行,不过一般不推荐这样的做法,sp_attach_db比较好,虽然比较繁琐,容易出错;
2、一般数据库崩溃的时候系统是未必能有时间把未完成的事务和脏(坏)页等写入磁盘的,这样的情况sp_attach_db(上述方法)就会失败,这种情况就产生了第二中方法,制定了一个良好的备份计划任务。按照你的计划生成备份文件,还原最新的完全备份,增量备份或者事务日志备份,然后如果你的活动事务日志还能读得出来的话,你可以还原到崩溃前的状态;这种方法的备份脚本及操作方法如下:打开企业管理器--管理--sql代理--作业,使用以下脚本建立一个计划:
declare @filename nvarchar(100) set @filename='F:\www\flooddatabasebak\stopq'+convert(char(10),getdate(),112) print @filename BACKUP DATABASE [db_name] TO DISK = @filename WITH NOINIT , NOUNLOAD , NAME = N' 备份', NOSKIP , STATS = 10, NOFORMAT;
3、如果上述两种情况你都没有,我们可以试着重新建立一个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>'
这种情况成功的机会还是相当大的,系统一般都会认可你新建立的日志。可以数据恢复了,但是这种操作正在进行的事务肯定是丢失了,原来的数据也可能受到一些损坏。
先把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可以有效完成。
就可以继续使用你的数据库了,这时候你最好是根据第二种方法做好备份。
|
|