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 http://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 (0)

Skip to main content