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

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

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

处理停机和维护时间

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

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

必须一提的是，测试之后，我了解到停止应用程序运行绝对不是没有理由的。但下一个问题是，生产应用程序需要脱机多久？在计划每个周末进行的正常两小时的维护时间之内能够对列进行加密吗？或者，需要更长的停机时间？为了弄清这个问题，我只需测量在沙箱环境中对列进行加密所花费的时间，因为沙箱环境与生产环境具有相同的服务器硬件和数据集。我发现，列加密要花费一个小时多一点的时间才能完成。坦白地说，由于我使用类似数据在笔记本电脑上模拟测试加密运行才花费了不到 5 分钟的时间，因此对于它花费这么长时间，我感到非常震惊。但是当我们在生产数据库系统中对列进行加密时，最要紧的是要使用陈旧服务器硬件所发生的情况。

了解到在正常维护时间内执行其他任务需要更多时间，我决定必须找到减少加密列花费时间的方法。我的第一个直觉就是删除包含目标列的两个索引。这样，Oracle 只需加密表本身中的列数据，之后我可以有效地重建索引，而没有日志记录开销。经过一些新的测试之后，我将加密列以及相关索引所需的时间从 70 分钟（在加密期间存在索引）减少到仅 20 分钟（加密列后重建索引）。列表 2 是我用来得出结论的测试示例（从我们在列表 1 中停止的位置继续）。此外，请注意，列表中的时间来自用来编写本文的测试系统，而不是来自我的客户端使用的实际系统。

SQL> -- Remove existing synthetic data
SQL> TRUNCATE TABLE app_001.transactions;

Table truncated.

SQL> -- Disable encryption of the credit card column
SQL> ALTER TABLE app_001.transactions
2 MODIFY (credit_card DECRYPT);

Table altered.

SQL> -- Load new synthetic data
SQL> BEGIN
2 -- AMEX
3 FOR i IN 1 .. 100000 LOOP
4 INSERT INTO app_001.transactions(trans_id, credit_card)
5 VALUES (
6 i,
7 '34' || TRUNC(DBMS_RANDOM.VALUE(low=>0, high=>99999999999999))
8 );
9 END LOOP;
10 COMMIT;
11 -- VISA
12 FOR i IN 100001 .. 400000 LOOP
13 INSERT INTO app_001.transactions(trans_id, credit_card)
14 VALUES (
15 i,
16 '4' || TRUNC(DBMS_RANDOM.VALUE(low=>0, high=>999999999999999))
17 );
18 END LOOP;
19 COMMIT;
20 -- MASTERCARD
21 FOR i IN 400001 .. 500000 LOOP
22 INSERT INTO app_001.transactions(trans_id, credit_card)
23 VALUES (
24 i,
25 '54' || TRUNC(DBMS_RANDOM.VALUE(low=>0, high=>99999999999999))
26 );
27 END LOOP;
28 COMMIT;
29 END;
30 /