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:

 
What We're Trying to Prove
When customers deploy a new Exadata Database Machine, it will come pre-seeded with RAC-enabled database on ASM storage spanning the Exadata storage cells. This is one by Oracle's ACS group during the installation, and we at Centroid worked alongside Oracle to build our configuration to meet the specs in our configuration template.

 

With Oracle Exadata, what SQL statements actually are eligible for offload processing? If you've found yourself puzzled by the documentation, test results or not quite putting two and two together, this post attempts to define and prove what types of SQL statements truly are eligible for offload processing, and measure results.

 

As documented, parallel query operations are offload eligible with Exadata Database Machine. Let's put this to the test.

 

With Exadata Smart Scan processing, Exadata is capable of offloading a large portion of a query's workload to the storage cells. Many claims exists out there that recommend "migrate to Exadata and drop all your indexes", but let's see how Smart Scan processing works with various types of index access through a series of tests.