Dimensionar recursos de base de dados individual na Base de Dados SQL do Azure

Este artigo descreve como dimensionar os recursos de computação e 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 faturas por segundo para a computação usada.

Depois de selecionar inicialmente o número de vCores ou DTUs, você pode dimensionar um único banco de dados dinamicamente para cima ou para baixo com base na experiência real usando:

• Transact-SQL
• Portal do Azure
• PowerShell
• CLI do Azure
• API REST

Impacto

A alteração da camada de serviço ou do tamanho de computação envolve principalmente o serviço executando as seguintes etapas:

1. Crie uma 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 solicitada e o tamanho da computação. Para algumas combinações de alterações na camada de serviço e no tamanho da computação, uma réplica do 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, o banco de dados permanece online durante esta etapa e as conexões continuam a ser direcionadas para o banco de dados na instância de computação original.

2. Roteamento de switch 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 descartadas. Quaisquer novas conexões são estabelecidas com o banco 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 o banco de dados está indisponível geralmente por menos de 30 segundos e, muitas vezes, por apenas alguns segundos. Se houver transações de longa duração em execução quando as conexões forem descartadas, a duração desta etapa pode 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.

Latência

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:

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');

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.

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

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

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

$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

$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 dimensionar bancos de dados via Transact-SQL, ALTER DATABASE é usado. Para dimensionar um banco de dados, um logon deve ser o logon de 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 no , um membro da função de banco de dados db_owner no masterbanco de dados atual ou dbo do banco de dados. Para obter mais informações, consulte ALTER DATABASE.

Para dimensionar bancos de dados 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 RBAC do Azure de Colaborador do SQL Server. Para obter mais informações, visite Funções internas do RBAC do Azure.

Considerações adicionais

• Se atualizar para um nível de serviço ou tamanho da computação mais elevado, o tamanho máximo da base de dados não aumentará, exceto se especificar um tamanho maior (maxsize) de forma explícita.
• Para fazer downgrade de um banco de dados, o espaço usado do banco de dados deve ser menor do que o tamanho máximo permitido da camada de serviço de destino e do tamanho de computação.
• Ao fazer o downgrade do nível Premium para o nível Standard, um custo de armazenamento extra se aplica se (1) o tamanho máximo do banco de dados for suportado no tamanho de computação de destino e (2) o tamanho máximo exceder a quantidade de armazenamento incluída do tamanho de 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, já que o S3 suporta um tamanho máximo de 1 TB e sua quantidade de armazenamento incluída é de apenas 250 GB. Assim, a quantidade de armazenamento extra é de 500 GB – 250 GB = 250 GB. Para obter preços de armazenamento extra, consulte Preços do Banco de Dados SQL do Azure. Se a quantidade real de espaço usada for menor do que a quantidade de armazenamento incluída, esse custo extra pode ser evitado reduzindo o 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 desejada e o tamanho de computação antes de atualizar o banco de dados primário (orientação geral para melhor desempenho). Ao atualizar para uma edição diferente, é necessá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 o downgrade de seus bancos de dados primários para a camada de serviço desejada e o tamanho de computação antes de fazer downgrade do banco de dados secundário (orientação geral para melhor desempenho). Ao fazer o downgrade para uma edição diferente, é necessário que o banco de dados primário seja rebaixado primeiro.
• As ofertas de serviço de restauro diferem entre os vários escalões de serviço. Se você estiver fazendo downgrade para a camada Básica , haverá um período de retenção de backup menor. Consulte Backups do Banco de Dados SQL do Azure.
• As novas propriedades do banco de dados não são aplicadas até que as alterações sejam concluídas.
• Quando a cópia de dados é necessária para dimensionar um banco de dados (consulte Latência) ao alterar a camada de serviço, a alta utilização de recursos simultânea à operação de dimensionamento pode causar tempos de dimensionamento mais longos. Com a recuperação acelerada de banco de dados (ADR), a reversão de transações de longa execução não é uma fonte significativa de atraso, mas o alto uso simultâneo de recursos pode deixar menos recursos de computação, armazenamento e largura de banda de rede para escala, especialmente para tamanhos de computação menores.

Faturação

Você é cobrado por cada hora 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 do armazenamento

Modelo de compra baseado em vCore

• O armazenamento pode ser provisionado até o limite de tamanho máximo de armazenamento de dados usando incrementos de 1 GB. O armazenamento mínimo de dados configurável é de 1 GB. Para limites de tamanho máximo de armazenamento de dados em cada objetivo de serviço, consulte as páginas de documentação de limite de recursos para Limites de recursos para bancos de dados únicos usando o modelo de compra vCore e Limites de recursos para bancos de dados únicos usando o modelo de compra DTU.

• O armazenamento de dados para uma base de dados individual pode ser aprovisionado ao aumentar ou diminuir o seu tamanho máximo através do portal do Azure, Transact-SQL, PowerShell, CLI do Azure ou API REST. Se o valor do tamanho máximo for especificado em bytes, tem de ser um múltiplo de 1 GB (1073741824 bytes).

• A quantidade de dados que podem ser armazenados nos arquivos de dados de um banco de dados é limitada pelo tamanho máximo de armazenamento de dados configurado. Além desse armazenamento, o Banco de Dados SQL do Azure adiciona automaticamente 30% mais armazenamento a ser usado para o log de transações. O preço do armazenamento para um único banco de dados ou um pool elástico é a soma dos valores de armazenamento de dados e de log de transações multiplicado pelo preço unitário de armazenamento do nível 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á de 10 GB + 3 GB = 13 GB.

  Nota

  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 tempdb banco de dados. tempdb está localizado no armazenamento SSD local em todos os níveis de serviço. O custo de está incluído no preço de um único banco de dados ou de tempdb um pool elástico.

• Para obter detalhes sobre o preço do armazenamento, consulte Preços do Banco de Dados SQL do Azure.

Modelo de compra baseado em DTU

• O preço da DTU para um único banco de dados inclui uma certa quantidade de armazenamento sem custo adicional. Pode ser aprovisionado armazenamento extra que ultrapasse a quantidade incluída mediante um custo adicional. Este aprovisionamento tem um limite de tamanho máximo de 250 GB de incrementos até chegar a 1 TB. Depois de ultrapassar 1 TB, os incrementos serão de 256 GB. Para obter as quantidades de armazenamento incluídas e os limites de tamanho máximo, consulte Banco de dados único: tamanhos de armazenamento e tamanhos de computação.
• O armazenamento de dados extra para uma base de dados individual pode ser aprovisionado ao aumentar o respetivo tamanho máximo através do 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 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 do Azure.

Base de dados georreplicadas

Para alterar o tamanho da base de dados de uma base de dados secundária replicada, altere o tamanho da base de dados principal. Esta alteração também será, em seguida, replicada e implementada na base de dados secundária.

Restrições P11 e P15 quando o tamanho máximo é superior a 1 TB

Mais de 1 TB de armazenamento no nível Premium está atualmente disponível em todas as regiões, exceto: Leste da China, Norte da China, Alemanha Central e Nordeste da Alemanha. Noutras regiões, o armazenamento máximo no escalão Premium está limitado a 1 TB. As seguintes considerações e limitações aplicam-se a bases 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 tiver sido definido para um valor maior que 1 TB, ele só poderá ser restaurado ou copiado para um banco de dados P11 ou P15. Posteriormente, 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 reescalonamento não exceda os limites máximos de tamanho do novo tamanho de computação.
• Para cenários de replicação geográfica ativa:
  • Configurando uma relação de replicação geográfica: se o banco de dados primário for P11 ou P15, o(s) secundário(s) também deve(m) ser P11 ou P15. Tamanhos de computação mais baixos são rejeitados como secundários, uma vez que não são capazes de suportar 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 dispara a mesma alteração no banco de dados secundário. Ambas as atualizações devem ser bem-sucedidas para que a alteração no primário entre em vigor. Aplicam-se limitações de região para a opção de mais de 1 TB. Se o secundário estiver em uma região que não suporta 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 SqlPackage para importar e exportar dados.

Conteúdos relacionados

Para limites gerais de recursos, consulte Limites de recursos baseados em vCore do Banco de Dados SQL do Azure - bancos de dados únicos e Limites de recursos baseados em DTU do Banco de Dados SQL do Azure - bancos de dados únicos.