Omvänd migrering av en databas från Hyperskala

Du kan migrera en befintlig Hyperskala-databas i Azure SQL Database till tjänstnivån Generell användning med hjälp av Azure-portalen, Azure CLI, PowerShell eller Transact-SQL.

Omvänd migrering till tjänstnivån Generell användning gör att kunder som nyligen har konverterat en befintlig databas i Azure SQL Database till Hyperskala kan gå tillbaka i en nödsituation om Hyperskala inte uppfyller deras behov. Omvänd migrering initieras av en ändring på tjänstnivå, men det är i stort sett en datastorleksflytt mellan olika arkitekturer.

Begränsningar för omvänd migrering

Omvänd migrering är tillgänglig under följande villkor:

• Omvänd migrering är endast tillgänglig inom 45 dagar efter den ursprungliga migreringen till Hyperskala.
• Databaser som ursprungligen skapades på tjänstnivån Hyperskala är inte berättigade till omvänd migrering.
• Du kan bara återgå till tjänstnivån Generell användning. Din migrering från Hyperskala till Allmänt syfte kan riktas mot antingen serverlösa eller förbestämda beräkningskategorier. Om du vill migrera databasen till en annan tjänstnivå, till exempel Affärskritisk eller en DTU-baserad tjänstnivå, ska du först omvänd-migrera till tjänstnivån Allmänt syfte och sedan ändra tjänstnivån.
• Omvänd migrering till databaser med mindre än 2 virtuella kärnor stöds inte. Du kan skala ned databasen till färre än 2 virtuella kärnor när migreringen är klar.
• Direkt omvänd migrering från eller till en elastisk pool stöds inte. Du kan endast återställa migreringen av en Hyperscale singeldatabas till en singeldatabas för allmän användning.
  • Om Hyperskala-databasen är en del av en elastisk hyperskalapoolmåste du först ta bort den från den elastiska hyperskalapoolen före omvänd migrering.
  • När omvänd migrering är klar kan du valfritt lägga till den enskilda databasen för generellt syfte i en elastisk pool för generellt syfte om det behövs.
• För databaser som inte kvalificerar sig för omvänd migrering är det enda sättet att migrera från Hyperskala till en tjänstnivå som inte är hyperskala att exportera/importera med hjälp av en bacpac-fil eller andra dataförflyttningstekniker (masskopiering, Azure Data Factory, Azure Databricks, SSIS osv.) Bacpac export/import från Azure-portalen, från PowerShell med hjälp av New-AzSqlDatabaseExport eller New-AzSqlDatabaseImport, från Azure CLI med az sql db export och az sql db import, och från REST API stöds inte. Bacpac import/export för mindre Hyperskala-databaser (upp till 150 GB) stöds med SSMS och SqlPackage version 18.4 och senare. För större databaser kan bacpac-export/import ta lång tid och kan misslyckas av olika orsaker.

Varaktighet och stilleståndstid

Till skillnad från vanliga åtgärder för servicenivåmålsändringar i Hyperskala är migrering till Hyperskala och omvänd migrering till Allmän användning datavolymbaserade åtgärder.

Varaktigheten för en omvänd migrering beror främst på databasens storlek och samtidiga skrivaktiviteter som sker under migreringen. Antalet virtuella kärnor som du tilldelar måldatabasen för generell användning påverkar också varaktigheten för den omvända migreringen. Vi rekommenderar att du etablerar måldatabasen generell användning med ett antal virtuella kärnor som är större än eller lika med det antal virtuella kärnor som tilldelats källdatabasen hyperskala för att upprätthålla liknande arbetsbelastningar.

Under omvänd migrering kan hyperskala-källdatabasen uppleva prestandaförsämring om den är mycket belastad. Mer specifikt kan transaktionsloggfrekvensen minskas (begränsas) för att säkerställa att omvänd migrering gör framsteg.

Du kommer att uppleva en kort period av stilleståndstid, vanligtvis några minuter, under den sista snabbväxlingen till den nya måldatabasen för generell användning.

Förutsättningar

Innan du påbörjar en omvänd migrering från Hyperskala till tjänstnivån Generell användning måste du se till att databasen uppfyller begränsningarna för omvänd migrering och:

• Databasen har inte geo-replikering aktiverad.
• Databasen har inte namngivna repliker.
• Databasen (allokerad storlek) är tillräckligt liten för att passa in på måltjänstnivån.
• Om du anger maximal databasstorlek för måldatabasen generell användning kontrollerar du att databasens allokerade storlek är tillräckligt liten för att passa in i den maximala storleken.

Nödvändiga kontroller utförs innan en omvänd migreringsåtgärd startas. Om kraven inte uppfylls misslyckas den omvända migreringsåtgärden omedelbart.

Säkerhetskopieringsprinciper

Du debiteras med den vanliga prissättningen för alla befintliga databassäkerhetskopior inom den konfigurerade kvarhållningsperioden. Du debiteras för ögonblicksbilder av Hyperskala-säkerhetskopieringslagring och för datalagringsblobar som måste behållas för att kunna återställa säkerhetskopian.

Du kan konvertera en databas till Hyperskala och återgå till Allmänt ändamål flera gånger. Endast säkerhetskopior från den aktuella och en gång tidigare nivån i databasen är tillgängliga för återställning. Om du har flyttat från tjänstnivån Generell användning till Hyperskala och tillbaka till Generell användning är de enda tillgängliga säkerhetskopiorna från den aktuella allmänna databasen och den omedelbart tidigare Hyperskala-databasen. Dessa bevarade säkerhetskopior faktureras enligt Azure SQL Database-fakturering. Alla tidigare nivåer som provats har inga tillgängliga säkerhetskopior och debiteras inte.

Du kan till exempel migrera mellan tjänstnivåerna Hyperskala och icke-Hyperskala:

1. Generell användning
2. Konvertera till Hyperskala
3. Omvänd migrering till generell användning
4. Tjänstnivåändring till Affärskritisk
5. Konvertera till Hyperskala
6. Omvänd migrering till Allmänt syfte

I det här fallet är de enda tillgängliga säkerhetskopiorna från steg 5 och 6 på tidslinjen, om de fortfarande är inom den konfigurerade kvarhållningsperioden. Säkerhetskopior från tidigare steg skulle vara otillgängliga. Överväg noggrant tillgängligheten för säkerhetskopior när du försöker utföra upprepade migreringar av samma databas mellan tjänstnivåerna Hyperskala och Generell användning. Säkerhetskopior av databaser som är äldre än den omedelbart tidigare databasen blir otillgängliga så snart en omvänd migrering startas och förblir otillgänglig även om migreringen avbryts.

Så här omvänt migrerar du en Hyperskala-databas till tjänstnivån Generell användning

Om du vill omvända migreringen av en befintlig Hyperskala-databas i Azure SQL Database till tjänstnivån Generell användning ska du först identifiera måltjänstmålet på tjänstnivån Generell användning och om du vill migrera till de etablerade eller serverlösa beräkningsnivåerna. Granska resursgränser för enskilda databaser om du inte är säker på vilket tjänstmål som passar din databas.

Om du vill göra ytterligare en ändring på tjänstnivån efter omvänd migrering till Generell användning ska du identifiera ditt slutliga måltjänstmål. Se till att databasens allokerade storlek är tillräckligt liten för att passa in i tjänstmålet.

Välj fliken för den metod som du föredrar för att ångra migreringen av databasen:

Portal

Med Azure-portalen kan du ångra migreringen till tjänstnivån Generell användning genom att ändra prisnivån för databasen.

1. Gå till databasen i Azure-portalen.
2. I det vänstra navigeringsfältet väljer du Compute + storage.
3. Välj listrutan för tjänstenivå för att expandera alternativen för tjänstenivåer.
4. Välj Generell användning (skalbar beräkning och lagringsalternativ) i listrutan.
5. Granska Maskinvarukonfiguration som listas. Om du vill väljer du Ändra konfiguration för att välja lämplig maskinvarukonfiguration för din arbetsbelastning.
6. Välj reglaget vCores om du vill ändra antalet vCores som är tillgängliga för din databas under tjänstenivån Generellt syfte.
7. Välj Använd.
8. Övervaka konverteringen i Azure-portalen.
   1. Gå till databasen i Azure-portalen.
   2. I det vänstra navigeringsfältet väljer du Översikt.
   3. Granska avsnittet Meddelanden längst ned i den högra panelen. Om åtgärder pågår visas en meddelanderuta.
   4. Om du vill visa information väljer du meddelanderutan.
   5. Fönstret Pågående åtgärder öppnas. Granska informationen om de pågående åtgärderna.

Azure CLI

Det här kodexemplet anropar az sql db update för att återställa en befintlig Hyperscale-databas till servicenivån Allmän användning. Du måste ange både utgåva och tjänstmål. Du kan välja antingen Provisioned eller Serverless för målberäkningsmodellen.

Ersätt resourceGroupName, serverName, databaseNameoch serviceObjective med lämpliga värden innan du kör följande kodexempel:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel

Du kan också ta med argumentet maxsize. Om maxsize-värdet överskrider den giltiga maximala storleken för måltjänstmålet returneras ett fel. Om argumentet maxsize inte har angetts är åtgärden som standard den maximala storleken som är tillgänglig för det angivna tjänstmålet. I följande exempel anges maxsize:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"
maxsize="200GB"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel --max-size $maxsize

Övervaka den pågående operationen med az sql db op list. Så här returnerar du de senaste eller pågående åtgärderna för en databas i Azure SQL Database:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"

az sql db op list -g $resourceGroupName -s $serverName -n $databaseName

PowerShell

Det här kodexemplet använder cmdleten Set-AzSqlDatabase för att omvänd migrera en befintlig databas från Hyperskala till tjänstnivån Generell användning. Du måste ange både utgåva och tjänstmål. Du kan välja antingen Provisioned eller Serverless för målberäkningsnivån.

Ersätt $resourceGroupName, $serverName, $databaseName, $serviceObjectiveoch $computeModel med lämpliga värden innan du kör det här kodexemplet:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective

Du kan också ta med argumentet maxsize. Om maxsize-värdet överskrider den giltiga maximala storleken för måltjänstmålet returneras ett fel. Om argumentet maxsize inte har angetts är åtgärden som standard den maximala storleken som är tillgänglig för det angivna tjänstmålet. I följande exempel anges maxsize:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"
$maxSizeBytes = "268435456000"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective -MaxSizeBytes $maxSizeBytes

Övervaka den pågående åtgärden med cmdleten Get-AzSqlDatabaseActivity, som returnerar de senaste eller pågående åtgärderna för en databas i Azure SQL Database. Ange parametrarna $resourceGroupName, $serverNameoch $databaseName till lämpliga värden för databasen innan du kör exempelkoden:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"

Get-AzSqlDatabaseActivity -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -DatabaseName $databaseName

Transact-SQL

För att omvänd migre en Hyperscale-databas till tjänstnivån Generell användning med Transact-SQL, anslut först till master-databasen på din logiska SQL-server med hjälp av SQL Server Management Studio (SSMS), Azure Data Studio.

Du måste ange både utgåva och tjänstmål i kommandot ALTER DATABASE.

Det här exemplet migrerar en databas med namnet mySampleDatabase till tjänstnivån Generell användning med GP_Gen5_4 tjänstmål. Ersätt databasnamnet och tjänstmålet med lämpliga värden innan du kör instruktionen.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2');
GO

Du kan också ta med argumentet maxsize. Om maxsize-värdet överskrider den giltiga maximala storleken för måltjänstmålet returneras ett fel. Om argumentet maxsize inte har angetts är åtgärden som standard den maximala storleken som är tillgänglig för det angivna tjänstmålet. I följande exempel anges maxsize:

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2', MAXSIZE = 200 GB);
GO

Om du vill övervaka åtgärder för en Hyperskala-databas ansluter du till master-databasen för din logiska server med hjälp av SQL Server Management Studio (SSMS), mssql-tillägget för Visual Studio Codeeller den klient som du väljer att köra Transact-SQL kommandon.

Fråga sys.dm_operation_status dynamisk hanteringsvy för att granska information om de senaste åtgärderna som utförts på databaser på din logiska server.

Den dynamiska hanteringsvyn sys.dm_operation_status returnerar åtgärder sorterade efter senaste tidpunkt. Ersätt databasnamnet med lämpligt värde innan du kör kodexemplet.

SELECT *
FROM sys.dm_operation_status
WHERE major_resource_id = 'mySampleDatabase'
ORDER BY start_time DESC;
GO

Relaterat innehåll

• Hur du hanterar en hyperscale-databas
• Konvertera en befintlig databas till Hyperskala