The Azure SQL Elastic Pools page shows pool membership, pool limits, database resource usage, and historical pool metrics. Use it to understand whether an elastic pool is correctly sized and which databases are driving usage.
What You Can Review
- Databases in the pool.
- Service tier and DTU or vCore information.
- CPU, storage, sessions, requests, data I/O, and log I/O.
- Pool limits and current usage.
- Historical resource charts by pool or selected database.
Workflow
- Open an Azure SQL logical server.
- Select Elastic Pools.
- Choose a pool.
- Review pool limits and current database usage.
- Select a database to isolate its resource history.
- Use the evidence to resize the pool, move a database, change service tier, or leave the pool unchanged.
How To Use Elastic Pool Evidence
Elastic pool analysis is about shared capacity. A single database can consume enough CPU, I/O, sessions, workers, or storage to affect other databases. The Elastic Pools page helps you identify whether pressure is pool-wide or driven by one database.
Use pool data when deciding whether to:
- Resize the pool.
- Move a noisy database into its own pool.
- Move a database out of the pool.
- Tune a query that drives resource spikes.
- Change service tier or limits.
Azure SQL Elastic Pool FAQ
What is a noisy neighbor database?
It is a database in the pool that consumes enough shared resources to slow other databases in the same pool.
Should I move a database out of the pool?
Consider it when one database repeatedly drives pool pressure and tuning does not reduce its impact.
How does Mini DBA help with pool cost?
Mini DBA shows resource evidence that supports sizing decisions. It does not replace Azure cost governance, but it helps show whether capacity is overused, underused, or unevenly distributed.