What is ADR (Asynchronous DRAM Refresh) behavior in power-loss scenarios?
In the world of high-performance databases and Persistent Memory (PMEM), ADR (Asynchronous DRAM Refresh) is the "magic trick" that allows volatile hardware to act like non-volatile storage. It is the critical hardware bridge that ensures your database logs don't vanish the moment the lights go out.
Here is how ADR behaves when the power fails and why it matters for your database consistency.
To understand ADR, you have to understand where data "lives" during a write. In a standard server, data is considered persistent only when it hits the physical platters of a disk or the NAND cells of an SSD.
ADR extends the "Persistence Domain" into the memory subsystem. It defines a boundary—usually starting at the Memory Controller write queues—where data is guaranteed to be saved even if the external power supply fails.
When the system sensors detect a power failure (a "power-good" signal drop), the ADR flow triggers instantly:
Hardware-Level Trigger: The CPU stops accepting new instructions. The Memory Controller (iMC) immediately switches to an internal power reserve (usually provided by large capacitors on the motherboard or a battery-backed power supply).
The Flush: The Memory Controller "drains" its internal write buffers (the WPQ or Write Pending Queues) directly into the DRAM or PMEM.
Self-Refresh Mode: Once the data is flushed, the ADR logic places the memory into "Self-Refresh Mode." This uses the remaining capacitive power to keep the memory refreshed just long enough for a secondary process to move the data to flash (in the case of NVDIMMs) or until the PMEM cells have permanently locked in the state.
Isolation: The hardware isolates the memory bus to prevent any "glitch" signals from corrupting the data as the voltage drops across the rest of the motherboard.
Without ADR, a database would have to wait for a "Flush-to-Media" confirmation every time it wrote to a log. This would be incredibly slow.
The "Write-and-Forget" Optimization: Because of ADR, the CPU only needs to ensure the data has reached the Memory Controller. Once it's in the controller's queue, the hardware considers it "safe."
Commit Latency: This reduces the latency of a persistent write from the milliseconds of a disk (or microseconds of a PMEM cell) down to the nanoseconds of a memory controller handshake.
Standard ADR has a "blind spot": the CPU Caches (L1/L2/L3).
Standard ADR: If data is sitting in the L3 cache but hasn't been flushed to the memory controller when the power fails, that data is lost. This is why databases must use CLWB or CLFLUSH instructions to manually push data out of the cache.
eADR (Enhanced ADR): Introduced in newer Intel platforms, eADR extends the persistence domain to include the CPU caches themselves. In a power-loss scenario, the capacitors have enough juice to flush the entire cache hierarchy into the memory controller and then to the media.
| Feature | Standard ADR | eADR (Enhanced) |
| Persistence Starts At: | Memory Controller | CPU Caches (L1/L3) |
| Software Requirement: | Must use CLWB / SFENCE | No flush instructions needed |
| Database Speed: | Fast | Extreme (DRAM speeds) |
| Scenario | ADR Action | Result |
| Normal Operation | Manages memory traffic. | Peak performance. |
| Instant Power Loss | Flushes Write Queues to media. | Zero Data Loss in the Persistence Domain. |
| Partial Voltage Drop | Isolates Memory Bus. | Prevents data corruption. |
ADR is the unsung hero of the modern "Safe Write." It allows database engines to treat memory as a permanent storage tier. When you see "Battery-Backed Write Cache" on a RAID controller, you are looking at a localized version of ADR. In a modern PMEM-equipped server, ADR provides that same safety for the entire memory bus.