Dimensione dinamicamente os recursos do banco de dados com o mínimo de tempo de inatividade - Banco de Dados SQL do Azure & Instância Gerenciada SQL do Azure
Aplica-se a:
Banco de Dados SQL do Azure Instância Gerenciada SQLdo Azure
O Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure permitem que você adicione dinamicamente mais recursos ao seu banco de dados com o mínimo de tempo de inatividade, no entanto, há uma alternância ao longo do período em que a conectividade é perdida para o banco de dados por um curto período de tempo, que pode ser atenuada usando a lógica de repetição.
Descrição geral
Quando a demanda por seu aplicativo cresce de um punhado de dispositivos e clientes para milhões, o Banco de Dados SQL do Azure e a Instância Gerenciada SQL são dimensionados rapidamente com o mínimo de tempo de inatividade. A escalabilidade é uma das características mais importantes da plataforma como serviço (PaaS) que permite adicionar dinamicamente mais recursos ao seu serviço quando necessário. O Banco de Dados SQL do Azure permite que você altere facilmente os recursos (energia da CPU, memória, taxa de transferência de E/S e armazenamento) alocados para seus bancos de dados.
Você pode reduzir problemas de desempenho devido ao aumento do uso do seu aplicativo que não pode ser corrigido usando métodos de indexação ou regravação de consulta. Adicionar mais recursos permite que você reaja rapidamente quando seu banco de dados atinge os limites de recursos atuais e precisa de mais energia para lidar com a carga de trabalho de entrada. O Banco de Dados SQL do Azure também permite reduzir a escala dos recursos quando eles não são necessários para reduzir o custo.
Você não precisa se preocupar com a compra de hardware e a alteração da infraestrutura subjacente. O dimensionamento de um banco de dados pode ser feito facilmente por meio do portal do Azure usando um controle deslizante.
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 SQL do Azure oferece apenas o modelo de compra baseado em vCore.
- O modelo de compra baseado em DTU oferece uma combinação de recursos de computação, memória e E/S em três níveis de serviço para suportar cargas de trabalho de banco de dados leves a pesadas: Basic, Standard e Premium. Os níveis de desempenho em cada camada fornecem uma mistura diferentes destes recursos, à qual pode adicionar recursos de armazenamento adicionais.
- 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. Esse modelo de compra oferece três níveis de serviço: Propósito Geral, Crítico para os Negócios e Hiperescala.
A camada de serviço, a camada 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 programaticamente a qualquer momento, para a camada de computação provisionada, para atender às necessidades de sua solução.
Nota
As exceções notáveis em que não é possível 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 Business Critical / Premium não podem ser alterados para usar a camada de serviço General Purpose / Standard. Atualmente, o único recurso desse tipo é o OLTP In-Memory.
- Os bancos de dados originalmente criados na camada de serviço Hyperscale não podem ser migrados para outras camadas de serviço. Se você migrar um banco de dados existente no Banco de Dados SQL do Azure para a camada de serviço Hyperscale, poderá reverter a migração para a camada de serviço de Propósito Geral dentro de 45 dias da migração original para Hyperscale. Se desejar migrar o banco de dados para outra camada de serviço, como Business Critical, primeiro faça a migração reversa para a camada de serviço de uso geral e, em seguida, execute uma migração adicional. Saiba mais em Como reverter a migração do Hyperscale.
Você pode ajustar os recursos alocados ao seu banco de dados alterando o objetivo do serviço, ou dimensionando, para atender às demandas de carga de trabalho. Isso também permite que você pague apenas pelos recursos de que precisa, quando precisar. 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 único banco de dados, você pode usar modelos 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 definir o limite máximo de recursos por grupo de bancos de dados no pool.
A Instância Gerenciada SQL do Azure também permite dimensionar:
- A Instância Gerenciada 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 dentro da instância gerenciada compartilharão os recursos alocados para a instância.
Gorjeta
O dimensionamento dinâmico permite que os clientes alterem a alocação de recursos manualmente ou programaticamente. O recurso de dimensionamento dinâmico está disponível para todos os recursos do Banco de Dados SQL do Azure e da Instância Gerenciada do SQL do Azure.
Além de dar suporte ao dimensionamento dinâmico, a camada Serverless no Banco de Dados SQL do Azure dá suporte ao dimensionamento automático. Os bancos de dados na camada Sem servidor dimensionam 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 dimensionar o banco de dados.
Impacto das operações de aumento ou redução de escala
Iniciar uma ação de aumento ou redução de escala em qualquer um dos tipos 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 seu serviço existente do Banco de Dados SQL do Azure. Quando 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 confirmadas serão revertidas. Novas conexões serão feitas com o mecanismo de banco de dados de destino.
Nota
Não é recomendável dimensionar sua instância gerenciada se uma transação de longa duração, como importação de dados, trabalhos de processamento de dados, reconstrução de índice, etc., estiver em execução ou se você tiver alguma 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 longa execução.
Nota
Você pode esperar uma pequena quebra de conexão quando o processo de expansão/redução de escala for concluído. Se você tiver implementado a lógica Retry para erros transitórios padrão, não notará o failover.
Métodos de escala alternativos
Dimensionar recursos é a maneira mais fácil e eficaz de melhorar o desempenho do seu banco de dados sem alterar o banco de dados ou o código do aplicativo. Em alguns casos, mesmo as camadas de serviço mais altas, tamanhos de computação e otimizações de desempenho podem não lidar com sua carga de trabalho de forma bem-sucedida e econômica. Nesse caso, você tem estas opções adicionais para dimensionar seu banco de dados:
- A expansão de leitura é um recurso disponível onde você está obtendo uma réplica somente leitura de seus dados, onde você pode executar consultas somente leitura exigentes, como relatórios. Uma réplica somente leitura manipulará sua carga de trabalho somente leitura sem afetar o uso de recursos no banco de dados principal.
- A fragmentação de banco de dados é um conjunto de técnicas que permite dividir seus dados em vários bancos de dados e dimensioná-los de forma independente.
Próximos passos
- Para obter informações sobre como melhorar o desempenho do banco de dados alterando o código do banco de dados, consulte Localizar e aplicar recomendações de desempenho.
- Para obter informações sobre como permitir que a inteligência de banco de dados interna otimize seu banco de dados, consulte Ajuste automático.
- Para obter informações sobre a expansão de leitura no Banco de Dados SQL do Azure, consulte como usar réplicas somente leitura para balancear a carga de trabalho de consulta somente leitura.
- Para obter informações sobre uma fragmentação de banco de dados, consulte Dimensionamento com o Banco de Dados SQL do Azure.
- Para obter um exemplo de como usar scripts para monitorar e dimensionar um único banco de dados, consulte Usar o PowerShell para monitorar e dimensionar um único Banco de Dados SQL.