The timeout period elapsed prior to obtaining a connection from the pool

Jan 4, 2012 at 10:27 PM


In encounter several errors : 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. when expoerting some databases.

Some are working fine.

Here are somme erroneous ID : 

04/01/2012 22:21:18;999558f1-b4fb-4ac7-aa1e-16df2146cf88

04/01/2012 22:20:33;cbe18a0f-1c82-4679-98c6-48811e4de87d

04/01/2012 22:19:36;38c9c99c-72c2-4d60-9c01-71f099e55087

I first thought the error was caused by Redgate SQL Azure Backup but I get the same error using the web interface.

Jan 4, 2012 at 10:34 PM

Thanks for posting r0dbeck,

By web interface do you mean the Windows Azure Portal?

Also do you see the same error when you use the CLI tool?

Jan 4, 2012 at 10:44 PM

Hi and thanks for your answer,

Yes, I meant the Azure Portal.

I did not try with the DacCli, but with a redgate tool that uses the CTP import/export tool.

I'm currently trying to run one backup alone with redgate tool it seems to work. Is there a limit to the number of parallel backup one can run ?

Jan 4, 2012 at 10:53 PM

I encountered the error again using the CLI while performing one unique backup : 04/01/2012 22:50:13;7ff5fc53-41f6-4395-92b1-b42eca57ce33

Jan 4, 2012 at 11:03 PM

Dac does not impose any limit on the number of parallel backups that are run. However ADO.NET may impose a limit on number of connections.

The fact that you are facing the issue for a single request means that it may be a different issue than the pool size.

Is it possible for you to share the failing command with us? If yes, can you email me at adityasa at microsoft dot com?

Jan 5, 2012 at 5:02 PM

Any of the connection problems are usually related to throttle events on the SQL Azure server.  There is some retry logic, but if the service keeps denying the request there is not much that can be done.  But I thought we had added messages to tell you when a throttle event retry was giving up.

If you are backing up multiple databases on the same server you can still be throttled by Azure.  Remember that each backup is running in your user context, and the user has usage limits that can cause throttle events to occur.

Try doing two backups against two different servers and see if you have the same problem.


Jan 5, 2012 at 5:06 PM

Hi and thanks for your analysis.

Do you know the usage limit per user ? I have several databases to backup every day, so I perform like 5 backups in parallel, I reduced the number to two for tonight.

Jan 5, 2012 at 5:20 PM

There is not a hard limit you can always bet on.  It depends upon the load of the server.  Throttle events are by far the most frustrating thing to deal with.  Of all the code I have written against SQL Azure the throttle event can come at any time, on things that worked 100 times in the past.  It can definately test your ability to anticipate all the failure points in a piece of code!

You should be able to do all your backups, but maybe space them out in time.  One at 1 am, one at 2 am, etc.  That would probably lesson the chances of you getting throttled.

Aditya may be able to track down why it is happening in your case (maybe it it not throttle related).


Jan 5, 2012 at 11:15 PM


I have 32 databases to backup every day. I never noticed this kind of error before.

Even when I try to backup one database at a time it sometimes fails...

Jan 25, 2012 at 6:50 PM

Hey rodbeck,

This issue should now be resolved for you.  Please let us know if you still hit this issue.

Jan 30, 2012 at 9:11 AM


It was solved on january the 17 th. The backups of the 28th and the 29th failed.

I contacted the technical support on this issue.