啟用 TDE 後處於可疑狀態的數據庫

我的一些數據庫處於可疑狀態。我怎樣才能讓他們上網？我不知道哪些資訊是相關的，哪些不是，但我會盡可能多地提供。這是發生的事情：

我通過以下方式在大約 100 個數據庫中啟用了 TDE。（證書 tde_certificate 是在另一個 SQL 伺服器上創建的，相同版本，如果重要的話。）

use master
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongPass'
--the key/cert was generated on another sql server (same version), if it matters
CREATE CERTIFICATE tde_certificate
FROM FILE = '\\dir\cert.bak'
WITH PRIVATE KEY (
file = '\\dir\key.pvk'
,DECRYPTION BY PASSWORD = 'StrongPass')

--then for each database:
use [SomeDb];
create database encryption key with algorithm = aes_256
encryption by server certificate tde_certificate

alter database [SomeDb] set encryption on

然後，對於所有啟用 TDE 的數據庫，TDE 似乎“停滯”在 0%。它處於這種狀態有一段時間，至少幾個小時（有些數據庫也非常小）。

日誌中的錯誤資訊顯示：

請在數據庫中創建主密鑰或在會話中打開主密鑰，然後再執行此操作。數據庫“dbname”的數據庫加密掃描已中止。重新發出 ALTER DB 以恢復掃描。

在故障轉移到另一個節點之後。除系統數據庫和未啟用 tde 的數據庫外，所有數據庫都卡在“RECOVERY_PENDING”中。

通過打開主加密密鑰並通過以下方式將數據庫設置為線上，我能夠使大多數數據庫線上：

use master
open master key decryption by password = 'ReallyStrongPassword'
alter database [SomeDb] set online

這適用於除 3 之外的所有數據庫。這些數據庫現在處於可疑狀態。

我嘗試了沒有運氣的修復：

use master
open master key decryption by password = 'ReallyStrongPassword'

ALTER DATABASE [SomeDb] set emergency
ALTER DATABASE [SomeDb] set single_user
DBCC CHECKDB ([SomeDb], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;
alter DATABASE [SomeDb] SET multi_user
alter DATABASE [SomeDb] SET online

結果：無法打開 Msg 926、Level 14、State 1、Line 30 數據庫“SomeDb”。它已被恢復標記為可疑。有關詳細資訊，請參閱 SQL Server 錯誤日誌。‘SomeDb’ 的 DBCC 結果。CHECKDB 在數據庫“SomeDb”中發現 0 個分配錯誤和 0 個一致性錯誤。

另外，我嘗試重新啟動加密掃描，但沒有運氣：

use master
open master key decryption by password = 'StrongPass'
DBCC TRACEON(5004)
DBCC TRACEOFF(5004)

exec sys.sp_resetstatus
   @DBName = 'SomeDb'

ALTER DATABASE SomeDb
SET ENCRYPTION on

結果：DBCC 執行完成。如果 DBCC 列印錯誤消息，請聯繫您的系統管理員。DBCC 執行完成。如果 DBCC 列印錯誤消息，請聯繫您的系統管理員。警告：您必須在訪問之前恢復此數據庫。

消息 5069，級別 16，狀態 1，第 131 行 ALTER DATABASE 語句失敗。消息 9001，級別 21，狀態 1，第 131 行數據庫“SomeDb”的日誌不可用。檢查事件日誌以獲取相關的錯誤消息。解決所有錯誤並重新啟動數據庫。

我注意到，每當我故障轉移到另一個節點時，所有數據庫（系統除外）都回到 RECOVERY_PENDING 狀態。我需要打開加密密鑰並明確將數據庫設置為聯機以使它們聯機（除了 3 個 SUSPECT dbs）。每次都會發生這種情況。

我在 SQL Server 2008 R2 Enterprise 上，集群有 2 個節點。我能夠在其他 4 個環境中使用相同的證書啟用 TDE，沒有任何問題。

關於我可以做些什麼來使這些數據庫線上的任何想法？

編輯：這是錯誤日誌的結果。我將其過濾到“每個”數據庫中。一個是可疑的，另一個是處於 recovery_pending 狀態。

http://pastebin.com/wasNk7Xw

編輯： sys.master_files 中引用的文件物理存在。我注意到 STATE = ONLINE 以及 sys.databases.state_desc = SUSPECT。

我能夠使數據庫重新聯機，事務日誌一定有問題。我重建了日誌，現在數據庫線上。我通過以下方式重新創建了日誌文件：

use master
open master key decryption by password = 'strongPassword'

ALTER DATABASE SuspectDb set emergency
ALTER DATABASE SuspectDb set single_user
ALTER DATABASE SuspectDb REBUILD LOG ON (NAME=SuspectDb_new_log_name, FILENAME='X:\SuspectDb_new_log_name.ldf')
alter DATABASE SuspectDb set multi_user

dbcc checkdb(SuspectDb) with data_purity, all_errormsgs,all_errormsg

執行 DBCC 後，有一堆一致性錯誤，但這超出了這個問題的範圍。如果我無法解決腐敗問題，我將發布一個新問題。

對於 3 個可疑數據庫，您能否檢查 sys.master_files 中引用的日誌文件物理上是否存在於磁碟上並且與其他工作數據庫日誌文件具有相同的訪問權限？只是您發布的一條錯誤消息說日誌文件失去，除非它是一個紅鯡魚，否則會使他們的問題與您的 TDE 問題分開並解釋可疑狀態。

我在您的日誌中註意到了這一點：04/13/2016 15:18:23,spid61,Unknown,Database SuspectDb 由於常式“XdesRMReadWrite::RollbackToLsn”中的錯誤 9001 而關閉。

如果日誌文件中存在由於空間不足而無法回滾的事務，則可能會發生這種情況，從而迫使數據庫進入可疑模式。您能否確認底層磁碟有可用空間，並且您還沒有設置並達到該數據庫文件的大小限制（例如，啟用了自動增長並設置為以合理的固定量增長）？

引用自：https://dba.stackexchange.com/questions/135350