Hantera en Hyperskala-databas

Gäller för:Azure SQL Database

Tjänstnivån Hyperskala ger en mycket skalbar lagrings- och beräkningsprestandanivå som utnyttjar Azure-arkitekturen för att skala ut lagrings- och beräkningsresurser för en Azure SQL Database avsevärt utöver de gränser som är tillgängliga för tjänstnivåerna Generell användning och Affärskritisk. Den här artikeln beskriver hur du utför viktiga administrationsuppgifter för Hyperskala-databaser, inklusive migrering av en befintlig databas till Hyperskala, återställning av en Hyperskala-databas till en annan region, omvänd migrering från Hyperskala till en annan tjänstnivå och övervakning av status för pågående och senaste åtgärder mot en Hyperskala-databas.

Lär dig hur du skapar en ny Hyperskala-databas i Snabbstart: Skapa en Hyperskala-databas i Azure SQL Database.

Dricks

Förenklade priser för SQL Database Hyperscale kommer snart. Mer information finns i prissättningsbloggen för Hyperskala.

Migrera en befintlig databas till Hyperskala

Du kan migrera befintliga databaser i Azure SQL Database till Hyperskala med hjälp av Azure-portalen, Azure CLI, PowerShell eller Transact-SQL.

Den tid som krävs för att flytta en befintlig databas till Hyperskala består av tiden för att kopiera data och tiden för att spela upp de ändringar som gjorts i källdatabasen vid kopiering av data. Datakopieringstiden är proportionell mot datastorleken. Vi rekommenderar att du migrerar till Hyperskala under en lägre skrivaktivitetsperiod så att tiden för att spela upp ackumulerade ändringar blir kortare.

Du får bara en kort tids stilleståndstid, vanligtvis några minuter, under den sista snabbheten till tjänstnivån Hyperskala.

Förutsättningar

Om du vill flytta en databas som är en del av en geo-replikeringsrelation , antingen som primär eller sekundär, till Hyperskala, måste du först avsluta datareplikeringen mellan den primära och sekundära repliken. Databaser i en redundansgrupp måste tas bort från gruppen först.

När en databas har flyttats till Hyperskala kan du skapa en ny hyperskala-geo-replik för databasen.

Migrera en databas till tjänstnivån Hyperskala

Om du vill migrera en befintlig databas i Azure SQL Database till tjänstnivån Hyperskala ska du först identifiera måltjänstmålet. Granska resursgränser för enskilda databaser om du inte är säker på vilket tjänstmål som passar din databas. I många fall kan du välja ett tjänstmål med samma antal virtuella kärnor och samma maskinvarugenerering som den ursprungliga databasen. Om det behövs kan du ändra tjänstmålet med minimal stilleståndstid.

Välj fliken för önskat verktyg för att migrera databasen:

Portal

Med Azure-portalen kan du migrera till tjänstnivån Hyperskala genom att ändra prisnivån för databasen.

1. Navigera till den databas som du vill migrera i Azure-portalen.
2. I det vänstra navigeringsfältet väljer du Beräkning + lagring.
3. Välj listrutan Tjänstnivå för att expandera alternativen för tjänstnivåer.
4. Välj Hyperskala (skalbar lagring på begäran) på den nedrullningsbara menyn.
5. Granska maskinvarukonfigurationen i listan. Om du vill väljer du Ändra konfiguration för att välja lämplig maskinvarukonfiguration för din arbetsbelastning.
6. Granska alternativet spara pengar. Välj den om du är berättigad till Azure Hybrid-förmån och vill använda den för den här databasen.
7. Välj skjutreglaget för virtuella kärnor om du vill ändra antalet virtuella kärnor som är tillgängliga för databasen under tjänstnivån Hyperskala.
8. Välj skjutreglaget High-AvailabilitySecondaryReplicas om du vill ändra antalet repliker under tjänstnivån Hyperskala.
9. Välj Använd.

Du kan övervaka åtgärder för en Hyperskala-databas medan åtgärden pågår.

Azure CLI

Det här kodexemplet anropar az sql db update för att migrera en befintlig databas i Azure SQL Database till tjänstnivån Hyperskala. Du måste ange både utgåva och tjänstmål.

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="HS_Gen5_2"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition Hyperscale --service-objective $serviceObjective

Du kan övervaka åtgärder för en Hyperskala-databas medan åtgärden pågår.

PowerShell

I följande exempel används cmdleten Set-AzSqlDatabase för att migrera en befintlig databas i Azure SQL Database till tjänstnivån Hyperskala. Du måste ange både utgåva och tjänstmål.

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

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

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "Hyperscale" `
    -RequestedServiceObjectiveName $serviceObjective

Du kan övervaka åtgärder för en Hyperskala-databas medan åtgärden pågår.

Transact-SQL

Om du vill migrera en befintlig databas i Azure SQL Database till tjänstnivån Hyperskala med Transact-SQL ansluter du först till databasen på den master logiska SQL-servern med azure-portalens frågeredigerare för Azure SQL Database, SQL Server Management Studio (SSMS) eller Azure Data Studio.

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

Det här exemplet migrerar en databas med namnet mySampleDatabase till tjänstnivån Hyperskala med HS_Gen5_2 tjänstmålet. Ersätt databasnamnet med lämpligt värde innan du kör -instruktionen.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_2');
GO

Du kan övervaka åtgärder för en Hyperskala-databas medan åtgärden pågår.

Omvänd migrering från Hyperskala

Omvänd migrering till tjänstnivån Generell användning gör att kunder som nyligen har migrerat en befintlig databas i Azure SQL Database till tjänstnivån Hyperskala kan flytta 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 princip en dataflytt 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 ångra migreringen till tjänstnivån Generell användning . Din migrering från Hyperskala till Generell användning kan riktas mot antingen serverlösa eller etablerade beräkningsnivåer. Om du vill migrera databasen till en annan tjänstnivå, till exempel Affärskritisk eller en DTU-baserad tjänstnivå, återställer du först migreringen till tjänstnivån Generell användning och ändrar sedan tjänstnivån.
• Direkt omvänd migrering från eller till en elastisk pool stöds inte. Du kan bara ångra migreringen av en enkel Hyperskala-databas till en enkel databas för generell användning.
  • Om Hyperskala-databasen är en del av en elastisk hyperskalapool (förhandsversion) må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 lägga till den enskilda databasen Generell användning i en elastisk pool för generell användning 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 Portal, från PowerShell med New-AzSqlDatabaseExport eller New-AzSqlDatabaseImport, från Azure CLI med az sql db export eller az sql db import, samt 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 måländring på tjänstnivå i Hyperskala är migrering till Hyperskala och omvänd migrering till Generell användning storleksanpassade dataå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.

Principer för säkerhetskopiering

Du debiteras med den vanliga prissättningen för alla befintliga databassäkerhetskopieringar 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 migrera en databas till Hyperskala och omvänd migrering tillbaka till Generell användning 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. Migrera till Hyperskala
3. Omvänd migrering till generell användning
4. Tjänstnivåändring till Affärskritisk
5. Migrera till Hyperskala
6. Omvänd migrering till generell användning

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 flera omvända migreringar från Hyperskala till nivån Generell användning.

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 utföra en ytterligare ändring av tjänstnivån efter omvänd migrering till generell användning identifierar du även ditt slutliga måltjänstmål och ser 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. Navigera till den databas som du vill migrera i Azure-portalen.
2. I det vänstra navigeringsfältet väljer du Beräkning + lagring.
3. Välj listrutan Tjänstnivå för att expandera alternativen för tjänstnivåer.
4. Välj Generell användning (skalbar beräkning och lagringsalternativ) på den nedrullningsbara menyn.
5. Granska maskinvarukonfigurationen i listan. Om du vill väljer du Ändra konfiguration för att välja lämplig maskinvarukonfiguration för din arbetsbelastning.
6. Granska alternativet spara pengar. Välj den om du är berättigad till Azure Hybrid-förmån och vill använda den för den här databasen.
7. Välj skjutreglaget för virtuella kärnor om du vill ändra antalet virtuella kärnor som är tillgängliga för databasen under tjänstnivån Generell användning.
8. Välj Använd.

Azure CLI

Det här kodexemplet anropar az sql db update för att omvänd migrera en befintlig Hyperskala-databas 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ä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å inkludera maxsize argumentet. Om värdet maxsize överskrider den giltiga maximala storleken för måltjänstmålet returneras ett fel. maxsize Om argumentet 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

Du kan övervaka åtgärder för en Hyperskala-databas medan åtgärden pågår.

PowerShell

Det här kodexemplet använder cmdleten Set-AzSqlDatabase för att omvänd migrera en befintlig databas från tjänstnivå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å inkludera maxsize argumentet. Om värdet maxsize överskrider den giltiga maximala storleken för måltjänstmålet returneras ett fel. maxsize Om argumentet 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

Du kan övervaka åtgärder för en Hyperskala-databas medan åtgärden pågår.

Transact-SQL

Om du vill ångra migreringen av en Hyperskala-databas till tjänstnivån Generell användning med Transact-SQL ansluter du först till master databasen på den logiska SQL-servern 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 ALTER DATABASE-instruktionen.

Det här exemplet migrerar en databas med namnet mySampleDatabase till tjänstnivån Generell användning med GP_Gen5_4 tjänstmålet. 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å inkludera maxsize argumentet. Om värdet maxsize överskrider den giltiga maximala storleken för måltjänstmålet returneras ett fel. maxsize Om argumentet 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

Du kan övervaka åtgärder för en Hyperskala-databas medan åtgärden pågår.

Övervaka åtgärder för en Hyperskala-databas

Du kan övervaka statusen för pågående eller nyligen slutförda åtgärder för en Azure SQL Database med hjälp av Azure-portalen, Azure CLI, PowerShell eller Transact-SQL.

Välj fliken för den metod som du föredrar för att övervaka åtgärder.

Portal

Azure-portalen visar ett meddelande för en databas i Azure SQL Database när en åtgärd som migrering, omvänd migrering eller återställning pågår.

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 rutan. Om åtgärder pågår visas en meddelanderuta.
4. Välj meddelanderutan för att visa information.
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 op-listan för att returnera senaste eller pågående åtgärder för en databas i Azure SQL Database.

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

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

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

PowerShell

Cmdleten Get-AzSqlDatabaseActivity 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

Om du vill övervaka åtgärder för en Hyperskala-databas ansluter du först till databasen på den masterlogiska servern med hjälp av SQL Server Management Studio (SSMS), Azure Data Studio eller den klient som du väljer för 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å [logisk server](logical-servers.md].

Det här kodexemplet returnerar alla hela i sys.dm_operation_status för den angivna databasen, sorterade efter vilka åtgärder som påbörjades senast. 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

Visa databaser på tjänstnivån Hyperskala

När du har migrerat en databas till Hyperskala eller konfigurerat om en databas på tjänstnivån Hyperskala kanske du vill visa och/eller dokumentera konfigurationen av hyperskaladatabasen.

Portal

Azure-portalen visar en lista över alla databaser på en logisk server. Kolumnen Prisnivå innehåller tjänstnivån för varje databas.

1. Gå till den logiska servern i Azure-portalen.
2. I det vänstra navigeringsfältet väljer du Översikt.
3. Rulla till listan över resurser längst ned i fönstret. Fönstret visar elastiska SQL-pooler och databaser på den logiska servern.
4. Granska kolumnen Prisnivå för att identifiera databaser på tjänstnivån Hyperskala.

Azure CLI

Det här Azure CLI-kodexemplet anropar az sql db-listan för att lista Hyperskala-databaser på en logisk server med deras namn, plats, servicenivåmål, maximal storlek och antal repliker med hög tillgänglighet.

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

resourceGroupName="myResourceGroup"
serverName="server01"

az sql db list -g $resourceGroupName -s $serverName --query "[].{Name:name, Location:location, SLO:currentServiceObjectiveName, Tier:currentSku.tier, maxSizeBytes:maxSizeBytes,HAreplicas:highAvailabilityReplicaCount}[?Tier=='Hyperscale']" --output table

PowerShell

Cmdleten Azure PowerShell Get-AzSqlDatabase returnerar en lista över Hyperskala-databaser på en logisk server med deras namn, plats, servicenivåmål, maximal storlek och antal repliker med hög tillgänglighet.

Ange parametrarna $resourceGroupName och $serverName till lämpliga värden innan du kör exempelkoden:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"

Get-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName | `
    Where-Object { $_.Edition -eq 'Hyperscale' } | `
        Select-Object DatabaseName, Location, currentServiceObjectiveName, Edition, `
        MaxSizeBytes, HighAvailabilityReplicaCount | `
            Format-Table

Granska kolumnen Edition för att identifiera databaser på tjänstnivån Hyperskala.

Transact-SQL

Om du vill granska tjänstnivåerna för alla Hyperskala-databaser på en logisk server med Transact-SQL ansluter du först till master databasen med SQL Server Management Studio (SSMS) eller Azure Data Studio.

Fråga sys.database_service_objectives systemkatalogvyn för att granska databaser på tjänstnivån Hyperskala:

SELECT d.name, dso.edition, dso.service_objective
FROM sys.database_service_objectives AS dso
JOIN sys.databases as d on dso.database_id = d.database_id
WHERE dso.edition = 'Hyperscale';
GO

Nästa steg

Läs mer om Hyperskala-databaser i följande artiklar:

• Snabbstart: Skapa en Hyperskala-databas i Azure SQL Database
• Hyperskala tjänstnivå
• Azure SQL Database Vanliga frågor och svar om hyperskala
• Sekundära repliker i hyperskala
• Vanliga frågor och svar om Azure SQL Database Hyperskala med namnet replicas