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

Este artigo descreve como escalar os recursos de cálculo e armazenamento disponíveis para um Base de Dados SQL do Azure no nível de computação provisionado. Alternativamente, o nível de computação sem servidor fornece cálculo de autoscaling e contas por segundo para o cálculo utilizado.

Depois de escolher inicialmente o número de vCores ou DTUs, pode escalar uma única base de dados para cima ou para baixo dinamicamente com base na experiência real utilizando:

Importante

Em algumas circunstâncias, pode precisar de encolher uma base de dados para recuperar o espaço não usused. Para obter mais informações, consulte Gerir o espaço de ficheiros em Base de Dados SQL do Azure.

Impacto

A alteração do nível de serviço ou do tamanho do cálculo envolve principalmente o serviço que executa os seguintes passos:

  1. Crie uma nova instância de computação para a base de dados.

    Uma nova instância de computação é criada com o nível de serviço solicitado e tamanho do cálculo. Para algumas combinações de alterações de nível de serviço e tamanho de cálculo, uma réplica da base de dados deve ser criada no novo caso de computação, que envolve copiar dados e pode influenciar fortemente a latência geral. Seja como for, a base de dados permanece on-line durante este passo, e as ligações continuam a ser direcionadas para a base de dados no caso do cálculo original.

  2. Altere o encaminhamento das ligações para uma nova instância computacional.

    As ligações existentes à base de dados na instância de cálculo original são eliminadas. Quaisquer novas ligações são estabelecidas na base de dados na nova instância computacional. Para algumas combinações de alterações de nível de serviço e tamanho de cálculo, os ficheiros de base de dados são separados e religados durante o comutador. Independentemente disso, o comutador pode resultar numa breve interrupção de serviço quando a base de dados não está disponível geralmente por menos de 30 segundos e muitas vezes durante apenas alguns segundos. Se houver transações de longa duração em execução quando as ligações forem retiradas, a duração deste passo pode demorar mais tempo para recuperar as transações abortadas. A recuperação acelerada da base de dados pode reduzir o impacto da abortação de transações de longa duração.

Importante

Não são perdidos dados durante qualquer etapa no fluxo de trabalho. Certifique-se de que implementou alguma lógica de relívaria nas aplicações e componentes que estão a utilizar Base de Dados SQL do Azure enquanto o nível de serviço é alterado.

Latência

A latência estimada para alterar o nível de serviço, escalar o tamanho do cálculo de uma única base de dados ou piscina elástica, mover uma base de dados dentro/para fora de uma piscina elástica, ou mover uma base de dados entre piscinas elásticas é parametrizada da seguinte forma:

Escalão de serviço Base de dados única básica,Standard
(S0-S1)
Piscina elástica básica,Standard
(S2-S12),
Fins Gerais base de dados única ou piscina elástica
Conjunto elástico ou base de dados individual Premium ou Crítico para a Empresa Hyperscale
Base de dados única básica,
Standard (S0-S1)
• Latência do tempo constante independente do espaço utilizado
• Normalmente, menos de 5 minutos
• Latência proporcional ao espaço de base de dados utilizado devido à cópia de
dados• Tipicamente, menos de 1 minuto por GB de espaço utilizado
• Latência proporcional ao espaço de base de dados utilizado devido à cópia de
dados• Tipicamente, menos de 1 minuto por GB de espaço utilizado
• Latência proporcional ao espaço de base de dados utilizado devido à cópia de
dados• Tipicamente, menos de 1 minuto por GB de espaço utilizado
Piscina elástica básica,
Standard (S2-S12),
Fins Gerais base de dados única ou piscina elástica
• Latência proporcional ao espaço de base de dados utilizado devido à cópia de
dados• Tipicamente, menos de 1 minuto por GB de espaço utilizado
• Para bases de dados individuais, a latência do tempo constante independente do espaço utilizado
• Normalmente, menos de 5 minutos para bases de dados únicas• Para piscinas
elásticas, proporcionais ao número de bases de dados
• Latência proporcional ao espaço de base de dados utilizado devido à cópia de
dados• Tipicamente, menos de 1 minuto por GB de espaço utilizado
• Latência proporcional ao espaço de base de dados utilizado devido à cópia de
dados• Tipicamente, menos de 1 minuto por GB de espaço utilizado
Conjunto elástico ou base de dados individual Premium ou Crítico para a Empresa • Latência proporcional ao espaço de base de dados utilizado devido à cópia de
dados• Tipicamente, menos de 1 minuto por GB de espaço utilizado
• Latência proporcional ao espaço de base de dados utilizado devido à cópia de
dados• Tipicamente, menos de 1 minuto por GB de espaço utilizado
• Latência proporcional ao espaço de base de dados utilizado devido à cópia de
dados• Tipicamente, menos de 1 minuto por GB de espaço utilizado
• Latência proporcional ao espaço de base de dados utilizado devido à cópia de
dados• Tipicamente, menos de 1 minuto por GB de espaço utilizado
Hyperscale N/D N/D N/D • Latência do tempo constante independente do espaço utilizado
• Tipicamente, menos de 2 minutos

Nota

Além disso, para bases de dados Standard (S2-S12) e Fins Gerais, a latência para mover uma base de dados dentro/para fora de uma piscina elástica ou entre piscinas elásticas será proporcional ao tamanho da base de dados se a base de dados estiver a utilizar Premium armazenamento de Share de Ficheiros (PFS).

Para determinar se uma base de dados está a utilizar o armazenamento de PFS, execute a seguinte consulta no contexto da base de dados. Se o valor na coluna 'AccountType' for PremiumFileStorage ou PremiumFileStorage-ZRS, a base de dados está a utilizar o armazenamento de 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 da zona permanecerá a mesma por defeito ao escalar do Crítico para a Empresa para o nível Fins Gerais. A latência para esta degradação quando o despedimento de zona estiver ativado, bem como a latência para a mudança para o despedimento de zona para o nível Fins Gerais será proporcional ao tamanho da base de dados.

Dica

Para monitorizar as operações em curso, consulte: Gerir operações utilizando a API de SQL REST, Gerir operações utilizando operações CLI, Monitor utilizando SQL T e estes dois comandos PowerShell: Get-AzSqlDatabaseActivity e Stop-AzSqlDatabaseActivity.

Cancelamento de alterações

Uma alteração do nível de serviço ou uma operação de rescalamento de cálculo podem ser canceladas.

O portal do Azure

Na folha de visão geral da base de dados, navegue para notificações e clique no azulejo indicando que há uma operação em curso:

Ongoing operation

Em seguida, clique no botão marcado Cancelar esta operação.

Cancel ongoing operation

PowerShell

A partir de um pedido de comando PowerShell, desemordene o $resourceGroupName$serverName, e $databaseName, em seguida, executar o seguinte comando:

$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"
}

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 desclassificar uma base de dados, o espaço utilizado na base de dados deve ser menor do que o tamanho máximo permitido do nível de serviço alvo e do tamanho do cálculo.
  • Ao reduzir de Premium para o nível Standard, aplica-se um custo de armazenamento extra se ambos (1) o tamanho máximo da base de dados for suportado no tamanho do cálculo alvo, e (2) o tamanho máximo exceder a quantidade de armazenamento incluída do tamanho do cálculo alvo. Por exemplo, se uma base de dados P1 com um tamanho máximo de 500 GB for reduzido para S3, então um custo de armazenamento extra se aplica uma vez que o S3 suporta um tamanho máximo de 1 TB e o seu valor de armazenamento incluído é de apenas 250 GB. Assim, a quantidade extra de armazenamento é de 500 GB – 250 GB = 250 GB. Para preços de armazenamento extra, consulte Base de Dados SQL do Azure preços. Se a quantidade real de espaço utilizado for inferior à quantidade de armazenamento incluída, então este custo extra pode ser evitado reduzindo o tamanho máximo da base de dados para a quantidade incluída.
  • Ao atualizar uma base de dados com geo-replicação ativada, atualize as suas bases de dados secundárias para o nível de serviço e tamanho do cálculo pretendido antes de atualizar a base de dados primária (orientação geral para melhor desempenho). Ao atualizar para uma edição diferente, é um requisito que a base de dados secundária é atualizada primeiro.
  • Ao desclassificar uma base de dados com geo-replicação ativada, desclasse as suas bases de dados primárias para o nível de serviço e tamanho de cálculo pretendidos antes de degradar a base de dados secundária (orientação geral para o melhor desempenho). Ao reduzir para uma edição diferente, é um requisito que a base de dados primária é desclassificada primeiro.
  • As ofertas de serviço de restauro diferem entre os vários escalões de serviço. Se estás a descer para o nível básico , há um período de retenção de reserva mais baixo. Consulte Base de Dados SQL do Azure Backups.
  • As novas propriedades da base de dados não são aplicadas até que as alterações estejam completas.
  • Quando a cópia de dados é necessária para escalar uma base de dados (ver Latência) ao alterar o nível de serviço, a utilização de recursos elevados simultaneamente para a operação de escalagem pode causar tempos de escala mais longos. Com a Recuperação acelerada da Base de Dados (ADR), o reversão de transações de longa duração não é uma fonte significativa de atraso, mas o elevado uso simultâneo de recursos pode deixar menos recursos de computação, armazenamento e largura de banda de rede para dimensionamento, particularmente para tamanhos de computação mais pequenos.

Faturação

Você é cobrado por cada hora existe uma base de dados usando o nível de serviço mais alto + tamanho de cálculo que se aplicava durante essa hora, independentemente do uso ou se a base de dados estava ativa por menos de uma hora. Por exemplo, se criar uma única base de dados e a eliminar cinco minutos depois, a sua conta reflete uma cobrança por uma hora de base de dados.

Alterar o tamanho do armazenamento

Modelo de compra baseado em vCore

  • Armazenamento pode ser a provisionado até ao limite máximo de armazenamento de dados, utilizando incrementos de 1 GB. O armazenamento mínimo de dados configurável é de 1 GB. Para os limites máximos de armazenamento de dados em cada objetivo de serviço, consulte as páginas de documentação limite de recursos para limites de recursos para bases de dados únicas utilizando o modelo de compra vCore e limites de recursos para bases de dados únicas utilizando 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 ficheiros de dados de uma base de dados é limitada pelo tamanho máximo de armazenamento de dados configurado. Além desse armazenamento, Base de Dados SQL do Azure atribui automaticamente mais 30% de armazenamento para ser usado para o registo de transações.
  • Base de Dados SQL do Azure atribui automaticamente 32 GB por vCore para a tempdb base de dados. tempdb está localizado no armazenamento SSD local em todos os níveis de serviço.
  • O preço de armazenamento de uma única base de dados ou de um conjunto elástico é a soma dos valores de armazenamento de dados e de armazenamento de registos de transações multiplicados pelo preço unitário de armazenamento do nível de serviço. O custo tempdb está incluído no preço. Para mais informações sobre o preço de armazenamento, consulte Base de Dados SQL do Azure preços.

Importante

Em algumas circunstâncias, pode precisar de encolher uma base de dados para recuperar o espaço não usused. Para obter mais informações, consulte Gerir o espaço de ficheiros em Base de Dados SQL do Azure.

Modelo de compra baseado em DTU

  • O preço do DTU para uma única base de dados inclui uma certa quantidade de armazenamento sem custos adicionais. 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 valores de armazenamento incluídos e limites de tamanho máximo, consulte base de dados única: tamanhos Armazenamento e tamanhos de cálculo.
  • 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 uma única base de dados é a quantidade extra de armazenamento multiplicada pelo preço extra da unidade de armazenamento do nível de serviço. Para mais informações sobre o preço do armazenamento extra, consulte Base de Dados SQL do Azure preços.

Importante

Em algumas circunstâncias, pode precisar de encolher uma base de dados para recuperar o espaço não usused. Para obter mais informações, consulte Gerir o espaço de ficheiros em Base de Dados SQL do Azure.

Base de dados geo-replicada

Para alterar o tamanho da base de dados de uma base de dados secundária replicada, altere o tamanho da base de dados primária. 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: China Leste, China Norte, Alemanha Central e Alemanha Nordeste. Nestas regiões, o máximo de armazenamento no nível Premium é limitado a 1 TB. As seguintes considerações e limitações aplicam-se às bases de dados P11 e P15 com um tamanho máximo superior a 1 TB:

  • Se o tamanho máximo de uma base de dados P11 ou P15 foi alguma vez definido para um valor superior a 1 TB, então só pode ser restaurado ou copiado para uma base de dados P11 ou P15. Posteriormente, a base de dados pode ser redimensionada para um tamanho de cálculo diferente, desde que a quantidade de espaço atribuído no momento da operação de rescalamento não exceda os limites máximos de tamanho máximo do novo tamanho do cálculo.
  • Para cenários de geo-replicação ativos:
    • Criação de uma relação de geo-replicação: Se a base de dados primária for P11 ou P15, o secundário também deve ser P11 ou P15. O tamanho do cálculo mais baixo é rejeitado como secundário, uma vez que não são capazes de suportar mais de 1 TB.
    • A atualização da base de dados primária numa relação de geo-replicação: Alterar o tamanho máximo para mais de 1 TB numa base de dados primária desencadeia a mesma alteração na base de dados secundária. Ambas as atualizações devem ser bem sucedidas para que a mudança nas primárias produza efeitos. Aplicam-se limitações da região para a opção de mais de 1-TB. Se o secundário está numa região que não suporta mais de 1 TB, as primárias não são melhoradas.
  • A utilização do serviço de Importar/Exportar para o carregamento de bases de dados P11/P15 com mais de 1 TB não é suportada. Utilize SqlPackage.exe para importar e exportar dados.

Passos seguintes

Para os limites globais de recursos, consulte Base de Dados SQL do Azure limites de recursos baseados em vCore - bases de dados únicas e limites de recursos baseados em Base de Dados SQL do Azure DTU - bases de dados únicas.