Delen via

Duur van beheerbewerkingen in Azure SQL Managed Instance

Van toepassing op:Azure SQL Managed Instance

In dit artikel worden de stappen en de duur van beheerbewerkingen in Azure SQL Managed Instance beschreven.

Zie het overzicht van beheerbewerkingen voor een overzicht van de onderliggende processen met betrekking tot beheerbewerkingen, zoals seeding en failover.

Stappen voor beheerbewerking

Het beheren van Azure SQL Managed Instance omvat de volgende bewerkingen:

  • Maken: De bewerkingen die optreden wanneer u een nieuw met SQL beheerd exemplaar maakt. Dit omvat het maken of wijzigen van het formaat van de onderliggende virtuele machinegroep (VM) en het implementeren van het SQL Database Engine-proces.
  • Update: Bewerkingen die optreden wanneer u de eigenschappen van een bestaand met SQL beheerd exemplaar wijzigt, zoals het schalen van rekenkracht of opslag, het wijzigen van de servicelaag of het bijwerken van de exemplaarconfiguratie. Het bijwerken omvat vaak het maken of aanpassen van de onderliggende virtuele machinegroep (VM); het invoeren van gegevens en het uitvoeren van een failover naar een nieuw SQL Database Engine-proces.
  • Verwijderen: Bewerkingen die optreden wanneer u een bestaand met SQL beheerd exemplaar verwijdert, inclusief het opschonen van resources zoals de VM-groep die is gekoppeld aan het exemplaar.

Bewerking aanmaken

Met de bewerking Maken wordt de implementatie van een nieuw met SQL beheerd exemplaar binnen een subnet van een virtueel netwerk gestart, terwijl u rekenkracht, opslag en de SQL Database Engine-omgeving voor het exemplaar instelt.

Het proces voor het maken doorloopt doorgaans drie fasen:

  1. Aanvraag valideren: de ingediende parameters worden syntactisch en semantisch gevalideerd. Als parameters ongeldig zijn (zoals het verkeerde subnet of niet-ondersteunde SKU), mislukt de bewerking onmiddellijk met een fout.
  2. De VM-groep maken of het formaat ervan wijzigen: hiermee maakt of breidt u een VM-groep uit om het nieuwe exemplaar te hosten. De duur van de bewerking is afhankelijk van of het exemplaar zone-redundant is of niet.
  3. Start een nieuw SQL-exemplaar: implementeert en start het SQL Database Engine-proces op de toegewezen VM's.

updatebewerkingen

De updatebewerking wijzigt de eigenschappen van een bestaand met SQL beheerd exemplaar, zoals het schalen van rekenkracht of opslag, het wijzigen van de servicelaag of het bijwerken van de exemplaarconfiguratie.

Het updateproces doorloopt doorgaans vijf fasen:

  1. Aanvraag valideren: de ingediende parameters worden syntactisch en semantisch gevalideerd. Controleert op ondersteunde updatetypen op basis van de huidige exemplaarconfiguratie en de aangevraagde wijzigingen. Als de aanvraag ongeldig is, mislukt de bewerking met een fout.
  2. Maak of wijzig het formaat van de VM-groep: afhankelijk van de wijziging wordt de bestaande VM-groep gewijzigd of wordt er een nieuwe VM-groep gemaakt, zoals in de volgende updatebewerkingen:
    • Opslag omhoog of omlaag schalen
    • Rekenkracht omhoog of omlaag schalen
    • De servicelaag wijzigen
    • De hardware wijzigen
    • Het onderhoudsvenster aanpassen
    • Zoneredundantie in- of uitschakelen
  3. SQL-exemplaar starten: er wordt een nieuw SQL Database Engine-proces geïnitialiseerd met de bijgewerkte configuratie.
    • Als er een nieuwe VM-groep wordt gemaakt of als de bestaande VM-groep wordt gewijzigd, wordt er een volledige SQL Database Engine-implementatie uitgevoerd.
  4. Seed/attach storage: bereidt de database voor op de nieuwe of aangepaste VM-groep. Het exemplaar is beschikbaar tijdens dit proces.
  5. Bereid u voor en voer vervolgens een failover uit: Verkeer wordt omgeleid naar het nieuwe exemplaar.
    • Uw exemplaar is alleen niet beschikbaar tijdens een failover, wanneer verkeer wordt omgeleid naar het nieuwe SQL Database Engine-proces. In de servicelaag Bedrijfskritiek is uw exemplaar maximaal 20 seconden niet beschikbaar, terwijl uw exemplaar in de servicelaag Algemeen gebruik maximaal 2 minuten niet beschikbaar is.
  6. Oude SQL-instantie opschonen: dealloceer de oude virtuele machines en verwijder de SQL-processen die niet langer vereist zijn.

Belangrijk

Het schalen van rekenkracht of opslag, of het wijzigen van de servicelaag, op hetzelfde moment als langlopende transacties (zoals het importeren van gegevens, gegevensverwerkingstaken of het opnieuw opbouwen van indexen) wordt niet aanbevolen omdat de failover van de database aan het einde van de bewerking alle lopende transacties annuleert.

Bewerking verwijderen

Met de bewerking Verwijderen wordt een bestaand met SQL beheerd exemplaar verwijderd en worden de bijbehorende resources opgeschoond. Zodra een verwijderbewerking wordt geactiveerd, wordt facturering voor SQL Managed Instance uitgeschakeld. De duur van de verwijderbewerking heeft geen invloed op de facturering.

Het verwijderingsproces doorloopt doorgaans vier fasen:

  1. Aanvraag valideren: de ingediende parameters worden syntactisch en semantisch gevalideerd. Als de aanvraag ongeldig is, mislukt de bewerking met een fout.
  2. Back-up van tail-log: als het exemplaar niet leeg is, wordt er voor elke database een back-up van tail-log gemaakt om ervoor te zorgen dat er geen gegevens verloren gaan nadat het exemplaar is verwijderd. Back-ups worden bewaard op basis van het bewaarbeleid van elke database.
  3. SQL-exemplaar opschonen: het SQL Database Engine-proces wordt verwijderd uit de VM-groep en de resources die aan het exemplaar zijn gekoppeld, worden vrijgegeven.
  4. VM-groep verwijderen: als het subnet andere exemplaren bevat, blijft de VM-groep intact voor deze exemplaren. Als het exemplaar dat wordt verwijderd het laatste exemplaar in het subnet is, wordt de VM-groep synchroon verwijderd als laatste stap. Wanneer het laatste exemplaar in een subnet wordt verwijderd, wordt door het verwijderen van de VM-groep automatisch het verwijderen van het virtuele cluster gestart.

Instancegroepen

Met exemplaargroepen kunt u meerdere exemplaren maken en beheren met gedeelde resources, waardoor u kosten kunt verlagen en het beheer kunt vereenvoudigen. Het implementeren van een afzonderlijk exemplaar binnen een bestaande pool is aanzienlijk sneller dan het inrichten van een zelfstandig beheerd exemplaar, omdat de infrastructuur al beschikbaar is.

Het maken van een exemplaarpool omvat de volgende stappen:

  • Aanvraag valideren: de ingediende parameters worden syntactisch en semantisch gevalideerd. Als de aanvraag ongeldig is, mislukt de bewerking met een fout.
  • Maak de VM-groep: er wordt een nieuwe VM-groep gemaakt om de exemplaargroep in een subnet van een virtueel Azure-netwerk te hosten. Het aantal vCores dat aan het virtuele cluster is toegewezen, is het maximumaantal vCores dat door alle exemplaren in de pool wordt gebruikt. Dit is een eenmalige bewerking waarmee de onderliggende infrastructuur voor meerdere beheerde exemplaren wordt ingesteld.
  • Exemplaar maken: exemplaren worden gemaakt in de exemplaargroep, waarbij het SQL Database Engine-proces wordt geïmplementeerd op de toegewezen VM's. De exemplaren delen de resources van het virtuele cluster, wat een efficiënter resourcegebruik mogelijk maakt. Instanties worden indien nodig door de klant aangemaakt.

Het maken van een exemplaar in een pool omvat de volgende stappen:

  • Aanvraag valideren: de ingediende parameters worden syntactisch en semantisch gevalideerd. Als de aanvraag ongeldig is, mislukt de bewerking met een fout.
  • Exemplaar maken: exemplaren worden gemaakt in de exemplaargroep, waarbij het SQL Database Engine-proces wordt geïmplementeerd op de toegewezen VM's.

Het verplaatsen van een exemplaar naar een exemplaargroep omvat de volgende stappen:

  • Aanvraag valideren: de ingediende parameters worden syntactisch en semantisch gevalideerd. Als de aanvraag ongeldig is, mislukt de bewerking met een fout.
  • VCores toewijzen: aan het exemplaar moet voldoende vCores uit de pool worden toegewezen. Aangezien vCores al zijn toegewezen aan de pool, is dit eenvoudig en werkt het hetzelfde als het toewijzen van een nieuw exemplaar in de pool.

Het verplaatsen van een exemplaar uit een exemplaargroep omvat de volgende stappen:

  • Aanvraag valideren: de ingediende parameters worden syntactisch en semantisch gevalideerd. Als de aanvraag ongeldig is, mislukt de bewerking met een fout.
  • De VM-groep maken of het formaat ervan wijzigen: hiervoor moet u een voldoende aantal vereiste vCores instellen voor het exemplaar buiten de pool. vCores zijn nog niet klaar en moeten worden ingericht, dus deze bewerking is hetzelfde als een updateproces dat het formaat van een bestaande VM-groep moet wijzigen of moet een nieuwe VM-groep aanmaken.

Zoneredundantie

Als zoneredundantie is ingeschakeld, worden reken- en opslaglagen verdeeld over meerdere beschikbaarheidszones om hoge beschikbaarheid en gegevensintegriteit te garanderen.

Zoneredundantie breidt de duur van beheerbewerkingen uit om wijzigingen in resources in meerdere beschikbaarheidszones mogelijk te maken.

Duur van beheerbewerking

De duur van beheerbewerkingen varieert op basis van de servicelaag van het beheerde SQL-exemplaar. De volgende secties bevatten gedetailleerde informatie over de duur van beheerbewerkingen voor elke servicelaag:

In de volgende tabel ziet u de duur van beheerbewerkingen in de servicelaag Algemeen gebruik , inclusief de langlopende segmenten en de geschatte duur voor elke bewerking:

Beheerbewerking Langlopende segmenten Geschatte duur
Operaties aanmaken
Een nieuw exemplaar maken VM-groep maken of het formaat ervan wijzigen 95% bewerkingen zijn binnen 30 minuten voltooid
Een nieuw zone-redundant exemplaar maken Vm-groep maken of het formaat ervan wijzigen met zoneredundantie 95% van de bewerkingen zijn binnen 4 uur voltooid
Nieuwe exemplaarpool maken De VM-groep maken 95% bewerkingen zijn binnen 30 minuten voltooid
Instantie creëren binnen een pool Geen 95% bewerkingen zijn in minder dan 10 minuten voltooid
Updatebewerkingen
Basisinstantie-eigenschappen wijzigen, zoals het licentietype of Microsoft Entra Geen Maximaal 1 minuut
Opslag uitbreiden Geen 99% bewerkingen zijn binnen 5 minuten voltooid
Rekenkracht schalen (vCores) VM-groep maken of het formaat ervan wijzigen 95% bewerkingen zijn binnen 60 minuten voltooid
Overstappen op de servicelaag Bedrijfskritiek De VM-groep opnieuw dimensioneren
+ Database-seeding		 95% bewerkingen zijn binnen 60 minuten voltooid + tijd voor het seeden van databases
Overschakelen naar de servicetier Volgende generatie Algemeen gebruik VM-groep maken of het formaat ervan wijzigen
+ Database-seeding		 95% bewerkingen zijn binnen 60 minuten voltooid + tijd voor het seeden van databases
Hardware- of onderhoudsvenster wijzigen VM-groep maken of het formaat ervan wijzigen 95% bewerkingen zijn binnen 60 minuten voltooid
Zoneredundantie inschakelen Nieuwe VM-groep maken
+ Database-seeding		 95% bewerkingen zijn binnen 4 uur voltooid + tijd voor het seeden van databases
Zoneredundantie uitschakelen Nieuwe VM-groep maken
+ Database-seeding		 95% bewerkingen zijn binnen 30 minuten voltooid + tijd voor het seeden van databases
Een exemplaar verplaatsen naar een exemplaargroep Geen 95% bewerkingen zijn binnen 10 minuten voltooid
Een exemplaar uit een exemplaargroep verplaatsen VM-groep maken of het formaat ervan wijzigen 95% bewerkingen zijn binnen 60 minuten voltooid
Verwijderingsbewerkingen
Niet-laatste exemplaar1 verwijderen Back-up van logboeken voor alle databases 95% bewerkingen zijn binnen 1 minuut voltooid.
Laatste exemplaar2 verwijderen Back-up van logboeken voor alle databases
Virtueel cluster verwijderen		 95% bewerkingen zijn in 90 minuten voltooid

1 Als het cluster meerdere VM-groepen bevat, wordt het verwijderen van het laatste exemplaar in de groep onmiddellijk geactiveerd om de VM-groep asynchroon te verwijderen.
2 Door het laatste exemplaar in het subnet te verwijderen, wordt het virtuele cluster onmiddellijk synchroon verwijderd.

Uw exemplaar is beschikbaar voor de duur van alle beheerbewerkingen, behalve tijdens de laatste failoverstap , wanneer verkeer wordt omgeleid naar het nieuwe SQL Database Engine-proces. In de servicelaag Bedrijfskritiek is uw exemplaar maximaal 20 seconden niet beschikbaar, terwijl uw exemplaar gedurende maximaal 2 minuten niet beschikbaar is in de servicelagen Algemeen gebruik en Volgende generatie .

Belangrijk

Voor updatebewerkingen die niet zijn voltooid, maar die ertoe leiden dat de database opnieuw wordt gekoppeld (zoals het schalen van vCores, het schalen van geheugen, het wijzigen van hardware of het onderhoudsvenster), wordt de failoverduur van databases op de servicelaag Volgende generatie Algemeen gebruik geschaald met het aantal databases, tot 10 minuten. Hoewel het exemplaar na 2 minuten beschikbaar is, zijn sommige databases mogelijk na een vertraging beschikbaar. De duur van de failover wordt gemeten vanaf het moment waarop de eerste database offline gaat, tot het moment waarop de laatste database online komt. Met de servicelaag Next-gen Algemeen gebruik wordt het maximum aantal databases per exemplaar verhoogd van 100 tot 500.

Duur van seeding

Seeding is het proces van het initialiseren en synchroniseren van gegevens in SQL Database Engine-processen. De duur van seeding is voornamelijk afhankelijk van de grootte van de database. Gemiddeld verloopt het zaaien met een snelheid van ongeveer 220 GB per uur.

Seeding wordt gelijktijdig uitgevoerd via acht parallelle kanalen. Op elk gewenst moment worden acht databases geselecteerd voor gegevensoverdracht. Zodra de overdracht van een database is voltooid, wordt de volgende beschikbare database toegewezen aan het nu gratis kanaal, wat zorgt voor continue en efficiënte doorvoer.

De volgende tabel bevat de volgende informatie:

  • Waarschijnlijk geschatte tijd voor het zaaien van het merendeel van de gevallen
  • Verwachte maximale geschatte seedingtijd voor 95% gevallen
Groottebereik van database (GB) Waarschijnlijke zaaitijd Verwachte maximale zaaiperiode
0 - 32 GB 30 minuten 1 uur
32 - 256 GB 1,5 uur 2 uur
256 - 512 GB 2 uur 5 uur
512 - 1024 GB 5 uur 9 uur
1024 - 2048 GB 9 uur 15 uur
2048 - 3072 GB 10 uur 16 uur
3072 - 4096 GB 12 uur 18 uur
Groter dan 4096 GB 15 uur 20 uur

Verwante inhoud

  • Last updated on