Dela via


Använda Resource Health för att felsöka anslutning för Azure SQL Managed Instance

Gäller för:Azure SQL Managed Instance

Resource Health för Azure SQL Managed Instance hjälper dig att diagnostisera och få support när ett Azure-problem påverkar dina resurser. Det informerar dig om det aktuella och tidigare hälsotillståndet för dina resurser och hjälper dig att åtgärda problem. Sidan Resurshälsa ger teknisk support när du behöver hjälp med problem med Azure-tjänsten.

A screenshot of the Azure portal showing the Resource Health page for an Azure SQL Managed Instance.

Hälsokontroller

Resurshälsa avgör hälsotillståndet för din SQL-hanterade instans genom att undersöka lyckade och misslyckade inloggningar till resursen. För närvarande undersöker Resurshälsa för din SQL-hanterade instans endast inloggningsfel på grund av systemfel och inte användarfel. Hälsostatusen uppdateras var 1:e till 2:e minut.

Hälsotillstånd

Tillgängligt

Statusen Tillgänglig innebär att Resource Health inte har identifierat inloggningsfel på grund av systemfel på din SQL-hanterade instans.

A screenshot of the Azure portal showing the status message for the state of Available.

Degraderad

Statusen Degraderad innebär att Resource Health har identifierat en majoritet av lyckade inloggningar, men även vissa fel. Det här är troligen tillfälliga inloggningsfel. Om du vill minska effekten av anslutningsproblem som orsakas av tillfälliga inloggningsfel implementerar du omprövningslogik i koden.

Inte tillgänglig

Statusen Ej tillgänglig innebär att Resource Health har identifierat konsekventa inloggningsfel i din SQL-hanterade instans. Kontakta supporten om resursen är i det här tillståndet under en längre tid.

Okänt

Hälsostatusen för Okänd anger att Resurshälsa inte har tagit emot information om den här resursen på mer än 10 minuter. Även om den här statusen inte är en slutgiltig indikation på resursens tillstånd är den en viktig datapunkt i felsökningsprocessen. Om resursen körs som förväntat ändras resursens status till Tillgänglig efter några minuter. Om du har problem med resursen kan statusen Okänd hälsotillstånd antyda att en händelse på plattformen påverkar resursen.

Historisk information

Du kan komma åt upp till 30 dagars hälsohistorik i avsnittet Hälsohistorik i Resurshälsa. Avsnittet innehåller också orsaken (när det är tillgängligt) för driftstopp. För närvarande visar Azure stilleståndstiden för resursen med två minuters kornighet. Den faktiska avbrottstiden är förmodligen mindre än en minut. Genomsnittet är 8 sekunder.

Orsaker till stilleståndstid

När din SQL-hanterade instans upplever stilleståndstid utförs analys för att fastställa en orsak. När det är tillgängligt rapporteras avbrottsorsaken i avsnittet Hälsohistorik i Resurshälsa. Avbrottsorsaker publiceras vanligtvis inom 45 minuter efter en händelse.

Välj ett underhållsperiod

Du kan konfigurera underhållsfönstret för att göra påverkanskänsliga underhållshändelser förutsägbara och mindre störande för din arbetsbelastning. Funktionen underhållsperiod hjälper dig att planera förutsägbara uppgraderingar eller schemalagt underhåll. Förhandsmeddelanden är tillgängliga för alla SQL-hanterade instanser. Med avancerade meddelanden kan kunder konfigurera att meddelanden skickas upp till 24 timmar före planerade händelser.

Planerat underhåll

Azure-infrastrukturen utför regelbundet planerat underhåll – uppgradering av maskinvaru- eller programvarukomponenter i datacentret. Medan databasen underhålls kan Azure SQL avsluta vissa befintliga anslutningar och neka nya. Inloggningsfelen under planerat underhåll är vanligtvis tillfälliga, och omförsökslogik för tillfälliga nätverksfel bidrar till att minska effekten. Om inloggningsfel kvarstår kontaktar du supporten.

Omkonfiguration

Omkonfigurationer betraktas som tillfälliga villkor och förväntas då och då. Dessa händelser kan utlösas av belastningsutjämning eller programvaru-/maskinvarufel. Alla klientproduktionsprogram som ansluter till en molndatabas bör implementera en robust logik för återförsök av anslutningar för tillfälliga fel, eftersom det skulle bidra till att minimera dessa situationer och bör i allmänhet göra felen transparenta för slutanvändaren.

Nästa steg