Migrar o Banco de Dados SQL do Azure do modelo baseado em DTU para o modelo baseado em vCore
Aplica-se a: 
Banco de Dados SQL do Azure
Este artigo descreve como migrar seu banco de dados do Banco de Dados SQL do Azure do modelo de compra baseado em DTU para o modelo de compra baseado em vCore.
Migrar um banco de dados
A migração de um banco de dados do modelo de compra baseado em DTU para o modelo de compra baseado em vCore é semelhante ao dimensionamento entre os objetivos de serviço nas camadas de serviço Básico, Standard e Premium, com duração semelhante e um tempo de inatividade mínimo no final do processo de migração. Um banco de dados migrado para o modelo de compra baseado em vCore pode ser migrado novamente para o modelo de compra baseado em DTU a qualquer momento usando as mesmas etapas, com a exceção dos bancos de dados migrados para a camada de serviço Hiperescala.
Você pode migrar seu banco de dados para um modelo de compra diferente usando o portal do Azure, o PowerShell, a CLI do Azure e o Transact-SQL.
Para migrar seu banco de dados para um modelo de compra diferente usando o portal do Azure, execute estas etapas:
Vá para o seu banco de dados SQL no portal do Azure.
Selecione Computação + Armazenamento em Configurações.
Use a lista suspensa em Camada de serviço para selecionar um novo modelo de compra e camada de serviço:
Escolher a camada de serviço de vCore e o objetivo de serviço
Na maioria dos casos de migração de DTU para vCore, os bancos de dados e os pools elásticos nas camadas de serviço Básico e Standard serão mapeados para a camada de serviço Uso Geral. Os bancos de dados e os pools elásticos na camada de serviço Premium serão mapeados para a camada de serviço Comercialmente Crítico. Dependendo do cenário e dos requisitos do aplicativo, a camada de serviço Hiperescala pode ser frequentemente usada como o destino de migração para bancos de dados e pools elásticos individuais em todas as camadas de serviço de DTU.
Para escolher o objetivo de serviço ou o tamanho da computação para o banco de dados migrado no modelo de vCore, use uma regra prática básica, mas aproximada: a cada 100 DTUs nas camadas Básico ou Standard, é necessário, no mínimo, 1 vCore, e a cada 125 DTUs na camada Premium, é necessário, no mínimo, 1 vCore.
Dica
Essa regra é aproximada porque não considera o tipo específico de hardware usado para o pool elástico ou o banco de dados de DTU.
No modelo de DTU, o sistema poderia selecionar qualquer configuração de hardware disponível para o banco de dados ou o pool elástico. Além disso, modelo de DTU, você tem apenas controle indireto sobre o número de vCores (CPUs lógicas), escolhendo valores de DTU ou de eDTU maiores ou menores.
No modelo de vCore, os clientes precisam fazer uma escolha explícita da configuração de hardware e do número de vCores (CPUs lógicas). Enquanto o modelo de DTU não oferece essas opções, o tipo de hardware e o número de CPUs lógicas usadas para cada banco de dados e pool elástico são expostos por meio de exibições de gerenciamento dinâmico. Isso possibilita determinar o objetivo de serviço de vCore correspondente com mais precisão.
A abordagem a seguir usa essas informações para determinar um objetivo de serviço de vCore com uma alocação semelhante de recursos, para obter um nível de desempenho semelhante após a migração para o modelo de vCore.
Mapeamento de DTU para vCore
A consulta Transact-SQL a seguir, quando executada no contexto de um banco de dados de DTU a ser migrado, retorna um número correspondente (possivelmente fracionário) de vCores em cada configuração de hardware no modelo de vCore. Você pode arredondar esse número para o número mais próximo de vCores disponíveis para bancos de dados e pools elásticos em cada configuração de hardware no modelo de vCore, os clientes podem escolher o objetivo de serviço de vCore que seja a correspondência mais próxima com o pool elástico ou o banco de dados de DTU.
Os cenários de migração de exemplo que usam essa abordagem são descritos na seção Exemplos.
Execute essa consulta no contexto do banco de dados a ser migrado, em vez de no banco de dados master. Ao migrar um pool elástico, execute a consulta no contexto de qualquer banco de dados do pool.
;WITH dtu_vcore_map
AS (
SELECT rg.slo_name,
CAST(DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS NVARCHAR(40)) COLLATE DATABASE_DEFAULT AS dtu_service_tier,
CASE
WHEN slo.slo_name LIKE '%SQLG4%' THEN 'Gen4' --Gen4 is retired.
WHEN slo.slo_name LIKE '%SQLGZ%' THEN 'Gen4' --Gen4 is retired.
WHEN slo.slo_name LIKE '%SQLG5%' THEN 'standard_series'
WHEN slo.slo_name LIKE '%SQLG6%' THEN 'standard_series'
WHEN slo.slo_name LIKE '%SQLG7%' THEN 'standard_series'
WHEN slo.slo_name LIKE '%GPGEN8%' THEN 'standard_series'
END COLLATE DATABASE_DEFAULT AS dtu_hardware_gen,
s.scheduler_count * CAST(rg.instance_cap_cpu / 100. AS DECIMAL(3, 2)) AS dtu_logical_cpus,
CAST((jo.process_memory_limit_mb / s.scheduler_count) / 1024. AS DECIMAL(4, 2)) AS dtu_memory_per_core_gb
FROM sys.dm_user_db_resource_governance AS rg
CROSS JOIN (
SELECT COUNT(1) AS scheduler_count
FROM sys.dm_os_schedulers
WHERE status COLLATE DATABASE_DEFAULT = 'VISIBLE ONLINE'
) AS s
CROSS JOIN sys.dm_os_job_object AS jo
CROSS APPLY (SELECT UPPER(rg.slo_name) COLLATE DATABASE_DEFAULT AS slo_name) slo
WHERE rg.dtu_limit > 0
AND DB_NAME() COLLATE DATABASE_DEFAULT <> 'master'
AND rg.database_id = DB_ID()
)
SELECT dtu_logical_cpus,
dtu_memory_per_core_gb,
dtu_service_tier,
CASE
WHEN dtu_service_tier = 'Basic' THEN 'General Purpose'
WHEN dtu_service_tier = 'Standard' THEN 'General Purpose or Hyperscale'
WHEN dtu_service_tier = 'Premium' THEN 'Business Critical or Hyperscale'
END AS vcore_service_tier,
CASE
WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.7
WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus
END AS standard_series_vcores,
5.05 AS standard_series_memory_per_core_gb,
CASE
WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.8
END AS Fsv2_vcores,
1.89 AS Fsv2_memory_per_core_gb,
CASE
WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.4
WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.9
END AS M_vcores,
29.4 AS M_memory_per_core_gb
FROM dtu_vcore_map;
Fatores adicionais
Além do número de vCores (CPUs lógicas) e da tipo de hardware, vários outros fatores podem influenciar a escolha do objetivo de serviço de vCore:
A consulta Transact-SQL de mapeamento faz a correspondência dos objetivos de serviço de DTU e vCore em termos da capacidade de CPU. Portanto, os resultados são mais precisos para cargas de trabalho associadas à CPU.
Para a mesma tipo de hardware e o mesmo número de vCores, os limites de recursos de taxa de transferência de log de transações e da IOPS para bancos de dados de vCore são geralmente maiores do que para bancos de dados de DTU. Para cargas de trabalho associadas a E/S, talvez seja possível reduzir o número de vCores no modelo de vCore para obter o mesmo nível de desempenho. Os limites de recursos reais para bancos de dados de DTU e vCore são expostos na exibição sys.dm_user_db_resource_governance. A comparação desses valores entre o banco de dados ou pool de DTU a ser migrado e um banco de dados ou pool de vCore com um objetivo de serviço com correspondência aproximada pode ajudar a escolher o objetivo de serviço de vCore com mais precisão.
A consulta de mapeamento também retorna a quantidade de memória por núcleo para o pool elástico ou o banco de dados de DTU a ser migrado e para cada configuração de hardware no modelo de vCore. É importante garantir uma memória total semelhante ou superior após a migração para vCore para as cargas de trabalho que exigem um cache de dados de memória grande a fim de obter desempenho suficiente ou para cargas de trabalho que exigem grandes concessões de memória para o processamento de consultas. Para essas cargas de trabalho, dependendo do desempenho real, talvez seja necessário aumentar o número de vCores para obter uma memória total suficiente.
A utilização de recursos históricos do banco de dados de DTU deve ser considerada na escolha do objetivo de serviço de vCore. Os bancos de dados de DTU com recursos de CPU consistentemente subutilizados podem precisar de menos vCores do que o número retornado pela consulta de mapeamento. Por outro lado, os bancos de dados de DTU em que uma utilização de CPU consistentemente alta causa um desempenho inadequado da carga de trabalho pode exigir mais vCores do que o retornado pela consulta.
Se estiver migrando bancos de dados com padrões de uso intermitentes ou imprevisíveis, considere o uso da camada de computação sem servidor para Banco de Dados SQL do Azure. O número máximo de trabalhos simultâneos (solicitações) na camada sem servidor é de 75% do limite na computação provisionada para o mesmo número máximo de vCores configurado. Além disso, a memória máxima disponível na camada sem servidor é de 3 GB vezes o número máximo de vCores configurados, que é menor do que a memória por núcleo para a computação provisionada. Por exemplo, no Gen5 a memória máxima é de 120 GB quando no máximo 40 vCores são configurados sem servidor, em comparação com 204 GB para uma computação provisionada de 40 vCores.
No modelo de vCore, o tamanho máximo de banco de dados com suporte pode ser diferente dependendo do hardware. Para bancos de dados grandes, verifique os tamanhos máximos com suporte no modelo de vCore para bancos de dados individuais e pools elásticos.
Para pools elásticos, os modelos Limites de recursos em pools elásticos usando o modelo de compra baseado em DTU e vCore têm diferenças no número máximo de bancos de dados com suporte por pool. Isso deve ser considerado ao migrar pools elásticos com muitos bancos de dados.
Algumas configurações de hardware podem não estar disponíveis em todas as regiões. Verifique a disponibilidade em Configuração de hardware para o Banco de Dados SQL.
As diretrizes de dimensionamento de DTU para vCore fornecidas nesta seção ajudam na estimativa inicial do objetivo de serviço do banco de dados de destino.
A configuração ideal do banco de dados de destino é dependente da carga de trabalho. Portanto, para atingir a taxa de preço/desempenho ideal após a migração, talvez seja necessário usar a flexibilidade do modelo vCore para ajustar o número de vCores, configuração de hardware e camadas de serviço e computação. Talvez também seja necessário ajustar parâmetros de configuração do banco de dados, como grau máximo de paralelismo e/ou alterar o nível de compatibilidade do banco de dados para permitir melhorias recentes no mecanismo de banco de dados.
Exemplos de migração de DTU para vCore
Observação
Os valores mostrados nos exemplos a seguir são apenas para fins ilustrativos. Os valores reais retornados nos cenários descritos podem ser diferentes.
Como migrar um banco de dados S9 Standard
A consulta de mapeamento retorna o seguinte resultado (algumas colunas não são mostradas para fins de brevidade):
| dtu_logical_cpus | dtu_memory_per_core_gb | standard_series_vcores | standard_series_memory_per_core_gb |
|---|---|---|---|
| 24,00 | 5,40 | 24,000 | 5,05 |
Vemos que o banco de dados padrão da DTU tem 24 CPUs lógicas (vCores), com 5,4 GB de memória por vCore. A correspondência direta com ele é um banco de dados de 2 vCores de Uso Geral em hardware de série padrão (Gen5), o objetivo de serviço de vCore GP_Gen5_24.
Como migrar um banco de dados S0 Standard
A consulta de mapeamento retorna o seguinte resultado (algumas colunas não são mostradas para fins de brevidade):
| dtu_logical_cpus | dtu_memory_per_core_gb | standard_series_vcores | standard_series_memory_per_core_gb |
|---|---|---|---|
| 0,25 | 1,3 | 0,500 | 5,05 |
Vemos que o banco de dados da DTU tem o equivalente a 0,25 CPUs lógicas (vCores), com 1,3 GB de memória por vCore. Os menores objetivos de serviço de vCore na configuração de hardware da série Standard (Gen5), GP_Gen5_2, fornecem mais recursos de computação do que o banco de dados S0 Standard. Portanto, uma correspondência direta não é possível. A opção GP_Gen5_2 é preferencial. Além disso, se a carga de trabalho for adequada à camada de computação Sem servidor, GP_S_Gen5_1 será uma correspondência mais próxima.
Como migrar um banco de dados P15 Premium
A consulta de mapeamento retorna o seguinte resultado (algumas colunas não são mostradas para fins de brevidade):
| dtu_logical_cpus | dtu_memory_per_core_gb | standard_series_vcores | standard_series_memory_per_core_gb |
|---|---|---|---|
| 42,00 | 4,86 | 42,000 | 5,05 |
Vemos que o banco de dados da DTU tem 42 CPUs lógicas (vCores), com 4,86 GB de memória por vCore. Embora não haja um objetivo de serviço vCore com 42 núcleos, o objetivo de serviço BC_Gen5_40 é quase equivalente em termos de CPU e capacidade de memória e é uma boa combinação.
Como migrar um pool elástico Básico de 200 eDTUs
A consulta de mapeamento retorna o seguinte resultado (algumas colunas não são mostradas para fins de brevidade):
| dtu_logical_cpus | dtu_memory_per_core_gb | standard_series_vcores | standard_series_memory_per_core_gb |
|---|---|---|---|
| 4,00 | 5,40 | 4,000 | 5,05 |
Vemos que o pool elástico da DTU tem 4 CPUs lógicas (vCores), com 5,4 GB de memória por vCore. O hardware da série padrão exige 4 vCores. No entanto, esse objetivo de serviço dá suporte a, no máximo, 200 bancos de dados por pool, enquanto o pool elástico Básico de 200 eDTUs dá suporte a até 500 bancos de dados. Se o pool elástico a ser migrado tiver mais de 200 bancos de dados, o objetivo de serviço de vCore correspondente precisará ser GP_Gen5_6, que dá suporte a até 500 bancos de dados.
Migrar bancos de dados com replicação geográfica
A migração do modelo baseado em DTU para o modelo de compra baseado em vCore é semelhante ao upgrade ou ao downgrade das relações de replicação geográfica entre bancos de dados nas camadas de serviço Standard e Premium. Durante a migração, você não precisa parar a replicação geográfica para as camadas de serviço Uso Geral e Comercialmente Crítico, mas deve seguir estas regras de sequenciamento:
- Ao atualizar, será necessário primeiro fazer upgrade do banco de dados secundário e, em seguida, upgrade do primário.
- Ao fazer downgrade, inverta a ordem: primeiro, você deverá fazer downgrade do banco de dados primário e, em seguida, fazer downgrade do secundário.
Para migrar para a camada de serviço de Hiperescala, a replicação geográfica deverá ser removida temporariamente. Para obter mais informações, consulte Migrar um banco de dados existente para Hiperescala.
Quando você estiver usando a replicação geográfica entre dois pools elásticos, recomendaremos que você defina um pool como o primário e o outro como o secundário. Nesse caso, ao migrar pools elásticos, use as mesmas diretrizes de sequenciamento. No entanto, se você tiver pools elásticos que contenham bancos de dados primários e secundários, trate o pool com a utilização mais alta como o primário e siga as regras de sequenciamento de acordo.
A seguinte tabela fornece diretrizes para cenários de migração específicos:
| Camada de serviço atual | Camada de serviço de destino | Tipo de migração | Ações do usuário |
|---|---|---|---|
| Standard | Uso Geral | Lateral | Pode migrar em qualquer ordem, mas é necessário garantir o dimensionamento apropriado de vCore, conforme descrito anteriormente |
| Premium | Comercialmente Crítico | Lateral | Pode migrar em qualquer ordem, mas é necessário garantir o dimensionamento apropriado de vCore, conforme descrito anteriormente |
| Standard | Comercialmente Crítico | Atualizar | Deve migrar primeiro o secundário |
| Comercialmente Crítico | Standard | Downgrade | Deve migrar primeiro o primário |
| Premium | Uso Geral | Downgrade | Deve migrar primeiro o primário |
| Uso Geral | Premium | Atualizar | Deve migrar primeiro o secundário |
| Comercialmente Crítico | Uso Geral | Downgrade | Deve migrar primeiro o primário |
| Uso Geral | Comercialmente Crítico | Atualizar | Deve migrar primeiro o secundário |
| Standard | Hiperescala | Lateral | A replicação geográfica deve ser desativada antes da migração para a Hiperescala |
| Premium | Hiperescala | Lateral | A replicação geográfica deve ser desativada antes da migração para a Hiperescala |
Migrar grupos de failover
A migração de grupos de failover com vários bancos de dados requer a migração individual dos bancos de dados primário e secundário. Durante esse processo, as mesmas considerações e regras de sequenciamento se aplicam. Depois que os bancos de dados forem convertidos para o modelo de compra baseado em vCore, o grupo de failover permanecerá em vigor com as mesmas configurações de política.
Criar um banco de dados secundário com replicação geográfica
Você só pode criar um banco de dados secundário com replicação geográfica (um secundário geográfico) usando a mesma camada de serviço usada para o banco de dados primário. Para bancos de dados com uma alta taxa de geração de logs, recomendamos criar o secundário geográfico com o mesmo tamanho da computação do primário.
Se você criar um secundário geográfico no pool elástico para um banco de dados primário individual, verifique se a configuração maxVCore do pool corresponde ao tamanho da computação do banco de dados primário. Se você criar um secundário geográfico no pool elástico para um primário em outro pool elástico, recomendamos que os pools tenham as mesmas configurações de maxVCore.
Usar a cópia de banco de dados para a migração de DTU para vCore
A cópia do banco de dados cria um instantâneo transacionalmente consistente dos dados como um ponto no tempo depois que a operação de cópia é iniciada. Ele não sincroniza dados entre a origem e o destino após esse momento determinado.
É possível copiar qualquer banco de dados com um tamanho da computação baseado em DTU para um banco de dados com um tamanho da computação baseado em vCore usando PowerShell, CLI do Azure ou Transact-SQL sem restrições ou sequenciamento especial, desde que o tamanho da computação de destino dê suporte ao tamanho máximo do banco de dados de origem. Não há suporte para copiar um banco de dados para uma camada de serviço diferente no portal do Azure.