Dimensionar recursos de conjuntos elásticos na Base de Dados SQL do Azure
Aplica-se a:
Banco de Dados SQL do Azure
Este artigo descreve como dimensionar os recursos de computação e armazenamento disponíveis para pools elásticos e bancos de dados agrupados no Banco de Dados SQL do Azure.
Alterar recursos de computação (vCores ou DTUs)
Depois de selecionar inicialmente o número de vCores ou eDTUs, você pode dimensionar um pool elástico para cima ou para baixo dinamicamente com base na experiência real usando qualquer um dos métodos abaixo:
Impacto da alteração da camada de serviço ou do reescalonamento do tamanho da computação
A alteração da camada de serviço ou do tamanho de computação de um pool elástico segue um padrão semelhante ao de bancos de dados únicos e envolve principalmente o serviço executando as seguintes etapas:
Criar nova instância de computação para o pool elástico
Uma nova instância de computação para o pool elástico é criada com a camada de serviço e o tamanho de computação solicitados. Para algumas combinações de alterações na camada de serviço e no tamanho da computação, uma réplica de cada banco de dados deve ser criada na nova instância de computação, o que envolve a cópia de dados e pode influenciar fortemente a latência geral. Independentemente disso, os bancos de dados permanecem online durante esta etapa e as conexões continuam a ser direcionadas para os bancos de dados na instância de computação original.
Roteamento de switch de conexões para nova instância de computação
As conexões existentes com os bancos de dados na instância de computação original são descartadas. Quaisquer novas conexões são estabelecidas com os bancos de dados na nova instância de computação. Para algumas combinações de alterações de camada de serviço e tamanho de computação, os arquivos de banco de dados são desanexados e reanexados durante o switch. Independentemente disso, o switch pode resultar em uma breve interrupção do serviço quando os bancos de dados estão indisponíveis geralmente por menos de 30 segundos e, muitas vezes, por apenas alguns segundos. Se houver transações ativas de longa duração quando as conexões forem descartadas, a duração desta etapa poderá levar mais tempo para recuperar transações abortadas. A recuperação acelerada do banco de dados pode reduzir o impacto do cancelamento de transações de longa execução.
Importante
Nenhum dado é perdido durante qualquer etapa do fluxo de trabalho.
Latência de alteração da camada de serviço ou reescalonamento do tamanho da computação
A latência estimada para alterar a camada de serviço, dimensionar o tamanho de computação de um único banco de dados ou pool elástico, mover um banco de dados para dentro/para fora de um pool elástico ou mover um banco de dados entre pools elásticos é parametrizada da seguinte maneira:
| Latência de dimensionamento do pool elástico | Para piscina elástica básica, padrão e de uso geral | Para Premium, Business Critical pool elástico | Para o pool elástico de hiperescala |
|---|---|---|---|
| Da piscina elástica básica, padrão e de uso geral | Proporcional ao número de bases de dados | • Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado. |
N/D – os bancos de dados precisam ser adicionados individualmente aos pools elásticos de hiperescala. Latência de dimensionamento por banco de dados documentada em Dimensionar recursos de banco de dados único. |
| Do pool elástico Premium, Business Critical | • Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado. |
• Latência proporcional ao espaço de banco de dados utilizado devido à cópia de dados. • Normalmente, menos de 1 minuto por GB de espaço utilizado. |
N/D – os bancos de dados precisam ser adicionados individualmente aos pools elásticos de hiperescala. Latência de dimensionamento por banco de dados documentada em Dimensionar recursos de banco de dados único. |
| Do pool elástico de hiperescala | N/A | N/A | • Latência de tempo constante independente do espaço utilizado. • Normalmente, menos de 2 minutos. |
Nota
- Ao alterar a camada de serviço ou a computação de dimensionamento para qualquer pool elástico não Hyperscale, a soma de espaço usada em todos os bancos de dados no pool deve ser usada para calcular a estimativa. A latência de dimensionamento para pools elásticos de hiperescala é independente do espaço usado.
- Para pools elásticos padrão e de uso geral, a latência de mover um banco de dados para dentro/para fora de um pool elástico ou entre pools elásticos será proporcional ao tamanho do banco de dados se o pool elástico estiver usando armazenamento PFS (Premium File Share). Para determinar se um pool está usando armazenamento PFS, execute a seguinte consulta no contexto de qualquer banco de dados no pool. Se o valor na coluna AccountType for
PremiumFileStorageouPremiumFileStorage-ZRS, o pool está usando armazenamento PFS.
SELECT s.file_id,
s.type_desc,
s.name,
FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');
Nota
- A propriedade redundante de zona permanecerá a mesma por padrão ao dimensionar um pool elástico da camada Business Critical para a camada General Purpose.
- A latência da operação de dimensionamento quando a redundância de zona é alterada para um pool elástico de uso geral é proporcional ao tamanho do banco de dados.
- Não há suporte para alterar um pool elástico não Hyperscale existente para a edição Hyperscale. Consulte Pools elásticos de hiperescala para obter mais detalhes. Em vez disso, os bancos de dados precisam ser adicionados individualmente aos pools elásticos de hiperescala.
- Não há suporte para alterar a edição de um pool elástico Hyperscale para uma edição que não seja Hyperscale. Consulte Pools elásticos de hiperescala para obter mais detalhes.
Gorjeta
Para monitorar operações em andamento, consulte: Gerenciar operações usando a API REST do SQL, Gerenciar operações usando CLI, Monitorar operações usando T-SQL e estes dois comandos do PowerShell: Get-AzSqlElasticPoolActivity e Stop-AzSqlElasticPoolActivity.
Considerações adicionais ao alterar a camada de serviço ou reescalonar o tamanho da computação
- Quando você reduz vCores ou eDTUs para um pool elástico, o espaço usado do pool deve ser menor do que o limite máximo de tamanho de dados da camada de serviço de destino e da computação do pool.
- Quando você aumenta as eDTUs para um pool elástico, um custo de armazenamento extra pode ser aplicado se:
- O tamanho máximo de dados do pool é suportado pelo pool de destino e
- O tamanho máximo de dados do pool excede a quantidade de armazenamento incluída do pool de destino.
- Por exemplo, se um pool de 100 eDTU Standard com um tamanho máximo de dados de 100 GB for reduzido para um pool de 50 eDTU Standard, um custo de armazenamento extra será aplicado, uma vez que o pool de destino suporta um tamanho máximo de dados de 100 GB e sua quantidade de armazenamento incluída é de apenas 50 GB. Assim, a quantidade de armazenamento extra é de 100 GB – 50 GB = 50 GB. Para obter preços de armazenamento extra, consulte Preços do Banco de dados SQL. Se a quantidade real de espaço usado for menor do que a quantidade de armazenamento incluída, esse custo extra pode ser evitado reduzindo o tamanho máximo dos dados para a quantidade incluída.
Faturação durante o reescalonamento
Você é cobrado por cada hora em que um banco de dados existe usando a camada de serviço mais alta + tamanho de computação aplicado durante essa hora, independentemente do uso ou se o banco de dados esteve ativo por menos de uma hora. Por exemplo, se você criar um único banco de dados e excluí-lo cinco minutos depois, sua fatura refletirá uma cobrança por uma hora de banco de dados.
Alterar o tamanho de armazenamento do conjunto elástico
O tamanho do armazenamento (tamanho máximo de dados) para o pool elástico pode ser especificado usando o portal do Azure, o PowerShell, a CLI do Azure ou a API REST. Quando você aumenta o tamanho máximo de dados do pool elástico, o valor especificado não pode exceder o limite de tamanho máximo de dados do objetivo de serviço do pool. Ao diminuir o tamanho máximo dos dados, o novo valor especificado deve ser igual ou maior do que a soma do espaço alocado em todos os bancos de dados do pool.
Importante
Em algumas circunstâncias, talvez seja necessário reduzir um banco de dados para recuperar espaço não utilizado. Para obter mais informações, consulte Gerenciar espaço de arquivo no Banco de Dados SQL do Azure.
Modelo de compra baseado em vCore
- O tamanho de armazenamento (tamanho máximo de dados) para pools elásticos nas camadas de uso geral ou crítica para os negócios pode ser especificado até os limites máximos de tamanho de dados especificados em Limites de recursos para pools elásticos usando o modelo de compra vCore. O tamanho máximo de dados para o pool elástico pode ser aumentado ou diminuído em múltiplos de 1 GB.
- O preço do armazenamento para um pool elástico é o tamanho máximo de dados especificado, multiplicado pelo preço unitário de armazenamento do nível de serviço. Para obter detalhes sobre preços de armazenamento, consulte Preços do Banco de dados SQL.
Importante
Em algumas circunstâncias, talvez seja necessário reduzir um banco de dados para recuperar espaço não utilizado. Para obter mais informações, consulte Gerenciar espaço de arquivo no Banco de Dados SQL do Azure.
Modelo de compra baseado em DTU
- O preço da eDTU para um conjunto elástico inclui uma determinada quantidade de armazenamento sem custos adicionais. O armazenamento de dados extra além do valor incluído pode ser provisionado por um custo adicional até o limite máximo de tamanho de dados correspondente às eDTUs provisionadas. Para obter as quantidades de armazenamento incluídas e os limites máximos de tamanho de dados, consulte Limites de recursos para pools elásticos usando o modelo de compra de DTU.
- O preço do armazenamento extra para um pool elástico é a quantidade de armazenamento extra multiplicada pelo preço unitário de armazenamento extra do nível de serviço. Para obter detalhes sobre o preço do armazenamento extra, consulte Preços do Banco de dados SQL.
- Os valores válidos para o tamanho máximo de dados para um pool elástico de camada Standard ou Premium podem ser um destes valores: 50 GB, 100 GB, 150 GB, 200 GB, 250 GB, 300 GB, 400 GB, 500 GB, 750 GB, 800 GB, 1024 GB, 1200 GB, 1280 GB, 1536 GB, 1600 GB, 1792 GB, 2000 GB, 2048 GB, 2304 GB, 2500 GB, 2560 GB, 2816 GB, 3000 GB, 3072 GB, 3328 GB, 3584 GB, 3840 GB, 4096 GB. O tamanho máximo de dados especificado não pode exceder o limite máximo de tamanho de dados especificado para as eDTUs provisionadas.
Importante
Em algumas circunstâncias, talvez seja necessário reduzir um banco de dados para recuperar espaço não utilizado. Para obter mais informações, consulte Gerenciar espaço de arquivo no Banco de Dados SQL do Azure.
Monitorar ou cancelar alterações de dimensionamento
Uma operação de alteração da camada de serviço ou reescalonamento de computação pode ser monitorada e cancelada.
Na página Visão geral do pool elástico SQL, navegue até Notificações e selecione o bloco que indica que há uma operação em andamento:
Na página Implantação resultante está em andamento , selecione Cancelar.
Permissões
Para dimensionar um pool elástico por meio do portal do Azure, PowerShell, CLI do Azure ou API REST, as permissões do RBAC do Azure são necessárias, especificamente as funções de Colaborador, Colaborador do Banco de Dados SQL ou Colaborador do SQL Server Azure RBAC. Para obter mais informações, visite Funções internas do RBAC do Azure.
Conteúdos relacionados
Para limites gerais de recursos, consulte Limites de recursos baseados em vCore do Banco de dados SQL - pools elásticos e Limites de recursos baseados em DTU do Banco de dados SQL - pools elásticos.