We recently migrated a client to the SQL Azure platform during the course of a production deployment. By all outward signs, it was successful: the web apps connected to it are all working.
However, when we look at the Azure monitor, we see many failed connections. We haven't been able to find much documentation explaining what constitutes a failed connection. And none of our users have been reporting problems. Does anyone know how this could be?
Using the sample query from this article (View Connection Issues on an SQL Azure Instance)
SELECT
[Date From] = EL.[start_time],
[Date To] = EL.[end_time],
[Database Name] = EL.[database_name],
[Event Type] = EL.[event_type],
[Event Sub Type] = EL.[event_subtype_desc],
[Description] = EL.[description],
[Additional Data] = EL.additional_data
FROM sys.event_log EL
WHERE EL.event_type != 'connection_successful'
AND EL.event_subtype_desc != 'idle_connection_timeout'
ORDER BY [Date From] DESC
We see results like this:
2013-04-19 16:40:00.0000000 2013-04-19 16:45:00.0000000 [DATABASE] connection_failed blocked_by_firewall Client IP address is not allowed to access the server. NULL
2013-04-19 16:40:00.0000000 2013-04-19 16:45:00.0000000 connection_failed blocked_by_firewall Client IP address is not allowed to access the server. NULL
2013-04-19 16:35:00.0000000 2013-04-19 16:40:00.0000000 [DATABASE] connection_failed blocked_by_firewall Client IP address is not allowed to access the server. NULL
2013-04-19 16:35:00.0000000 2013-04-19 16:40:00.0000000 connection_failed blocked_by_firewall Client IP address is not allowed to access the server. NULL
2013-04-19 16:30:00.0000000 2013-04-19 16:35:00.0000000 [DATABASE] connection_failed blocked_by_firewall Client IP address is not allowed to access the server. NULL
2013-04-19 16:30:00.0000000 2013-04-19 16:35:00.0000000 connection_failed blocked_by_firewall Client IP address is not allowed to access the server. NULL
2013-04-19 16:25:00.0000000 2013-04-19 16:30:00.0000000 [DATABASE] connection_failed blocked_by_firewall Client IP address is not allowed to access the server. NULL
2013-04-19 16:25:00.0000000 2013-04-19 16:30:00.0000000 connection_failed blocked_by_firewall Client IP address is not allowed to access the server. NULL
2013-04-19 16:20:00.0000000 2013-04-19 16:25:00.0000000 [DATABASE] connection_failed blocked_by_firewall Client IP address is not allowed to access the server. NULL
2013-04-19 16:20:00.0000000 2013-04-19 16:25:00.0000000 connection_failed blocked_by_firewall Client IP address is not allowed to access the server. NULL
2013-04-19 16:15:00.0000000 2013-04-19 16:20:00.0000000 [DATABASE] connection_failed blocked_by_firewall Client IP address is not allowed to access the server. NULL
And an example of our connection string, as requested:
<add name="[MyContext]"
providerName="System.Data.SqlClient"
connectionString="
Server=tcp:[machine].database.windows.net,1433;
Database=[database];
User ID=[user]@[machine];
Password=[password];
Trusted_Connection=False;
Encrypt=True;
Connection Timeout=30;"/>
If the application persistently fails to connect to Azure SQL Database, it usually indicates an issue with one of the following: Firewall configuration. The Azure SQL database or client-side firewall is blocking connections to Azure SQL Database.
SSMS cannot connect to azure sql databaseYour client IP address does not have access to the server azure. Sign in to an Azure account and create a new firewall rule to enable access. This is for obvious security reasons. You don't want to allow everyone to be able to connect to your sql database in azure.
Navigate to the database blade in the Azure portal and, under Settings, select Connection strings. Review the complete ADO.NET connection string.
So ever since the first day of launch, we have not seen anymore failed connections. My current thinking is that there may be a back end process on the Azure side that was not functioning properly with the new instance, but has since either stopped, or been fixed, as we have not changed anything. I'll let it sit a few more days and if we don't see any more problems, chalk it up to environment setup glitches.
Here's the status a week or so later. Not a heavily used site, but no sign of anymore connection errors.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With