经验之谈：使用Oracle的TDE特性加密

核心提示： 列表1使用与您的生产环境相同的沙箱环境，简单比较启用列加密前后加载代表性数据集所花费的时间，经验之谈：使用Oracle的TDE特性加密(3)，以使您更好地了解列加密对生产系统性能的影响，和所有的性能测试一样，这些超时又会造成连接断开，然后导致后续的事务失败，我怀疑对列进行加密所造成的性能损

列表　1　使用与您的生产环境相同的沙箱环境，简单比较启用列加密前后加载代表性数据集所花费的时间，以使您更好地了解列加密对生产系统性能的影响。　

和所有的性能测试一样，我怀疑对列进行加密所造成的性能损失会因系统而异，具体取决于普通变量（CPU、平均负载等）。在列表 1 中，您注意到计算的性能损失为 36% (((56.14-76.31)/56.14)*100)，但是，使用我们在客户系统中收集的实验证据，预计数据加载过程所耗费的时间应该大约增加 11%，这与在生产中使用 TDE 获得结果完全一样。

在本例中，我侧重于对具有索引的数据加载过程估计数据加密的性能损失。如果您的系统具有不同类型的关键过程，如要求苛刻的报表生成周期，那么我建议您使用沙箱环境来比较数据加密前后该过程所花费的时间。本文后面的“确定潜在查询计划更改”部分将讨论查询和数据加密的特别注意事项。

处理停机和维护时间

我的客户比较关心的另一个问题是，在加密约一百万行的表中的现有列数据时，需要对哪些生产应用程序（如果有）进行必要的停用。我最初想法是，理论上不需要停止任何应用程序 — 毕竟，Oracle 文档明确表示了对现有列的数据进行加密本质上就是对整个表进行多行更新。如果没有更多地考虑这件事，我不会明白为什么新行无法并发插入到表中以及为什么现有行更新无法继续。当我咕哝着熟悉的 Oracle 口号“读取方不会阻止写入方，写入方也不会阻止读取方”时，我的确没有想到列加密会影响查询。

但是，在长时间从事 DBA 工作后，我才总结出，若要对生产系统进行最终的实际更改，需要对理论进行测试，以避免出现意外问题，这一点非常重要。您瞧，当我在加密列期间，针对沙箱数据库对应用程序本身进行了测试，从而发现了很多问题。最重要的是，我发现进行中的加密延长了某些查询的响应时间，以至于应用程序会遇到响应超时。这些超时又会造成连接断开，然后导致后续的事务失败，进而会更加麻烦 — 我将为您提供详细信息。