EC Wait Type in SQL Server

EC is a wait type with two lives. It fell into disuse in older versions, then was repurposed around SQL Server 2014 as the wait recorded when a page is read from a Buffer Pool Extension (BPE) file, the feature that spills clean buffer pool pages to an SSD-backed file to stretch memory on RAM-limited boxes.

If BPE is not configured, expect zero. If it is, EC is your meter for how often queries fetch pages back from the extension instead of RAM.

Is It a Problem?

It is a usage gauge with a performance edge. BPE reads happen one page at a time, so workloads dominated by single-threaded (or low-DOP) scans feel BPE latency the most; heavily parallel scans hide it better. Prevalent EC means a large share of your working set lives in the extension rather than memory, which is BPE doing its job, at SSD speed instead of RAM speed.

Whether that trade is acceptable depends on the queries paying it.

Common Causes

• Buffer Pool Extension configured on a memory-constrained instance, with the working set exceeding RAM.
• Scan-heavy queries repeatedly pulling pages back from the BPE file.
• BPE file on storage slower than the feature assumes (it wants low-latency SSD).

What To Do

1. Confirm BPE state and size: sys.dm_os_buffer_pool_extension_configuration, and how much of the buffer pool lives in the extension (sys.dm_os_buffer_descriptors with is_in_bpool_extension).
2. Weigh the honest fix: more RAM beats BPE in nearly every case where the hardware allows it; BPE is a stopgap for boxes that cannot grow.
3. Make sure the BPE file sits on genuinely fast local SSD, and size it per guidance (a small multiple of max server memory).

How To See It

Rank it against everything else with Get-WaitStatistics; on BPE-enabled instances, its share tells you how hard the extension is working.

---

Part of the SQL Server Wait Types Library.
Related deep dive: PAGEIOLATCH_SH Wait Type.