Exadata is Oracle’s flagship engineered system — purpose-built hardware and software, Smart Scans offloading query processing to storage cells, Hybrid Columnar Compression reducing storage requirements dramatically, InfiniBand connecting database and storage nodes at extremely low latency. On paper, it’s the most powerful Oracle Database platform available. On OCI, it’s available as a fully managed cloud service that lets you provision an Exadata environment without buying a single piece of hardware.

I’ve worked with several customers who moved to Exadata Cloud Service (ExaCS) in the last two years. Here’s what I wish someone had told them before they started.

The Smart Scan Gotcha That Ruins Your First Benchmark

The signature feature of Exadata is Smart Scan — the ability to offload full table scans to the storage cells, dramatically accelerating analytical queries. But Smart Scan doesn’t activate automatically. It activates only under specific conditions, and if your workload doesn’t meet those conditions, you’re running a very expensive Oracle Database without the headline feature.

Smart Scan requires:

• Full table scan or index fast full scan (no index range scans)
• Direct path read (bypasses buffer cache)
• The segment must be stored on Exadata cells (not all storage is eligible)
• Session parameter cell_offload_processing must be enabled (it’s on by default)

The most common reason I see Smart Scan not activating: the table fits in the buffer cache. If Oracle can satisfy the full scan from buffer cache, it uses buffer cache reads instead of direct path reads, and Smart Scan doesn’t trigger. For data warehouse workloads where tables are larger than available memory, this is rarely a problem. For OLTP workloads with frequently accessed tables that fit in cache — Smart Scan never fires.

sql

-- Check if Smart Scan is being used for your query
SELECT sql_id, physical_read_bytes, io_cell_offload_eligible_bytes,
       io_cell_offload_returned_bytes,
       ROUND(io_cell_offload_eligible_bytes / NULLIF(physical_read_bytes,0) * 100, 2) offload_pct
FROM v$sql
WHERE sql_id = '&your_sql_id';

If io_cell_offload_eligible_bytes is zero, Smart Scan was never attempted for that statement.

Hybrid Columnar Compression — Test Before You Trust

HCC (Hybrid Columnar Compression) is another Exadata headline feature. It can achieve 10x-50x compression ratios compared to standard Oracle compression. The mechanism: Oracle compresses data in column-major order within a compression unit of multiple rows. Identical or similar column values across rows compress extremely well.

The limitation that surprises people: any update to a single row within a compression unit decompresses the entire compression unit. This is by design — the compressed format doesn’t support in-place row updates. Oracle migrates the updated row out of the compression unit as a regular heap row.

For append-only data (historical data, audit tables, log data) this doesn’t matter. For frequently updated tables, HCC causes row chaining, performance degradation, and over time, space expansion that eliminates your compression benefit.

My rule: use HCC for cold data that is inserted once and read many times. Never use it on tables with significant UPDATE or DELETE activity.

sql

-- Check HCC effectiveness on a segment
SELECT column_value compressiontype,
       COUNT(*) rowcount
FROM table(dbms_compression.get_compression_ratio(
    'SCHEMA_NAME', 'TABLE_NAME', NULL, NULL))
WHERE column_value != 'No Compression'
GROUP BY column_value;

Sizing: Shape Selection Is More Important Than You Think

On ExaCS, you choose a “shape” — Quarter Rack, Half Rack, Full Rack — and each shape determines the number of database nodes and storage cells you get. The mistake I see most often: customers choose a shape based on their current database size and assume performance will scale linearly.

It doesn’t. ExaCS performance is heavily dependent on the ratio of your active data to available Smart Cache (flash storage). The Exadata storage cells have a flash cache layer that keeps hot data in flash. If your working set fits in flash cache, I/O performance is extraordinary. If your working set exceeds flash cache, you’re hitting spinning disk, and the performance profile changes completely.

Before sizing ExaCS, understand:

• Your database’s total size
• Your hot data size (the subset that’s actively queried, not just stored)
• Your peak IOPS requirements
• Your redo generation rate (this affects the database nodes, not just storage)

A Quarter Rack ExaCS can be dramatically over-specified for a 500GB OLTP database, and dramatically under-specified for a 5TB analytical database with complex queries. The database size alone tells you almost nothing about the right shape.

IORM — Exadata’s I/O Resource Manager

ExaCS introduces a concept that doesn’t exist on regular Oracle: I/O Resource Manager (IORM). Since multiple databases share the same storage cells, you can prioritize I/O at the storage cell level — not just CPU at the database level.

sql

-- Check current IORM plan
SELECT name, status FROM v$iorm_plan;
-- View database I/O categories
SELECT dbname, share, allocation, limit
FROM v$dbreplay_client_ipd;

If you’re running multiple databases on the same ExaCS infrastructure (which is common — it’s one of the cost justifications for ExaCS), configure IORM to protect your production databases from being I/O-starved by a runaway batch job on a dev database sharing the same cells.

This is a layer of resource management that most DBAs who come from single-database Exadata environments have never touched. In a shared ExaCS environment, it’s essential.

Patching on ExaCS — It’s Different

On regular Oracle Database, you apply patches to your Oracle Home. On ExaCS, the full stack needs patching: database software, Grid Infrastructure, and the Exadata storage cell software. Oracle manages the storage cell patching on the managed service. You manage the database and GI patching.

The complication: these patch levels must be compatible. You can’t apply a database patch that requires a newer storage cell software version than what’s installed on your cells. The “patch catalog” for ExaCS is more constrained than for regular Oracle installations.

Oracle provides a Patch Checker tool specifically for ExaCS to validate patch compatibility before applying. Use it. Every time.

The payoff: ExaCS patching can be done with zero downtime using rolling patch mode across RAC nodes. If you’re running a multi-node ExaCS, plan your maintenance windows around rolling patches, not outage windows.

When ExaCS Is the Right Choice

After all of this, let me be direct about where ExaCS genuinely makes sense:

• Analytical and data warehouse workloads with large table scans
• High-volume OLTP with I/O as the primary bottleneck
• Environments running multiple Oracle databases that can share infrastructure and justify the cost through consolidation
• Organizations that need Exadata’s capabilities but can’t manage hardware procurement and data center operations

Where it probably doesn’t make sense:

• Small databases (under 500GB) where regular OCI DB Systems or Autonomous Database deliver everything you need at a fraction of the cost
• Applications where Smart Scan never activates (OLTP with good buffer cache hit ratios)
• Teams without Oracle DBA expertise — ExaCS reduces hardware management overhead but it doesn’t eliminate the need for database expertise