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.

 

Oracle allows you to configure "Flash-Based Grid Disks" from the PCIe flash cards that reside in each Exadata storage cell. This allows you to create ASM disk groups on flash storage and in theory, should yield solid-state performance gains for the segments residing in these ASM disk groups.

 

Oracle recommends a 4MB ASM allocation unit (AU) size for its ASM disk groups. In this post, we'll explore test cases with different ASM disk group AU sizes. Let's create some tablespaces to match our testing requirements:

 

In this post we'll perform tests for full-scanning a table when it's stored in an ASM disk group with CELL.SMART_SCAN_CAPABLE=FALSE and compare with the same table stored in a tablespace residing on an ASM disk group with CELL.SMART_SCAN_CAPABLE=TRUE. Let's create an ASM disk group to match this requirement: