One of the most under-the-radar but important changes introduced in Oracle Database 19c Release Update (RU) 19.26 is the new default setting for the parameter DB_LOST_WRITE_PROTECT.
🔄 From NONE to AUTO: A Quiet but Powerful Shift
Previously, the default setting for DB_LOST_WRITE_PROTECT was:
DB_LOST_WRITE_PROTECT = NONE
This meant lost write detection was completely disabled by default unless explicitly turned on.
Starting with RU 19.26, Oracle has made a significant shift:
DB_LOST_WRITE_PROTECT = AUTO
This change is also reflected in Oracle Database 23ai. It’s more than just a default toggle — it's a smarter, adaptive mechanism that brings better protection with minimal performance trade-offs.
💡 What Is a Lost Write?
A Lost Write is a critical data corruption event where:
Oracle writes a data block to storage,
The storage subsystem acknowledges the write as successful,
But the data block is never actually written to persistent storage.
These can be caused by memory errors, firmware bugs, OS issues, or storage controller failures. Lost writes are notoriously difficult to detect and often surface during recovery or standby failovers.
Oracle defines a lost write as:
"A data block lost write occurs when an I/O subsystem acknowledges the completion of the block write, while in fact the write did not occur in the persistent storage."
🧠 Why AUTO Matters: Intelligent Lost Write Detection
The new AUTO value for DB_LOST_WRITE_PROTECT changes how Oracle handles lost write detection:
▶️ On a Primary Database:
Oracle only logs buffer cache reads in the redo log if:
Physical standby databases exist, and
Real-time redo apply is enabled.
▶️ On a Standby Database:
Oracle performs lost write detection only if the apply lag is within reasonable bounds.
If apply lag exceeds:
60 seconds, or
2/3 of the FSFO apply lag threshold (if Fast-Start Failover is enabled),
Then lost write detection is temporarily skipped to reduce overhead and ensure smooth role transitions.
⚙️ Comparison of DB_LOST_WRITE_PROTECT Modes
Value Description Performance Impact
NONE No lost write detection. 🔋 Low
TYPICAL Logs reads for read/write tablespaces. ⚖️ Moderate
FULL Logs reads for all tablespaces (read-only + read/write). 🛠️ High
AUTO (NEW) Adapts based on real-time redo and apply lag. ⚙️ Balanced
🚨 Real-World Impact: Why It Matters
With older RUs and the default NONE, lost write protection was disabled by default — even in Data Guard environments. This left many systems unprotected by mistake, simply because DBAs weren’t aware or didn’t configure it explicitly.
Now, AUTO intelligently enables protection only when it's needed, helping DBAs avoid the all-or-nothing trade-off between performance and data integrity.
🧪 What Should You Do?
Here are a few actions to take if you’ve recently applied Oracle 19.26 or higher:
✅ 1. Check the Current Setting
SHOW PARAMETER DB_LOST_WRITE_PROTECT;
If you see AUTO, you're on the new default.
✅ 2. Monitor Redo Generation
You may notice an increase in redo generation, especially if:
You have a physical standby.
Real-time redo apply is enabled.
See MOS Note: 37260974
“Database Generating Large Amount Of Redo After Applying Jan 2025 DBRU”
✅ 3. Understand the Error ORA-00752
If you ever encounter:
ORA-00752: recovery detected a lost write of a data block
Do not attempt to fix this manually. Instead:
Shutdown the primary database.
Failover to the standby.
Open a support SR with Oracle immediately.