Escalar recursos de banco de dados individual no Banco de Dados SQL do Azure

Artigo
09/17/2024

Aplica-se a: Banco de Dados SQL do Azure

Este artigo descreve como escalar os recursos de computação e de armazenamento disponíveis para um Banco de Dados SQL do Azure na camada de computação provisionada. Como alternativa, a camada de computação sem servidor fornece dimensionamento automático de computação e cobra por segundo de computação usada.

Depois de escolher inicialmente o número de vCores ou DTUs, você poderá escalar verticalmente e de forma dinâmica um banco de dados individual com base na experiência real usando:

Importante

Em algumas circunstâncias, talvez seja necessário reduzir um banco de dados para recuperar o espaço não utilizado. Para obter mais informações, consulte gerenciar o espaço de arquivo para bancos de dados no banco de dados SQL do Azure.

Observação

O Microsoft Entra ID era anteriormente conhecido como Azure Active Directory (Azure AD).

Impacto

Alterar a camada de serviço ou o tamanho da computação envolve principalmente o serviço executando as seguintes etapas:

Criar nova instância de computação para o banco de dados.

Uma nova instância de computação é criada com a camada de serviço e o tamanho de computação solicitados. Para algumas combinações de alterações de tamanho de computação e camada de serviço, uma réplica do banco de dados deve ser criada na nova instância de computação que envolve a cópia de dados e pode influenciar muito a latência em geral. Ainda assim, o banco de dados permanece online durante essa etapa, e as conexões continuam a ser direcionadas para o banco de dados na instância de computação original.
Alternar o roteamento de conexões para uma nova instância de computação.

As conexões existentes com o banco de dados na instância de computação original são removidas. Todas as conexões novas são estabelecidas com o banco de dados na nova instância de computação. Para algumas combinações de alterações de tamanho de computação e camada de serviço, os arquivos de banco de dados são desanexados e reanexados durante a alternância. Ainda assim, a alternância pode resultar em uma breve interrupção do serviço quando o banco de dados estiver indisponível por menos de 30 segundos e geralmente dura apenas alguns segundos. Se houver transações de execução prolongada em execução quando as conexões forem descartadas, a duração desta etapa pode ser maior para recuperar as transações anuladas. A Recuperação Acelerada de Banco de Dados no SQL do Azure pode reduzir o impacto da anulação de transações de execução prolongada.

Importante

Nenhum dado é perdido durante as etapas no fluxo de trabalho. Verifique se você implementou alguma lógica de repetição nos aplicativos e componentes que estão usando o Banco de Dados SQL do Azure enquanto a camada de serviço é alterada.

Latency

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/fora de um pool elástico ou mover um banco de dados entre pools elásticos é parametrizada da seguinte maneira:

Latência de escala de banco de dados	Para Banco de dados individual Básico, Banco de Dados Individual Standard (S0-S1)	Para banco de dados individual Standard (S2-S12), banco de dados individual de Uso Geral, banco de dados em pool elástico Básico, banco de dados em pool elástico Standard, banco de dados em pool de Uso Geral	Para banco de dados individual Premium ou banco de dados em pool, banco de dados individual Comercialmente Crítico ou banco de dados em pool	Para banco de dados individual em Hiperescala ou banco de dados em pool
De Banco de dados individual básico, Banco de Dados Individual Standard (S0-S1)	• Latência de tempo constante independente do espaço usado. • Normalmente, menos de cinco minutos.	• Latência proporcional ao espaço de banco de dados usado devido à cópia dos dados • Normalmente, menos de um minuto por GB de espaço usado.	• Latência proporcional ao espaço de banco de dados usado devido à cópia dos dados • Normalmente, menos de um minuto por GB de espaço usado.	• Latência proporcional ao espaço de banco de dados usado devido à cópia dos dados • Normalmente, menos de um minuto por GB de espaço usado.
De banco de dados em pool Básico, banco de dados individual Standard (S2-S12), banco de dados em pool Standard, banco de dados individual de Uso Geral ou banco de dados em pool	• Latência proporcional ao espaço de banco de dados usado devido à cópia dos dados • Normalmente, menos de um minuto por GB de espaço usado.	• Para Latência de tempo constante independente do espaço usado para Bancos de Dados Individuais. • Normalmente, menos de cinco minutos para Bancos de Dados Individuais • Para pools elásticos, proporcionais ao número de bancos de dados.	• Latência proporcional ao espaço de banco de dados usado devido à cópia dos dados • Normalmente, menos de um minuto por GB de espaço usado.	• Latência proporcional ao espaço de banco de dados usado devido à cópia dos dados • Normalmente, menos de um minuto por GB de espaço usado.
De banco de dados individual Premium ou banco de dados em pool, banco de dados individual Comercialmente Crítico ou banco de dados em pool	• Latência proporcional ao espaço de banco de dados usado devido à cópia dos dados • Normalmente, menos de um minuto por GB de espaço usado.	• Latência proporcional ao espaço de banco de dados usado devido à cópia dos dados • Normalmente, menos de um minuto por GB de espaço usado.	• Latência proporcional ao espaço de banco de dados usado devido à cópia dos dados • Normalmente, menos de um minuto por GB de espaço usado.	• Latência proporcional ao espaço de banco de dados usado devido à cópia dos dados • Normalmente, menos de um minuto por GB de espaço usado.
De banco de dados individual em Hiperescala ou banco de dados em pool	N/D	Confira Fazer a migração reversa de Hiperescala para cenários e limites com suporte.	N/D	• Latência de tempo constante independente do espaço usado. • Normalmente, menos de dois minutos.

Observação

Além disso, para os bancos de dados Standard (S2-S12) e Uso Geral, a latência para mover um banco de dados para dentro/fora de um pool elástico ou entre pools elásticos será proporcional ao tamanho do banco de dados se este estiver usando o armazenamento PFS (compartilhamento de arquivos Premium).
No caso de mover um banco de dados para/de um pool elástico, somente o espaço usado pelo banco de dados afeta a latência, não o espaço usado pelo pool elástico.
Para determinar se um banco de dados está usando o armazenamento PFS, execute a consulta a seguir no contexto do banco de dados. Se o valor na coluna AccountType for PremiumFileStorage ou PremiumFileStorage-ZRS, o banco de dados está usando o 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');

Observação

A propriedade com redundância de zona permanecerá a mesma por padrão ao escalar um Banco de Dados Individual da camada Comercialmente Crítico para a Uso Geral.
A latência para a operação de escala quando a redundância de zona é alterada para um banco de dados individual de Uso Geral é proporcional ao tamanho do banco de dados.

Dica

Para monitorar operações em andamento, confira: Gerenciar operações usando a API REST do SQL, Gerenciar operações usando a CLI, Monitorar operações usando o T-SQL e estes dois comandos do PowerShell: Get-AzSqlDatabaseActivity e Stop-AzSqlDatabaseActivity.

Monitorar ou cancelar as alterações de escala

Uma operação de alteração de camada de serviço ou redimensionamento de computação pode ser monitorada e cancelada.

Na página Visão geral do banco de dados SQL, procure a barra de notificação indicando que uma operação de dimensionamento está em andamento e selecione o link Ver mais para a implantação em andamento.

Na página Operações em andamento resultante, selecione Cancelar esta operação.

Para invocar os comandos do PowerShell em um computador, o pacote Az versão 9.7.0 ou mais nova deve ser instalado localmente. Ou considere usar o Azure Cloud Shell para executar Azure PowerShell em shell.azure.com.

Primeiro, faça logon no Azure e defina o contexto adequado para sua assinatura:

Login-AzAccount
$SubscriptionID = "<YourSubscriptionIdHere>"
Select-AzSubscription -SubscriptionName $SubscriptionID

Para monitorar operações em um banco de dados, incluindo as operações de escala, use Get-AzSqlDatabaseActivity. A amostra a seguir retorna um OperationId para cada operação em execução no momento.

Get-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01"

Para cancelar uma operação assíncrona como uma escala de banco de dados, identifique a operação e use Stop-AzSqlDatabaseActivity com um OperationId específico, como na amostra a seguir.

Stop-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" -OperationId af97005d-9243-4f8a-844e-402d1cc855f5

Em um terminal do Cloud Shell, use o seguinte comando de amostra para identificar as operações em execução no momento. Em um terminal de Cloud Shell, defina as variáveis $resourceGroupName, $serverName e $databaseName e, em seguida, execute o seguinte comando:

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv

Para interromper uma operação assíncrona, como uma escala de banco de dados, de um terminal de Cloud Shell, defina as variáveis $resourceGroupName, $serverName e $databaseName e execute o seguinte comando:

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
$operationName = (az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv)
if (-not [string]::IsNullOrEmpty($operationName)) {
    (az sql db op cancel --resource-group $resourceGroupName --server $serverName --database $databaseName --name $operationName)
        "Operation " + $operationName + " has been canceled"
}
else {
    "No service tier change or compute rescaling operation found"
}

Permissões

Para escalar bancos de dados usando Transact-SQL: ALTER DATABASE é utilizado. Para escalar um banco de dados, um logon precisa ser o logon do administrador do servidor (criado quando o servidor lógico do banco de dados SQL do Azure foi provisionado), o administrador do Microsoft Entra do servidor, um membro da função de banco de dados dbmanager em master, um membro da função de banco de dados db_owner no banco de dados atual ou dbo do banco de dados. Para saber mais, confira ALTERAR BANCO DE DADOS.

Para escalar bancos de dados usando o portal do Azure, o PowerShell, a CLI do Azure ou a API REST: são necessárias permissões do Azure RBAC, especificamente as funções de Contribuidor, a função Colaborador do BD SQL ou Contribuidor do SQL Server do Azure RBAC. Para obter mais informações, confira Azure RBAC built-in roles.

Considerações adicionais

Se você estiver atualizando para uma camada de serviço ou tamanho da computação maior, o tamanho máximo do banco de dados não aumentará, a menos que você especifique explicitamente um tamanho maior (tamanho máximo).
Para fazer downgrade de um banco de dados, o espaço usado dele deve ter um tamanho menor do que o máximo permitido para a camada de serviço e o tamanho da computação de destino.
Ao fazer o downgrade da camada Premium para a camada Standard, um custo de armazenamento extra será aplicado se (1) o tamanho máximo do banco de dados tiver suporte no tamanho da computação de destino e (2) o tamanho máximo ultrapassar a quantidade de armazenamento incluída de tamanho da computação de destino. Por exemplo, se um banco de dados P1 com um tamanho máximo de 500 GB for reduzido para S3, um custo de armazenamento extra será aplicado, pois S3 dá suporte a um tamanho máximo de 1 TB, e a quantidade de armazenamento incluída é somente de 250 GB. Assim, a quantidade de armazenamento extra será 500 GB – 250 GB = 250 GB. Para obter o preço do armazenamento adicional, confira Preços do Banco de Dados SQL do Azure. Se a quantidade real de espaço usado for menor do que a quantidade de armazenamento incluído, esse custo extra poderá ser evitado por meio da redução do tamanho máximo do banco de dados para a quantidade incluída.
Ao atualizar um banco de dados com replicação geográfica habilitada, atualize seus bancos de dados secundários para a camada de serviço e o tamanho da computação desejados antes de atualizar o banco de dados primário (orientação geral para o melhor desempenho). Ao atualizar para uma edição diferente, é obrigatório que o banco de dados secundário seja atualizado primeiro.
Ao fazer downgrade de um banco de dados com replicação geográfica habilitada, faça downgrade dos seus bancos de dados primários para a camada de serviço e o tamanho da computação desejados antes de atualizar o banco de dados secundário (orientação geral para o melhor desempenho). Ao fazer downgrade para uma edição diferente, é obrigatório fazer downgrade do banco de dados primário antes.
As ofertas de serviço de restauração são diferentes para as várias camadas de serviço. Se você estiver fazendo downgrade para a camada Básica, haverá um período de retenção de backup inferior. Confira Backups automatizados no Banco de Dados SQL do Azure.
As novas propriedades do banco de dados não serão aplicadas até que as alterações sejam concluídas.
Quando a cópia de dados é necessária para escalar um banco de dados (confira Latência) ao alterar a camada de serviço, a alta utilização de recursos simultâneos durante a operação de escala pode causar tempos de escala mais longos. Com a Recuperação Acelerada de Banco de Dados (ADR), o reversão de transações de execução prolongada não é uma origem significativa de atraso, mas o alto uso dos recursos simultâneos pode deixar menos recursos de computação, armazenamento e Bandwidth de rede disponíveis para a escala, especialmente em tamanhos da computação menores.

Cobrança

Você será cobrado pelas horas em que um banco de dados existir usando a camada de serviço mais alta e o tamanho da computação aplicado durante essas horas, independentemente do uso ou se o banco de dados ficou ativo por menos de uma hora. Por exemplo, se você criar um banco de dados individual e o excluir depois de cinco minutos, sua fatura apresentará uma cobrança referente a uma hora de banco de dados.

Alterar o tamanho de armazenamento

Modelo de compra baseado em vCore

O armazenamento pode ser provisionado até o limite de tamanho máximo de armazenamento de dados com incrementos de 1 GB. O armazenamento de dados configurável mínimo é de 1 GB. Para limites máximos de tamanho do armazenamento de dados em cada objetivo de serviço, consulte as páginas da documentação de limite de recursos para Limites de recursos para bancos de dados individuais usando o modelo de compra vCore e Limites de recursos para bancos de dados individuais usando o modelo de compra DTU.
É possível provisionar o armazenamento de dados para um único banco de dados aumentando ou diminuindo seu tamanho máximo usando o Portal do Azure, o Transact-SQL, o PowerShell, a CLI do Azure ou a API REST. Se o valor do tamanho máximo for especificado em bytes, ele deverá ser um múltiplo de 1 GB (1073741824 bytes).
A quantidade de dados que pode ser armazenada nos arquivos de um banco de dados é limitada pelo tamanho máximo do armazenamento de dados configurado. Além desse armazenamento, o Banco de Dados SQL do Azure adiciona automaticamente 30% a mais de armazenamento a ser usado para o log de transações. O preço de armazenamento para um único banco de dados ou um pool elástico é a soma das quantidades de armazenamento de dados e armazenamento de log de transações multiplicada pelo preço unitário do armazenamento da camada de serviço. Por exemplo, se o armazenamento de dados estiver definido como 10 GB, o armazenamento adicional do log de transações será de 10 GB * 30% = 3 GB e a quantidade total de armazenamento faturável será 10 GB + 3 GB = 13 GB.

Observação

O tamanho máximo do arquivo de log de transações é gerenciado automaticamente e, em alguns casos, pode ser maior que 30% do tamanho máximo de armazenamento de dados. Isso não aumenta o preço do armazenamento para o banco de dados.
O Banco de Dados SQL do Azure aloca automaticamente 32 GB por vCore para o banco de dados tempdb. tempdb está localizado no armazenamento SSD local em todas as camadas de serviço. O custo de tempdb está incluído no preço de um único banco de dados ou um pool elástico.
Para obter detalhes sobre o preço de armazenamento, confira Preços do Banco de Dados SQL do Azure.

Importante

Modelo de compra baseado em DTU

O preço de DTU para um único banco de dados inclui uma determinada quantidade de armazenamento sem custo adicional. O armazenamento extra além da quantidade incluída pode ser provisionado mediante um custo adicional até o limite máximo de tamanho, em incrementos de 250 GB até 1 TB e, em seguida, em incrementos de 256 GB além de 1 TB. Para conhecer as quantidades de armazenamento incluídas e os limites máximos de tamanho, confira Banco de dados individual: tamanhos de armazenamento e tamanhos de computação.
É possível provisionar o armazenamento extra para um único banco de dados aumentando seu tamanho máximo usando o Portal do Azure, Transact-SQL, PowerShell, CLI do Azure ou API REST.
O preço do armazenamento extra para um único banco de dados é a quantidade de armazenamento extra multiplicada pelo preço unitário do armazenamento extra da camada de serviço. Para obter detalhes sobre o preço de armazenamento extra, confira Preços do Banco de Dados SQL do Azure.

Importante

Banco de dados replicado geograficamente

Para alterar o tamanho de um banco de dados secundário replicado, altere o tamanho do banco de dados primário. Essa alteração será replicada e implementada também no banco de dados secundário.

Limitações do P11 e P15 quando o tamanho máximo for maior que 1 TB

Atualmente, há mais de 1 TB de armazenamento na camada Premium disponível em todas as regiões, exceto Leste da China, Norte da China, Alemanha Central e Nordeste da Alemanha. Nessas regiões, o armazenamento máximo na camada Premium é limitado a 1 TB. As seguintes considerações e limitações se aplicam aos bancos de dados P11 e P15 com um tamanho máximo superior a 1 TB:

Se o tamanho máximo de um banco de dados P11 ou P15 for definido como um valor maior que 1 TB, ele só poderá ser restaurado ou copiado para um banco de dados P11 ou P15. Subsequentemente, o banco de dados pode ser redimensionado para um tamanho de computação diferente, desde que a quantidade de espaço alocado no momento da operação de redimensionamento não exceda os limites de tamanho máximo do novo tamanho de computação.
Para cenários com replicação geográfica ativa:
- Configurar uma relação de replicação geográfica: se o banco de dados primário for P11 ou P15, os secundários também deverão ser P11 ou P15. Tamanhos de computação inferiores são rejeitados como secundários, pois não são capazes de dar suporte a mais de 1 TB.
- Atualizando o banco de dados primário em uma relação de replicação geográfica: alterar o tamanho máximo para mais de 1 TB em um banco de dados primário disparará a mesma alteração no banco de dados secundário. As duas atualizações devem ser bem-sucedidas para que a alteração no primário entre em vigor. Há limitações de região para a opção superior a 1 TB. Se o secundário estiver em uma região que não dá suporte a mais de 1 TB, o primário não será atualizado.
Não há suporte para o uso do serviço de Importação/Exportação para carregar bancos de dados P11/P15 com mais de 1 TB. Use o SqlPackage para importar e exportar dados.

Compartilhar via

Escalar recursos de banco de dados individual no Banco de Dados SQL do Azure

Impacto

Latency

Monitorar ou cancelar as alterações de escala

Permissões

Considerações adicionais

Cobrança

Alterar o tamanho de armazenamento

Modelo de compra baseado em vCore

Modelo de compra baseado em DTU

Banco de dados replicado geograficamente

Limitações do P11 e P15 quando o tamanho máximo for maior que 1 TB

Comentários

Recursos adicionais

Compartilhar via

Escalar recursos de banco de dados individual no Banco de Dados SQL do Azure

Impacto

Latency

Monitorar ou cancelar as alterações de escala

Permissões

Considerações adicionais

Cobrança

Alterar o tamanho de armazenamento

Modelo de compra baseado em vCore

Modelo de compra baseado em DTU

Banco de dados replicado geograficamente

Limitações do P11 e P15 quando o tamanho máximo for maior que 1 TB

Conteúdo relacionado

Comentários

Recursos adicionais