Ajustar a escala dos recursos de banco de dados de modo dinâmica e com tempo de inatividade mínimo: Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure

  • Artigo

Aplica-se a: Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure

O Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure permitem que você adicione dinamicamente mais recursos ao seu banco de dados com tempo de inatividade mínimo. No entanto, há uma mudança no período em que a conectividade é perdida no banco de dados por um curto período de tempo, o que pode ser minimizado usando a lógica de repetição.

Visão geral

Quando a demanda de seu aplicativo aumenta de alguns dispositivos e clientes para milhões, o Banco de Dados SQL do Azure e a Instância Gerenciada de SQL são dimensionados de maneira dinâmica e com tempo de inatividade mínimo. A escalabilidade é uma das características mais importantes do PaaS (plataforma como serviço) que possibilita adicionar dinamicamente mais recursos ao serviço, quando necessário. O Banco de Dados SQL do Azure permite que você altere com facilidade os recursos (potência da CPU, memória, taxa de transferência de E/S e armazenamento) alocados a seus bancos de dados.

Você pode atenuar problemas de desempenho devido ao aumento no uso do aplicativo que não pode ser corrigido usando métodos de indexação ou de reescrita de consulta. A adição de mais recursos permite que você responda rapidamente quando seu banco de dados atingir os limites de recursos atuais e precisar de mais capacidade para manipular a carga de trabalho de entrada. O Banco de Dados SQL do Azure também possibilita que você reduza verticalmente os recursos quando eles não forem necessários para reduzir o custo.

Você não precisa se preocupar com a compra do hardware e a alteração da infraestrutura subjacente. O dimensionamento de um banco de dados pode ser feito com facilidade por meio do portal do Azure usando um controle deslizante.

Dimensionar o desempenho do banco de dados

O Banco de Dados SQL do Azure oferece o modelo de compra baseado em DTU e o modelo de compra baseado em vCore, enquanto a Instância Gerenciada de SQL do Azure oferece apenas o modelo de compra baseado em vCore.

  • O modelo de compra baseado em DTU oferece uma mistura de computação, memória e recursos de E/S em três camadas de serviço para dar suporte a cargas de trabalho leves e pesadas de banco de dados: Básico, Standard e Premium. Níveis de desempenho dentro de cada camada fornecem uma mistura diferente desses recursos, aos quais você pode adicionar recursos de armazenamento.
  • O modelo de compra baseado em vCore permite que você escolha o número de vCores, a quantidade ou memória e a quantidade e velocidade de armazenamento. O modelo de compra oferece três camadas de serviço: Uso Geral, Comercialmente Crítica e Hiperescala.

As camadas de serviço, de computação e os limites de recursos para um banco de dados, pool elástico ou instância gerenciada podem ser alterados a qualquer momento. Por exemplo, você pode criar seu primeiro aplicativo em um único banco de dados usando a camada de computação sem servidor e, em seguida, alterar sua camada de serviço manualmente ou por meio de programação a qualquer momento, para a camada de computação provisionada, para atender às necessidades de sua solução.

Observação

Exceções notáveis em que você não pode alterar a camada de serviço de um banco de dados são:

  • Os bancos de dados que usam recursos que estão disponíveis apenas nas camadas de serviço Comercialmente Crítico/Premium, não podem ser alterados para usar a camada de serviço Uso Geral/Standard. Atualmente, o único recurso desse tipo é o OLTP na memória.
  • Os bancos de dados originalmente criados na camada de serviço de Hiperescala não podem ser migrados para outras camadas de serviço. Se você tiver migrado um banco de dados existente no Banco de Dados SQL do Azure para a camada de serviço de Hiperescala, é possível fazer a migração reversa para a camada de serviço de Uso Geral em até 45 dias da migração original para a Hiperescala. Se você quiser migrar o banco de dados para outra camada de serviço, como Comercialmente Crítico, primeiro faça a migração reversa para a camada de serviço de Uso Geral e, em seguida, faça outra migração. Saiba mais em Como reverter a migração da Hiperescala.

Você pode ajustar os recursos alocados ao banco de dados alterando o objetivo de serviço ou dimensionamento para atender às demandas de carga de trabalho. Isso também permite que você pague apenas pelos recursos necessários, quando precisar deles. Consulte a nota sobre o impacto potencial que uma operação de escala pode ter em um aplicativo.

O Banco de Dados SQL do Azure oferece a capacidade de dimensionar dinamicamente seus bancos de dados:

  • Com um banco de dados individual, você pode usar modelos de DTU ou vCore para definir a quantidade máxima de recursos que serão atribuídos a cada banco de dados.
  • Os pools elásticos permitem que você defina o limite máximo de recursos por grupo de bancos de dados no pool.

A Instância Gerenciada de SQL do Azure também permite que você dimensione:

  • Uma Instância Gerenciada de SQL usa o modo vCores e permite que você defina o máximo de núcleos de CPU e o máximo de armazenamento alocado para sua instância. Todos os bancos de dados na instância gerenciada compartilharão os recursos alocados para a instância.

Dica

A escala dinâmica permite que os clientes alterem a alocação de recurso de forma manual ou programática. A capacidade de escala dinâmica está disponível para todos os recursos de Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

Além de dar suporte à escala dinâmica, a camada sem servidor no Banco de Dados SQL do Azure dá suporte ao dimensionamento automático. Os bancos de dados na camada sem servidor escalam recursos automaticamente dentro de um intervalo especificado pelo cliente, com base na demanda de carga de trabalho. Nenhuma ação do cliente é necessária para escalar o banco de dados.

Impacto das operações de aumento ou redução da escala

Iniciar uma ação de escalar verticalmente ou reduzir verticalmente, em qualquer uma das variantes mencionados acima, reinicia o processo do mecanismo de banco de dados e o move para uma máquina virtual diferente, se necessário. Mover o processo do mecanismo de banco de dados para uma nova máquina virtual é um processo online durante o qual você pode continuar usando o serviço de Banco de Dados SQL do Azure existente. Depois que o mecanismo de banco de dados de destino estiver pronto para processar consultas, as conexões abertas com o mecanismo de banco de dados atual serão encerradas e as transações não comprometidas serão revertidas. Novas conexões serão feitas com o mecanismo de banco de dados de destino.

Observação

Não é recomendável dimensionar sua instância gerenciada se uma transação de longa execução, como importação de dados, trabalhos de processamento de dados, recompilação de índice, etc., estiver em execução ou se você tiver qualquer conexão ativa na instância. Para evitar que o dimensionamento demore mais tempo para ser concluído do que o normal, você deve dimensionar a instância após a conclusão de todas as operações de execução longa.

Observação

Você pode esperar uma pequena interrupção de conexão quando o processo de dimensionar verticalmente/horizontalmente for concluído. Se você tiver implementado a lógica de repetição para erros transitórios padrão, não perceberá o failover.

Métodos alternativos de escala

O dimensionamento de recursos é a maneira mais fácil e mais eficiente para melhorar o desempenho do banco de dados sem alterar o código do banco de dados ou do aplicativo. Em alguns casos, até mesmo as camadas de serviço, os tamanhos da computação e as otimizações de desempenho mais altas podem não conseguir manipular a carga de trabalho com sucesso e de forma econômica. Nesse caso, há outras opções para dimensionar o banco de dados:

  • A escala de leitura é um recurso disponível em que você obtém uma réplica somente leitura de seus dados, na qual você pode executar consultas somente leitura mais exigentes, como relatórios. A réplica somente leitura manipulará a carga de trabalho somente leitura sem afetar o uso de recursos no banco de dados primário.
  • A fragmentação de banco de dados é um conjunto de técnicas que permite dividir os dados em vários bancos de dados e dimensioná-los de forma independente.

Próximas etapas