10/14/2019 Document 1303412.

1
Copyright (c) 2019, Oracle. All rights reserved. Oracle Confidential.

Performance Impact of TDE. (Doc ID 1303412.1)

In this Document

Goal
Solution
1. What performance problems can be expected?
2. How large is the impact on performance?
3. How to investigate?
4. What to do to alleviate the performance of the execution plans?
References

APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.2.0.2 and later

Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Information in this document applies to any platform.
Checked for relevance on 04-Jun-2013

GOAL

What are the performance implications of the TDE (transparent data encryption) feature?

SOLUTION

The first things to take into consideration are the encryption mechanisms for column and tablespace encryption. Because
they are different, these 2 encryption types cannot be compared in terms of performance.

1. With column encryption, the data is encrypted on disk and in the buffer cache and decrypted in the session private
memory (PGA). The data block itself is not fully encrypted, only the specified columns. The data is encrypted when written
into the buffer cache and decrypted when read into the PGA.

2. With tablespace encryption, the data is encrypted on disk and decrypted in the buffer cache and subsequently when
processed in the PGA. The entire data blocks are encrypted on disk. The data is encrypted when written to disk by the
DBWR and decrypted when read from the disk into the buffer cache.

1. What performance problems can be expected?

It is very important to take into consideration that the encrypt/decrypt operations are an overhead to the existing plans.
Encryption and decryption are typically CPU intensive operations and would always require additional CPU resources. They
are not generating specific wait events. The time needed to decrypt the data should not be compared to the time needed
to execute a statement or read a block from disk. As a rule of thumb, when a statement involves encrypted tables, the
encrypted data should be accessed as little as possible, in order to avoid the encryption/decryption overhead as much as
possible, in order to manage the queries increased execution time. As a result, if a 'large' table column in a 'large' table is
encrypted (column encryption) or a 'large' table is encrypted (tablespace encryption), performing a full table scan on such
a table can increase significantly the execution time as compared to the situation when the table were not encrypted.

1.1 If using column encryption, the most common performance problem is a change of execution plans.
The most common problem is caused by the fact that column encryption is unable to use the range scan on indexes,
because when the index columns are encrypted (all or some of them) the index keys are not sorted in the same order as
in the non-encrypted form. Consequently, with TDE column encryption, an index range scan becomes a full table scan.
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=1d90zqy4dn_52&id=1303412.1 1/3
10/14/2019 Document 1303412.1

The execution plan can regress as well when encrypting the table columns with SALT and using the same columns to filter
the query result in the WHERE clauses. According to the documentation, SALT means adding a random strings of data to
the encrypted data and consequently making the encryption function non-deterministic. As a result, to be able to do the
comparison between the encrypted column and the predicate in the WHERE clause, the column data has to be decrypted
first, which would always result in a full table scan and in decrypting all the records in the column and, of course, large
increases in the execution time.

Another problem is when the table columns are used in the where clauses of the queries. Sometimes,the columns are
decrypted as a result and decrypt functions (appears as INTERNAL_FUNCTION in the execution plan) are applied on them,
which can lead to poor approximations of column selectivity, leading to improper plans. This happens mostly when the
encrypted columns are using SALT to encrypt the data, but it can happen for other reasons as well, including bugs. See
note 454980.1 for an example.

1.2 If using tablespace encryption, queries requesting a large number of encrypted blocks (especially full table scan) would
suffer from performance degradations which can be 10 times and even larger as compared to the same statement running
on unencrypted data and using the same execution plan. This is not a bug, it is the expected overhead when reading a full
table from disk into the buffer cache. Please note that full table scans should be avoided in any performance tuning effort
and the overhead of decryption depends on available resources, parallelization may help also. Consider that for OLTP
activity the overhead of encryption is small as active blocks are modified in the unencrypted buffer cache and only when
blocks are read from or written to disk need decryption and encryption, to some extent a larger buffer cache may help, but
be careful not to trade too much of the other memory areas like the shared pool. Equally, execution plan changes are to
be also considered, but to a lot smaller extent than with column encryption. Hardware acceleration can help to reduce
encryption / decryption overhead, all modern Intel CPU's support AES-NI. SPARC processors also support hardware
acceleration, for more information see note 1365021.1 . This document also lists some performance related patches that
are generally applicable.

2. How large is the impact on performance?

The impact on a query performance cannot be assessed without testing. It can be anything from neglectible impact (under
1%) to severe performance losses (execution time increases 10 times or more, depending on scenario). Each situation
should be treated as a separate case, there is no general solution for all these statements.

3. How to investigate?

The problematic statements have to be checked. Using dbms_monitor tracing (or the 10046 event), the execution plan
should be generated and investigated. The plans should be compared to the same statement plan generated without
column encryption. If there are no execution plan changes but the CPU usage increases dramatically, then it is very likely
this is caused by the encryption overhead.

4. What to do to alleviate the performance of the execution plans?

4.1 If noticing execution plans changes, these situations should be submitted to Oracle Support for additional checks.
4.2 Check if the columns used in the predicates and joins of the statements are encrypted with SALT. Try encrypting these
columns with NO SALT, as it generally should provide better performance.

4.3 For tablespace encryption and full table scan operations:

4.3.1. if a table is very large and queried mostly with full table scan operations, consider not storing it in an encrypted
tablespace but use column encryption and encrypt just the sensitive columns.
4.3.2. if a table is not very large, queried mostly with full table scan operations and must reside in an encrypted
tablespace, consider the possibility of keeping it as much as possible in the buffer cache by enabling the keep buffer pool
and setting the table to use it. This way, only part of the blocks in the table would be read from disk and decrypted,
reducing significantly the decryption overhead.
4.3.3. consider the possibility of building aggregate materialized views on such the large tables residing in encrypted
tablespaces. This way, the final data would reach in a faster way the end user.
4.3.4. the degree of parallelism and the number and power of the CPU is also an important factor that can reduce the time
taken for a full table scan. Consider increasing the degree of parallelism for these problematic tables.
4.3.5. if the queries are not using aggregate functions and yet returning a small amount of records, then indexes would
likely help. The statements should be tuned and indexes added as needed on the tables.

REFERENCES

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=1d90zqy4dn_52&id=1303412.1 2/3
10/14/2019 Document 1303412.1

NOTE:1365021.1 - How To Benefit From Hardware Acceleration for Tablespace Encryption?

NOTE:454980.1 - Best Practices For Having Indexes On Encrypted Columns Using TDE Column encryption.

Didn't find what you are looking for?

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=1d90zqy4dn_52&id=1303412.1 3/3