The default – or at least a very common - configuration for Exadata is to configure all the flash as Exadata Smart Flash Cache (ESFC). This is a simple and generally performant configuration, but won’t be the best choice for all cases. In particular, if you have table which is performance critical, and it could fit in the flash storage you have available, you might be better off configuring some of your flash as grid disk, creating an ASM disk group from that, and putting the table there.
Here’s the procedure:
1. Drop the flash cache, create a new flashcache of a smaller size, then create the griddisks from the unallocated space. These CELLCLI commands do that:
CellCLI> drop flashcache
Flash cache exa1cel01_FLASHCACHE successfully dropped
CellCLI> create flashcache all size=288g
Flash cache exa1cel01_FLASHCACHE successfully created
CellCLI> create griddisk all flashdisk prefix=ssddisk
There’s 384G of flash on each storage cell, so the above commands create about 96G of SSD grid disk. Run those commands on each cell node, perhaps by using the CCLI command (see this post for an example).
2. The above procedure will create disks in the format o/cellIpAddress/ssddisk_FD_*_cellnode. Log into an ASM instance, and issue the following command to create a diskgroup from those disks:
1 create diskgroup DATA_SSD normal redundancy disk 'o/*/ssddisk*'
2 attribute 'compatible.rdbms'='188.8.131.52.0',
Alternatively you can use the database control for the ASM instance to create the new diskgroup. Your new flash disks should show up as candidate disks.
The relative performance of flash disks, vs flash cache is similar in Exadata to what I’ve seen using the Database flash cache. Placing an object directly on flash is faster than using the cache, although the cache is very effective. Here’s the results for 200,000 primary key lookups across 1,000,000 possible primary keys: