逐步执行
第一步:
–把ArbinResult1_2替换成质疑的数据库名称
USE MASTER
GO
SP_CONFIGURE ‘ALLOW UPDATES’,1 RECONFIGURE WITH OVERRIDE
GO
第二步:
–修改数据库为紧急模式
ALTER DATABASE ArbinResult1_2 SET EMERGENCY
GO
第三步
–使数据库变为单用户模式
ALTER DATABASE ArbinResult1_2 SET SINGLE_USER
GO
第四步:
–修复数据库日志重新生成,此命令检查的分配,结构,逻辑完整性和所有数据库中的对象错误。
–当您指定“REPAIR_ALLOW_DATA_LOSS”作为DBCC CHECKDB命令参数,该程序将检查和修复报告的错误。
–但是,这些修复可能会导致一些数据丢失。
DBCC CHECKDB(‘ArbinResult1_2’,‘REPAIR_ALLOW_DATA_LOSS’)
GO
第五步:
ALTER DATABASE ArbinResult1_2 SET ONLINE
GO
第六步:
SP_CONFIGURE ‘ALLOW UPDATES’, 0 RECONFIGURE WITH OVERRIDE
GO
第七步:
–使数据库变回为多用户模式
ALTER DATABASE ArbinResult1_2 SET MULTI_USER
GO
————————————————
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
原文链接:https://blog.csdn.net/Hakim2214/article/details/121792973
在数据库使用过程中,由于突然断电或者服务器突然宕机的情况下,SQL Server数据库为了避免数据库被错误使用或者非法恢复时,会将一些数据库置为“可疑”状态。这时数据库是不能被外界访问的,所以必须将这些数据库恢复正常。
利用以下SQL语句可以对“可疑”数据库进行恢复。
USE MASTER
GO
SP_CONFIGURE ‘ALLOW UPDATES’,1 RECONFIGURE WITH OVERRIDE
GO
ALTER DATABASE dbName SET EMERGENCY
GO
sp_dboption ‘dbName’, ‘single user’, ‘true’
GO
DBCC CHECKDB(‘dbName’,‘REPAIR_ALLOW_DATA_LOSS’)
GO
ALTER DATABASE dbName SET ONLINE
GO
sp_configure ‘allow updates’, 0 reconfigure with override
GO
sp_dboption ‘dbName’, ‘single user’, ‘false’
GO
尽管这样能够使得数据库恢复正常,至少可以让对数据库进行操作。包括查询、更新等。但是这并没有真正的解决问题,只是修改了数据库的“可疑”状态。
接着就需要找具体问题所在,发生这种情况的缘由很多,或是数据库操作、或是触发器、存储过程、索引、日志。如果你的数据库不是很大,其间的数据不多,希望能够重新建立数据库,然后再导入数据。如果很大,而且很重要不能及时更新的话,希望大家搜索一下数据库或者系统、应用程序的日志,看一下日志记录,或许你会发现一些可疑的苗头。
最后,发现数据库在记录日志的时候出现了问题,建议删除久的日志文件(当然主日志文件是不能删除的),你可以添加新的日志文件。并检查数据库、日志的自增长是否正常。
————————————————
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
原文链接:https://blog.csdn.net/happycell188/article/details/49661241