Oracle publishes that Exadata IO works best with a 4MB allocation unit size for ASM disk groups, so ASM disk groups should be created with AU_SIZE=4M.  Further, Oracle also recommends that segment extents sizes should be a multiple of 4Mb if they’re to be accessed via Smart Scan. Here, we’ll attempt to demonstrate why this is the case.


We had quite a bit of discussion about where our extents resided on our Exadata Grid Disks.  The question was posed – if Exadata farms out IO requests to each cell in our storage grid, how does it know which extents reside on which disks? How do these get placed on grid disks, and is Exadata intelligent enough to know exactly where to look for the extents or will it simply search for matching extents regardless and allow the result set to determine where the data resides?


The “_small_table_threshold” setting controls a few cell offload functions, such as what types of tables will qualify for caching in Smart Flash Cache.  Here, I’ll try to reason out why it defaults to what it does and what the impact is of changing it for various Exadata features.

In one of recent tests demonstrating Smart Scan processing, we did a full-scan on a 4Gb table and returned all columns, all rows, blanketed by a “select count(*)”.  Over 4 Gb were eligible for predicate offload, but only 2 Gb was actually returned over the InfiniBand interconnect.  In this section I’ll attempt to show why.


Those familiar with Exadata know that both row filtering and column filtering occurs with Smart Scan cell offload operations.  Both techniques limit the number of bytes returned from the Exadata storage servers over the InfiniBand interconnect to the compute servers.  Here, we’ll explore the impact of column filtering.

With Oracle Exadata, CELLCLI is the command-line interface to manage, monitor, and report on storage cell characteristics, configuration, and behavior.
The simple answer is no, unless you’ve got a shared file-system on which to put your dump and log files.


An active request represents a "client" or application-centric view of I/O requests being processed by the cell. Similar to previous sections, the graphic below shows the detail associated with Active Request monitoring.

Alerts indicate warning, critical, clear, and informational messages about operations within a cell.


In this post, we'll show you how to resize your Exadata storage cell Grid Disks and the ASM disk groups that reside on them. We'll assume we've a storage environment comprised of different ASM disk groups for different application and database purposes, and further, different Grid Disks to support these ASM disk group requirements. Let's imagine we want to re-baseline and resize everything.