从Oracle数据库1Og的R2版本开始，一个叫做透明数据加密(TDE)的特性让数据加密变得极其容易。我们所需要做的就是把某列声明成加密的，剩下的全部由Oracle完成。当用户输入数据时，列值会被截获、加密，然后用加密后的格式保存。然后，当这一列被查询时，又会自动对列值进行解密，然后把解密后的文本（明文）返回给用户。用户甚至都不需要知道发生过加密和解密——也就是所谓的透明。全部都是由Oracle代码内部完成，不需要任何触发器或者复杂的过程逻辑。
下面是一个使用TDE的例子：
要想把表ACCOUNTS中的SSN列声明成加密的，只需这样声明：
ALTER TABLE accounts MODIFY (ssn ENCRYPT USING 'AES256')
Oracle数据库马上就会用AES算法以及一个256位的密钥对SSN -列进行加密。密钥被保存在数据字典表中，不过为了防止被窃，这个密钥还会用一个主密钥加密，这个主密钥保存在一个单独的叫做钱包的位置。这个钱包，缺省时，位于$ORACLE_BASE/admin/$ORACLE- SID/wallet。不过我们也可以在SQLNET.ORA文件中指定一个不同的位置。
当用户用下面语句插入数据时：
INSERT INTO accounts (ssn) VALUES (’123456789’)真实的值是以加密格式放在数据文件、重做日志以及归档日志中的，因此也会在备份文件中。当一个用户以后查询这个数据时，加密的值会自动被解密，显示的还是最初的值。上述语句执行之前，必须要先由DBA或者安全管理员打开这个钱包。
TDE的目的只有一个：用最小的代价加密敏感数据，避免可能的对数据文件的盗窃带来的破坏。不过，注意，强调的重点是透明——也就是说，加密是自动进行的，解密也一样。在数据库中。Oracle不会区分用户。当一个用户查询数据库时，Oracle不管这个验证用户到底是谁，都会给他明文值。
TDE也有一些限制：
一方面，不能对外键列使用TDE，对于许多企业应用来说这确实是一个限制。另一方面，对于使用了TDE的列我们只能创建b树索引。不过，如果我们是用PL/SQL实现我们自己的加密过程，这些限制就无所谓了。在判断TDE是否能够符合我们的目标时，自动化是我们必须要考虑的另一个方面。对于TDE来说，钱包（主密钥保存在这里）必须要由DBA通过类似于下面的命令打开：
ALTER SYSTEM SET ENCRYPTION WALLET OPEN AUTHENTICATED BY "pooh"饯包的密码是“pooh”。如果数据库数据文件（或者重做日志文件、或者这些文件的备份文件）被偷了，由于小偷不知道密码“pool"加密列的内容还是加密的，有了这个密码他才能打开钱包。每次数据库启动之后，钱包都必须要由DBA显式地打开，然后才能用于插入或者访问过程的加密。如果钱包没有打开，对这些列的插入以及访问就会失败。因此，这也是在数据库打开之后需要执行的额外一步操作。另外，我们必须要保证负责打开数据库的人知道钱包的密码。
为了让这一步更加容易和更加自动化，我们一般都会考虑创建一个数据库启动触发器，在其中调用ALTER SYSTEM命令（前面显示的）打开钱包。不过，如果你这么做，这个启动触发器就会去掉对于钱包的唯一保护，接着，就是加密的列。因此，如果我们使用TDE，我们永远都不能使用这样的启动触发器，我们必须准备好每次数据库启动之后再执行额外的一步操作。不过，如果我们构建我们自己的加密基础设施，那么只要数据库启动它就可用，就不需要额外的步骤，也没有钱包密码需要记忆和输入。
总的来说。TDE的功能有限。它提供了一个对数据文件、重做日志、备份文件进行加密的快速容易方法。不过，它没有根据用户的不同保护数据；它的解密是基于访问的。如果我们需要对解密过程有更多的控制能力，我们就需要依赖我们自己的加密基础设施。
在许多情况下，我们还是需要构造一个更复杂的系统，在这个系统中，只有当发出请求的用户确实被授权阅读这些数据时，解密后的明文才会显示给他，如果不是这样，返回的就是加密的值。使用TDE是不可能满足这个需求的，因为TDE会不分青红皂白地对一切数据解密。不过，我们可以构建一个自己的架构实现这个目的。