從前文中，我們瞭解到，使用TDE是非常有必要的，但很多同行開始時可能並不知道該功能，或者知道該功能時產品已經運行較長一段時間，那麼我們是否可以立刻開始進行TDE了呢？我們先來深入瞭解TED的過程。
TDE對數據庫文件的加密是在頁級別實現的，被稱爲靜態數據加密，意思是對數據和日誌文件同時進行加密。對於數據的變更，TDE實施的實時加密和解密數據和日誌文件的過程，先進行加密，再寫入磁盤；對於已經存在的數據，先讀入內存，加密後再寫入磁盤。讀取加密數據時，是讀入內存中進行解密的，最終將解密後的數據返回前端。而對數據庫更改數據庫加密的證書和非對稱祕鑰的過程，是一個先解密後加密的過程。如下是我在對一個數據庫關閉數據庫TDE的時候查看系統視圖sys.dm_database_encryption_keys 的結果：
SELECT
DB_NAME(database_id) DBName
, encryption_state
, CASE encryption_state
WHEN 0 THEN '不存在數據庫加密密鑰，未加密'
WHEN 1 THEN '未加密'
WHEN 2 THEN '正在進行加密'
WHEN 3 THEN '已加密'
WHEN 4 THEN '正在更改密鑰'
WHEN 5 THEN '正在進行解密'
WHEN 6 THEN '正在進行保護更改' --正在更改對數據庫加密密鑰進行加密的證書或非對稱密鑰
END
, percent_complete
FROM sys.dm_database_encryption_keys
這個數據庫超過了1T，此結果是我關閉TDE後1個小時左右查詢到的，我們可以看到解密進度纔到了6.5%，進度還是相當慢的。同時我們使用sp_lock查看一下數據庫的鎖的情況，如下圖：
在大量的extent（8個連續的頁）上存在更新鎖，當然我們還可以看到數據庫級別加密掃描的共享鎖。
同時，我們從資源管理器中可以看到：
數據庫所在的磁盤D在進行着大量的讀寫操作，D盤的隊列的長度也異常的到達了50。同時CPU、內存也都大量的使用。
TDE是一個消耗I/O、內存和CPU的過程。所以選擇對數據庫進行加密的時機很重要。
最佳實踐：是在數據庫上線之始就開啓TDE。當然有DBA已經錯過了這個時機，爲避免影響生產環境，我們最好選擇維護的時機或者選擇錯過業務高峯期進行此操作。
還有一種情況是，我們沒有很好的管理TDE的證書和私鑰備份文件，在管理人員變動時，需要更改加密方式，那麼我們的最佳實踐只能選擇錯過業務高峯期進行此操作。
當然，這一情況在SQL Server 2019（15.x）版本中得到改觀，其增加了暫停加密數據庫掃描的功能。即當我們發現系統負荷過高時，我們可以暫停數據庫加密掃描，等過了高峯後，我們再啓動加密進程繼續加密。
暫停加密掃描：
ALTER DATABASE <db_name> SET ENCRYPTION SUSPEND;
繼續加密掃描：
ALTER DATABASE <db_name> SET ENCRYPTION RESUME;
當您使用的是SQL Server 2019，那麼很高興的告訴您，您將不用像之前的版本那樣小心翼翼的確定什麼時候啓動TDE或者修改加密證書，just begin！
同時在sys.dm_database_encryption_keys 動態視圖中添加了encryption_scan_modify_date 字段，記錄上一次暫停數據庫加密掃描的時間。
數據庫加密掃描暫停期間，如果您重啓這個實例，在啓動的錯誤信息裏將指出存在數據庫加密掃描暫停。