How does Exadata offload SQL processing to storage?
In a traditional database architecture, the storage layer is "passive"—it simply fetches blocks of data and sends them over the network to the database server. When you run a query on a multi-terabyte table, the network becomes a massive bottleneck.
Exadata Smart Scan changes this by making the storage "active." Instead of moving all the data to the query, Exadata moves the query logic to the data. This is known as SQL Offloading.
When the Oracle Database decides a query would benefit from offloading, it issues a Smart Scan. Instead of requesting specific blocks, the database sends a description of the SQL command to the storage cells.
The storage cells then perform two primary types of filtering before sending a single byte back to the database server:
Most tables have dozens or hundreds of columns, but a typical query might only need two or three (e.g., SELECT name, balance...).
Traditional SAN: Sends the entire row (all columns) back to the DB.
Exadata: The storage cell strips away the unneeded columns and only sends the requested ones.
This is where the real magic happens. If your query includes a WHERE clause (e.g., WHERE region = 'WEST'), the storage cell evaluates that condition directly against the data on the disk.
Traditional SAN: Sends every row in the table to the DB server, where the DB discards the ones that don't match.
Exadata: The storage cell discards the non-matching rows immediately. Only the "rows of interest" ever travel across the network.
Offloading is supercharged by HCC. Because Exadata storage "understands" the database format, it can decompress data directly on the storage cell CPUs.
Since the data is compressed (often 10x to 50x), the storage cell can scan through massive amounts of data with very little physical disk I/O. It decompresses the data in memory, filters it, and sends only the small result set back to the database server.
Before the storage cell even starts a Smart Scan, it consults the Storage Index (the memory-resident Min/Max metadata we discussed earlier). If the Storage Index shows that a 1MB chunk of data cannot possibly contain the values requested in the WHERE clause, the cell skips that chunk entirely. This avoids unnecessary I/O altogether.
To visualize the impact, imagine a 10TB table scan:
Traditional Architecture: 10TB of data must travel over the fiber channel network. Even at 10GB/s, this takes over 15 minutes and consumes massive DB server CPU to process.
Exadata Architecture: The storage cells scan the 10TB locally. They filter it down to, say, 100MB of relevant results. Only that 100MB travels over the 100Gbps RoCE network. The query completes in seconds.
| Feature | Function in Storage Cell |
| Predicate Filtering | Evaluates WHERE clauses to drop irrelevant rows. |
| Column Projection | Only sends back the SELECT columns you asked for. |
| Join Offloading | Uses Bloom Filters to filter "Fact" tables during joins. |
| Decryption/Decompression | Handles security and HCC logic at the storage level. |
You can verify SQL offloading in your execution plan. Look for the operation STORAGE SELECT STATEMENT or check the session statistics for "cell physical IO bytes eligible for predicate offload."
SELECT name, value/1024/1024/1024 AS GB
FROM v$statname n, v$sesstat s
WHERE n.statistic# = s.statistic#
AND n.name = 'cell physical IO bytes saved by storage index';