Oracle Exadata Smart Flash Cache works seamlessly with Oracle Data Guard standby databases, ensuring that both primary and standby systems benefit from caching. However, managing cache behavior during switchover or failover events requires careful planning to maintain performance.

This article explains how Exadata Smart Flash Cache handles write data, read data, and outlines methods to prepare the cache for standby workloads.

Caching Write Data

• Write data = data inserted or updated in the database.
• On the primary database, changes are recorded in redo logs and cached in Smart Flash Cache.
• On the standby database, when redo logs are applied, the same changes are cached automatically.
• ✅ Result: The hottest write data is cached on both primary and standby systems without extra configuration.

Caching Read Data

• On the primary database, frequently accessed read data is cached automatically.
• On the standby database, read data caching requires additional approaches since not all read activity is propagated.

Approach 1: Active Data Guard

• Queries executed on an open read-only Active Data Guard standby interact directly with Smart Flash Cache.
• Benefits:
  • Most active read data cached automatically.
  • Supports buffer cache reads and Smart Scan reads.
  • Maintains columnar cache and storage indexes.
• ✅ Best option when you can replay application queries on the standby database.

Command Example:

-- Run queries on Active Data Guard standby
SELECT * FROM sales WHERE region = 'APAC';

This query will populate Smart Flash Cache on the standby just like on the primary.

📊 Approach 2: Database Buffer Cache with Lost Write Detection

• Lost write detection generates redo records for blocks read into the primary buffer cache.
• When applied to the standby, this keeps Smart Flash Cache synchronized with the primary.
• Handles OLTP read data (buffer cache reads).
• Does not track Smart Scan reads (which bypass buffer cache).

Enable Lost Write Detection:

ALTER SYSTEM SET db_lost_write_protect = AUTO;
-- or
ALTER SYSTEM SET db_lost_write_protect = TYPICAL;
ALTER SYSTEM SET db_lost_write_protect = FULL;

Starting with Oracle Database 19.26, the default is AUTO.

📊 Approach 3: Loading Cache After Role Transition

• After a switchover or failover, you can manually warm the cache on the new primary.
• Techniques include:
  • Running full table scans or parallel queries to populate cache.
  • Using INDEX FAST FULL SCAN to load index blocks.
  • Applying CELL_FLASH_CACHE KEEP to force caching of critical segments.

Command Examples:

-- Force caching a table
ALTER TABLE customers STORAGE (CELL_FLASH_CACHE KEEP);
-- Reset to default after warming
ALTER TABLE customers STORAGE (CELL_FLASH_CACHE DEFAULT);
-- Populate cache with index blocks
SELECT /*+ INDEX_FFS(customers_idx) */ COUNT(*) FROM customers;

Best Practices

• Use Active Data Guard when possible for automatic read caching.
• Enable lost write detection to synchronize buffer cache reads between primary and standby.
• After role transitions, manually warm the cache with scans or KEEP option.
• Always reset KEEP to DEFAULT after loading to avoid impacting other workloads.
• Monitor cache usage with CellCLI:

CellCLI> LIST FLASHCACHECONTENT

Conclusion

Exadata Smart Flash Cache ensures high performance for both primary and standby databases. By combining automatic caching for writes, Active Data Guard for reads, lost write detection, and manual cache warming after role transitions, administrators can maintain consistent performance across Oracle Data Guard environments.