Databases Reference
In-Depth Information
[oracle@cm01dbm01 ~]$ dcli -g ./cell_group cellcli -e create flashcache all
cm01cel01: Flash cache cm01cel01_FLASHCACHE successfully created
cm01cel02: Flash cache cm01cel02_FLASHCACHE successfully created
cm01cel03: Flash cache cm01cel03_FLASHCACHE successfully created
[oracle@cm01dbm01 ~]$
if you issue a create flashcache all statement prior to creating your SFl storage, exadata will allocate all of
the pCi flash storage for SFC and leave none for SFl. For this reason, we recommend creating SFl first. When you do so,
exadata wll automatically allocate 512 mB of storage from the available pCi flash for SFl, leaving the rest unallocated for
SFC or pehaps permanent flash-based grid disk storage.
Note
You can also elect to manually size a subset of your PCI flash for SFC by specifying the size attribute. In the
following script, we are specifying to allocate 100 GB of storage for SFC:
[oracle@cm01dbm01 ~]$ dcli -g ./cell_group cellcli -e create flashcache all size=100g
cm01cel01: Flash cache cm01cel01_FLASHCACHE successfully created
cm01cel02: Flash cache cm01cel02_FLASHCACHE successfully created
cm01cel03: Flash cache cm01cel03_FLASHCACHE successfully created
[oracle@cm01dbm01 ~]$
How It Works
Smart Flash Cache and Smart Flash Logging are Exadata software features that utilize PCI flash storage to intelligently
cache data. SFC is designed to provide an extra layer of flash-based cache for data, and SFL is designed to cushion
redo log writes.
With SFL, when the storage cells receive a redo log write request, Exadata will perform a parallel write to both
the on-disk redo logs as well as a small amount of flash storage carved out from the available PCI flash storage.
When either of these writes completes successfully, the database issuing the I/O request will receive a write
acknowledgement. This design allows for Exadata to provide smooth redo log write I/O performance in the event that
either writes to permanent storage or flash storage is slow. SFL is not permanent storage; it is simply a temporary store
designed to provide fast redo log write response times.
Both SFC and SFL utilize the same PCI flash storage on each cell. SFL capacity defaults to 512 MB and is not
subject to resizing, but SFC can be configured to use any or all of the remaining storage on your flash cards. While they
use the same physical storage, SFC and SFL storage is managed (that is, dropped and created) independently.
SFC is typically configured to use all of the available flash storage above the 512 MB chunk reserved for SFL, but
the Exadata DMA can elect to only allocate a subset of available storage based on business needs. Typically, DMAs
would only limit the size of SFC when deciding to configure permanent grid disk storage on flash, as discussed in
Recipe 9-11.
SFL hasn't always existed on the Exadata storage cells; it was introduced with storage cell image 11.2.2.4.2 as a means
to provide a flash-based “cushion” for redo log write activity in situations when LGWR is unable to write redo entries to disk
(or the disk's DRAM cache) fast enough. For DML-intensive workloads, SFC can provide a high-speed storage solution to
reduce write I/O wait times. To learn more about the performance benefits of SFC, please see Recipe 18-7.
Data in Smart Flash Cache is managed automatically by the Exadata Storage Server software using a least recently
used algorithm. As the flash storage becomes full, Exadata will age lesser-used data from cache in a similar manner to
how blocks are aged from the database buffer cache. One thing that is unique about cached data in Smart Flash Cache
is that it is persistent across database instance restarts, so even if you bounce your instances, SFC will still contain
copies of cached data unless the data has been aged or SFC has been dropped.
 
 
Search WWH ::




Custom Search