Använda underhållsscheman för att hantera tjänstuppdateringar och underhåll

Funktionen underhållsschema integrerar meddelanden om planerat underhåll för Service Health, Övervakning av resurshälsa och schemaläggningstjänst för underhåll för Synapse SQL-pool (informationslager) i Azure Synapse Analytics.

Du bör använda schemaläggning av underhåll för att välja ett tidsfönster när det är praktiskt att ta emot nya funktioner, uppgraderingar och korrigeringar. Du måste välja en primär och en sekundär underhållsperiod inom en sjudagarsperiod, varje fönster måste vara inom separata dagintervall.

Du kan till exempel schemalägga ett primärt fönster på lördag 22:00 till söndag 01:00 och sedan schemalägga ett sekundärt fönster på onsdag 19:00 till 22:00. Om underhåll inte kan utföras under den primära underhållsperioden, kommer det att försöka underhålla igen under den sekundära underhållsperioden. Serviceunderhåll kan ibland inträffa under både de primära och sekundära fönstren. För att säkerställa ett snabbt slutförande av alla underhållsåtgärder kan DW400c- och lägre informationslagernivåer slutföra underhållet utanför en angiven underhållsperiod.

Alla nyligen skapade instanser av informationslager har ett systemdefinierat underhållsschema som tillämpas under distributionen. Schemat kan redigeras så snart distributionen är klar.

När du väljer ett underhållsperiod måste du välja en starttid och ange en maximal varaktighet. Den "maximala varaktigheten för ett underhållsperiod" avgör inom vilken tidsram underhållsaktiviteter ska utföras. Den här tidsramen kan vara mellan tre (3) och åtta (8) timmar, med ett minimikrav på tre (3) timmar. Under den här perioden kommer ditt informationslager tillfälligt att vara offline eftersom din dedikerade pool flyttas till uppgraderad kapacitet med en process som liknar pausa/återuppta. Under typiska förhållanden slutförs den här åtgärden på långt under 30 minuter, men det är viktigt att observera att det i vissa fall kan ta längre tid. Om det till exempel finns aktiva transaktioner när underhållet påbörjas kommer de att avbrytas och återställas, vilket kan orsaka fördröjningar i återställningen av onlinetjänsten. För att förhindra denna situation rekommenderar vi att du ser till att det inte finns några aktiva långvariga transaktioner i början av underhållsperioden.

Alla underhållsåtgärder bör slutföras inom de angivna underhållsfönstren om vi inte behöver distribuera en tidskänslig uppdatering. Om ditt informationslager pausas under ett schemalagt underhåll uppdateras det under återuppta-åtgärden. Du meddelas omedelbart efter att ditt informationslagerunderhåll har slutförts.

Kommentar

• Underhållsfönstren gäller inte för DW400c eller lägre prestandanivåer. De kan genomgå underhåll när som helst.
• DW400c och lägre kan uppleva flera korta förluster i anslutningen vid olika tidpunkter under underhållsperioden.

Aviseringar och övervakning

Integrering med Service Health-meddelanden och Resource Health Check Monitor gör att kunderna kan hålla sig informerade om den kommande underhållsaktiviteten. Den här automatiseringen drar nytta av Azure Monitor. Du kan bestämma hur du vill bli meddelad om kommande underhållshändelser. Du kan också välja vilka automatiserade flöden som hjälper dig att hantera stilleståndstid och minimera driftpåverkan.

Kommentar

Ett 24-timmars förhandsmeddelande föregår alla underhållshändelser. Om vi måste distribuera en tidskritisk uppdatering kan de avancerade meddelandetiderna minskas avsevärt. Detta kan ske utanför en identifierad underhållsperiod på grund av uppdateringens kritiska natur.

Om du har fått ett förhandsmeddelande om att underhåll kommer att ske, men att underhållet inte kan utföras under tidsperioden i meddelandet, får du ett meddelande om annullering. Underhållet återupptas därefter under nästa schemalagda underhållsperiod.

Alla aktiva underhållshändelser visas i avsnittet Service Health – Planerat underhåll . Service Health-historiken innehåller en fullständig post med tidigare händelser. Du kan övervaka underhåll via instrumentpanelen för Azure Service Health-kontrollportalen under en aktiv händelse.

Tillgänglighet för underhållsschema

Även om schemaläggning av underhåll inte är tillgängligt i den valda regionen kan du visa och redigera ditt underhållsschema när som helst. När schemaläggning av underhåll blir tillgängligt i din region blir det identifierade schemat omedelbart aktivt i synapse SQL-poolen.

Visa ett underhållsschema

Som standard har alla nyligen skapade instanser av informationslager en åtta timmar lång primär och sekundär underhållsperiod som tillämpas under distributionen. Som du ser ovan kan du ändra fönstren så snart distributionen är klar. Inget underhåll sker utanför de angivna underhållsperioderna utan föregående meddelande.

Utför följande steg för att visa underhållsschemat som har tillämpats på din Synapse SQL-pool:

1. Logga in på Azure-portalen.
2. Välj den Synapse SQL-pool som du vill visa.
3. Den valda Synapse SQL-poolen öppnas på översiktsbladet. Underhållsschemat som tillämpas på informationslagret visas under underhållsschemat.

Hoppa över eller ändra underhållsschema

För att säkerställa efterlevnaden av de senaste säkerhetskraven kan vi inte hantera begäranden om att hoppa över eller fördröja dessa uppdateringar. Du kan dock ha några alternativ för att justera underhållsperioden om du använder DW500c och högre informationslagernivåer inom den aktuella cykeln beroende på din situation:

• Om du får ett meddelande om underhåll och behöver mer tid för att slutföra dina jobb eller meddela ditt team, kan du ändra underhållsperiodens starttid, så länge du gör det innan den definierade underhållsperioden har påbörjats. Då flyttas underhållsperioden framåt i tiden inom cykeln.

• Du kan utlösa underhållet manuellt genom att pausa och återuppta (eller skala) din dedikerade SQL-pool efter starten av en cykel där ett "Väntande" meddelande har tagits emot. Helgunderhållscykeln startar på lördag kl. 00:00 UTC och underhållscykeln i mitten av veckan startar tisdag kl. 12:00 UTC.

• Även om vi kräver ett minsta fönster på 3 timmar, kommer den här åtgärden under normala förhållanden att slutföras på långt under 30 minuter. Det är emellertid viktigt att observera att det i vissa fall kan ta längre tid. Om det till exempel finns aktiva transaktioner när underhållet påbörjas kommer de att avbrytas och återställas, vilket kan orsaka fördröjningar i återställningen av onlinetjänsten. För att förhindra denna situation rekommenderar vi att du ser till att det inte finns några aktiva långvariga transaktioner i början av underhållsperioden.

Kommentar

• Om du ändrar fönstret till en starttid före den faktiska nuvarande tiden utlöses underhåll omedelbart, och om det finns aktiva transaktioner när underhållet startar avbryts och återställs dessa.
• När åtgärden för att pausa och återuppta har slutförts för att initiera underhållet kommer du, istället för att få ett meddelande som bekräftar att underhållet har slutförts, att meddelas om att detta har avbrutits.
• Om du använder DW400c eller lägre: Även om du kan ändra underhållsschemat följs detta inte eftersom det är en lägre prestandanivå. Som tidigare nämnts kan dessa informationslagernivåer genomgå underhåll när som helst med underhållscykeln.

Identifiera de primära och sekundära fönstren

De primära och sekundära fönstren måste ha separata dagintervall. Ett exempel är ett primärt fönster mellan tisdag och torsdag och ett sekundärt fönster för lördag–söndag. Termerna "Primär" och "Sekundär" bör betraktas som "Fönster 1" respektive "Fönster 2". Det innebär att något av fönstren kan hämtas i valfri ordning för att distribuera underhållsuppgraderingar.

Utför följande steg för att ändra underhållsschemat för din Synapse SQL-pool:

1. Logga in på Azure-portalen.

2. Välj den Synapse SQL-pool som du vill uppdatera. Sidan öppnas på översiktsbladet. Öppna sidan för inställningar för underhållsschema genom att välja länken Sammanfattning av underhållsschema på översiktsbladet. Eller välj alternativet Underhållsschema på resursmenyn till vänster.

   

3. Identifiera det föredragna dagintervallet för det primära underhållsfönstret med hjälp av alternativen överst på sidan. Det här valet avgör om ditt primära fönster inträffar en veckodag eller under helgen. Ditt val uppdaterar listrutevärdena. Under förhandsversionen kanske vissa regioner ännu inte stöder den fullständiga uppsättningen tillgängliga Dag-alternativ .

   

4. Välj önskade primära och sekundära underhållsfönster med hjälp av listrutorna:

   • Dag: Önskad dag för underhåll under det valda fönstret.
   • Starttid: Önskad starttid för underhållsperioden.
   • Tidsfönster: Önskad varaktighet för tidsfönstret.

   Området Schemalägg sammanfattning längst ned på bladet uppdateras baserat på de värden som du har valt.

5. Välj Spara. Ett meddelande visas som bekräftar att ditt nya schema nu är aktivt.

   Du kan uppdatera alternativen Dag, Starttid, Tid (inklusive standardfönstret på 8 timmar) när som helst. Om du sparar ett schema i en region som inte stöder schemaläggning av underhåll visas följande meddelande. Inställningarna sparas och blir aktiva när funktionen blir tillgänglig i den valda regionen.

   

Vanliga frågor och svar

Vilken är den förväntade frekvensen för underhållet.

Underhåll kan ske mer än en gång per månad, eftersom underhåll kan omfatta os-uppdateringar, säkerhetskorrigeringar och drivrutiner, interna Uppdateringar av Azure-infrastruktur och DW-korrigeringar och uppdateringar. Varje kund har ett schema med underhållscykler två gånger i veckan mellan lördag–söndag och tisdag–torsdag.

Vilka ändringar har gjorts när underhållet har slutförts, även om min dedikerade SQL-poolversion förblir densamma?

När en underhållsuppdatering har slutförts kan SQL-poolversionen förbli oförändrad. Detta beror på att underhåll kan omfatta OS-uppdateringar, säkerhetskorrigeringar och drivrutiner, interna uppdateringar av Azure-infrastruktur och DW-korrigeringar och uppdateringar. Endast om en Synapse DW-korrigering eller uppdatering ingår i underhållet visas en ändring av SQL Dedicated-poolversionen.

Går det att uppgradera versionen av min dedikerade SQL-pool på begäran?

• Nej, schemalagt underhåll sköter hanteringen av dedikerade SQL-pooler. Du kan dock ha några alternativ för att utlösa underhållet när cykeln har startat, beroende på din situation. Verifiera schema för hoppa över eller ändra underhåll
• Det är viktigt att komma ihåg att den dedikerade SQL-poolen är en PaaS-funktion (Platform as a Service). Detta innebär att Microsoft Azure hanterar alla typer av uppgifter som rör tjänsten, till exempel infrastruktur, underhåll, uppdateringar och skalbarhet. Schemalagt underhåll kan spåras genom att ställa in en avisering/avisering så att du håller dig informerad om den kommande underhållsaktiviteten.

Vilka ändringar, om några, bör göras före eller efter att det dedikerade SQL-poolunderhållet har slutförts?

• Under underhållet kommer tjänsten att tillfälligt kopplas från, ungefär som när du pausar, återupptar eller skalar. Normalt slutförs den övergripande underhållsåtgärden på mindre än 30 minuter. Det kan emellertid ta lite längre tid, beroende på databasaktiviteten under underhållsfönstret. Vi rekommenderar att du pausar ETL, tabelluppdateringar och särskilt transaktionsåtgärder för att undvika längre underhåll än normalt. Till exempel:
• Om din instans är mycket upptagen under det planerade fönstret, särskilt med frekvent uppdaterings- och borttagningsaktivitet, kan underhållsåtgärden ta längre tid än normalt. För att minska risken för utökad underhållsaktivitet rekommenderar vi att du begränsar aktiviteten till mestadels skrivskyddade frågor mot databasen om möjligt och särskilt undviker tidskrävande transaktionsfrågor (se nästa objekt).
• Om det finns aktiva transaktioner när underhållet påbörjas avbryts de och återställs, vilket kan orsaka fördröjningar i återställningen av onlinetjänsten. För att förhindra denna situation rekommenderar vi att du ser till att det inte finns några aktiva långvariga transaktioner i början av underhållsperioden.

Vi fick ett meddelande om ett kommande schemalagt underhåll av dedikerad SQL-pool med spårnings-ID 0000-000, men detta avbröts eller schemalades sedan om. Vad ledde till att underhållet avbröts eller schemalades om?

Det finns olika faktorer som kan leda till att schemalagt underhåll avbryts, inklusive åtgärder som:

• Pausa eller skala åtgärder efter att ha fått ett väntande underhållsmeddelande medan cykeln initieras.
• Om du riktar in dig på olika servicenivåmål (SLO) under underhållscykeln, till exempel om du övergår från ett serviceavtal som är högre än DW400c och sedan skalar tillbaka till ett SLO som är lägre eller lika med DW400c, eller vice versa, kan en annullering ske. Detta beror på att underhållsperioder inte är tillämpliga för DW400c eller lägre prestandanivåer och de kan genomgå underhåll när som helst.
• Interna infrastrukturfaktorer, till exempel faktiska ändringar i schemaläggningen av planerat underhåll av versionsteamet.
• Underhåll kan avbrytas eller schemaläggas om intern övervakning upptäcker att underhåll tar längre tid än förväntat. Underhållet måste slutföras inom serviceavtal (SLA) som definieras av inställningar för kundunderhållsperioder.

Finns det några metodtips som jag behöver överväga för vår arbetsbelastning under underhållsfönstret?

• Ja, om möjligt pausa alla transaktions- och ETL-arbetsbelastningar under det planerade underhållsintervallet för att undvika fel eller fördröjningar i återställningen av onlinetjänsten. Långvariga transaktionsoperationer bör avslutas innan en planerad underhållsperiod tar vid.
• För att arbetsbelastningar ska vara motståndskraftiga mot avbrott som orsakas av underhållsåtgärder använder du omprövningslogik för både anslutnings- och kommandonivåerna (frågan) och tillämpar längre återförsöksintervall och/eller fler återförsök för att motstå en utökad anslutningsförlust som kan sträcka sig upp till eller större än 30 minuter i vissa fall.

Nästa steg

• Läs mer om att skapa, visa och hantera aviseringar med hjälp av Azure Monitor.
• Läs mer om webhook-åtgärder för loggaviseringsregler.
• Läs mer om att skapa och hantera åtgärdsgrupper.
• Läs mer om Azure Service Health.