How to deal with the limits of Azure SQL Database maximum logins
by Roberto Cavalcanti
If you have experienced this error code 10928: Resource ID: 3 on your Azure SQL Database, that means that you have reached a limit of concurrent logins allowed for that database on that service tier. The error message looks like this:
"10928: Resource ID: 3. The %s limit for the database is %d and has been reached. See https://go.microsoft.com/fwlink/?LinkId=267637 for assistance."
How to prevent this issue?
Let's suppose that you have a S2 database. This is a Standard tier database that allows you to have a maximum of 120 users logged in at the same time, according to the table below (numbers valid for June of 2015 at the time of this publication). If you allow your application to try to login the 121st user, then your application will get throttled with this error 10928 Resource ID: 3.
Service Tier/Performance Level |
DTU |
MAX DB Size |
Max Concurrent Requests |
Max Concurrent Logins |
Max Sessions |
Benchmark Transaction Rate |
Predictability |
Basic |
5 |
2 GB |
30 |
30 |
300 |
16,600 transactions per hour |
Good |
Standard/S0 |
10 |
250 GB |
60 |
60 |
600 |
521 transactions per minute |
Better |
Standard/S1 |
20 |
250 GB |
90 |
90 |
900 |
934 transactions per minute |
Better |
Standard/S2 |
50 |
250 GB |
120 |
120 |
1,200 |
2,570 transactions per minute |
Better |
Standard/S3 |
100 |
250 GB |
200 |
200 |
2,400 |
5,100 transactions per minute |
Better |
Premium/P1 |
125 |
500 GB |
200 |
200 |
2,400 |
105 transactions per second |
Best |
Premium/P2 |
250 |
500 GB |
400 |
400 |
4,800 |
228 transactions per second |
Best |
Premium/P3 |
1000 |
500 GB |
1,600 |
1,600 |
19,200 |
735 transactions per second |
Best |
Table 1: Current Azure SQL Database Resource Limits in June 2015.
Here are a few suggestions for you to prevent that from happening:
- Migrate the S2 databases to a higher level tier that would serve the purposes of your applications needs of having more than 120 concurrent logins, for example.
- Develop your own mechanism of governing the access to your databases. Block the Logins that are beyond the maximum capacity of the database you chose. (120 maximum logins in the case of S2s)
- Treat the exception that your application gets whenever the limits of Logins are reached (error 10928, resource ID 3), and inform the user in a graceful way that there no more available connections at that moment, and then retry to connect in every so many seconds, until there is an available login connection.
- Increase the service level (i.e. from S2 to S3, or P2) whenever necessary, and decrease it back when the higher number of available logins is not necessary anymore (From a financial standpoint, this should cost you only a few extra cents, or few extra Dollars per hour during these times of extra capacity need)
This is not a comprehensive list, and you can come up with many more suggestions, but it is a good way to get started, and to prevent this kind of throttling.
More resources about this topic:
Azure SQL Database Resource Limits
https://msdn.microsoft.com/en-us/library/azure/dn338081.aspx
Azure SQL Database Service Tiers and Performance Levels
https://msdn.microsoft.com/en-us/library/azure/dn741336.aspx
Comments
- Anonymous
July 13, 2017
good