Elastic Pool Limit Reached

Question

We are having an issue where we are exceeding the request limit of an elastic pool and we have no idea why because when we perform the same task in a test environment the problem does not occur.

What we are trying to do is upgrade a database by running several SQL scripts against it and the way we do this is to use C# to create a single SQLConnection and SQLCommand object and re-use both to execute the scripts against the database in a transaction. When we upgrade a database in a test environment the session count of the elastic pool stays flat and does not spike but when we perform the same upgrade against the same database in a different elastic pool the session count increases by over 100 which then errors because the limit has been exceeded.

This shows the session count spiking:

This shows the same upgrade process on the same database but in a different elastic pool and the session count does not spike at all:

If the system that failed is restarted before the upgrade is run it will work although the session count does increase it isn't by over 100, more like 10-20.

We would like to know why the session count would suddenly jump from 35 to 145 but only in certain elastic pools?

Answer 1

Hi developer-0760,

Thankyou for reaching Microsoft Q&A. It looks like the spike in sessions is happening because your elastic pool has a limit on how many connections and requests can run at one time and that limit is shared across all the databases in the pool. If your upgrade process runs when other apps or jobs are already connected to the pool, your total active sessions can suddenly jump and hit that limit, causing errors. That’s why you’re seeing it in production but not in your quieter test pool.

Here are some things you can do:

1.Try to make sure your code always closes database connections when it’s done using them, instead of keeping one connection open all the time. Short-lived connections are best.

2.Avoid constantly changing connection details in your app, as each new variation can create extra connections behind the scenes.

3.If you’re running lots of scripts in parallel, try reducing how many run at once so you don’t create a big burst of sessions.

4.You can track who’s connecting by running a simple query during the upgrade. This helps spot who or what is creating extra connections.

5.If this keeps happening, think about running upgrades in a pool with fewer other jobs or increasing resources for your elastic pool.

Helpful References:

1.Tech Community: Session Limit in Elastic Pool​
2. Best Practice for Disposing Connections​
3.Guide to Sessions in Azure SQL

Please let us know if you have any questions and concerns.

Answer 2

Hello developer-0760,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are having issue with Elastic Pool Limit Reached.

Follow the steps below to resolve the issue:

1. Inspect Thread Saturation / eDTU Exhaustion

          SELECT TOP 10 
          FROM sys.dm_db_resource_stats
          ORDER BY end_time DESC;
   

   Check CPU %, worker thread usage, storage. Compare recent WARNINGS with thresholds.
2. Check concurrent requests / sessions

          SELECT COUNT() AS connections
          FROM sys.dm_exec_connections
          WHERE [session_id] > 50;
   

   May catch abrupt spikes in session usage.
3. Trace waiting and blocking behavior by configure Extended Events / DMVs to log:
   • CPU/Worker thread saturation (wait_type = THREADPOOL)
   • Resource waits (request_limit breaches)
4. Identify long-running queries, heavy DML patterns, or transactions not closed properly and method: Trace deadlocks or blocked chains using sys.dm_os_waiting_tasks to evaluate workload pattern.
5. Tune or optimize concurrency by starting with ALTER DATABASE … SET MAXDOP = 1; optionally set THREAD_POOL_MAX_THREADS_PER_CPU at server level and avoid large parallel workloads as a workaround not as a fix.
6. Partition your data into multiple pools/databases to reduce per-DB pressure, using sharding, switch to vCore-based General Purpose / Business Critical for higher thread limits, and adjust connection pooling in application.
7. If constant connection limit issues occur, prefer higher eDTU tiers and validate impact via resource_stats queries post-change.
8. Set alerts for utilization %, and use sys.elastic_pool_resource_stats vs. resource_stats to see per-DB vs pool-level usage in your monitor and alert.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

---

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.