在被設(shè)置為“可疑”后很納悶，之前沒有遇到此類情況，問了幾個前輩依然未找到問題所在。***還是解決了，現(xiàn)在給大家分享我的解決辦法：

首先，不能使得數(shù)據(jù)庫脫機、分離等操作，在這種情況下，數(shù)據(jù)庫不能驚醒備份的。如果你真的使得數(shù)據(jù)庫脫機，就再也沒有辦法解決了。我也干過這件傻事，千萬不能重蹈覆轍哦。

其次，執(zhí)行下列代碼，將dbName換成你自己的數(shù)據(jù)庫。

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

接著，盡管這樣能夠使得數(shù)據(jù)庫恢復(fù)正常，至少可以讓對數(shù)據(jù)庫進行操作。包括查詢、更新等。但是這并沒有真正的解決問題，只是修改了數(shù)據(jù)庫的“可疑”狀態(tài)。

下面就要找具體問題所在，發(fā)生這種情況的緣由很多，或是數(shù)據(jù)庫操作、或是觸發(fā)器、存儲過程、索引、日志。

如果你的數(shù)據(jù)庫不是很大，其間的數(shù)據(jù)不多，希望能夠重新建立數(shù)據(jù)庫，然后再導(dǎo)入數(shù)據(jù)。

如果很大，而且很重要不能及時更新的話，希望大家搜索一下數(shù)據(jù)庫或者系統(tǒng)、應(yīng)用程序的日志，看一下日志記錄，或許你會發(fā)現(xiàn)一些可疑的苗頭。

***，發(fā)現(xiàn)數(shù)據(jù)庫在記錄日志的時候出現(xiàn)了問題，建議刪除久的日志文件（當(dāng)然主日志文件是不能刪除的），你可以添加新的日志文件。并檢查數(shù)據(jù)庫、日志的自增長是否正常。

【編輯推薦】

1. 符合數(shù)據(jù)庫需求的***SQL Server版本選擇
2. SQL Server通過代碼執(zhí)行代理任務(wù)
3. SQL Server置疑數(shù)據(jù)庫解決方法