What is write-back flash cache behavior?
In the Exadata ecosystem, the Smart Flash Cache can operate in two modes: Write-Through and Write-Back. While Write-Through is the safer, more conservative default, Write-Back is the high-performance configuration that transforms Exadata into an OLTP powerhouse.
Here is a deep dive into how Write-Back behavior works and why it is a game-changer for write-intensive workloads.
To understand Write-Back, you first have to look at how a standard write works:
Write-Through (The Default): When the database writes a data block, it must be written to the Hard Disk before the storage cell sends an acknowledgment. The Flash Cache is only used to speed up reads.
Write-Back: The data block is written directly to the NVMe Flash. The storage cell acknowledges the write as soon as it hits the Flash. The data is "destaged" (moved) to the slower hard disks later, in the background.
Hard drives are slow—they have moving parts and high seek latency. Flash is fast. By using Write-Back mode, you effectively remove the physical disk latency from the database's write path.
Key Benefits:
Reduced "Free Buffer Waits": The database can clear its memory buffers much faster because the storage is swallowing the writes at flash speeds.
Massive IOPS: Write-Back allows for significantly higher write throughput, which is essential for heavy batch loads, massive updates, or high-concurrency OLTP.
Eliminating Disk Spikes: Because the storage cell manages the "destaging" to disk, it can smooth out bursts of I/O activity, preventing the database from feeling the impact of a saturated physical disk.
A common concern with write-back caching is: "What if the flash fails before the data is moved to the disk?"
Exadata handles this with extreme redundancy:
Non-Volatile Flash: Data is written to NVMe flash, which is persistent (it doesn't disappear if the power goes out).
Double/Triple Mirroring: When a write happens in Write-Back mode, the block is mirrored to the flash on different storage cells.
Dirty Block Tracking: The storage software keeps track of "dirty" blocks (blocks in flash that haven't been written to disk yet). If a storage cell fails, the mirrored copy on another cell ensures no data is lost.
The move from Flash to Disk (Destaging) happens automatically. The storage cell monitors its flash capacity and disk activity:
Trickle Destage: When the system is quiet, the cell slowly moves dirty blocks to the hard disks.
High-Priority Destage: If the Flash Cache starts getting full, the cell aggressively pushes data to the disks to make room for new incoming writes.
While Write-Back provides a massive performance boost, it isn't always necessary.
| Use Case | Recommended Mode |
| Read-Heavy Data Warehouse | Write-Through (Disk writes are rare). |
| High-Volume OLTP | Write-Back (Critical for write performance). |
| Batch Processing / ETL | Write-Back (Significantly reduces load times). |
| Extreme Flash (EF) Cells | Always Write-Back (Everything is flash anyway!). |
You can check if your storage cells are in Write-Back mode using CellCLI:
# Run this on a storage cell
CellCLI> LIST CELL ATTRIBUTES flashCacheMode
If it returns WriteThrough, and your database is suffering from "db file parallel write" or "write complete waits," a move to Write-Back might be your best performance tuning move.
Write-Back Flash Cache essentially turns your Flash into a high-speed buffer for your disks. It allows the database to perform at the speed of light (Flash) while still benefiting from the massive capacity and lower cost of hard drives.