TDE可以为我们的数据库提供加密保护，但是，不是任何情况下都可以随意开启TDE的，同时开启TDE后，我们的数据库维护管理工作也需要进行一些调整。
下面我们就先看看开启TDE需要的条件吧！
无法正常开启TDE的情况只有一种，那就是数据库中有只读文件组。
一般，我们查询sys.dm_database_encryption_keys可以得到DEK的状态，encryption_state为1、2、3、4、5分别表示没有加密、加密中、已加密、密钥改变中、解密中的状态。正常情况下，当我们设置正确并开启TDE后，encryption_state=3，表示表示TDE开启，数据库已加密。但是当数据库中有只读文件组的时候，我们设置正确并开启TDE时，SQL Server不会有任何异常，打开数据库属性窗口也可以看到TDE已开启。不过我们会发现，encryption_state永远等于2，也就是说一直处于加密中状态而无法完成。所以，如果数据库有只读文件组，那么将无法成功开启TDE。
另外一种情况是，如果数据库使用了filestream数据类型VARBINARY(MAX)，那么文件流数据类型将不会被加密，不过数据库本身还是可以使用TDE来进行加密的。
再来看看开启TDE后，都会造成哪些影响。
首先考虑的是数据库的恢复。
因为开启TDE后，数据库的数据文件、日志文件、备份文件都会被加密，所以如果没有TDE的证书备份的话，将无法进行数据库的恢复。这里不仅仅指数据库备份的恢复，还包括事物日志传送和数据库镜像等，如果辅助服务器上没有有效的TDE证书，那么事物日志传送和数据库镜像都会失败。
其次我们看下数据库的备份压缩。
在SQL Server 2008上，正常的数据库备份压缩，可以达到90%以上的压缩比，即压缩后的文件只有压缩前的10%以下的大小；但是开启TDE后，备份压缩的效率就非常不明显了，压缩后的文件差不多都是压缩前的90%以上。
最后，还有一个问题是系统临时数据库tempdb。
如果在SQL Server实例上的任何数据库上开启了TDE，那么这个实例上的tempdb也将会自动加密，这将导致其他未开启TDE的数据库在使用tempdb数据库时性能下降。
基本上，开启TDE所要考虑的方面就是以上5点。如果你想开启TDE用来保护数据库，而且你的数据库中没有只读文件，也没有filestream数据类型或者有filestream数据类型，但是这个类型的数据不加密也可以接受，并且你也考虑到了数据库恢复、备份压缩以及tempdb数据库使用上会有一些变化，这些变化都不会对的系统造成重大的影响，你都可以接受的话，那么你就可以开启TDE了。
