Upgrade encrypted databases to 26ai

Encryption and Compression in Exadata: How It Really Works

After a great vacation, I'm finally back with a new blog post. This one is about two weeks later than my usual Thursday schedule, but I hope you'll find it worth the wait.

Today's topic is a question that comes up surprisingly often: how do compression and Transparent Data Encryption (TDE) actually work in Oracle Exadata? The answer is actually quite simple - with one important exception.

Everything described here applies equally to Oracle Exadata and all of its deployment models, including ExaDB-C@C, ADB-C@C, ADB-D, and ExaDB-D, whether deployed on-premises, in OCI, or in supported third-party clouds.

The Normal Data Path

The fundamental rule is simple:

Compression always happens before encryption.

This has to be the case because encrypted data is essentially random and therefore cannot be compressed efficiently. Oracle's implementation of TDE tablespace encryption is fully compatible with Oracle compression technologies, including Exadata Hybrid Columnar Compression (EHCC), by compressing data before encrypting it.

For normal database reads and writes, all compression, decompression, encryption, and decryption are performed by the Exadata Database Servers (compute nodes).

The Exadata Storage Servers simply store and return encrypted database blocks.

The processing flow looks like this:

Writes

On the Database Server:

1. Compress the data.
2. Encrypt the compressed data.
3. Write the encrypted blocks to the Storage Servers.

Reads

On the Database Server:

1. Read the encrypted blocks from the Storage Servers.
2. Decrypt the blocks.
3. Decompress the data.
4. Return the data to the application.

In other words, during conventional database I/O, all crypto and compression work is handled by the Database Servers.

The Smart Scan Exception

The only exception occurs when the Oracle optimizer chooses an Exadata Smart Scan, typically during eligible full table scans.

In this case, Exadata moves part of the work to the Storage Servers:

1. The Storage Servers decrypt the encrypted data.
2. Smart Scan performs predicate filtering and column projection on the Storage Servers.
3. Only the required rows and columns are returned to the Database Servers.
4. The Database Servers complete the remaining processing before returning the results to the application.

This is one of the reasons Smart Scan is so effective: instead of transferring entire encrypted database blocks across the InfiniBand or RoCE network, only the data that actually satisfies the SQL query is sent back to the Database Servers.

Hardware Acceleration

Another point that is sometimes overlooked is hardware acceleration.

Both the Exadata Database Servers and the Exadata Storage Servers use processors with hardware cryptographic instructions (such as Intel AES-NI or their equivalents on other processor architectures). Oracle Transparent Data Encryption automatically leverages these capabilities whenever they are available, significantly reducing the CPU cost of encryption and decryption.

In other words, encryption is not only offloaded architecturally where appropriate - it is also accelerated at the processor level.

The Bottom Line

The architecture is remarkably straightforward:

Normal database I/O

• Database Server: Compress → Encrypt → Write
• Database Server: Read → Decrypt → Decompress → Return to the application

Smart Scan

• Storage Server: Decrypt → Smart Scan filtering and projection
• Database Server: Complete processing and return the results

Keeping these two execution paths separate makes it much easier to understand how Exadata combines compression, Transparent Data Encryption, and Smart Scan without sacrificing either performance or security.

If you've ever wondered why encrypted databases on Exadata still deliver outstanding Smart Scan performance, this separation of responsibilities between the Database Servers and the Storage Servers is a big part of the answer.