在SQL Server 2008中配置TDE时是否有最佳实践？在SQLMag上，文章“透明数据加密常见问题解答”说，CPU使用率可能增加了30％？
除了增加服务器功能之外，打开TDE时，DBA通常还会执行其他操作吗？
在SQL Server 2008中配置TDE时是否有最佳实践？在SQLMag上，文章“透明数据加密常见问题解答”说，CPU使用率可能增加了30％？
除了增加服务器功能之外，打开TDE时，DBA通常还会执行其他操作吗？
Answers:
我注意到的其他几点是，如果您使用备份压缩功能，则该功能与TDE一起使用效果不佳。我们注意到压缩率非常低，几乎可以忽略不计。因此，如果使用备份压缩，请考虑这一点。
我敢肯定，您会知道的，但仅是要补充一下，TDE可用于企业版，因此在为TDE设置SQL Server时也要考虑这一点。
TDE没有提供像单元级别加密所提供的特定于用户或数据库角色的粒度控制。
确保将加密密钥安全地存储在安全的位置，以便在发生还原方案时可以访问该密钥。熟悉还原已加密到新服务器的数据库。（最初是Jonathan Fite的评论）。
首先，在加密数据库之前，请备份主密钥和证书并脱机存储。不要等到应用TDE之后再执行此操作。还要将密码存储在密码库中，并弄清楚哪些密码与哪个对象相关；您真的不想迷失这些。
TDE对数据库的影响完全取决于所涉及的工作量：我最近将TDE应用于数据仓库，而对夜间负载的性能影响却没有，这表明该进程不受CPU限制。但是，对于您的数据库而言可能并非如此。因此，如果您可以首先在开发环境上测试工作负载，则可以这样做。
不仅加密文件中的数据：TDE还将加密tempDB，因此，如果您有其他大量使用TempDB的数据库，则可能会发现性能下降。备份和快照也都被加密。
还考虑是否需要将该数据库还原到其他环境（例如，测试或UAT）。您将需要将用于加密数据库的证书还原到其他服务器。这听起来好像不是一个太大的问题，但是如果您在任何这些环境中都没有企业或开发人员，那么这可能会变得很昂贵。在整个环境中应用TDE的另一种方法是将数据库还原到企业/开发人员之间的中间实例，然后对敏感数据进行加扰，或者删除加密并创建要还原到其他环境的新备份。第二个选择可能不是最明智的选择，但它始终是一个选择。
打开TDE时，有两个应用于数据库的锁：共享锁和更新锁。TechNet充分说明了这一点：
启用（或禁用）TDE后，该数据库在sys.databases目录视图中标记为已加密，并且DEK状态设置为“正在进行加密”。服务器启动一个后台线程（称为加密扫描或扫描），该线程扫描所有数据库文件并对其进行加密（如果禁用TDE，则将其解密）。在执行DDL时，将对数据库进行更新锁定。与DDL异步运行的加密扫描采用了共享锁。与这些锁不冲突的所有常规操作都可以继续。排除的操作包括修改文件结构和分离数据库。从缓冲池对磁盘的普通数据库写操作已加密，而日志文件写操作可能未进行写操作。扫描还会强制对虚拟日志文件（VLF）进行翻转，以确保以后对日志的写操作得到加密。
我的经验是在白天很少使用而在一夜之间大量使用的数据仓库上，因此我能够在白天将TDE应用于应用程序时的中断很少。如果要在生产环境中对OLTP进行加密，则最好在维护时段内安排此时间，以最大程度地减少问题。
编辑：同样在压缩点上；尽管TDE确实会影响备份压缩，但它不会影响行/页面/列存储压缩。因此，如果要平衡备份带来的压缩损失，可以压缩数据库中的对象。同样，根据您的工作量，您可能会/可能不想在数据库上实施压缩，因为这会进一步给CPU造成压力。有一篇关于压缩实现的TechNet优秀文章：https : //technet.microsoft.com/zh-cn/library/dd894051%28v=sql.100%29.aspx