Partilhar via

Migrar o Banco de Dados SQL do Azure do modelo baseado em DTU para o modelo baseado em vCore

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

Este artigo descreve como migrar seu banco de dados no Banco de Dados SQL do Azure do modelo de compra baseado em DTU para o modelo de compra baseado em vCore.

Migrar uma base 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 Basic, 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 de volta para o modelo de compra baseado em DTU a qualquer momento da mesma maneira, com exceção dos bancos de dados migrados para a camada de serviço Hyperscale .

Escolha a camada de serviço vCore e o objetivo do serviço

Para a maioria dos cenários de migração DTU para vCore, os bancos de dados e pools elásticos nas camadas de serviço Básico e Standard serão mapeados para a camada de serviço de Propósito Geral . Os bancos de dados e pools elásticos na camada de serviço Premium serão mapeados para a camada de serviço Crítica para os Negócios. Dependendo do cenário e dos requisitos do aplicativo, a camada de serviço Hyperscale pode ser usada frequentemente como destino de migração para bancos de dados e pools elásticos em todas as camadas de serviço DTU.

Para escolher o objetivo do serviço, ou o tamanho de computação, para o banco de dados migrado no modelo vCore, você pode usar uma regra prática simples, mas aproximada: cada 100 DTUs nas camadas Basic ou Standard exigem pelo menos 1 vCore, e cada 125 DTUs na camada Premium exigem pelo menos 1 vCore.

Gorjeta

Essa regra é aproximada porque não considera o tipo específico de hardware usado para o banco de dados DTU ou pool elástico.

No modelo DTU, o sistema pode selecionar qualquer configuração de hardware disponível para seu banco de dados ou pool elástico. Além disso, no modelo DTU você tem apenas controle indireto sobre o número de vCores (CPUs lógicas) escolhendo valores de DTU ou eDTU mais altos ou mais baixos.

No modelo vCore, os clientes devem fazer uma escolha explícita da configuração de hardware e do número de vCores (CPUs lógicas). Embora o modelo DTU não ofereça 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 torna possível determinar o objetivo do serviço vCore correspondente com mais precisão.

A abordagem a seguir usa essas informações para determinar um objetivo de serviço vCore com uma alocação semelhante de recursos, para obter um nível semelhante de desempenho após a migração para o modelo vCore.

Mapeamento de DTU para vCore

Uma consulta T-SQL abaixo, quando executada no contexto de um banco de dados DTU a ser migrado, retorna um número correspondente (possivelmente fracionário) de vCores em cada configuração de hardware no modelo 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 vCore, os clientes podem escolher o objetivo de serviço vCore que é a correspondência mais próxima para seu banco de dados DTU ou pool elástico.

Exemplos de cenários de migração usando 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 master banco de dados. Ao migrar um pool elástico, execute a consulta no contexto de qualquer banco de dados no 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 do tipo de hardware, vários outros fatores podem influenciar a escolha do objetivo do serviço vCore:

  • A consulta Transact-SQL de mapeamento corresponde aos objetivos de serviço DTU e vCore em termos de capacidade de CPU, portanto, os resultados serão mais precisos para cargas de trabalho vinculadas à CPU.
  • Para o mesmo tipo de hardware e o mesmo número de vCores, os limites de recursos de IOPS e taxa de transferência do log de transações para bancos de dados vCore geralmente são maiores do que para bancos de dados DTU. Para cargas de trabalho ligadas a E/S, pode ser possível reduzir o número de vCores no modelo vCore para alcançar o mesmo nível de desempenho. Os limites reais de recursos para bancos de dados DTU e vCore são expostos na visualização sys.dm_user_db_resource_governance . Comparar esses valores entre o banco de dados ou pool DTU a ser migrado e um banco de dados ou pool vCore com um objetivo de serviço aproximadamente correspondente ajudará você a selecionar o objetivo de serviço vCore com mais precisão.
  • A consulta de mapeamento também retorna a quantidade de memória por núcleo para o banco de dados DTU ou pool elástico a ser migrado e para cada configuração de hardware no modelo vCore. Garantir memória total semelhante ou superior após a migração para vCore é importante para cargas de trabalho que exigem um cache de dados de memória grande para obter desempenho suficiente ou cargas de trabalho que exigem grandes concessões de memória para processamento de consultas. Para essas cargas de trabalho, dependendo do desempenho real, pode ser necessário aumentar o número de vCores para obter memória total suficiente.
  • A utilização de recursos históricos do banco de dados DTU deve ser considerada ao escolher o objetivo do serviço vCore. Os bancos de dados 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 DTU em que a utilização consistentemente alta da CPU causa um desempenho inadequado da carga de trabalho podem exigir mais vCores do que os retornados 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 Serverless . Observe que o número máximo de trabalhadores simultâneos no serverless é de 75% do limite na computação provisionada para o mesmo número máximo de vCores configurados. Além disso, a memória máxima disponível no serverless é 3 GB vezes o número máximo de vCores configurados, que é menor do que a memória por núcleo para computação provisionada. Por exemplo, no Gen5, a memória máxima é de 120 GB quando 40 vCores máximos são configurados sem servidor, contra 204 GB para uma computação provisionada de 40 vCore.
  • No modelo vCore, o tamanho máximo do banco de dados suportado pode diferir dependendo do hardware. Para bancos de dados grandes, verifique os tamanhos máximos suportados no modelo vCore para bancos de dados únicos e pools elásticos.
  • Para pools elásticos, os modelos DTU e vCore têm diferenças no número máximo suportado de bancos de dados 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.

Importante

As diretrizes de dimensionamento DTU para vCore acima são fornecidas para ajudar na estimativa inicial do objetivo do serviço de banco de dados de destino.

A configuração ideal do banco de dados de destino depende da carga de trabalho. Assim, para alcançar a relação preço/desempenho ideal após a migração, talvez seja necessário aproveitar a flexibilidade do modelo vCore para ajustar o número de vCores, a configuração de hardware e as camadas de serviço e computação. Também pode ser necessário ajustar os parâmetros de configuração do banco de dados, como o grau máximo de paralelismo, e/ou alterar o nível de compatibilidade do banco de dados para habilitar melhorias recentes no mecanismo de banco de dados.

Exemplos de migração de DTU para vCore

Nota

Os valores nos exemplos abaixo são apenas para fins ilustrativos. Os valores reais retornados nos cenários descritos podem ser diferentes.

Migrando um banco de dados Standard S9

A consulta de mapeamento retorna o seguinte resultado (algumas colunas não são mostradas para 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 DTU tem 24 CPUs lógicas (vCores), com 5,4 GB de memória por vCore. A correspondência direta com isso é um banco de dados vCore de uso geral 2 em hardware de série padrão (Gen5), o objetivo de serviço vCore GP_Gen5_24 .

Migrando um banco de dados Standard S0

A consulta de mapeamento retorna o seguinte resultado (algumas colunas não são mostradas para 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 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 vCore na configuração de hardware da série padrão (Gen5), GP_Gen5_2, fornecem mais recursos de computação do que o banco de dados Standard S0, portanto, uma correspondência direta não é possível. É preferível a opção GP_Gen5_2 . Além disso, se a carga de trabalho for adequada para a camada de computação sem servidor, GP_S_Gen5_1 será uma correspondência mais próxima.

Migrando um banco de dados Premium P15

A consulta de mapeamento retorna o seguinte resultado (algumas colunas não são mostradas para 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 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.

Migrando um pool elástico Basic 200 eDTU

A consulta de mapeamento retorna o seguinte resultado (algumas colunas não são mostradas para 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 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 suporta um máximo de 200 bancos de dados por pool, enquanto o pool elástico Basic 200 eDTU suporta até 500 bancos de dados. Se o pool elástico a ser migrado tiver mais de 200 bancos de dados, o objetivo do serviço vCore correspondente terá que ser GP_Gen5_6, que suporta até 500 bancos de dados.

Migrar bancos de dados replicados geograficamente

A migração do modelo baseado em DTU para o modelo de compra baseado em vCore é semelhante ao upgrade ou 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, não é necessário interromper a replicação geográfica, mas seguir estas regras de sequenciamento:

  • Ao atualizar, você deve atualizar o banco de dados secundário primeiro e, em seguida, atualizar o primário.
  • Ao fazer o downgrade, inverta a ordem: você deve fazer o downgrade do banco de dados primário primeiro e, em seguida, fazer o downgrade do secundário.

Ao usar a replicação geográfica entre dois pools elásticos, recomendamos que você designe um pool como primário e o outro como secundário. Nesse caso, ao migrar pools elásticos, você deve usar 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 principal e siga as regras de sequenciamento de acordo.

A tabela a seguir fornece orientação 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 Fins Gerais Laterais Pode migrar em qualquer ordem, mas precisa garantir o dimensionamento vCore apropriado, conforme descrito acima
Premium Crítico para a Empresa Laterais Pode migrar em qualquer ordem, mas precisa garantir o dimensionamento vCore apropriado, conforme descrito acima
Standard Crítico para a Empresa Atualizar Deve migrar secundário primeiro
Crítico para a Empresa Standard Mudar para uma versão anterior Deve migrar primeiro o primário
Premium Fins Gerais Mudar para uma versão anterior Deve migrar primeiro o primário
Fins Gerais Premium Atualizar Deve migrar secundário primeiro
Crítico para a Empresa Fins Gerais Mudar para uma versão anterior Deve migrar primeiro o primário
Fins Gerais Crítico para a Empresa Atualizar Deve migrar secundário primeiro

Migrar grupos de failover

A migração de grupos de failover com vários bancos de dados requer migração individual dos bancos de dados primários e secundários. Durante esse processo, aplicam-se as mesmas considerações e regras de sequenciação. 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 de replicação geográfica

Você pode criar um banco de dados secundário de replicação geográfica (um geosecundário) somente usando a mesma camada de serviço usada para o banco de dados primário. Para bancos de dados com alta taxa de geração de logs, recomendamos a criação do geosecundário com o mesmo tamanho de computação do primário.

Se você estiver criando um geosecundário no pool elástico para um único banco de dados primário, verifique se a maxVCore configuração do pool corresponde ao tamanho de computação do banco de dados primário. Se você estiver criando um geosecundário para um primário em outro pool elástico, recomendamos que os pools tenham as mesmas maxVCore configurações.

Usar cópia de banco de dados para migrar de DTU para vCore

Você pode copiar qualquer banco de dados com um tamanho de computação baseado em DTU para um banco de dados com um tamanho de computação baseado em vCore sem restrições ou sequenciamento especial, desde que o tamanho de computação de destino ofereça suporte ao tamanho máximo do banco de dados de origem. A cópia do banco de dados cria um instantâneo transacionalmente consistente dos dados a partir de um ponto no tempo após o início da operação de cópia. Ele não sincroniza dados entre a origem e o destino após esse point-in-time.

Próximos passos