This topic described how the Exadata Smart Flash Cache works in conjunction with Oracle Data Guard standby databases and outlines various methods for preparing Exadata Smart Flash Cache to handle the workload after a switchover or failover to the standby database.

Caching Write Data

Write data is data that is inserted or updated in the database. When primary database blocks are modified or updated, the changes are recorded in the redo log and the data may be read into Exadata Smart Flash Cache (if it is not already there) or updated within Exadata Smart Flash Cache (if it already resides in the cache).

When the redo log entries are applied to a standby database, the changes are applied to the standby database files, and the changes may also be read into or updated in Exadata Smart Flash Cache on the standby database.

So, for write data, Exadata Smart Flash Cache automatically caches the hottest data on the primary and standby databases.

Caching Read Data

Read data is data that is read from the database. On Exadata primary databases, the most active read data is automatically cached in Exadata Smart Flash Cache. However, unlike write data, some read data cannot be propagated to the standby database.

The remainder of this topic describes different approaches available for managing Exadata Smart Flash Cache on standby databases to best handle the workload after an Oracle Data Guard role transition (switchover or failover).

Caching Read Data with Active Data Guard

Queries executed on an open read-only Active Data Guard standby database interact with Exadata Smart Flash Cache. So, just like a primary database, the most active read data is automatically cached in Exadata Smart Flash Cache for all queries run on an Active Data Guard standby database. This approach handles reads into the database buffer cache and reads associated with Exadata Smart Scan. It also ensures that the columnar cache and storage index are actively maintained on the standby database.

Using Active Data Guard to maintain Exadata Smart Flash Cache on the standby database is a simple and effective option in situations where you can replay the application query workload on the standby database.

Caching Read Data Through the Database Buffer Cache

You can enable the lost write detection feature in Oracle Database in conjunction with an Oracle Data Guard physical standby database to generate and apply redo records for blocks read into the primary database buffer cache. The primary purpose of these redo records is to protect against lost writes. However, when the redo records are applied to the standby database, Exadata Smart Flash Cache automatically caches to hottest data, which effectively keeps the standby cache synchronized with the primary cache for the corresponding data.

The capability handles data that is read into the database buffer cache, which is sometimes referred to as OLTP read data. However, reads associated with Exadata Smart Scan bypass the buffer cache and therefore cannot be tracked using lost write detection.

You can enable lost write detection by setting the db_lost_write_protect database parameter to AUTO, TYPICAL, or FULL. See DB_LOST_WRITE_PROTECT in Oracle Database - Database Reference.

Lost write detection generates additional I/O on both the primary and standby databases. However, the impact is minimal, and enabling lost write detection is generally recommended in conjunction with Oracle Data Guard. See Configure and Deploy Oracle Data Guard in Oracle Database - High Availability Overview and Best Practices. Starting with Oracle Database release 19.26, the default value for db_lost_write_protect is AUTO.

Loading the Cache After an Oracle Data Guard Role Transition

In addition to the aforementioned approaches, you can use various techniques to manually load Exadata Smart Flash Cache after an Oracle Data Guard role transition (switchover or failover). This approach enables you to proactively warm the cache after a standby database is converted to run the primary workload.

See Manually Populating Exadata Smart Flash Cache.