0 
0 I noticed yesterday a new feature that could have the potential to be a small, by me unnoticed, gem called "Flash Cache". I hope someone on the internet, that has tested it, will post his or hers experiences on this…
While using DBMS_METADATA:
select dbms_metadata.get_ddl('TABLE','MYDATA', user) from dual;
DBMS_METADATA.GET_DDL(‘TABLE’,’MYDATA’,USER)
——————————————————————————–
CREATE TABLE "XMLDB_USER"."MYDATA"
( "ID" NUMBER(9,0),
"DOC" "SYS"."XMLTYPE"
) SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS NOLOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT
FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT)
TABLESPACE "XML_DATA"
XMLTYPE COLUMN "DOC" STORE AS SECUREFILE BINARY XML (
TABLESPACE "XML_DATA" ENABLE STORAGE IN ROW CHUNK 8192
NOCACHE NOLOGGING NOCOMPRESS KEEP_DUPLICATES
STORAGE(INITIAL 106496 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 BUFFER_POOL DEFAULT
FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT
))
XMLSCHEMA "http://www.myserver.com/MySchema.xsd" ELEMENT "ROOT"
DISALLOW NONSCHEMA
So I looked it up in the 11gR2 manuals:
storage_clause
STORAGE
({ INITIAL size_clause
| NEXT size_clause
| MINEXTENTS integer
| MAXEXTENTS { integer | UNLIMITED }
| maxsize_clause
| PCTINCREASE integer
| FREELISTS integer
| FREELIST GROUPS integer
| OPTIMAL [ size_clause | NULL ]
| BUFFER_POOL { KEEP | RECYCLE | DEFAULT }
| FLASH_CACHE { KEEP | NONE| DEFAULT }
…and via a search on the docs it says:
FLASH_CACHE
The FLASH_CACHE clause lets you specify how buffers for a schema object are to be cached in flash memory. In order to use this clause, a database flash cache must be enabled on your system. A flash cache is an extension of the database buffer cache that lives on a flash disk, which is a solid state storage device that uses flash memory.
- Without flash cache, the database re-uses each clean buffer in main memory as needed, overwriting it. If the overwritten buffer is needed later, then the database must read it from magnetic disk.
- With flash cache, the database can write the body of a clean buffer to the flash cache, enabling reuse of its main memory buffer. The database keeps the buffer header in an LRU list in main memory to track the state and location of the buffer body in the flash cache. If this buffer is needed later, then the database can read it from the flash cache instead of from magnetic disk.
KEEP
Specify KEEP if you want buffers to be written to the flash cache when they are aged out of main memory, and remain in the flash cache as long as the flash cache size is large enough.NONE
Specify NONE if you want buffers to be discarded and re-used when they are aged out of main memory. These buffers will not be put on the flash cache. This is the behavior if flash cache is not enabled on your system.DEFAULT
Specify DEFAULT if you want buffers to be written to the flash cache when they are aged out of main memory, and then be aged out of the flash cache with the standard LRU algorithm. This is the default if flash cache is enabled and you do not specify KEEP or NONE.
When to Configure Flash Cache (Database Administrators Guide 11gR2)
Consider adding flash cache when all of the following are true:
The Buffer Pool Advisory section of your Automatic Workload Repository (AWR) report or STATSPACK report indicates that doubling the size of the buffer cache would be beneficial.
dbfilesequentialreadis a top wait event.You have spare CPU.
…on the database parameter side:
SQL> show parameter flash
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_flash_cache_file string
db_flash_cache_size big integer 0
db_flash_cache_file
Specifies the path and file name for the file to contain flash cache, in either the operating system file system or an Oracle Automatic Storage Management disk group. If the file does not exist, the database creates it during startup. The file must reside on a flash disk. If you configure flash cache on a disk drive (spindle), performance may suffer.
The following is an example of a valid value for db_flash_cache_file: /dev/fioa1
db_flash_cache_size
Specifies the size of the flash cache. Must be less than or equal to the physical memory size of the flash disk device. Expressed as nG, indicating the number of gigabytes (GB). For example, to specify a 16 GB flash cache, set db_flash_cache_size to 16G.
You can use ALTER SYSTEM to set db_flash_cache_size to zero to disable flash cache. You can also use ALTER SYSTEM to set flash cache back to its original size to reenable it. However, dynamically changing the size of the flash cache is not supported.
Interesting indeed. I only need a server that has this hardware so I could test its effect…
😎
Related posts:
Oracle 11g Release 2 New Features Oracle Database 11g Release 2: Flash Cache and Exadata V2 
Introducing Oracle 11gR2 Edition Based Redefinition or: On Parallel Application Universes 
Cloud Control: How a Camel can make you cross a Data Guard Mountain 
A Short Note on Pesky CSSCAN Results Before a Characterset Change
http://blogs.sun.com/BestPerf/entry/oracle_flash_cache_sga_caching
The announcement of today explains it (Oracle Sun Exadata V2 machine), it probably will be exclusive to Exadata setup’s, just like columnar compression techniques.
This feature is not supported on current Linux release. You will get an error on trying to start database with flashcache size set.
“On the AMIS Technology Blog, Marco Gralike writes, ‘I noticed yesterday a new feature that could have the potential […]”
Log Buffer #160
Interresting, it really would be great to find some test results of this feature using actual flash hardware !