I often get "The specified network name is no longer available" multiple times when trying to connect in Management Studio, and I also get this error through code. Transient fault handling doesn't seem to completely solve the issue. I haven't faced this issue before with Azure databases (at least from what I can remember).
Is there a way to solve this?
Related
I created a linked service for creating an HDInsight cluster a few weeks back, was able to modify it after the fact as well for # nodes, cluster type, etc.
When I go to edit the HDInsight linked service today, it throws back "Maximum call stack size exceeded". I tried creating a fresh linked service today with the same parameters and I encounter the same error there.
I tried the same behavior on a different data factory under a different subscription and there it was successful, no errors were thrown. Then I tried it with a different linked service there, and saw the same error... Wondering if anybody has encountered this particular scenario and had insights.
The Issue should have been fixed. Please refresh the UI and try again. Thanks for the patience.
I'm experiencing problems with Azure PUTs. They are either extremely slow or are failing intermittently when the requests originate from servers in the US Central region. Requests from US East appear to be working ok, although a little slower than usual. Unclear if other regions originating such requests are also facing issues.
I also see the Azure Dashboard mentioning outages of Web Apps in NA, but Storage is shown as all green. I'm assuming that the Dashboard hasn't quite caught up to the actual situation.
I was having a similar issue with puts which surfaced through Application Insights. It took some digging to find that we were getting a 409 error.
I asked microsoft and found that CreateIfNotExists correctly returns a 409 (my error) if the container exists which i was calling each time.
Below is a link to my discussion with MS.
https://social.msdn.microsoft.com/Forums/en-US/67652f9c-b941-4729-a3b3-21530ed9f2fb/blob-storage-is-failing-with-409-and-then-retrying-without-any-retry-code-and-succeeding?forum=windowsazuredata
I have 5 Azure SQL Database instances all located under the same SQL Server instance in Azure. When I view the "Resource Health" section of any of the databases, I am seeing quite a bit of the messages "we're sorry, your sql database is unavailable" which is concerning.
I am trying to understand though,is this just normal Azure SQL downtime/outage or if there is an issue in my database itself. Looking at the past logs, the DTU usage, etc. do not show any unnecessary strain on the system or usage above my allotted threshold. Yet, I am seeing databases marked as down for several minutes at a time daily from the past two weeks of history that Azure provides.
Excerpt from Conversation with Azure Support
This is bug with portal, which is causing to show these error messages.This has nothing to do with Availability of database..
this will be fixed soon
In Mail :
As discussed the error messages that you saw are due to a known Bug in Azure Postal which should be fixed soon.
Thank you for your time on the phone. It was my pleasure to work with you on this issue.
As agreed over call this support incident will now be archived. If you have further problems within the scope of this issue, please do reopen the support case.
At certain times during the week while I'm testing my Mobile Services app I get a 503 error (Service Unavailable). It happens whether I try to call the app from localhost or live on my Azure Website. It hangs around for 10-15 minutes and then goes away on its own. It doesn't seem to be caused by anything in particular that I am doing (i.e. I have not updated any code). The 503 error occurs when I'm trying to call one of my custom APIs in my Mobile Services account. A few of the requests make it through (strangely enough) but the majority return a 503 error.
I've seen that someone had a very similar problem here (Why does Azure give me an intermittent Error 503. The service is unavailable?) without an acceptable resolution.
I am using the free version of Mobile Services but I should be no where near pushing the limits of what the free version can handle; I am the sole user of the app right now.
It will soon be time to make the service live and I'm shuddering at the thought of support calls that will come in during one of these funky states the service gets into. Any help in debugging the problem would be greatly appreciated.
EDIT:
I've narrowed this down to a database problem. I have one main query (sproc) that I use to feed data to the UI. I noticed that when I get the 503 errors the query takes about 13 seconds (when run in SSMS). When things are running "normally", the query takes less than a second.
This doesn't solve my problem though, in fact it makes it more perplexing because I am using the Business Edition of Windows Azure SQL Database and there shouldn't be a 13 second fluctuation in execution time!
This problem seems to happen randomly. Is there some kind of caching in SQL Server that could explain this? Maybe my query really does take 13 seconds to execute and the caching superficially speeds it up.
Could you try transitioning your database/server to one of the "editions"? They have resource governance to promote predictable performance. Web/Business suffer from a noisy neighbor problem. It sounds like that may be your issue, considering it is intermittent.
Here's a link to a page describing the editions. https://msdn.microsoft.com/en-us/library/azure/dn741340.aspx
I've successfully implemented Umbraco 4.7 to a Windows Azure Website and SQL Azure, but sometimes I get errors similar to this one:
SQL helper exception in ExecuteScalar ---> System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) --->
It seems that Umbraco does not manage retry logic (sql azure transient fault handling). Does anybody know of any non-traumatic way to implement this on the umbraco side?
Amhed, There is no easy way todo this, people using Umbraco in Azure have generally come up with session state problems that are causing connection issues, but as you stated you are only catching a 1% which means you are picking up transient errors. You will have probably seen the discussion here
http://our.umbraco.org/forum/core/general/27179-SQL-Azure-connectivity-issues?p=1
The net effect is that you have to take the umbraco code base and rebuild it with a retry framework in it. That comes with a serious overhead to using Umbraco and taking future releases. You would best lobbying Umbraco core team to put a full retry framework in place and supporting it. (Lets not even talk about security issues ;)
This probably not what you want to hear but effectively it is roll your own datalayer time.
Having said all that I went and had a look: ;) (Because this does interest me for something else)
As starting point though from looking at the source in Umbraco they are using
Microsoft.ApplicationBlocks.Data
As the base for making connections and executing SQL commands
from Looking at the umbraco.DataLayer.SqlHelpers.SqlServer.SqlServerHelper
using SH = Microsoft.ApplicationBlocks.Data.SqlHelper;
So my guess is that you would need to replace this block. A quick (dirty) search on the internet you get
http://www.sharpdeveloper.net/source/SqlHelper-Source-Code-cs.html
You could reflect out the class though to make sure.
This then you could rebuild out with a transient fault handling framework and then you could effectively drop in potential as a change of dll (famous last words).
But you could at least get
using (ReliableSqlConnection conn = new ReliableSqlConnection(connString, retryPolicy))
easily going in that type of class and more lovely stuff.
http://msdn.microsoft.com/en-us/library/hh680899(v=pandp.50).aspx
If I was going to do this, this is where i would start from and I would go in at that level.
I am not sure if that would cover 100% the connection set as I don't work actively in umbraco code base so this is best guess but looking at source this were I would start from and change out and looks to be your best starting point.
hths,
James