使用作为 Oracle 高级安全选件（版本 10.2 及更高版本）的一部分引入的 Oracle 数据库透明数据加密 (TDE)，可以有选择地对保留在数据库底层数据文件中的敏感数据库数据以及所有下游文件组件（如联机重做日志、归档重做日志和数据库备份）进行加密。TDE 的基本目标是保护在这些原始操作系统文件中发现的敏感数据，防止不怀好意的人访问磁盘或备份磁带时对这些数据进行窥探，然后尝试还原数据库或扫描原始操作系统文件中的数据，如个人可识别信息或信用卡信息。
作为我的咨询惯例的一部分，我已经实施 TDE 多次。但是，在其中一个最近的合约之前，我一直使用 TDE 对现有表中的新列或属于全新表的列进行加密。在这两种情况下使用 TDE 非常简单，因为目标列为空，因此由于缺乏数据和现有应用程序相关性而不会涉及较大的风险。
我最近实施 TDE 的体验有所不同。我帮助一家大型公司对一个已超过一百万行的表中的现有列进行加密。还有一个依赖于列的关键任务应用程序，因此，您可以设想一下，在开始工作之前有很多重要的事情要考虑。在 Internet 上搜索可提供经验的类似情形之后，我发现只有几个优秀的资源可以帮助我。
本文概述了我在通过使用 TDE 对现有数据进行加密的过程中总结出的经验教训。如果您尝试对现有列数据使用 TDE，我希望此处提供的信息可帮助您迅速有效地开展类似工作。
确定可能的限制
研究客户的系统时，我做的第一件事情就是查找与目标列有关的将禁止我们对列加密的数据模型特征，或者查找可能对现有操作产生负面影响的有关列的事项。该研究包括查找列索引和完整性约束。
正如 Oracle 文档明确声明，当您想对具有索引的某个列进行加密时，需要了解很多限制条件。Oracle 不允许对具有位图索引的列进行加密，这与我们的情况没有密切关系。但是，目标列具有多个普通的（B 树）索引。尽管 Oracle 允许对具有普通索引的列进行加密，但是 Oracle 禁止对索引列进行“salt 处理”加密。Salt 处理通过在加密之前向数据添加随机字符串来提高重复数据的安全性，因此窃贼使用模式匹配识别技术更加难于破解加密的数据。总而言之，经过这个最初的分析之后，我们会遇到一种情况，那就是我们可以对列进行加密，但不能进行 salt 处理。
对列索引进行分析后，我本可以到此为止，但是我想回答的下一个问题是“使用这些索引合适吗？”我的思考过程是这样：如果索引没有用，那么我会将其删除，从而减少维护索引条目所必需的系统开销，尤其是考虑到加密的额外负担。要判断索引是否有用，我使用 Oracle 数据库的索引监视特性。我发现，实际上索引正处于使用当中，因此我们必须对其继续进行维护。
接下来，我查看了引用完整性约束条件中是否涉及目标列。由于每个表都具有其自己的加密密钥，因此 Oracle 不允许您使用 TDE 对外键关系中涉及的列进行加密。在我们的情况下，引用完整性约束条件中未涉及目标列。
评估性能开销
我的客户询问的第一组问题之一就是“TDE 对我的应用程序的一般性能影响如何？”Oracle 文档中有一小部分论述了一般情况下 TDE 对相关应用程序性能的影响。但是我的客户希望获得一些具体的统计信息，以帮助他们了解 TDE 如何影响日常进行的有严格时间要求的数据加载过程。
为了满足客户需求，我计算了每天在有严格时间要求的过程中插入到目标表中的平均行数。然后，我在客户端的相同沙箱环境中创建了一个类似的测试表和索引，测量在加密目标列前后插入相同数量的行所花费的时间。时间消耗上的差别让我们更好地了解了在该过程中对列数据进行加密所造成的“性能损失”。列表 1 是我如何使用 SQL*Plus 执行该操作的示例。
SQL> CONNECT system
Enter password:
Connected.
SQL> -- Configure Oracle-Managed (Data) Files
SQL> ALTER SYSTEM
2 SET db_create_file_dest = '/data01/oracle/'
3 SCOPE = MEMORY;
System altered.
SQL> -- Create two new tablespaces for the demo,
SQL> -- one for data segments, one for index segments
SQL> CREATE TABLESPACE data_001
2 DATAFILE SIZE 1G;
Tablespace created.
SQL> CREATE TABLESPACE indx_001
2 DATAFILE SIZE 500M;
Tablespace created.
SQL> -- Create a user for the demo
SQL> CREATE USER app_001 IDENTIFIED BY app
2 DEFAULT TABLESPACE data_001
3 TEMPORARY TABLESPACE temp
4 QUOTA UNLIMITED ON data_001
5 QUOTA UNLIMITED ON indx_001;
User created.
SQL> GRANT CREATE SESSION, CREATE TABLE TO app_001;
Grant succeeded.
SQL> -- Work as the demo user
SQL> CONNECT app_001/app;
Connected.
SQL> -- Create the demo table in the default tablespace
SQL> CREATE TABLE app_001.transactions (
2 trans_id INTEGER
3 CONSTRAINT transactions_pk PRIMARY KEY
4 USING INDEX TABLESPACE indx_001,
5 credit_card INTEGER NOT NULL
6 );
Table created.
SQL> -- Create an index in the INDX_001 tablespace
SQL> CREATE INDEX app_001.transactions_ndx1
2 ON app_001.transactions(credit_card)
3 TABLESPACE indx_001;
Index created.
SQL> -- Time how long it takes to load data in the clear
SQL> SET TIMING ON;
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 /
PL/SQL procedure successfully completed.
Elapsed: 00:00:56.14
SQL> SET TIMING OFF;
SQL> -- Remove existing synthetic data
SQL> TRUNCATE TABLE app_001.transactions;
Table truncated.
SQL> -- Enable encryption of the credit card column
SQL> ALTER TABLE app_001.transactions
2 MODIFY (credit_card ENCRYPT NO SALT);
Table altered.
SQL> -- Time how long it takes to load encrypted data
SQL> SET TIMING ON;
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 /
PL/SQL procedure successfully completed.
Elapsed: 00:01:16.31
SQL> SET TIMING OFF;
列表 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 /
PL/SQL procedure successfully completed.
SQL> -- Time how long it takes to encrypt credit card data
SQL> -- with corresponding indexes in place
SQL> SET TIMING ON;
SQL> ALTER TABLE app_001.transactions
2 MODIFY (credit_card ENCRYPT NO SALT);
Table altered.
Elapsed: 00:02:27.18
SQL> SET TIMING OFF;
SQL> -- Remove existing synthetic data
SQL> TRUNCATE TABLE app_001.transactions;
Table truncated.
SQL> -- Drop all indexes that correspond to the credit card column
SQL> DROP INDEX app_001.transactions_ndx1;
Index dropped.
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 /
PL/SQL procedure successfully completed.
SQL> -- Time how long it takes to:
SQL> -- 1. Encrypt credit card data without corresponding indexes in place
SQL> -- 2. Recreate corresponding indexes
SQL> SET TIMING ON;
SQL> ALTER TABLE app_001.transactions
2 MODIFY (credit_card ENCRYPT NO SALT);
Table altered.
Elapsed: 00:01:15.48
SQL> CREATE INDEX app_001.transactions_ndx1
2 ON app_001.transactions(credit_card)
3 TABLESPACE indx_001
4 PARALLEL 2
5 NOLOGGING;
Index created.
Elapsed: 00:00:02.98
SQL> SET TIMING OFF;
列表 2 要快速执行对现有数据进行加密的过程，只需在对其进行加密之前删除列的底层索引，然后再重建索引。
注：本文的模拟环境中使用了 CREATE INDEX 语句。在实际的设置中，可考虑使用 Oracle 数据库的 DBMS_METADATA 实用程序包来生成 CREATE INDEX 语句，您可以使用这些语句在完成数据加密之后重新创建索引。
总之，在列加密之后重建索引的新策略可留出更多时间来处理整个过程中最具挑战性的问题，这将在下一部分中进行说明。
#p#
删除未加密数据的虚副本
Oracle 和底层主机操作系统使用优化的算法来更新数据块中的数据，目的是最大程度地减少降低性能的磁盘 I/O。在对现有列数据进行加密的特定情况下，通常发生的一件事是 Oracle 将加密的列数据写入到新数据块并且只是将之前未加密的值占用的空间标记为未使用。换句话说，Oracle 不会尝试清除较旧的未加密数据。只要所讨论的系统持续遇到大量更新活动，您就有理由确信当重用块空间时 Oracle 将最终覆盖较旧的未加密数据。但是考虑到我的客户正在准备进行合规性审计，我必须确保在加密过程之后立即擦除未加密的敏感数据。
进行了很多研究之后，我在 Oracle 技术网上发现了一个 FAQ 以及一个网志，该网志确认这一特定问题并提供了有关解决该问题的一些基本想法。一般的想法是将包含之前未加密数据的所有段移动到新的表空间（以及数据文件），然后使用一个操作系统实用程序删除旧数据文件。但该做法听起来容易，做起来难。事实是，在安全删除旧表空间及其数据文件之前，您很有可能需要移动大量段以及包含敏感数据的段。
为了使这一可能费时费力且易于出错的过程自动进行，我将一些脚本放在一起，以帮助我构建完成这一切所需的 DDL 语句。这里，我要向 Tom Kyte 表示谢意，因为此处的一些工作是修改我在 Asktom 站点找到的内容查询。列表 3 显示了我使用的整个过程的一个示例。
Enter password:
Connected.
SQL> -- Create new tablespaces for data and index segments
SQL> CREATE TABLESPACE data_002 DATAFILE SIZE 1G;
Tablespace created.
SQL> CREATE TABLESPACE indx_002 DATAFILE SIZE 500M;
Tablespace created.
SQL> -- Generate a script to move existing segments to new tablespaces
SQL> COL ORDER_COL1 NOPRINT;
SQL> COL ORDER_COL2 NOPRINT;
SQL> SET HEADING OFF;
SQL> SET VERIFY OFF;
SQL> SET ECHO OFF;
SQL> SELECT DECODE( segment_type, 'TABLE' , segment_name, table_name ) order_col1,
2 DECODE( segment_type, 'TABLE', 1, 2 ) order_col2,
3 'ALTER ' || segment_type || ' ' || LOWER(owner) || '.' || LOWER(segment_name) ||
4 DECODE( segment_type, 'TABLE', ' MOVE ', ' REBUILD ' ) ||
5 'TABLESPACE ' || LOWER(DECODE( segment_type, 'TABLE' , '&&NEW_DATA_TBS' , '&&NEW_INDX_TBS' )) || ';'
6 FROM dba_segments,
7 (SELECT table_name, index_name FROM dba_indexes WHERE tablespace_name = UPPER('&&OLD_INDX_TBS'))
8 WHERE segment_type in ( 'TABLE', 'INDEX' )
9 AND segment_name = index_name (+)
10 AND tablespace_name IN (UPPER('&&OLD_DATA_TBS'), UPPER('&&OLD_INDX_TBS'))
11 AND owner = UPPER('&&OWNER')
12 ORDER BY 1, 2;
Enter value for new_data_tbs: data_002
Enter value for new_indx_tbs: indx_002
Enter value for old_indx_tbs: indx_001
Enter value for old_data_tbs: data_001
Enter value for owner: app_001
ALTER TABLE app_001.transactions MOVE TABLESPACE data_002;
ALTER INDEX app_001.transactions_pk REBUILD TABLESPACE indx_002;
ALTER INDEX app_001.transactions_ndx1 REBUILD TABLESPACE indx_002;
SQL> SET HEADING ON;
SQL> SET VERIFY ON;
SQL> SET ECHO ON;
SQL> -- execute script output
SQL> ALTER TABLE app_001.transactions MOVE TABLESPACE data_002;
Table altered.
SQL> ALTER INDEX app_001.transactions_pk REBUILD TABLESPACE indx_002;
Index altered.
SQL> ALTER INDEX app_001.transactions_ndx1 REBUILD TABLESPACE indx_002;
Index altered.
SQL> -- Check for any unusable indexes
SQL> SELECT owner, index_name, tablespace_name
2 FROM dba_indexes
3 WHERE STATUS = 'UNUSABLE';
no rows selected
SQL> -- Gather new schema stats
SQL> EXEC dbms_stats.gather_schema_stats('app_001');
PL/SQL procedure successfully completed.
SQL> -- Check for remaining segments in old tablespaces
SQL> SELECT distinct owner
2 FROM dba_segments
3 WHERE tablespace_name IN (UPPER('&&OLD_DATA_TBS'), UPPER('&&OLD_INDX_TBS'));
old 3: WHERE tablespace_name IN (UPPER('&&OLD_DATA_TBS'), UPPER('&&OLD_INDX_TBS'))
new 3: WHERE tablespace_name IN (UPPER('data_001'), UPPER('indx_001'))
no rows selected
SQL> -- Check for users assigned to old tablespaces
SQL> SELECT username, default_tablespace FROM dba_users
2 WHERE default_tablespace IN (UPPER('&&OLD_DATA_TBS'), UPPER('&&OLD_INDX_TBS'));
old 2: WHERE default_tablespace IN (UPPER('&&OLD_DATA_TBS'), UPPER('&&OLD_INDX_TBS'))
new 2: WHERE default_tablespace IN (UPPER('data_001'), UPPER('indx_001'))
USERNAME DEFAULT_TABLESPACE
------------------------------ ------------------------------
APP_001 DATA_001
SQL> -- Assign new default tablespaces for users, as necessary
SQL> ALTER USER app_001
2 DEFAULT TABLESPACE data_002;
User altered.
SQL> -- List the data file names of old tablespaces
SQL> COL tablespace_name FOR A15;
SQL> COL file_name FOR A70;
SQL> SET LINES 100;
SQL> SELECT tablespace_name, file_name
2 FROM dba_data_files
3 WHERE tablespace_name IN (UPPER('&&OLD_DATA_TBS'), UPPER('&&OLD_INDX_TBS'));
old 3: WHERE tablespace_name IN (UPPER('&&OLD_DATA_TBS'), UPPER('&&OLD_INDX_TBS'))
new 3: WHERE tablespace_name IN (UPPER('data_001'), UPPER('indx_001'))
TABLESPACE_NAME FILE_NAME
--------------- ----------------------------------------------------------------------
DATA_001 /data01/oracle/db001/datafile/o1_mf_data_001_4m081w7m_.dbf
INDX_001 /data01/oracle/db001/datafile/o1_mf_indx_001_4m082l4q_.dbf
SQL> -- Drop old tablespaces, but keep data files in place
SQL> DROP TABLESPACE data_001
2 INCLUDING CONTENTS KEEP DATAFILES;
Tablespace dropped.
SQL> DROP TABLESPACE indx_001
2 INCLUDING CONTENTS KEEP DATAFILES;
Tablespace dropped.
SQL> -- Shred/remove old data files
SQL> HOST shred -n 200 -z -u /data01/oracle/db001/datafile/o1_mf_data_001_4m081w7m_.dbf
SQL> HOST shred -n 200 -z -u /data01/oracle/db001/datafile/o1_mf_indx_001_4m082l4q_.dbf
列表 3 删除剩余敏感数据的未加密虚副本需要一系列步骤才能解决很多相关性。
列表 3 中的最后一步针对特定的操作系统。在本例中，我演示了 Linux/Unix shred 实用程序的用法。其他您可能想探究的实用程序是 Linux/Unix wipe、scrub 和 srm 程序。
准备可能的重新生成密钥操作
我的客户还想做些准备以应对将来可能需要重新生成密钥的情况。为现有数据重新生成密钥意味着您要使用新密钥对现有数据重新加密。当您怀疑某人已经获得对现有表密钥的访问权限并且可能会在您的控制之外破解敏感数据时，可能需要执行该操作。
完成重新生成密钥操作的步骤与最初加密现有数据的步骤类似：删除目标列上的索引，重新生成该列数据的密钥，然后重建删除的索引。或者，如果您担心与使用以前的密钥加密的数据相对应的虚副本，可以重复将段移动到新表空间、删除旧表空间、然后清除旧表空间的数据文件的过程。
注：以我的经验，PCI 审计员会对重新生成万能加密密钥非常满意，因为该过程不需要访问任何数据，并且 PCI 标准不包含对 2 层密钥体系结构（如 Oracle 的体系结构）的建议。从符合 PCI 的角度看，重新生成万能加密密钥应该足够了，而且 PCI 审计员无法强制具有几十亿行的公司将其业务关闭几天，仅仅只是为了重新生成密钥。
确定可能的查询计划更改
Oracle 文档、若干文章以及我阅读过的一些论坛帖子几乎都提到了有关加密列的数据后现有查询执行计划可能发生更改的概要信息以及某些具体信息。一般来说，相对于没有索引的列，在加密具有索引的列时，您必须注意执行 SQL 语句所发生的情况。当 Oracle 加密具有索引的列时，Oracle 还将加密相应的索引值。如果您花点时间考虑这个问题，就会清楚地发现以具有索引的数据为目标的相等谓词应该继续利用索引，但由于该索引值存储在索引中的方式，加密值的随机性质使得加密索引的范围扫描成本过高。列表 4 演示了这些详细描述的基本情况。
SQL> CONNECT app_001
Enter password:
Connected.
SQL> -- Create a plan table
SQL> @?/rdbms/admin/utlxplan.sql;
Table created.
SQL> -- Disable encryption of the credit card column
SQL> ALTER TABLE app_001.transactions
2 MODIFY (credit_card DECRYPT);
Table altered.
SQL> -- Ensure schema stats are current
SQL> EXEC dbms_stats.gather_schema_stats('app_001');
PL/SQL procedure successfully completed.
SQL> -- Display some representative data
SQL> COL credit_card FOR 9999999999999999;
SQL> SELECT * FROM app_001.transactions
2 WHERE rownum < 5;
TRANS_ID CREDIT_CARD
---------- -----------------
389 3469681098409570
390 3441050723354352
391 3485598407754404
392 3485458104610650
SQL> -- Enable tracing and explain plan output
SQL> SET AUTOTRACE ON EXPLAIN;
SQL> -- Demonstrate an equality predicate targeting the
SQL> -- encrypted column
SQL> SELECT * FROM app_001.transactions
2 WHERE credit_card = 3485458104610650;
TRANS_ID CREDIT_CARD
---------- -----------------
392 3485458104610650
Execution Plan
----------------------------------------------------------
Plan hash value: 32329967
-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 14 | 5 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TRANSACTIONS | 1 | 14 | 5 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TRANSACTIONS_NDX1 | 1 | | 3 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("CREDIT_CARD"=3485458104610650)
SQL> -- Demonstrate a range predicate targeting the
SQL> -- encrypted column
SQL> SELECT * FROM app_001.transactions
2 WHERE credit_card BETWEEN 3499990000000000 AND 3499999999999999;
TRANS_ID CREDIT_CARD
---------- -----------------
4629 3499990987277941
18597 3499993250694089
13364 3499996558049599
79326 3499996616476145
60420 3499997873591732
24392 3499998608513414
97433 3499999831086288
72183 3499999977925392
8 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 32329967
-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3 | 42 | 6 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TRANSACTIONS | 3 | 42 | 6 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TRANSACTIONS_NDX1 | 3 | | 3 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("CREDIT_CARD">=3499990000000000 AND "CREDIT_CARD"<=3499999999999999)
SQL> -- Disable tracing and explain plan output
SQL> SET AUTOTRACE OFF;
SQL> -- Encrypt the column (and indexes)
SQL> ALTER TABLE app_001.transactions
2 MODIFY (credit_card ENCRYPT NO SALT);
Table altered.
SQL> -- Ensure schema stats are current
SQL> EXEC dbms_stats.gather_schema_stats('app_001');
PL/SQL procedure successfully completed.
SQL> -- Enable tracing and explain plan output
SQL> SET AUTOTRACE ON EXPLAIN;
SQL> -- Rerun previous queries, compare execution plans
SQL> SELECT * FROM app_001.transactions
2 WHERE credit_card = 3485458104610650;
TRANS_ID CREDIT_CARD
---------- -----------------
392 3485458104610650
Execution Plan
----------------------------------------------------------
Plan hash value: 32329967
-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 14 | 5 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TRANSACTIONS | 1 | 14 | 5 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TRANSACTIONS_NDX1 | 1 | | 3 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("CREDIT_CARD"=3485458104610650)
SQL> SELECT * FROM app_001.transactions
2 WHERE credit_card BETWEEN 3499990000000000 AND 3499999999999999;
TRANS_ID CREDIT_CARD
---------- -----------------
60420 3499997873591732
4629 3499990987277941
18597 3499993250694089
13364 3499996558049599
24392 3499998608513414
79326 3499996616476145
72183 3499999977925392
97433 3499999831086288
8 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 1321366336
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1250 | 17500 | 914 (2)| 00:00:11 |
|* 1 | TABLE ACCESS FULL| TRANSACTIONS | 1250 | 17500 | 914 (2)| 00:00:11 |
----------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(INTERNAL_FUNCTION("CREDIT_CARD")>=3499990000000000 AND
INTERNAL_FUNCTION("CREDIT_CARD")<=3499999999999999)
SQL> -- Disable tracing and explain plan output
SQL> SET AUTOTRACE OFF;
列表 4 仔细识别引用加密列数据的 SQL 语句，然后比较加密前后这些语句的执行计划，以查找是否存在任何更改。
我还想知道加密的开销是否会改变计划成本以及优化程序的选择，即使在文档建议不要这样做的情况下。为了确保我确切知道进行生产时关键任务应用程序所发生的情况，我在沙箱环境中进行了一些额外的工作。首先，我从各种自动负载信息库 (AWR) 快照中收集了一个使用频繁的 SQL 语句（CPU、Gets 和 I/O）列表。然后，我比较了加密列前后每个 SQL 语句的查询执行计划。我的研究转向对多个基于相等的条件使用一个谓词的复杂查询，其中一个条件是以将要进行加密的列为目标。让我吃惊的是，在对列进行加密之后，该查询的执行计划发生了改变。遗憾的是，我无法在我的测试实验室中为本文复制这些结果，我仍然无法完全确定查询计划发生改变的原因。但我之所以在此处提到这种情况是想指出，在对生产系统进行更改之前，最好在测试环境中研究生产应用程序密钥查询的执行计划。如果我假设没有任何使用频繁的查询会发生改变，那么我们将对生产系统进行更改并且不得不勉强拼凑一个解决方案。
此处的教训是，在进行更改之前，您应该始终对这些事项进行测试，无论您在文档和其他来源中阅读了什么内容都是如此。
结论
使用 Oracle 的 TDE 特性加密新表与没有任何数据的表中的列或者现有表中的新列非常简单，原因是不存在任何需要担心的相关性。相反，加密现有列数据需要仔细研究并在您的沙箱环境中进行测试，然后才能在实际生产系统中实施您的计划，因为加密可能会影响很多相关性。
Steve Bobrowski 自 Oracle 数据库版本 5 开始一直使用该软件，曾就职于 Oracle；他还是 The Database Domain (dbdomain.com) 的创始人以及五本 Oracle 出版社出版的书籍的作者（包括《Oracle 数据库 10g 快捷版上机操作》系列）。最近，Steve 担任着几个大型公司（如 Computer Sciences Corporation、BEA Systems 和 Salesforce.com）的 SaaS 顾问和 SaaS 首席技术官。
【编辑推荐】
