Underhållsperiod

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.

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.

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.

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).

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.

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

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.

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.

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

• Konfigurera underhållsperiod
• Förhandsaviseringar

Läs mer

• Vanliga frågor och svar om underhållsfönster
• Azure SQL Database
• Hanterad Azure SQL-instans
• Planera för Azure-underhållshändelser i Azure SQL Database och Azure SQL Managed Instance