Fix it now
Error 701 is the engine reporting insufficient system memory in a named resource pool; 802 is the buffer pool itself having nothing left. On Standard and Enterprise that usually points at tuning or at max server memory. On Express it usually points at the edition, whose buffer pool is capped at 1,410 MB however much RAM the machine has.
SELECT SERVERPROPERTY('Edition') AS Edition, SERVERPROPERTY('ProductVersion') AS Version;
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max server memory (MB)';
SELECT physical_memory_in_use_kb/1024 AS UsedMB FROM sys.dm_os_process_memory;
SELECT TOP 10 type, SUM(pages_kb)/1024 AS MB FROM sys.dm_os_memory_clerks GROUP BY type ORDER BY MB DESC;
- Read the edition first. It decides whether the rest of this is tuning or a ceiling you cannot move.
- Compare what the process is using against the ceiling for your edition and release. Flat at the ceiling with free RAM on the machine is the edition talking.
- Read the clerk list. If
MEMORYCLERK_SQLBUFFERPOOLdominates, this is ordinary pressure; ifCACHESTORE_SQLCPdoes, the plan cache is full of single-use ad hoc plans. - On Standard or Enterprise, set max server memory to leave Windows real headroom, then work on whatever the top clerk pointed at.
max server memory (MB) is an advanced option. Calling sp_configure for it without setting show advanced options to 1 first returns error 15123, which reads like a typo and is not one.
If the errors stop under the same workload, you are done. If the numbers say the edition is the ceiling, the next section explains what that ceiling is.
Why it happens
SQL Server does not ask Windows for memory query by query. It takes a large region and manages it internally through memory clerks, of which the buffer pool holding data and index pages is by far the largest. When a statement needs a workspace grant, a plan, a lock structure or a sort area and the pools cannot satisfy it, the engine raises 701 – and note that its published text names a resource pool, so the message tells you which pool ran out even when only the default pools exist. Error 802 is the narrower statement that the buffer pool has no free pages.
Two separate ceilings apply and they behave very differently. The one you set is max server memory (MB). The one the edition sets, you cannot. Microsoft publishes those as scale limits: Express is 1,410 MB of buffer pool per instance whatever the machine holds; Standard is 128 GB on SQL Server 2022 and earlier and 256 GB on SQL Server 2025; Web, which exists up to SQL Server 2022 and is absent from the SQL Server 2025 editions table, is 64 GB. Enterprise is bounded only by the operating system.
There are separate, smaller allowances on top of that figure for columnstore segment cache and memory-optimised data: 32 GB each on Standard, 352 MB each on Express. Those are the numbers to check when a columnstore or In-Memory OLTP workload is the thing complaining, because they are far tighter than the buffer pool ceiling and are easy to miss.
That distinction decides your approach entirely. On Express, a machine with sixty-four gigabytes of RAM still gives the engine 1,410 MB, so adding RAM changes nothing and the money is wasted. On Standard and Enterprise the same errors usually mean something else: max server memory set so high that Windows starves, a plan cache bloated by ad hoc statements, an oversized grant from a bad estimate, or a machine that is simply too small for the work.
The edition caps the buffer pool
You have this one if SERVERPROPERTY('Edition') returns Express or Web, and process memory sits flat at a ceiling no matter how much RAM the machine has.
- Compare
sys.dm_os_process_memoryagainst the documented ceiling for your edition and release, not against installed RAM. - Before concluding you need more memory, check whether a missing index is the real problem. An index that removes a scan is the cheapest fix there is.
- If the workload genuinely needs more than the edition allows, only an edition change removes the limit.
max server memory can be set below the edition ceiling but not above it. Setting a large number on Express does nothing, which misleads people into thinking it has been applied.
max server memory is unset or set too high
You have this one if Windows is short of memory, the operating system is paging, and SQL Server holds nearly everything.
- Decide how much to leave for Windows, agents and any other instances on the machine, then set the rest explicitly.
- Apply it:
EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'max server memory (MB)', <value>; RECONFIGURE; - Watch
available_physical_memory_kbinsys.dm_os_sys_memoryover the next day and adjust once, rather than guessing repeatedly.
The setting takes effect without a restart, but the engine releases memory gradually rather than instantly. Give it time before deciding it did nothing.
A non-buffer clerk has taken the space
You have this one if The clerk query shows something other than MEMORYCLERK_SQLBUFFERPOOL dominating, very often CACHESTORE_SQLCP, the ad hoc plan cache.
- Run the clerk query and identify the largest consumer by name before changing anything.
- For a plan cache full of single-use ad hoc plans,
optimize for ad hoc workloadsstores a small plan stub on first compilation instead of the full plan, which is what that option exists for. Getting the application to parameterise its queries is the real fix. - If it is another clerk, find which feature owns it before clearing anything.
DBCC FREEPROCCACHE relieves pressure for a few minutes and costs you every cached plan on the instance. Use it as a diagnostic, never as a scheduled job.
One query asks for an unreasonable grant
You have this one if A single report or overnight job reproduces the failure while the rest of the workload is unaffected.
- Capture the plan and compare the requested memory grant with the rows actually returned. A grant far larger than the data means the estimate is wrong.
- Update statistics on the tables involved, and add the index the plan is missing rather than letting it sort everything.
- Where one workload keeps damaging the rest, resource governor can cap its grants. It is available in Enterprise and Standard from SQL Server 2025, and in Enterprise and Developer only before that.
The failures are at connection time, not query time
You have this one if 17803 or 17189 in the error log rather than 701 and 802, and the complaint is that people cannot log in.
- Read 17803 literally: there was a memory allocation failure during connection establishment, and the connection was closed. It is login-time pressure, not a query.
- 17189 reports that the instance failed to spawn a thread for a new login or connection, and it carries an operating system error code. Look that code up rather than the 17189.
- Reduce non-essential memory load on the machine, or give the instance more, and check the worker pool as well as memory.
Full reference
The documented ceilings, by edition and release
| Scale limit | Enterprise | Standard (2025) | Standard (2022 and earlier) | Web (2022 and earlier) | Express |
|---|---|---|---|---|---|
| Buffer pool per instance | Operating system maximum | 256 GB | 128 GB | 64 GB | 1,410 MB |
| Columnstore segment cache per instance | Unlimited | 32 GB | 32 GB | 16 GB | 352 MB |
| Memory-optimised data per database | Unlimited | 32 GB | 32 GB | 16 GB | 352 MB |
| Compute capacity | Operating system maximum | Lesser of 4 sockets or 32 cores | Lesser of 4 sockets or 24 cores | Lesser of 4 sockets or 16 cores | Lesser of 1 socket or 4 cores |
Web edition does not appear in the SQL Server 2025 editions table at all. If you are planning a move and your current instance is Web, the comparison to make is against Standard rather than against a newer Web.
Matching the symptom to where to look
| What you see | Where to look |
|---|---|
| 701 naming a resource pool, on large sorts or hash joins | An oversized memory grant, usually from a bad cardinality estimate |
| 701 and 802 constantly, on Express | The edition ceiling, not the workload |
| 802 with the buffer pool clerk dominating | Ordinary buffer pool pressure. Index or add memory |
| The plan cache clerk dominating | Single-use ad hoc plans |
| 17803 in the log | Memory allocation failed while a connection was being established |
| 17189 in the log | A thread could not be spawned for a new login. Read the operating system code it carries |
The memory queries worth keeping
SELECT total_physical_memory_kb/1024 AS PhysMB,
available_physical_memory_kb/1024 AS FreeMB
FROM sys.dm_os_sys_memory;
SELECT physical_memory_in_use_kb/1024 AS UsedMB,
large_page_allocations_kb/1024 AS LargePageMB,
memory_utilization_percentage
FROM sys.dm_os_process_memory;
SELECT TOP 10 type, SUM(pages_kb)/1024 AS MB
FROM sys.dm_os_memory_clerks
GROUP BY type
ORDER BY MB DESC;
Clerk names worth recognising
| Clerk type | What it is |
|---|---|
MEMORYCLERK_SQLBUFFERPOOL |
The buffer pool: data and index pages. Normally the largest by a wide margin |
CACHESTORE_SQLCP |
Cached plans for ad hoc and prepared statements |
CACHESTORE_OBJCP |
Cached plans for stored procedures and functions |
OBJECTSTORE_LOCK_MANAGER |
Lock structures. If this is large, read the article on 1204 instead |
MEMORYCLERK_SQLOPTIMIZER |
Compilation. Large values point at heavy recompilation |
USERSTORE_TOKENPERM |
The security token cache. Worth recognising because it is not a cache you tune directly |
Setting max server memory without guessing
- Establish what else runs on the machine: other instances, Reporting Services, an antivirus engine, a backup agent, the application itself.
- Leave the operating system a genuine allowance rather than a token one, and remember that on a virtual machine the host may be over-committed as well.
- Set the value explicitly with sp_configure, having enabled show advanced options first.
- Watch available_physical_memory_kb across a full business day, then adjust once.
- On Express, set it below 1,410 MB if the machine also runs an application. You cannot raise it, but lowering it stops the two fighting over the same shortage.
Where resource governor now fits
Resource governor lets you put a workload into its own pool with its own memory allowance, which is the clean way to stop one report starving everything else. Microsoft documents it as available in Enterprise, Enterprise Developer, Standard and Standard Developer starting with SQL Server 2025; before that it was Enterprise and Developer only. That is a genuine change in the advice: on a current Standard instance, capping a badly behaved workload no longer requires Enterprise.
When a licence is the actual fix
If the instance is Express and the workload genuinely needs more memory than 1,410 MB, this is a licence boundary rather than a tuning problem, and no amount of indexing removes it. SQL Server 2025 Standard (2-core pack) raises the buffer pool ceiling to 256 GB and the compute cap to the lesser of 4 sockets or 32 cores, and it brings resource governor with it so a single misbehaving workload can be contained rather than tolerated. The change is an in-place edition upgrade: no data moves and the outage is a service restart. Core licences come in two-core packs, so the quantity follows the cores the instance runs on. Before buying, confirm from the clerk figures that memory really is the constraint and not one missing index. Arco will look at those numbers with you and say which edition they justify.
Every code this article covers
| Code | What it points at | Source |
|---|---|---|
701 |
There is insufficient system memory in the named resource pool to run this query | Microsoft Learn |
802 |
There is insufficient memory available in the buffer pool | Microsoft Learn |
17803 |
A memory allocation failure occurred during connection establishment and the connection was closed; reduce non-essential memory load or increase system memory | Microsoft Learn |
17189 |
SQL Server failed, with an operating system error code in the message, to spawn a thread to process a new login or connection | Microsoft Learn |
Confirm the fix worked
- Errors 701 and 802 stop appearing in the instance error log under the same workload.
sys.dm_os_process_memoryshows the engine using memory up to your intended ceiling, with Windows still reporting free memory.- The query that previously failed completes, and its plan shows a memory grant in proportion to the rows it returns.
- No single clerk other than the buffer pool dominates
sys.dm_os_memory_clerks. - If you changed edition,
SERVERPROPERTY('Edition')reflects it and the instance now uses more than the old ceiling.
Questions people ask about this
Will adding RAM fix this?
On Standard or Enterprise, often, provided max server memory is set to use it. On Express, no: the buffer pool ceiling is 1,410 MB per instance whatever the machine holds, so a bigger machine gives the engine exactly as much as a small one.
What is the Standard memory ceiling?
128 GB of buffer pool per instance on SQL Server 2022 and earlier, and 256 GB on SQL Server 2025. Check the release before quoting a figure, because the older number is the one most people still repeat.
Should I set max server memory on Express at all?
You cannot raise it above 1,410 MB, but you can set it lower, which is worth doing on a machine that also runs an application. It stops the two fighting over the same shortage.
Is resource governor still Enterprise-only?
No. Microsoft documents it as available in Enterprise, Enterprise Developer, Standard and Standard Developer from SQL Server 2025. On earlier releases it was Enterprise and Developer only.
What does moving to Standard cost?
It depends on the core count, since licences come in two-core packs. Where the user population is small and countable, Server plus CAL is worth comparing. Send us the core count and we will price both.
