Update 7-October-2011: the log write caching capability has been officially announced as “Exadata Smart Flash Log”. I saw a few Oracle product management slides at OpenWorld presentations; one slide deck online is here on slide 30. A sample graph is provided, showing how the peak response times drop significantly with the additional cache.
These peaks would correspond to the times when the controller RAM cache is full. Another feature of the cache is that it returns write success status to the database when either flash or disk controller acknowledge the write, meaning tat the flash memory functions as a type of upper bound to redo write latency.
Exadata storage server software version 11.2.2.4.0 (patch link) has just been released. The readme file (My Oracle Support login required) lists 218 different changes, but one in particular sticks out:
11781936 NEED SMART FLASH LOGGING OF RDBMS REDO
I have confirmed that this means that redo write caching is now available in Exadata storage servers. This can bring a huge boost to redo-intensive OLTP applications, especially when the small 512mb controller cache on the storage servers fills up during periods of heavy utilization.
Another change that may have impacts during an upgrade:
12563439 CELLMONITOR USER IS NOT RESTRICTED TO RUNNING CELLCLI
If you’re using the cellmonitor OS user run commands other than a plain cellcli, this may stop working on upgrade. This would happen if custom scripts were built to do additional monitoring that’s not part of cellcli.
The patch includes a new version of the OFED InfiniBand drivers, so those applying the patch to storage servers should also apply the included minimal pack to database servers as well, to keep driver versions consistent.
7 Comments. Leave new
[…] Why should I store redo logs in flash memory Traditional enterprise storage infrastructure uses battery-backed memory caches to buffer writes, significantly improving commit latency for Oracle databases. Since ODA doesn’t have such a cache, it uses flash memory for this purpose instead. (As of version 11.2.2.4.0, Exadata does this too) […]
Good to see this as enhancement ! I am keeping my eye on Pythian to provide test results to witness performance improvements. I guess my EBS (11gr2) could be a prime beneficiary as concurrent inserts by more than 1200 processes is causing huge commit latencies in my prod db. (‘log file sync’ is > 60 ms!)
Hello, does it means redo writes on flash storage are supported ?
I thought that flash storage hadn’t a real efficiency for sequential writes, how do you feel about that (and Oracle) ?
@Cedric: redo writes are now cached in the flash cache in write-back mode.
When compared to magnetic disks, sequential writes aren’t as proportionally faster as random reads. However they’re much more consistent: you don’t see the great variability in response times that occurs when disks are busy and the RAM buffer is full.
“I have confirmed that this means that write-back write caching is now available in Exadata storage servers.”
This is not correct. Exadata Smart Flash Log works like this: Writes are sent to both flash and disk, the write completes (as seen from the db) when the first one returns. This *is not* the same as write-back caching.
Thanks Greg. I briefly mentioned the “un-write-back” acknowledgement behavior in the 7-October update, but hadn’t revised the original post. This has now been corrected.
Thanks for finally talking about >Exadata Smart Flash Cache now
Supports Redo Writes <Liked it!