首先确认已经备份了mdf和ldf文件
在SQL Server中新建一个同名的数据库然后停止SQL Server服务
用原有的mdf和ldf文件覆盖新建数据库对应的mdf和ldf文件
重新启动SQL Server服务这是应该会看到这个数据库处于置疑(Suspect)状态
在SQL查询分析器中执行以下命令以允许更新系统表
use mastergosp_configure ‘allow updates’reconfigure with overridego
将这个数据库置为紧急模式
update sysdatabases set status = where name = ‘db_name’go
使用DBCC CHECKDB命令检查数据库中的错误
DBCC CHECKDB(‘db_name’)GO
如果DBCC CHECKDB命令失败请转至第步否则先将数据库置为单用户模式再尝试对其进行修复
sp_dboption ‘db_name’’single user’’true’DBCC CHECKDB(‘db_name’ REPAIR_ALLOW_DATA_LOSS)GO
如果在执行DBCC CHECKDB(‘db_name’ REPAIR_ALLOW_DATA_LOSS)命令时提示说数据库未处于单用户模式状态的话则重新启动SQL Server服务然后继续尝试
如果DBCC CHECKDB(‘db_name’ REPAIR_ALLOW_DATA_LOSS)命令失败请转至第步否则若成功修复了数据库中的错误
重新执行DBCC CHECKDB(‘db_name’)命令确认数据库中已没有错误存在
清除数据库的置疑状态sp_resetstatus ‘db_name’
清除数据库的单用户模式状态sp_dboption ‘db_name’’single user’’false’
重新启动SQL Server服务如果一切正常的话则数据库已经成功恢复
如果以上步骤都不能解决问题的话请参考附件中的文档尝试通过重建事务日志来恢复数据库中的数据如果您只有MDF文件问题就更加复杂一些我们需要直接重建事务日志了:
在SQL Server中新建一个同名的数据库然后停止SQL Server服务
用原有的ldf文件覆盖新建数据库对应的mdf文件将其日志文件(ldf)删除
启动SQL Server服务并将数据库置为紧急模式(同上: 步骤和步骤)
停止并重新启动SQL Server服务
执行以下命令重建数据库日志文件(下面是个示例您要用您实际的数据库名)
DBCC REBUILD_LOG(’cas_db’ ‘D:cas_dbcas_db_LogLDF’)
重新将该数据库置为单用户模式
再次尝试使用DBCC CHECKTABLE或DBCC CHECKDB命令检查并修复数据库中的错误