Search service SQL connection pool exhaustion after the March 2026 update

The behavior matches classic SQL connection pool exhaustion: connections opened by the SharePoint Search timer job are not being returned to the pool, so once the pool reaches its Max Pool Size, all subsequent requests queue and then time out.

From the SQL side and the .NET data provider side, the key facts are:

• ADO.NET creates a separate pool per unique connection string and user identity.
• Connections are only returned to the pool when they are explicitly closed or disposed.
• If the maximum pool size is reached and no usable connection is available before the timeout, an exception is thrown with the message you are seeing.

Relevant mechanics:

1. ADO.NET connection pooling
   • A pool is created per unique connection string; connections are added as needed up to the maximum pool size (default 100) and are released back to the pool when closed or disposed.
   • If the pool is full and no idle connection is available, requests wait until the connection timeout (default 15 seconds); if no connection can be reclaimed, a timeout exception is raised.
   • This is exactly the pattern visible in the ULS message: “The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.”
2. Importance of closing connections
   • Connections that are not explicitly closed or disposed may not be returned to the pool. If code opens connections in a loop without closing them, the pool fills and stays full until the process recycles.
   • Correct pattern is to wrap each SqlConnection in a using block (or explicitly call Close/Dispose) so that every use returns the connection to the pool.
3. Symptoms of a leak vs. normal load
   • In a leak scenario, the number of active connections to the SQL instance steadily increases and never drops, even when workload is low.
   • Recycling the process (or in this case, restarting SPTimerV4) clears the pool and temporarily restores service, which matches what is being observed.

Given that this started immediately after a specific update and is tied to a specific timer job (QueryLogJobDefinition), the likely root cause is a regression where that job’s code path is failing to close its SqlConnection objects. That is consistent with known patterns in other Microsoft components where hotfixes were required to address connection leaks in adapters or services.

Mitigation and next steps:

1. Treat this as a product defect rather than a configuration issue.
   • The pool behavior and limits are by design; the leak is in the caller (the timer job) not returning connections.
   • Manually increasing Max Pool Size would only delay the failure and increase SQL resource usage; it does not fix the leak.
2. Short-term operational mitigation
   • Continue scheduled recycling of the affected process as a temporary workaround (e.g., scheduled restart of SPTimerV4 during off-hours) to clear the pool before it saturates.
   • Monitor SQL connections on the SharePoint content and search databases to confirm the growth pattern and correlate with the QueryLogJobDefinition schedule.
3. Long-term fix
   • A code-level fix is required in the component that owns QueryLogJobDefinition so that every SqlConnection is closed or disposed after use. In .NET, this means ensuring all connection usage is wrapped in using blocks or explicit Close/Dispose calls.
   • Once that fix is applied (via a cumulative update or hotfix from the product group), the timer job will return connections to the pool correctly and the pool will stabilize instead of exhausting.
4. Additional checks on the SQL side
   • Confirm that the SQL instance is healthy and not under abnormal CPU or memory pressure; however, in this case the primary symptom is pool exhaustion, not general SQL slowness.
   • Ensure that no other application roles or security context changes are preventing pooled connections from being reused; standard ADO.NET pooling assumes the connection state can be reset and reused.

Because the connection pool behavior is fixed and controlled by the ADO.NET provider, the only sustainable resolution is to obtain and apply the SharePoint/Search fix that corrects the connection leak in QueryLogJobDefinition. Until that is available, controlled recycling of the timer service and careful monitoring of connection counts are the safest mitigations.

References:

• Establish a connection
• SQL Server connection pooling (ADO.NET)