Yes, it’s a mouthful, and yes, it sounds like something you already know about. But let’s go through it just in case you were thinking about something else.
Exadata 20.1 (hint: pronounce it “twenty-dot-one”, not “twenty-one”, you’ll realize why in about 6 months ;) ) released June 2020, added features under the areas of smarter infrastructure, improved performance and smarter management. If you haven’t read up on it, I recommend reading our Exadata 20.1 Release blog post or watching Kodi’s webcast.
One feature, new in twenty-dot-one, is the Exadata Smart Flash Log Write-Back, not to be confused with Exadata Smart Flash Log, which is the precursor to this new feature... actually, let’s look back at Smart Flash Log so we can see the enhancement that Smart Flash Log Write-Back brings.
If we look at our documentation for Smart Flash Log:
“The goal of the Oracle Exadata Smart Flash Log is to perform redo write operations simultaneously to both flash memory and disk, and complete the write operation when the first of the two completes.”
Basically, writing to disk is too slow on its own, writing to flash can sometimes have a hiccup, so let’s write the redo log in two places, fastest to complete wins. The effect being that performance outliers are eliminated, and the database goes faster. You may remember seeing graphics like this one showing the benefits of Smart Flash Log:
Smart Flash Log is a fantastic performance enhancing feature that continues to provide reduced response times and removes performance outliers (check your “log file parallel write” and “log file sync” metrics in AWR).. It uses practically no flash capacity (<0.1%) and is completely automatic and transparent. It’s uniquely Exadata, as legacy storage IO cannot differentiate redo log IO from others, so we’re in a pretty good situation here.
So, isn’t this enough? We’ve increased performance, reduced unpredictability, why wouldn’t we stop there?
This is Exadata, that’s why. The endless quest for the best database platform.
Even though Exadata Smart Flash Log prevents the occasional log write outlier, and increases the average redo log write performance, the total log write throughput is still bound by the hard drives (in a HC Storage Server), as all redo log entries must eventually be written to the hard drives for persistence. Therefore, if the disk IO bandwidth is saturated (either because of high-volume redo log activity, or other IO intensive activities like Golden Gate log mining, log archiving, or RMAN backup/restore), log writes may experience a performance bottleneck.
Enter Exadata Smart Flash Log Write-Back.
Let’s look at the documentation for this new feature:
“To increase log write throughput in high performance database workloads, redo log writes to hard drives are now automatically and transparently stored using Exadata Smart Flash Cache in Write-Back mode on High Capacity Exadata Storage Servers. Freeing up hard disk drive resources for I/O intensive activities such as GoldenGate log mining, log archiving, and RMAN backup and restore. Depending on system workload, up to 2.5x improvement in log write throughput can be achieved”.
Hmm, sounds like the very definition of the Smart Flash Log Write-Back is the exact gap that Smart Flash Log couldn’t overcome. Fancy that.
(Just as an aside, if you’re not familiar with the terms Write-Back and Write-Through. They are the two ways you can configure the Flash Cache in Exadata for data transactions. “Write-Through” cache reads IOs from the Flash Cache, but writes through to disk, while with Write-Back cache, both reads and writes are cached in the Flash Cache, boosting performance.)
Now, as of Exadata 20.1, if you’re running your databases in ARCHIVELOG mode, with Write-Back enabled on your X7 (or above) HC Storage Servers’ Smart Flash Cache, you’ll automatically be using Smart Flash Log Write-Back.
But how do you tell? It is transparent and automatic after all, so how do you know you’re using it?
AWR is the easiest place to see it in action. (Remember Cecilia's advice?)
Flash Cache Redo Caching - If you look at an AWR report from previous Exadata versions, and again after 20.1, you’ll notice an additional section, Flash Cache Redo Caching, built specifically for this new feature. Here’s a screenshot from a 20.1 AWR report:
As you can see, in this section of the report you’ll see the Total, plus the individual storage server statistics of Write Requests and Write MBs for Redo Log in Flash Cache.
Flash Log - is another section that’s been enhanced for Flash Log Write-Back, again, here’s a screenshot:
You can see highlighted here, FC Writes and Skips are new columns within the Flash Log table in the AWR Report, showing the number of Writes to Flash Cache from the Redo Log.
Finally, if you’re running a multi-database environment with heavy redo generation workload, have a look at your AWR Report before and after the Exadata 20.1 update. You should see an improvement in the redo size metric in the Key Instance Activity Stat section.
A few other details on Smart Flash Log Write-Back to cover before we finish up today:
There you have it. Now you know what Exadata Smart Flash Log Write-Back is, it may not roll off the tongue too well, but it's just another example of why Exadata is more than the sum of its parts, software plus hardware = engineered for excellence.
We are always interested in your feedback, you are welcome to engage with us via comments here or reach me by twitter @GavinAtHQ.