从前文中，我们了解到，使用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 字段，记录上一次暂停数据库加密扫描的时间。
数据库加密扫描暂停期间，如果您重启这个实例，在启动的错误信息里将指出存在数据库加密扫描暂停。