This document discusses solid state disk (SSD) technologies and how they can improve performance in Oracle databases. It provides an overview of traditional hard disk drives and how SSDs address limitations in seek time and throughput. SSD performance, economics, and flash memory concepts are explained. The document focuses on Oracle's 11gR2 database flash cache architecture, which uses idle CPU cycles to cache hot database blocks to flash to reduce physical read I/O. Performance comparisons show reductions in read latency and write complete waits with the flash cache enabled. Recommendations include using SSDs for small read-heavy tablespaces and enabling the database flash cache.
3. Agenda Recap of Traditional Disk drive technologies Solid State Disk (SSD) technologies SSD performance SSD economics Flash SSD Write IO Oracle DB flash cache architecture Performance comparisons
7. Moore’s law Transistor density doubles every 18 months Exponential growth is observed in most electronic components: CPU clock speeds RAM Hard Disk Drive storage density But not in mechanical components Service time (Seek latency) – limited by actuator arm speed and disk circumference Throughput (rotational latency) – limited by speed of rotation, circumference and data density
13. Flash Technology concepts Storage Hierarchy: Cell: One (SLC) or Two (MLC) bits Page: Typically 4K Block: Typically 128-512K Writes: Read and first write require single page IO Overwriting a page requires an erase & overwrite of the block Wear endurance: 100,000 cycles for SLC before failure 5,000 – 10,000 cycles for MLC
16. “Write Amplification” measures the efficiency of this algorithm“Wear Levelling” ensures that writes are evenly spread across the drive The TRIM API allows OS to invoke cleanup on file delete Some SSD have extra blocks for write optimization You want an SSD with SLC, TRIM (?) and low write amplification
17. Oracle DB flash cache Introduced in 11GR2 for OEL and Solaris only OEL patch 8974084 Secondary cache maintained by the DBWR, but only when idle cycles permit Architecture is tolerant of poor flash write performance
26. Write complete waits Flash cache architecture avoids ‘free buffer waits’ due to flash IO, but write complete waits can still occur on hot blocks. Free buffer waits are still likely against the database files, due to high physical read rates created by the flash cache
27. Recommendations Consider a hierarchy of storage – memory, flash, disk, tape (don’t wait for SSD “Nirvana”) Use SLC flash SSD with low write amplification. Consider flash SSD datafiles for small tablespaces especially read only. Partitioning a large table might allow more frequently accessed data to reside on flash Consider db flash cache to reduce read IO for large tablespaces (OEL/Solaris only).
31. References Guy Harrison blog (guyharrison.net) postings: http://bit.ly/6yKhlh http://bit.ly/6mrX3k http://bit.ly/dmTFYh Kevin Closson: http://kevinclosson.wordpress.com/2009/12/15/pardon-me-where-is-that-flash-cache-part-ii/ General articles on SSD: http://www.anandtech.com/storage/showdoc.aspx?i=3631 http://en.wikipedia.org/wiki/Flash_memory
Editor's Notes
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.