Delen via


Een Hyperscale-database beheren

Van toepassing op: Azure SQL Database

De Hyperscale-servicelaag biedt een zeer schaalbare opslag- en rekenprestatielaag die gebruikmaakt van de Azure-architectuur voor het uitschalen van opslag- en rekenresources voor een Azure SQL Database aanzienlijk buiten de limieten die beschikbaar zijn voor de servicelagen Algemeen en Bedrijfskritiek. In dit artikel wordt beschreven hoe u essentiële beheertaken uitvoert voor Hyperscale-databases, waaronder het migreren van een bestaande database naar Hyperscale, het herstellen van een Hyperscale-database naar een andere regio, het omgekeerd migreren van Hyperscale naar een andere servicelaag en het bewaken van de status van lopende en recente bewerkingen op een Hyperscale-database.

Meer informatie over het maken van een nieuwe Hyperscale-database in quickstart: Een Hyperscale-database maken in Azure SQL Database.

Tip

Vereenvoudigde prijzen voor SQL Database Hyperscale binnenkort beschikbaar. Raadpleeg de blog over prijzen van Hyperscale voor meer informatie.

Een bestaande database migreren naar Hyperscale

U kunt bestaande databases in Azure SQL Database migreren naar Hyperscale met behulp van Azure Portal, de Azure CLI, PowerShell of Transact-SQL.

De tijd die nodig is om een bestaande database naar Hyperscale te verplaatsen, bestaat uit de tijd die nodig is om gegevens te kopiëren en de tijd om de wijzigingen die in de brondatabase zijn aangebracht, opnieuw af te spelen tijdens het kopiëren van gegevens. De tijd voor het kopiëren van gegevens is evenredig aan de grootte van de gegevens. We raden u aan om tijdens een lagere schrijfactiviteitsperiode naar Hyperscale te migreren, zodat de tijd voor het opnieuw afspelen van geaccumuleerde wijzigingen korter is.

Tijdens de laatste cutover naar de Hyperscale-servicelaag ervaart u slechts een korte periode van downtime, meestal een paar minuten.

Vereisten

Als u een database wilt verplaatsen die deel uitmaakt van een geo-replicatierelatie, hetzij als primaire of als secundaire, naar Hyperscale, moet u eerst de gegevensreplicatie tussen de primaire en secundaire replica beëindigen. Databases in een failovergroep moeten eerst uit de groep worden verwijderd.

Zodra een database is verplaatst naar Hyperscale, kunt u een nieuwe Geo-replica van Hyperscale voor die database maken.

Een database migreren naar de Hyperscale-servicelaag

Als u een bestaande database in Azure SQL Database wilt migreren naar de Hyperscale-servicelaag, moet u eerst uw doelservicedoelstelling identificeren. Controleer de resourcelimieten voor individuele databases als u niet zeker weet welke servicedoelstelling geschikt is voor uw database. In veel gevallen kunt u een servicedoelstelling kiezen met hetzelfde aantal vCores en dezelfde hardwaregeneratie als de oorspronkelijke database. Indien nodig kunt u de servicedoelstelling met minimale downtime wijzigen.

Selecteer het tabblad voor het hulpprogramma van uw voorkeur om uw database te migreren:

Met Azure Portal kunt u migreren naar de Hyperscale-servicelaag door de prijscategorie voor uw database te wijzigen.

Screenshot of the compute + storage panel of a database in Azure SQL Database. The service tier dropdown is expanded, displaying the option for the Hyperscale service tier.

  1. Navigeer naar de database die u wilt migreren in Azure Portal.
  2. Selecteer Compute en opslag in de linkernavigatiebalk.
  3. Selecteer de vervolgkeuzelijst Servicelaag om de opties voor servicelagen uit te vouwen.
  4. Selecteer Hyperscale (schaalbare opslag op aanvraag) in de vervolgkeuzelijst.
  5. Controleer de vermelde hardwareconfiguratie . Selecteer desgewenst Configuratie wijzigen om de juiste hardwareconfiguratie voor uw workload te selecteren.
  6. Bekijk de optie om geld te besparen. Selecteer deze als u in aanmerking komt voor Azure Hybrid Benefit en deze wilt gebruiken voor deze database.
  7. Selecteer de schuifregelaar vCores als u het aantal vCores wilt wijzigen dat beschikbaar is voor uw database onder de Hyperscale-servicelaag.
  8. Selecteer de schuifregelaar High-AvailabilitySecondaryReplicas als u het aantal replica's onder de Hyperscale-servicelaag wilt wijzigen.
  9. Selecteer Toepassen.

U kunt bewerkingen voor een Hyperscale-database bewaken terwijl de bewerking wordt uitgevoerd.

Migreren omkeren van Hyperscale

Met omgekeerde migratie naar de servicelaag Algemeen gebruik kunnen klanten die onlangs een bestaande database in Azure SQL Database hebben gemigreerd naar de Hyperscale-servicelaag teruggaan in noodgevallen, als Hyperscale niet aan hun behoeften voldoet. Hoewel omgekeerde migratie wordt gestart door een wijziging in de servicelaag, is het in feite een verplaatsing van grootte van gegevens tussen verschillende architecturen.

Beperkingen voor omgekeerde migratie

Omgekeerde migratie is beschikbaar onder de volgende omstandigheden:

  • Omgekeerde migratie is alleen beschikbaar binnen 45 dagen na de oorspronkelijke migratie naar Hyperscale.
  • Databases die oorspronkelijk in de Hyperscale-servicelaag zijn gemaakt, komen niet in aanmerking voor omgekeerde migratie.
  • U kunt de migratie alleen omkeren naar de servicelaag Algemeen gebruik . Uw migratie van Hyperscale naar Algemeen gebruik kan gericht zijn op de serverloze of ingerichte rekenlagen. Als u de database wilt migreren naar een andere servicelaag, zoals Bedrijfskritiek of een op DTU gebaseerde servicelaag, moet u eerst de migratie naar de servicelaag Algemeen gebruik omkeren en vervolgens de servicelaag wijzigen.
  • Directe omgekeerde migratie van of naar een elastische pool wordt niet ondersteund. U kunt alleen een Individuele Hyperscale-database omkeren naar een individuele database voor algemeen gebruik.
    • Als de Hyperscale-database deel uitmaakt van een elastische Hyperscale-pool (preview), moet u deze eerst verwijderen uit de elastische Hyperscale-pool voordat u de migratie ongedaan maakt.
    • Nadat de omgekeerde migratie is voltooid, kunt u desgewenst de individuele database voor algemeen gebruik toevoegen aan een elastische pool voor algemeen gebruik, indien nodig.
  • Voor databases die niet in aanmerking komen voor omgekeerde migratie, is de enige manier om van Hyperscale naar een niet-Hyperscale-servicelaag te migreren om te exporteren/importeren met behulp van een bacpac-bestand of andere technologieën voor gegevensverplaatsing (bulkgewijs kopiëren, Azure Data Factory, Azure Databricks, SSIS, enzovoort) Bacpac exporteren/importeren vanuit Azure Portal, vanuit PowerShell met behulp vanNew-AzSqlDatabaseExport of New-AzSqlDatabaseImport, vanuit Azure CLI met behulp van az sql db export en az sql db import, en vanuit REST API wordt niet ondersteund. Bacpac importeren/exporteren voor kleinere Hyperscale-databases (maximaal 150 GB) wordt ondersteund met behulp van SSMS en SqlPackage versie 18.4 en hoger. Voor grotere databases kan het exporteren/importeren van bacpac lang duren en om verschillende redenen mislukken.

Duur en downtime

In tegenstelling tot normale wijzigingsbewerkingen op serviceniveau in Hyperscale, zijn migratie naar Hyperscale en omgekeerde migratie naar Algemeen gebruik de grootte van gegevensbewerkingen.

De duur van een omgekeerde migratiebewerking is voornamelijk afhankelijk van de grootte van de database en gelijktijdige schrijfactiviteiten die plaatsvinden tijdens de migratie. Het aantal vCores dat u aan de doeldatabase algemeen gebruik toewijst, heeft ook invloed op de duur van de omgekeerde migratie. U wordt aangeraden de doeldatabase Algemeen gebruik in te richten met een aantal vCores groter dan of gelijk aan het aantal vCores dat is toegewezen aan de Hyperscale-brondatabase om vergelijkbare workloads te ondersteunen.

Tijdens omgekeerde migratie kan de Hyperscale-brondatabase prestatievermindering ondervinden als deze aanzienlijk wordt belast. In het bijzonder kan de snelheid van transactielogboeken worden verlaagd (beperkt) om ervoor te zorgen dat omgekeerde migratie vooruitgang boekt.

Tijdens de laatste cutover naar de nieuwe doeldatabase algemeen ervaart u een korte periode van downtime, meestal een paar minuten.

Vereisten

Voordat u een omgekeerde migratie start van Hyperscale naar de servicelaag Algemeen gebruik, moet u ervoor zorgen dat uw database voldoet aan de beperkingen voor omgekeerde migratie en:

  • Voor uw database is geo-replicatie niet ingeschakeld.
  • Uw database heeft geen benoemde replica's.
  • Uw database (toegewezen grootte) is klein genoeg om in de doelservicelaag te passen.
  • Als u de maximale databasegrootte voor de doeldatabase Algemeen gebruik opgeeft, moet u ervoor zorgen dat de toegewezen grootte van de database klein genoeg is om in die maximale grootte te passen.

Vereiste controles worden uitgevoerd voordat een omgekeerde migratiebewerking wordt gestart. Als niet aan de vereisten wordt voldaan, mislukt de omgekeerde migratiebewerking onmiddellijk.

Back-upbeleid

U wordt gefactureerd met de normale prijzen voor alle bestaande databaseback-ups binnen de geconfigureerde bewaarperiode. U wordt gefactureerd voor de momentopnamen van Back-upopslag van Hyperscale en voor blobs voor gegevensopslag die moeten worden bewaard om de back-up te kunnen herstellen.

U kunt een database meerdere keren migreren naar Hyperscale en de migratie terugdraaien naar Algemeen gebruik. Alleen back-ups van de huidige en eens vorige laag van uw database zijn beschikbaar voor herstel. Als u bent overgestapt van de servicelaag Algemeen gebruik naar Hyperscale en terug naar Algemeen gebruik, zijn de enige beschikbare back-ups van de huidige database algemeen gebruik en de direct vorige Hyperscale-database. Deze bewaarde back-ups worden gefactureerd volgens azure SQL Database-facturering. Voor eerdere lagen die zijn geprobeerd, zijn geen back-ups beschikbaar en worden er geen kosten in rekening gebracht.

U kunt bijvoorbeeld migreren tussen hyperscale- en niet-Hyperscale-servicelagen:

  1. Algemeen gebruik
  2. Migreren naar Hyperscale
  3. Omgekeerd migreren naar Algemeen gebruik
  4. Servicelaag wijzigen in Bedrijfskritiek
  5. Migreren naar Hyperscale
  6. Omgekeerd migreren naar Algemeen gebruik

In dit geval zijn de enige beschikbare back-ups uit stap 5 en 6 van de tijdlijn, als ze zich nog binnen de geconfigureerde bewaarperiode bevinden. Back-ups uit eerdere stappen zijn niet beschikbaar. Overweeg zorgvuldig de beschikbaarheid van back-ups bij het uitvoeren van meerdere omgekeerde migraties van Hyperscale naar de laag Algemeen gebruik.

Een Hyperscale-database omkeren naar de servicelaag Algemeen gebruik

Als u een bestaande Hyperscale-database in Azure SQL Database wilt omkeren naar de servicelaag Algemeen gebruik, moet u eerst uw doelservicedoelstelling identificeren in de servicelaag Algemeen gebruik en of u wilt migreren naar de ingerichte of serverloze rekenlagen. Controleer de resourcelimieten voor individuele databases als u niet zeker weet welke servicedoelstelling geschikt is voor uw database.

Als u een extra servicelaagwijziging wilt uitvoeren na omgekeerde migratie naar Algemeen gebruik, identificeert u ook uw uiteindelijke doelservicedoelstelling en zorgt u ervoor dat de toegewezen grootte van uw database klein genoeg is om in die servicedoelstelling te passen.

Selecteer het tabblad voor de gewenste methode om de database om te draaien:

Met Azure Portal kunt u omgekeerd migreren naar de servicelaag Algemeen gebruik door de prijscategorie voor uw database te wijzigen.

Screenshot of the compute + storage panel of a Hyperscale database in Azure SQL Database.

  1. Navigeer naar de database die u wilt migreren in Azure Portal.
  2. Selecteer Compute en opslag in de linkernavigatiebalk.
  3. Selecteer de vervolgkeuzelijst Servicelaag om de opties voor servicelagen uit te vouwen.
  4. Selecteer Algemeen gebruik (schaalbare reken- en opslagopties) in de vervolgkeuzelijst.
  5. Controleer de vermelde hardwareconfiguratie . Selecteer desgewenst Configuratie wijzigen om de juiste hardwareconfiguratie voor uw workload te selecteren.
  6. Bekijk de optie om geld te besparen. Selecteer deze als u in aanmerking komt voor Azure Hybrid Benefit en deze wilt gebruiken voor deze database.
  7. Selecteer de schuifregelaar vCores als u het aantal vCores wilt wijzigen dat beschikbaar is voor uw database onder de servicelaag Algemeen gebruik.
  8. Selecteer Toepassen.

Bewerkingen voor een Hyperscale-database bewaken

U kunt de status van lopende of onlangs voltooide bewerkingen voor een Azure SQL Database bewaken met behulp van Azure Portal, de Azure CLI, PowerShell of Transact-SQL.

Selecteer het tabblad voor de gewenste methode om bewerkingen te bewaken.

In Azure Portal wordt een melding weergegeven voor een database in Azure SQL Database wanneer een bewerking zoals een migratie, omgekeerde migratie of herstel wordt uitgevoerd.

Screenshot of the overview panel of a database in Azure SQL Database. A notification of an ongoing operation appears in the notification area at the bottom of the panel.

  1. Navigeer naar de database in Azure Portal.
  2. Selecteer Overzicht in de linkernavigatiebalk.
  3. Controleer de sectie Meldingen onder aan het rechterdeelvenster. Als er bewerkingen worden uitgevoerd, wordt er een meldingsvak weergegeven.
  4. Selecteer het meldingsvak om details weer te geven.
  5. Het deelvenster Lopende bewerkingen wordt geopend. Bekijk de details van de lopende bewerkingen.

Databases weergeven in de Hyperscale-servicelaag

Nadat u een database naar Hyperscale hebt gemigreerd of een database opnieuw hebt geconfigureerd in de Hyperscale-servicelaag, kunt u de configuratie van uw Hyperscale-database bekijken en/of documenteren.

Azure Portal toont een lijst met alle databases op een logische server. De kolom Prijscategorie bevat de servicelaag voor elke database.

Screenshot of the overview panel of a logical server in Azure SQL Database, databases at the bottom of the panel.

  1. Navigeer naar uw logische server in Azure Portal.
  2. Selecteer Overzicht in de linkernavigatiebalk.
  3. Schuif naar de lijst met resources onder aan het deelvenster. In het venster worden de elastische SQL-pools en -databases op de logische server weergegeven.
  4. Bekijk de kolom Prijscategorie om databases in de Hyperscale-servicelaag te identificeren.

Volgende stappen

Meer informatie over Hyperscale-databases vindt u in de volgende artikelen: