任何数据库系统都无法避免崩溃的状况,即使你使用了Clustered,双机热备……仍然无法完全根除系统中的单点故障,何况对于大部分用户来说,无法承受这样昂贵的硬件投资。所以,在系统崩溃的时候,如何恢复原有的宝贵数据就成为一个极其重要的问题了。
在恢复的时候,最理想的情况就是你的数据文件和日志文件都完好无损了,这样只需要sp_attach_db,把数据文件附加到新的数据库上即可,或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行,不过一般不推荐这样的做法,sp_attach_db比较好,虽然麻烦许多。
但是呢,一般数据库崩溃的时候系统是未必能有时间把未完成的事务和脏页等写入磁盘的,这样的情况sp_attach_db就会失败。那么,寄期望于DBA制定了一个良好的灾难恢复计划吧。按照你的恢复计划,还原最新的完全备份,增量备份或者事务日志备份,然后如果你的活动事务日志还能读得出来的话,这样的话你可以还原到崩溃前的状态。
一般的单位都是没有专职的DBA的,如果没有可用的备份,更可能是最近一次备份的时间过于久远而导致不可接受的数据损失,而且你的活动事务日志也处于不可用的状态,那就是最麻烦的情况了。
不幸的是,一般数据库崩溃都是由于存储子系统引起的,而这样的情况是几乎不可能有可用的日志用于恢复的。
首先,你可以试一下sp_attach_single_file_db,试着恢复一下你的数据文件,虽然能恢复的可能性不大,不过假如这个数据库刚好执行了一个checkpoint的话,还是有可能成功的。
我们可以试着重新建立一个Log,先把数据库设置为emergency mode,sysdatabases的status为32768 就表示数据库处于此状态。
不过系统表是不能随便改的,设置一下先Use MasterGosp_configure 'allow updates', 1reconfigure with overrideGo然后 update sysdatabases set status = 32768 where name = '' 现在,祈求满天神佛的保佑吧,重新建立一个log文件。成功的机会还是相当大的,系统一般都会认可你新建立的日志。如果没有报告什么错误,现在就可以松一口气了。
虽然数据是恢复了,可是别以为事情就算完成了,正在进行的事务肯定是丢失了,原来的数据也可能受到一些损坏:
先把SQL Server 重新启动一下,然后检查你的数据库吧;
先设置成单用户模式,然后做dbcc sp_dboption '', 'single user', 'true'DBCC CHECKDB('');
转载保留:http://www.qqread.com/sqlserver/2007/10/f348851.html相关专题
- SQL Server 数据处理专题 (1859篇文章)
- SQL Server 索引和查询专题 (3328篇文章)
- SQL Server (1816篇文章)
- 数据库专栏 (5169篇文章)
- 数据库处理专题 (8708篇文章)
- 城域网专题 (7840篇文章)
- 数据库安全技术专题 (13188篇文章)
- 数据库安装与卸载 (10561篇文章)
- Linux数据库宝典 (13195篇文章)
- 备份和恢复 (68篇文章)
- 讲解SQL Server数据库触发器的安全隐患 (0次浏览)
- SQL Server 2000和JDBC的融合实例 (0次浏览)
- 用SQL Server 2005实现WebService (0次浏览)
- 用NetBeans5.0连接SQL Server2005数据库 (0次浏览)
- 使用NetBeans5.0连接SQL Server 2005数据库 (0次浏览)
- 如何使用SQL Server 2000中的XML功能一 (0次浏览)
- 访谈:SQL Server Everywhere仅仅是另一种数据 (0次浏览)
- 地中海船运公司通过SQL Server2005处理5TB的数 (0次浏览)
- 从SQL Server 4.2到SQL Server 2005 (0次浏览)



