背景介绍:
2017年,3月某一天晚 上凌晨,上海某医院由于重启主交换机,没有和厂商联系,造成sql server数据库变成“三角惊叹号+数据库名+(可疑)”了,打不开,不能使用。
原因:在重启主交换机的时候,mssql集群ip冲突,造成数据库异常关机,此时正有数据在插入数据库中,造成数据的逻辑不一致。
解决办法:
1、 修改数据库为紧急模式
ALTER DATABASE 数据库名 SET EMERGENCY
2、 使数据库变为单用户模式
ALTER DATABASE 数据库名 SET SINGLE_USER
3、修正数据库,可能会导致一些数据丢失。
DBCC CheckDB ('数据库名',REPAIR_ALLOW_DATA_LOSS) //修复一次不成功,就多修复几次
2017年,3月某一天晚 上凌晨,上海某医院由于重启主交换机,没有和厂商联系,造成sql server数据库变成“三角惊叹号+数据库名+(可疑)”了,打不开,不能使用。
原因:在重启主交换机的时候,mssql集群ip冲突,造成数据库异常关机,此时正有数据在插入数据库中,造成数据的逻辑不一致。
解决办法:
1、 修改数据库为紧急模式
ALTER DATABASE 数据库名 SET EMERGENCY
2、 使数据库变为单用户模式
ALTER DATABASE 数据库名 SET SINGLE_USER
3、修正数据库,可能会导致一些数据丢失。
DBCC CheckDB ('数据库名',REPAIR_ALLOW_DATA_LOSS) //修复一次不成功,就多修复几次
4、使数据库变回为多用户模式
ALTER DATABASE 数据库名 SET MULTI_USER
使用这种方法修复了部分数据库并且成功。但是在某个重要的库上修复失败,所幸这个库可以正常使用,不是 可疑状态 。
日志报的错误大概的意思是数据库的系统表损坏,导致修复失败。
因为公司买了微软的服务,询问微软的技术人员,回复说:系统表损坏,修复不了,只能新建相同的库和表,然后把能够select出来的数据导进去。
幸运的是我们有一个事故发生当天凌晨的备份,除了一个表select报错之外,所有的表都是好的。更幸运的是可以使用 DBCC Checktable来修复这张表(丢失几条数据)
所以我们的方案就是:这个备份加上备份的最后的一条记录的作为条件把差的数据补上。
所以,最最重要的是数据库一定要有可用的,近期的备份。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31447263/viewspace-2136219/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/31447263/viewspace-2136219/