Apologies, I’m a database type.....Quest is best known for toad, but we also have enterprise monitoring across all levels of the stackIn Melbourne, SQL Navigator + the spotlights. It’s not a complete co-incidence about the star trek theme.
The higher logical read rate overwhelms the HDD
Understanding Solid State Disk and the Oracle Database Flash Cache (older version)
Understanding Solid State Disk and the 11gR2 DB flash cache <br />Guy Harrison<br />Director R&D, Melbourne<br />www.guyharrison.net <br />
Agenda<br />Recap of Traditional Disk drive technologies<br />Solid State Disk (SSD) technologies<br />SSD performance<br />SSD economics<br />Flash SSD Write IO<br />Oracle DB flash cache architecture<br />Performance comparisons<br />
Moore’s law<br />Transistor density doubles every 18 months<br />Exponential growth is observed in most electronic components:<br />CPU clock speeds<br />RAM<br />Hard Disk Drive storage density <br />But not in mechanical components<br />Service time (Seek latency) – limited by actuator arm speed and disk circumference <br />Throughput (rotational latency) – limited by speed of rotation, circumference and data density<br />
Flash Technology concepts<br />Storage Hierarchy:<br />Cell: One (SLC) or Two (MLC) bits<br />Page: Typically 4K <br />Block: Typically 128-512K<br />Writes:<br />Read and first write require single page IO<br />Overwriting a page requires an erase & overwrite of the block<br />Wear endurance:<br />100,000 cycles for SLC before failure <br />5,000 – 10,000 cycles for MLC <br />
Flash write mitigation algorithms <br /><ul><li>Garbage collection and “cleaning” maintains free blocks for writes.
“Write Amplification” measures the efficiency of this algorithm</li></ul>“Wear Levelling” ensures that writes are evenly spread across the drive<br />The TRIM API allows OS to invoke cleanup on file delete<br />Some SSD have extra blocks for write optimization <br />You want an SSD with SLC, TRIM (?) and low write amplification<br />
Oracle DB flash cache <br />Introduced in 11GR2 for OEL and Solaris only<br />OEL patch 8974084<br />Secondary cache maintained by the DBWR, but only when idle cycles permit<br />Architecture is tolerant of poor flash write performance<br />
Write complete waits <br />Flash cache architecture avoids ‘free buffer waits’ due to flash IO, but write complete waits can still occur on hot blocks.<br />Free buffer waits are still likely against the database files, due to high physical read rates created by the flash cache<br />
Recommendations<br />Consider a hierarchy of storage – memory, flash, disk, tape (don’t wait for SSD “Nirvana”)<br />Use SLC flash SSD with low write amplification. <br />Consider flash SSD datafiles for small tablespaces especially read only. <br />Partitioning a large table might allow more frequently accessed data to reside on flash<br />Consider db flash cache to reduce read IO for large tablespaces (OEL/Solaris only). <br />