Skip Headers
Oracle® Database Advanced Security Guide
12c Release 1 (12.1)

E17729-19
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

7 Frequently Asked Questions About Transparent Data Encryption

This chapter provides answers to frequently asked questions about transparency and performance issues with Transparent Data Encryption.

This chapter contains:

Transparency Questions About Transparent Data Encryption

  1. Is Transparent Data Encryption compatible with my application software?

    Transparent Data Encryption is compatible with applications by default because it does not alter the inbound SQL statements or the outbound SQL query results. Oracle executes internal testing and validation of certain Oracle and third-party application software to capture helpful deployment tips or scripts, and to evaluate performance profiles. See the following Oracle Technology Network page to find more information about deployment scripts that you can use for various applications.

    http://www.oracle.com/technetwork/database/options/advanced-security/index-099011.html

    Be aware of the difference between Transparent Data Encryption and the DBMS_CRYPTO PL/SQL package. This package is intended for different customer use cases. It is an API and toolkit solution and as such, it is non-transparent.

  2. Is Transparent Data Encryption compatible with other Oracle Database tools and technologies that I am using?

    One of the chief benefits of Transparent Data Encryption is its integration with frequently used Oracle Database tools and technologies such as high-availability clusters, storage compression, backup compression, data movement, database backup and restore, and database replication. Specific Oracle technologies that are integrated directly with Transparent Data Encryption include Oracle Real Application Clusters (Oracle RAC), Oracle Recovery Manager (RMAN), Oracle Data Guard, Advanced Compression, Oracle Data Pump, and Oracle GoldenGate, among others. Transparent Data Encryption also has special points of integration with Oracle Exadata that fully use unique features of Oracle-engineered systems.

    Transparent Data Encryption also works easily with security features of the Oracle Database. With Transparent Data Encryption, privilege grants, roles, Oracle Database Vault realms, Virtual Private Database policies, and Oracle Label Security labels remain in effect. You can use these and other security features in tandem with Transparent Data Encryption encryption.

  3. Are there any known Transparent Data Encryption limitations or incompatibilities?

    • TDE column encryption: TDE column encryption encrypts and decrypts data transparently when data passes through the SQL layer. Some features of Oracle will bypass the SQL layer, and hence cannot benefit from TDE column encryption. The following are known database features that TDE column encryption does not support, and their relevant software version numbers:

      • Materialized View Logs (not supported prior to Oracle Database 11g Release 2)

      • Streams (not supported prior to Oracle Database 11g Release 1)

      • Synchronous and asynchronous change data capture for data warehousing (CDC)

      • Transportable Tablespaces

      • LOBs

      Note that Secure Files were introduced in Oracle Database 11g Release 1, so it is not supported with TDE column encryption prior to that release

    • TDE tablespace encryption: TDE tablespace encryption encrypts all content that is stored in the tablespace at the block level in storage, and it generally does not conflict with other database features. TDE tablespace encryption does not have any of the limitations that TDE column encryption has. However, you should be aware of the following:

      • For Transportable Tablespaces (TTS) that use TDE tablespace encryption, the origin database can be encrypted with TDE, but it requires that the destination database is not encrypted with TDE. This is because you would have to overwrite the Oracle Wallet on the destination database with the origin database's Oracle Wallet, thus losing access to existing encrypted data on the destination. Also, the origin and destination databases both must share the same endianness.

      • Do not attempt to encrypt database internal objects such as the SYSTEM, SYSAUX, UNDO, or TEMP tablespaces using TDE tablespace encryption. You should focus TDE tablespace encryption on tablespaces that hold application data, not on these core components of the Oracle database.

Performance Questions About Transparent Data Encryption

  1. What is the typical performance overhead from Transparent Data Encryption?

    There are many different variables involved in the creation of an accurate Transparent Data Encryption performance test. The results can vary depending on the test environment, test case or workload, measurement metrics or methods, and so on. Oracle cannot guarantee a specific performance overhead percentage that can apply in all possible scenarios. In practice, the performance tests by many Transparent Data Encryption customers are often in the low single digits as a percentage, but that is not universally the case. Customer examples that cite 1 percent and 2 percent overhead respectively are published on Oracle Technology Network in the following URL:

    http://streaming.oracle.com/ebn/podcasts/media/12740910_ColumbiaU_120312.mp3

    If possible, use Oracle Real Application Testing (Oracle RAT) to capture a real production workload and then replay it against Transparent Data Encryption to get a true indication of the performance overhead that the you can expect within your environment.

    See also:

  2. How can I tune for optimal Transparent Data Encryption performance?

    • TDE column encryption:

      • Limit the crypto processing by only encrypting the subset of columns that are strictly required to be protected. In addition, turn off the optional integrity checking feature.

      • After you apply column encryption, rebuild the column indexes.

    • TDE tablespace encryption: TDE tablespace encryption improves performance by caching unencrypted data in memory in the SGA buffer cache. This feature reduces the number of crypto operations that must be performed when users run SELECT queries, which draw from the SGA instead of drawing from disk. (Drawing from disk forces the database to perform decrypt operations.) Ensure that the size of the SGA buffer cache is large enough to take full advantage of this performance optimization.

      Another major performance boost comes from using hardware and software that supports CPU-based cryptographic acceleration available in Intel AES-NI and Oracle SPARC T4/T5. To take advantage of this feature, you must be running a recent version of the database, have a recent version of the operating system installed, and be using hardware that includes crypto acceleration circuitry within its CPUs/cores.

      Database compression further speeds up Transparent Data Encryption performance because the crypto processing occurs on data that already is compressed, resulting in less total data to encrypt and decrypt.

    • In general:

      • Ensure that you have applied the latest patches, which you can download from My Oracle Support at

        https://support.oracle.com

      • When you specify an encryption algorithm, remember that AES is slightly faster than 3DES. Use AES128 where possible. Be aware that the performance benefit is small.

      • Use Exadata, which includes additional performance benefits. For more information about Oracle Exadata, see Oracle Database Testing Guide.

  3. Are there specific issues that may slow down TDE performance, and if so, how do I avoid them?

    TDE tablespace performance is slower if the database cannot use CPU-based hardware acceleration on the host machine due to factors such as older hardware, an older database version, or an older operating system.

    Note the following with regard to specific database workloads:

    • Encrypting the whole data set at once (for example, while doing ”Bulk Data Load” into an Oracle data warehouse): Lower crypto performance has been observed during bulk load of new data into the database or data warehouse. New data cannot be cached in SGA, so TDE tablespace encryption performance optimizations are bypassed. Hence, Transparent Data Encryption has no bonus performance benefits in this type of operation.

      Follow these guidelines:

      • Ensure that the database is running on servers with CPU-based cryptographic acceleration. This accelerates not only decrypt operations, but also encrypt operations as well (for loading new data). Take the crypto processing out of band by pre-encrypting the data set and then using Transportable Tablespaces (TTS) to load into the database. Try to parallelize this procedure where possible. This requires the database instance to copy the required TDE key to the keystore on the destination database. The procedure may not be feasible when there is a fixed time window for encryption and loading, and these must be done serially.

      • Consider using TDE column encryption. Encrypt only the handful of sensitive regulated columns instead of encrypting an entire tablespace.

    • Decrypting an entire data set at once (for example, while performing a full table scan by reading directly from disk, with no reading from SGA):

      Lower crypto performance is observed when running full table scan queries where data is read directly from storage. Certain performance optimizations of TDE tablespace encryption are bypassed (no caching). Hence, Transparent Data Encryption has no bonus performance benefits in this type of operation.

      Follow these guidelines:

      • Ensure that the database is running on servers with CPU-based cryptographic acceleration.

      • Retest the full table scan queries with a larger SGA size to measure performance when data is read from cache. Try setting the Oracle event number 10949 to disable direct path read.

      • Partition the database so that less data is scanned by full table scan operations. Production databases often use partitioning for this kind of scenario (that is, to limit the total amount of data scanned).

      • Consider using TDE column encryption. Encrypt only the handful of sensitive regulated columns instead of encrypting an entire tablespace.