Reverter a migração de um banco de dados do Hyperscale

Aplica-se a:Banco de Dados SQL do Azure

Você pode migrar um banco de dados Hyperscale existente no Banco de Dados SQL do Azure para a camada de serviço de Propósito Geral usando o portal do Azure, a CLI do Azure, o PowerShell ou o Transact-SQL.

A migração reversa para a camada de serviço de Uso Geral permite que os clientes que converteram recentemente um banco de dados existente no Banco de Dados SQL do Azure para o Hyperscale voltem em uma emergência, caso o Hyperscale não atenda às suas necessidades. Embora a migração reversa seja iniciada por uma alteração na camada de serviço, ela é essencialmente uma movimentação de tamanho de dados entre arquiteturas diferentes.

Limitações da migração inversa

A migração inversa está disponível nas seguintes condições:

• A migração reversa só está disponível dentro de 45 dias após a migração original para o Hyperscale.
• Os bancos de dados criados originalmente na camada de serviço Hyperscale não são qualificados para migração reversa.
• Você pode realizar a migração reversa somente para a camada de serviço de uso geral. Sua migração do Hyperscale para o General Purpose pode ter como destino as camadas de computação sem servidor ou provisionadas. Se desejar migrar o banco de dados para outra camada de serviço, como Business Critical ou uma camada de serviço baseada em DTU, primeiro faça a migração reversa para a camada de serviço de uso geral e, em seguida, altere a camada de serviço.
• Não há suporte para migração reversa para bancos de dados com menos de 2 vCores. Você pode reduzir o banco de dados para menos de 2 vCores assim que a migração for concluída.
• Não há suporte para migração reversa direta de, ou para, um pool elástico. Você pode reverter a migração apenas de um único banco de dados Hyperscale para um banco de dados único de uso geral.
  • Se o banco de dados Hyperscale fizer parte de um pool elástico Hyperscale, você precisará primeiro removê-lo do pool elástico Hyperscale antes da migração reversa.
  • Após a conclusão da migração reversa, você pode, opcionalmente, adicionar o banco de dados único de Uso Geral a um pool elástico de Propósito Geral, se necessário.
• Para bancos de dados que não se qualificam para migração reversa, a única maneira de migrar da Hyperscale para uma camada de serviço que não seja Hyperscale é exportar/importar usando um arquivo bacpac ou outras tecnologias de movimentação de dados (Bulk Copy, Azure Data Factory, Azure Databricks, SSIS, etc.) Não há suporte para exportação/importação do Bacpac do portal do Azure, do PowerShell usando New-AzSqlDatabaseExport ou New-AzSqlDatabaseImport, da CLI do Azure usando az sql db export e az sql db import, e da API REST. A importação/exportação do Bacpac para bancos de dados Hyperscale menores (até 150 GB) é suportada usando SSMS e SqlPackage versão 18.4 e posterior. Para bancos de dados maiores, a exportação/importação de bacpac pode levar muito tempo e pode falhar por vários motivos.

Duração e tempo de inatividade

Ao contrário das operações regulares de alteração de objetivo de nível de serviço no Hyperscale, a migração para o Hyperscale e a migração reversa para o General Purpose são operações dependentes do tamanho dos dados.

A duração de uma operação de migração reversa depende principalmente do tamanho do banco de dados e das atividades de gravação simultâneas que acontecem durante a migração. O número de vCores atribuídos ao banco de dados de uso geral de destino também afeta a duração da migração reversa. Recomendamos que você provisione o banco de dados de uso geral de destino com um número de vCores maior ou igual ao número de vCores atribuídos ao banco de dados Hyperscale de origem para sustentar cargas de trabalho semelhantes.

Durante a migração reversa, o banco de dados Hyperscale de origem pode sofrer degradação de desempenho se estiver sob carga substancial. Especificamente, a taxa de log de transações pode ser reduzida (limitada) para garantir que a migração reversa esteja progredindo.

Você experimentará um curto período de tempo de inatividade, geralmente alguns minutos, durante a transição final para o novo banco de dados de propósito geral de destino.

Pré-requisitos

Antes de iniciar uma migração reversa do Hyperscale para a camada de serviço de uso geral, você deve garantir que seu banco de dados atenda às limitações da migração reversa e:

• Seu banco de dados não tem a Replicação Geográfica habilitada.
• Seu banco de dados não tem réplicas nomeadas.
• Seu banco de dados (tamanho alocado) é pequeno o suficiente para caber na camada de serviço de destino.
• Se você especificar o tamanho máximo do banco de dados para o banco de dados de uso geral de destino, verifique se o tamanho alocado do banco de dados é pequeno o suficiente para caber nesse tamanho máximo.

As verificações de pré-requisitos ocorrem antes do início de uma operação de migração reversa. Se os pré-requisitos não forem atendidos, a operação de migração reversa falhará imediatamente.

Políticas de cópia de segurança

A cobrança é feita usando o preço normal para todos os backups de banco de dados existentes dentro do período de retenção configurado. Você é cobrado pelos snapshots de armazenamento de backup Hyperscale e pelos blobs de armazenamento com base no tamanho dos dados que devem ser mantidos para poder restaurar o backup.

Você pode converter um banco de dados para Hyperscale e reverter a migração de volta para o General Purpose várias vezes. Somente backups da camada atual e anterior do banco de dados estão disponíveis para restauração. Se você tiver mudado da camada de serviço de Propósito Geral para a Hiperescala e de volta para a Finalidade Geral, os únicos backups disponíveis são os do banco de dados de Propósito Geral atual e o banco de dados de Hiperescala imediatamente anterior. Esses backups retidos são cobrados de acordo com a cobrança do Banco de Dados SQL do Azure. Os níveis anteriores tentados não terão backups disponíveis e não serão cobrados.

Por exemplo, você pode migrar entre camadas de serviço Hyperscale e não Hyperscale:

1. Fins Gerais
2. Converter para Hyperscale
3. Migração reversa para uso geral
4. Alteração da camada de serviço para Crítico para o Negócio
5. Converter para Hyperscale
6. Migração reversa para uso geral

Nesse caso, os únicos backups disponíveis seriam das etapas 5 e 6 da linha do tempo, se ainda estiverem dentro do período de retenção configurado. Quaisquer backups de etapas anteriores não estariam disponíveis. Considere cuidadosamente a disponibilidade de backups ao tentar migrações repetidas do mesmo banco de dados entre as camadas de serviço Hyperscale e General Purpose. Os backups de bancos de dados anteriores ao banco de dados imediatamente anterior ficam indisponíveis assim que uma migração reversa é iniciada e permanecem indisponíveis mesmo se a migração for cancelada.

Como reverter a migração de um banco de dados Hyperscale para a camada de serviço de uso geral

Para reverter a migração de um banco de dados Hyperscale existente no Banco de Dados SQL do Azure para a camada de serviço de Propósito Geral, primeiro identifique seu objetivo de serviço de destino na camada de serviço de Propósito Geral e se deseja migrar para as camadas de computação provisionadas ou sem servidor. Revise os limites de recursos para bancos de dados únicos se não tiver certeza de qual objetivo de serviço é o certo para seu banco de dados.

Se desejar realizar uma alteração adicional na camada de serviço após a migração reversa para Propósito Geral, identifique seu eventual objetivo de serviço de destino. Certifique-se de que o tamanho alocado do banco de dados seja pequeno o suficiente para se encaixar nesse objetivo de serviço.

Selecione o separador para o seu método preferido de migração reversa do seu banco de dados.

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

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

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

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

$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

$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

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

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

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

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

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

Conteúdo relacionado

• Como gerenciar um banco de dados Hyperscale
• Converter um banco de dados existente em Hyperscale