Dela via

Underhållsperiod

  • Artikel

Gäller för:Azure SQL DatabaseAzure SQL Managed Instance

Med funktionen underhållsperiod kan du konfigurera underhållsschemat för Azure SQL Database - och Azure SQL Managed Instance-resurser , vilket gör påverkanskänsliga underhållshändelser förutsägbara och mindre störande för din arbetsbelastning.

Kommentar

Funktionen underhållsperiod skyddar endast mot planerad påverkan från uppgraderingar eller schemalagt underhåll. Den skyddar inte mot alla redundansorsaker. undantag som kan orsaka korta anslutningsavbrott utanför ett underhållsperiod är maskinvarufel, belastningsutjämning för kluster och databasomkonfigurationer på grund av händelser som en ändring i databasens servicenivåmål.

Förhandsmeddelanden (förhandsversion) är tillgängliga för databaser som har konfigurerats för att använda ett underhållsfönster som inte är standard och hanterade instanser med valfri konfiguration (inklusive standardinställningen). Med avancerade meddelanden kan kunder konfigurera att meddelanden skickas upp till 24 timmar före planerade händelser.

Översikt

Azure utför regelbundet planerat underhåll av SQL Database- och SQL-hanterade instansresurser. Under Azure SQL-underhållshändelsen är databaser fullt tillgängliga, men kan bli föremål för korta omkonfigurationer inom respektive tillgänglighets-SERVICEavtal för SQL Database och SQL-hanterad instans.

Underhållsfönstret är avsett för produktionsarbetsbelastningar som inte är motståndskraftiga mot databas- eller instansomkonfigurationer och som inte kan absorbera korta anslutningsavbrott som orsakas av planerade underhållshändelser. Genom att välja ett underhållsperiod som du föredrar kan du minimera effekten av planerat underhåll eftersom det sker utanför din högsta kontorstid. Motståndskraftiga arbetsbelastningar och icke-produktionsarbetsbelastningar kan förlita sig på Azure SQL:s standardprincip för underhåll.

Underhållsfönstret är kostnadsfritt och kan konfigureras när du skapar eller för befintliga Azure SQL-resurser. Den kan konfigureras med hjälp av Azure-portalen, PowerShell, CLI eller Azure API.

Viktigt!

Att konfigurera underhållsperioden är en tidskrävande asynkron åtgärd, ungefär som att ändra tjänstnivån för Azure SQL-resursen. Resursen är tillgänglig under åtgärden, förutom en kort omkonfiguration som sker i slutet av åtgärden och vanligtvis varar upp till 8 sekunder även vid avbrutna långvariga transaktioner. För att minimera effekten av omkonfigurationen bör du utföra åtgärden utanför rusningstiderna.

Få mer förutsägbarhet med underhållsfönstret

Som standard blockerar Azure SQL-underhållsprincipen de mest effektfulla uppdateringarna under perioden 08:00 till 17:00 lokal tid varje dag för att undvika störningar under vanliga tider med hög belastning. Lokal tid bestäms av platsen för Den Azure-region som är värd för resursen och kan observera sommartid i enlighet med definitionen för lokal tidszon.

Du kan ytterligare justera underhållsuppdateringarna till en tid som passar dina Azure SQL-resurser genom att välja mellan två ytterligare underhållsperioder:

  • Veckodag : 22:00–06:00 lokal tid, måndag– torsdag
  • Helgfönster : 22:00 till 06:00 lokal tid, fredag - söndag

I listan över underhållsperioder visas startdagen för varje åtta timmars underhållsperiod. "22:00–06:00 lokal tid, måndag– torsdag" innebär till exempel att underhållsfönstren börjar kl. 22:00 lokal tid varje dag (måndag till torsdag) och slutförs kl. 06:00 lokal tid följande dag (tisdag till fredag).

När valet av underhållsfönster har gjorts och tjänstkonfigurationen har slutförts sker planerat underhåll endast under det fönster som du väljer. Även om underhållshändelser vanligtvis slutförs i ett enda fönster, kan vissa av dem sträcka sig över två eller flera angränsande fönster.

Kommentar

Azure SQL Database och Azure SQL Managed Instance följer en säker distributionspraxis där Azure-kopplade regioner garanterat inte distribueras till samtidigt. Det går dock inte att förutsäga vilken region som ska uppgraderas först, så distributionsordningen är inte garanterad. Ibland uppgraderas den primära instansen först och ibland är den sekundär.

  • I situationer där databasen är aktiverad för geo-replikering eller redundansgrupper och geo-replikeringen inte överensstämmer med Azure-regionpareringen bör du ha olika scheman för underhållsperioder för din primära och sekundära databas. Du kan till exempel välja veckodagunderhållsfönster för din geo-sekundära databas och helgunderhållsfönstret för din geo-primära databas.
  • I situationer där din hanterade Azure SQL-instans har redundansgrupper och grupperna inte är anpassade till azure-regionparkopplingen bör du ha olika scheman för underhållsperioder för din primära och sekundära databas. Du kan till exempel välja veckodagunderhållsfönster för din geo-sekundära databas och helgunderhållsfönstret för din geo-primära databas.

Viktigt!

I mycket sällsynta fall där en senareläggning av åtgärden kan orsaka allvarliga konsekvenser, som att tillämpa kritiska säkerhetskorrigeringar, kan det hända att det konfigurerade underhållsfönstret tillfälligt åsidosätts.

Förhandsaviseringar

Underhållsmeddelanden kan konfigureras för att varna dig om kommande planerade underhållshändelser för din Azure SQL Database och Azure SQL Managed Instance. Aviseringarna tas emot 24 timmar i förväg, innan underhållsfönstret öppnas och i slutet av underhållsfönstret. Mer information finns i Förhandsaviseringar.

Funktion tillgänglig

Prenumerationstyper som stöds

Du kan konfigurera och använda underhållsfönstret för följande erbjudandetyper: Betala per användning, Molnlösningsleverantör (CSP), Microsoft företagsavtal eller Microsoft-kundavtal.

Erbjudanden som är begränsade till endast dev/test-användning är inte berättigade (t.ex. Dev/Test – betala per användning eller Enterprise Dev/Test som exempel).

Kommentar

Ett Azure-erbjudande är den typ av Azure-prenumeration som du har. Till exempel är en prenumeration med betala per användning-priser, Azure i Open och Visual Studio Enterprise alla Azure-erbjudanden. Varje erbjudande eller plan har olika villkor och fördelar. Ditt erbjudande eller din plan visas i prenumerationens översikt. Mer information om hur du byter prenumeration till ett annat erbjudande finns i Ändra din Azure-prenumeration till ett annat erbjudande.

Servicenivåmål som stöds

Om du väljer ett annat underhållsfönster än standardvärdet är det tillgängligt på alla serviceavtal förutom:

  • Pooler i Azure SQL Managed Instance
  • Nivåerna Azure SQL Database DTU Basic, S0 och S1
  • DC-maskinvara
  • Fsv2-maskinvara
  • Hyperskala tjänstnivå med zonredundans
  • Elastiska hyperskalapooler

Stöd för Azure SQL Managed Instance-regionen för underhållsperioder

Om du väljer ett underhållsperiod för Azure SQL Managed Instance är det för närvarande tillgängligt i följande regioner:

  • Australien, centrala 1
  • Australien, centrala 2
  • Australien, östra
  • Australien, sydöstra
  • Brasilien, södra
  • Brasilien, sydöstra
  • Kanada, centrala
  • Kanada, östra
  • Indien, centrala
  • Central US
  • Östra Kina 2
  • Norra Kina 2
  • East US
  • USA, östra 2
  • Asien, östra
  • Frankrike, centrala
  • Frankrike, södra
  • Tyskland, västra centrala
  • Tyskland, norra
  • Japan, östra
  • Japan, västra
  • Sydkorea, centrala
  • Sydkorea, södra
  • USA, norra centrala
  • Europa, norra
  • Norge, östra
  • Norge, västra
  • Sydafrika, norra
  • Sydafrika, västra
  • USA, södra centrala
  • Indien, södra
  • Sydostasien
  • Schweiz, norra
  • Schweiz, västra
  • Förenade Arabemiraten, centrala
  • Förenade Arabemiraten, norra
  • Storbritannien, södra
  • Storbritannien, västra
  • US Gov, Arizona
  • US Gov, Texas
  • US Gov, Virginia
  • USA, västra centrala
  • Europa, västra
  • Indien, västra
  • USA, västra
  • USA, västra 2
  • USA, västra 3

Stöd för Azure SQL Database-regionen för underhållsperioder

Att välja ett underhållsperiod för Azure SQL Database som inte är standard är för närvarande tillgängligt i följande regioner, ordnat efter inköpsmodell.

Följande tabell är avsedd för databaser som inte är zonredundanta. För databaser i en Azure-tillgänglighetszon, se tabellen för zonredundanta databaser.

Azure-region SQL Database: Minnesoptimerad i Hyperskala Premium-serien och Premium-serien Alla andra Köpmodeller och nivåer för Azure SQL Database
Australien, östra Ja Ja
Sydöstra Australien Ja
Brasilien, södra Ja
Brasilien, sydöstra Ja
Kanada, centrala Ja Ja
Östra Kanada Ja
Indien, centrala Ja
Centrala USA Ja Ja
Östra Kina 2 Ja
Norra Kina 2 Ja
USA, östra Ja Ja
USA, östra 2 Ja Ja
Asien, östra Ja
Centrala Frankrike Ja
Södra Frankrike Ja
Tyskland, västra centrala Ja
Japan, östra Ja Ja
Västra Japan Ja
Norra centrala USA Ja
Europa, norra Ja Ja
USA, södra centrala Ja Ja
Södra Indien Ja
Sydostasien Ja
Schweiz, norra Ja
Förenade Arabemiraten, norra Ja
Södra Storbritannien Ja
Västra Storbritannien Ja
US Gov, Texas Ja
US Gov, Virginia Ja
Västra centrala USA Ja
Västeuropa Ja Ja
Västra USA Ja Ja
Västra USA 2 Ja Ja
Västra USA 3 Ja

Följande tabell gäller för zonredundanta databaser.

Azure-region Alla andra Köpmodeller och nivåer för Azure SQL Database i en Azure-tillgänglighetszon
Australien, östra Ja
Kanada, centrala Ja
Centrala USA Ja
USA, östra 1 Ja
USA, östra 2 Ja
Japan, östra Ja
Europa, norra Ja
USA, södra centrala Ja
Sydostasien Ja
Södra Storbritannien Ja
Västeuropa Ja
Västra USA 2 Ja

Gateway-underhåll

För att få maximal nytta av underhållsperioder kontrollerar du att klientprogrammen använder anslutningsprincipen för omdirigering. Omdirigering är den rekommenderade anslutningsprincipen, där klienter upprättar anslutningar direkt till noden som är värd för databasen, vilket leder till minskad svarstid och förbättrat dataflöde.

  • I Azure SQL Database kan alla anslutningar som använder proxyanslutningsprincipen påverkas av både det valda underhållsfönstret och ett underhållsfönster för gatewaynoder. Klientanslutningar som använder den rekommenderade omdirigeringsanslutningsprincipen påverkas dock inte av en omkonfiguration av gatewaynodunderhåll.

  • I Azure SQL Managed Instance finns gateway-noderna i det virtuella klustret och har samma underhållsfönster som den hanterade instansen, men att använda principen för omdirigeringsanslutning rekommenderas fortfarande för att minimera antalet avbrott under underhållshändelsen.

Mer information om klientanslutningsprincipen i Azure SQL Database finns i Azure SQL Database Anslut ion policy.

Mer information om klientanslutningsprincipen i Azure SQL Managed Instance finns i Anslutningstyper för Azure SQL Managed Instance.

Överväganden för Azure SQL Managed Instance

Azure SQL Managed Instance består av tjänstkomponenter som finns på en dedikerad uppsättning isolerade virtuella datorer som körs i undernätet för en kunds virtuella nätverk. Dessa virtuella datorer är ordnade i grupper för att bilda ett virtuellt kluster som kan vara värd för flera hanterade instanser. Eftersom ett underhållsfönster som konfigurerats för instanser i samma undernät kan påverka antalet grupper av virtuella datorer i det virtuella klustret och hanteringsåtgärder för virtuella kluster, finns det några saker att tänka på innan du konfigurerar underhållsfönstret.

Konfiguration av underhållsfönster är en tidskrävande åtgärd

Alla instanser som finns i samma grupp för virtuella datorer delar samma underhållsfönster. Som standard finns alla hanterade instanser i en grupp med ett standardunderhållsfönster. Om du anger en annan underhållsperiod, antingen när du skapar instansen eller när den redan har skapats, placeras instansen i en separat datorgrupp med motsvarande underhållsperiod. Om det inte finns någon sådan grupp i klustret skapas en ny för att hantera den nya konfigurationen av instansen. Om du konfigurerar ytterligare instanser i det virtuella klustret så att de använder samma underhållsfönster läggs även dessa instanser till i gruppen, vilket innebär att gruppen kan behöva ändras. Att lägga till instanser i en ny datorgrupp och ändra storlek på befintliga datorgrupper kan öka varaktigheten för åtgärden för att konfigurera en underhållsperiod.
Den förväntade varaktigheten för att konfigurera ett underhållsperiod för en hanterad instans kan beräknas med den uppskattade varaktigheten för instanshanteringsåtgärder.

Viktigt!

När du konfigurerar ett underhållsfönster kräver det sista steget i åtgärden en omkonfiguration av instansen som vanligtvis varar upp till 8 sekunder, även om den avbryter långvariga transaktioner. För att minimera påverkan konfigurerar du ett underhållsperiod utanför hög belastning på kontorstid.

Krav på IP-adressutrymme

Varje ny virtuell datorgrupp i ett undernät kräver ytterligare IP-adresser enligt ip-adressallokeringen för det virtuella klustret. Om du ändrar ett underhållsperiod för en befintlig hanterad instans krävs också tillfällig ytterligare IP-kapacitet, ungefär som när du skalar antalet virtuella kärnor för respektive tjänstnivå.

Ändring av IP-adress

Om du konfigurerar eller ändrar ett underhållsfönster ändras IP-adressen för instansen till en annan IP-adress inom IP-adressintervallet för undernätet.

Viktigt!

Kontrollera att NSG- och brandväggsregler inte blockerar datatrafik efter en ÄNDRING av IP-adressen.

Serialisering av hanteringsåtgärder för virtuella kluster

Åtgärder som påverkar det virtuella klustret, till exempel tjänstuppgraderingar eller storleksändring av det virtuella klustret (till exempel att lägga till nya eller ta bort oanvända beräkningsnoder), serialiseras. Därför kan en ny virtuell klusteråtgärd inte starta förrän den föregående åtgärden har slutförts. Om underhållsfönstret stängs innan den pågående underhållsåtgärden har slutförts läggs den pågående underhållsåtgärden på is till nästa underhållsperiod. Andra hanteringsåtgärder som skickas under den tiden spärras också och återupptas under eller efter nästa underhållsperiod när den ursprungliga pågående underhållsåtgärden har slutförts. Det är inte vanligt att en underhållsåtgärd tar längre tid än ett enda underhållsperiod per virtuell datorgrupp i ett kluster, men det kan inträffa för mycket komplexa underhållsåtgärder.

Serialiseringen av hanteringsåtgärder för virtuella kluster är ett allmänt beteende som även gäller för standardprincipen för underhåll. När du konfigurerar ett schema för underhållsperioder kan perioden mellan två intilliggande fönster vara några dagar lång. Även om det är ovanligt att underhållsåtgärden sträcker sig över två fönster kan nyligen skickade åtgärder vara pausade i flera dagar, vilket kan blockera åtgärder som kräver ytterligare beräkningsnoder, till exempel att skapa en ny eller ändra storlek på en befintlig instans.

Hämta en lista över underhållshändelser

Azure Resource Graph är en Azure-tjänst som har utformats för att utöka Azure Resource Management. Azure Resource Graph Explorer ger effektiv och högpresterande resursutforskning med möjlighet att köra frågor i stor skala över en viss uppsättning prenumerationer så att du effektivt kan styra din miljö.

Du kan använda Azure Resource Graph Explorer för att fråga efter underhållshändelser. En introduktion till hur du kör dessa frågor finns i Snabbstart: Kör din första Resource Graph fråga med Azure Resource Graph Explorer.

Om du vill söka efter underhållshändelser för alla SQL-databaser i din prenumeration använder du följande exempelfråga i Azure Resource Graph Explorer:

servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where  impactedService =~ 'SQL Database'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc

Om du vill söka efter underhållshändelser för alla hanterade instanser i din prenumeration använder du följande exempelfråga i Azure Resource Graph Explorer:

servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where  impactedService =~ 'SQL Managed Instance'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc

Fullständig referens för exempelfrågorna och hur du använder dem i verktyg som PowerShell eller Azure CLI finns i Azure Resource Graph-exempelfrågor för Azure Service Health.

Nästa steg

Läs mer