Ler em inglês

Compartilhar via

Camada de computação sem servidor para Banco de Dados SQL do Azure

  • Artigo

Aplica-se a: Banco de Dados SQL do Azure

Sem servidor é uma camada de computação para bancos de dados únicos no Banco de Dados SQL do Azure que dimensiona automaticamente a computação com base na demanda da carga de trabalho e cobra pela quantidade de computação usada por segundo. A camada de computação sem servidor também pausa os bancos de dados automaticamente durante períodos inativos quando apenas o armazenamento é cobrado e retoma automaticamente os bancos de dados quando a atividade retorna. A camada de computação sem servidor está disponível na camada de serviço de Uso Geral e na camada de serviço de Hiperescala.

Observação

Atualmente, a pausa e a retomada automáticas têm suporte apenas na camada de serviço de Uso Geral.

Visão geral

Um intervalo de dimensionamento automático de computação e um atraso de pausa automática são parâmetros importantes para a camada de computação sem servidor. A configuração desses parâmetros forma o custo de computação e a experiência de desempenho do banco de dados.

Diagrama que indica quando a cobrança sem servidor pararia de incorrer em cobranças de computação devido à inatividade.

Configuração de desempenho

  • mínimo de vCores e máximo de vCores são parâmetros configuráveis que definem o intervalo de capacidade de computação disponível para o banco de dados. Os limites de memória e E/S são proporcionais ao intervalo de vCore especificado. 
  • O atraso de pausa automática é um parâmetro configurável que define o período que o banco de dados deve ficar inativo antes que ele entre automaticamente em pausa. O banco de dados é retomado automaticamente quando o próximo logon ou outra atividade ocorre. Alternativamente, a pausa automática pode ser desabilitada.

Custo

  • O custo de um banco de dados sem servidor é a soma do custo de computação e do custo de armazenamento.
  • Quando o uso de computação está entre os limites mínimo e máximo configurados, o custo de computação baseia-se no vCore e na memória usada.
  • Quando o uso de computação estiver abaixo dos limites mínimos configurados, o custo de computação se baseará no mínimo de vCores e no mínimo de memória configurada.
  • Quando o banco de dados é pausado, o custo de computação é zero, e somente os custos de armazenamento são incorridos.
  • O custo de armazenamento é determinado da mesma forma que na camada de computação provisionada.

Para obter mais detalhes, consulte Cobrança.

Cenários

A camada sem servidor é otimizada para preço/desempenho para bancos de dados individuais com padrões de uso intermitentes e imprevisíveis que podem gerar atraso no aquecimento de computação após períodos ociosos. Por outro lado, a camada de computação provisionada é otimizada para preço/desempenho para bancos de dados individuais ou múltiplos bancos de dados em pools elásticos com maior uso médio que não podem apresentar atrasos no aquecimento de computação.

Cenários adequados para a computação sem servidor

  • Bancos de dados individuais com padrões de uso intermitentes e imprevisíveis intercalados com períodos de inatividade e menor utilização média de computação ao longo do tempo.
  • Bancos de dados individuais na camada de computação provisionada que são frequentemente reescalonados e clientes que preferem delegar o reescalonamento de computação para o serviço.
  • Novos bancos de dados individuais sem histórico de uso em que o escalonamento de computação é difícil ou impossível de estimar antes da implantação no Banco de Dados SQL do Azure.

Cenários adequados para computação provisionada

  • Bancos de dados individuais com padrões de uso mais regulares, previsíveis e maior utilização média de computação ao longo do tempo.
  • Bancos de dados que não podem tolerar compensações de desempenho resultantes do corte mais frequente de memória ou do atrasos de retomada após uma pausa.
  • Vários bancos de dados com padrões de uso intermitentes e imprevisíveis que podem ser consolidados em pools elásticos para melhor otimização de preços e desempenho.

Comparar camadas de computação

A tabela a seguir resume as diferenças entre a camada de computação sem servidor e a camada de computação provisionada:

Computação sem servidor Computação provisionada
Padrão de uso do banco de dados Uso intermitente e imprevisível com menor utilização média de computação ao longo do tempo. Padrões de uso mais regulares com maior utilização média de computação ao longo do tempo ou vários bancos de dados usando pools elásticos.
Esforço de gerenciamento de desempenho Inferior Superior
Dimensionamento de computação Automático Manual
Capacidade de resposta de computação Inferior após períodos de inatividade Imediata
Granularidade de cobrança Por segundo Por hora

Camada de serviço e modelo de compra

A tabela a seguir descreve o suporte sem servidor com base no modelo de compra, nas camadas de serviço e no hardware:

Categoria Com suporte Sem suporte
Modelo de compra vCore DTU
Camada de serviço Uso Geral
Hiperescala		 Comercialmente Crítico
Hardware Série Standard (Gen 5) Todos os outros hardwares

Dimensionamento automático

Capacidade de resposta de dimensionamento

Os bancos de dados sem servidor são executados em um computador com capacidade suficiente para satisfazer as demandas de recursos sem interrupção para qualquer quantidade de computação solicitada dentro dos limites definidos pelo valor de máximo de vCores. Ocasionalmente, o balanceamento de carga ocorrerá automaticamente se o computador não puder atender à demanda de recursos dentro de alguns minutos. Por exemplo, se a demanda de recursos for 4 vCores, mas só 2 vCores estiverem disponíveis, poderá levar alguns minutos para balancear a carga antes do fornecimento de 4 vCores. O banco de dados permanece online durante o balanceamento de carga, exceto por um breve período ao final da operação, quando as conexões são perdidas.

Gerenciamento de memória

Nas camadas de serviço de uso geral e de Hiperescala, a memória de bancos de dados sem servidor é recuperada com mais frequência do que para bancos de dados de computação provisionados. Esse comportamento é importante para controlar os custos na camada sem servidor e pode afetar o desempenho.

Recuperação de cache

Ao contrário dos bancos de dados de computação provisionada, a memória de cache SQL é recuperada de um banco de dados sem servidor quando a utilização de CPU ou de cache ativo for baixa.

  • A utilização do cache ativo é considerada baixa quando o tamanho total das entradas de cache usadas mais recentemente fica abaixo de um limite durante um período.
  • Quando a recuperação do cache é disparada, o tamanho do cache de destino é reduzido incrementalmente para uma fração do tamanho anterior, e a recuperação só continua se o uso permanece baixo.
  • Quando ocorre a recuperação do cache, a política para selecionar entradas de cache a serem removidas é a mesma política de seleção que para bancos de dados de computação provisionados quando a pressão de memória é alta.
  • O tamanho do cache nunca é reduzido abaixo do limite mínimo de memória, conforme definido pelo mínimo de vCores.

Em bancos de dados de computação sem servidor e provisionados, as entradas de cache poderão ser removidas se toda a memória disponível for usada.

Quando a utilização da CPU é baixa, a utilização do cache ativo pode ficar alta dependendo do padrão de uso e impedir a recuperação da memória. Além disso, pode haver outros atrasos depois que a atividade do usuário parar antes que a recuperação de memória ocorra, devido a processos periódicos em segundo plano que respondem à atividade anterior do usuário. Por exemplo, operações de exclusão e tarefas de limpeza de Repositório de Consultas geram registros fantasmas que são marcados para exclusão, mas não são excluídos fisicamente até que o processo de limpeza fantasma seja executado. A limpeza de fantasma poderia envolver a leitura de páginas de dados no cache.

Hidratação de cache

O cache de memória do SQL aumenta à medida que os dados são obtidos do disco da mesma forma e com a mesma velocidade dos bancos de dados provisionados. Quando o banco de dados está ocupado, o cache pode aumentar sem restrições enquanto houver memória disponível.

Gerenciamento de cache de disco

No nível de serviço de Hiperescala tanto nas camadas de computação provisionadas e sem servidor, cada réplica de computação usa um cache RBPEX (Extensão do Pool de Buffers Resilientes), que armazena páginas de dados no SSD local para melhorar o desempenho de E/S. No entanto, na camada de computação sem servidor da Hiperescala, o cache RBPEX para cada réplica de computação aumenta e diminui automaticamente em resposta ao aumento e diminuição da demanda de carga de trabalho. O tamanho máximo que o cache RBPEX pode atingir é três vezes a memória máxima configurada para o banco de dados. Para obter detalhes sobre a memória máxima e os limites de dimensionamento automático RBPEX sem servidor, confira os limites de recursos de Hiperescala sem servidor.

Pausa e retomada automáticas

Atualmente, a pausa e a retomada automáticas sem servidor têm suporte apenas na camada de uso geral.

Pausa automática

A pausa automática será ativada se todas as seguintes condições forem verdadeiras durante o atraso de pausa automática:

  • Número de sessões = 0
  • CPU = 0 para a carga de trabalho do usuário em execução no pool de recursos do usuário

Há uma opção para desativar a pausa automática, se desejado.

Os seguintes recursos não oferecem suporte à pausa automática, mas oferecem suporte ao dimensionamento automático. Se qualquer um dos recursos a seguir for usado, a pausa automática deverá ser desabilitada e o banco de dados permanecerá online, independentemente da duração da inatividade do banco de dados:

  • Replicação geográfica (replicação geográfica ativa e grupos de failover).
  • Retenção de backup de longo prazo (LTR).
  • O banco de dados de sincronização usado na sincronização de dados SQL oferecem suporte à pausa automática, ao contrário dos bancos de dados de sincronização, os bancos de dados de hub e de membros.
  • Alias DNS criado para o servidor lógico que contém um banco de dados sem servidor.
  • Trabalhos Elásticos, o banco de dados sem servidor habilitado para pausa automática não pode ser usado como um Banco de Dados de Trabalho. Bancos de dados sem servidor direcionados a trabalhos elásticos dão suporte à pausa automática. As conexões de trabalho retomarão um banco de dados.

A pausa automática é evitada temporariamente durante a implantação de algumas atualizações de serviço que exigem que o banco de dados esteja online. Nesses casos, a pausa automática será permitida novamente após o término da atualização do serviço.

Solução de problemas de pausa automática

Se a pausa automática estiver habilitada e os recursos que bloqueiam a pausa automática não forem usados, mas um banco de dados não pausar automaticamente após o período de atraso, as sessões do aplicativo ou do usuário podem estar impedindo a pausa automática.

Para ver se há qualquer aplicativo ou sessões de usuário conectadas ao banco de dados no momento, conecte-se ao banco de dados usando qualquer ferramenta de cliente e execute a seguinte consulta:

SELECT session_id,
       host_name,
       program_name,
       client_interface_name,
       login_name,
       status,
       login_time,
       last_request_start_time,
       last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
      AND
      (
          (
          wg.name like 'UserPrimaryGroup.DB%'
          AND
          TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
          )
      OR
      wg.name = 'DACGroup'
      );

Dica

Depois de executar a consulta, desconecte-se do banco de dados. Caso contrário, a sessão aberta usada pela consulta impedirá a pausa automática.

  • Se o conjunto de resultados não estiver vazio, ele indicará que há sessões impedindo a pausa automática no momento.
  • Se o conjunto de resultados estiver vazio, ainda é possível que as sessões tenham sido abertas, possivelmente por um curto período, em algum momento anterior durante o período de atraso de pausa automática. Para verificar atividades durante o período de atraso, você pode usar a auditoria de SQL do Azure e examinar os dados de auditoria para o período relevante.

Importante

A presença de sessões abertas, com ou sem utilização simultânea da CPU no pool de recursos do usuário, é o motivo mais comum para um banco de dados sem servidor não pausar automaticamente conforme o esperado.

Retomada automática

A retomada automática será ativada se uma das seguintes condições for verdadeira em algum momento:

Recurso Gatilho de retomada automática
Autenticação e autorização Logon
Detecção de ameaças Habilitar/desabilitar as configurações de detecção de ameaças no nível do banco de dados ou do servidor.
Alterar as configurações de detecção de ameaças no nível do banco de dados ou do servidor.
Descoberta e classificação de dados Adicionar, modificar, excluir ou exibir os rótulos de confidencialidade
Auditoria Exibir os registros de auditoria.
Atualizar ou exibir a política de auditoria.
Mascaramento de dados Adicionar, modificar, excluir ou exibir as regras de mascaramento de dados
Transparent Data Encryption Exibir o estado ou status de Transparent Data Encryption
Avaliação de vulnerabilidade Verificações ad hoc e verificações periódicas, se habilitadas
Consultar o armazenamento de dados (desempenho) Modificar ou exibir configurações do repositório de consultas
Recomendações do desempenho Exibir ou aplicar recomendações de desempenho
Ajuste automático Aplicação e verificação de recomendações de ajuste automático, como indexação automática
Cópia de banco de dados Criar banco de dados como uma cópia.
Exportar para um arquivo BACPAC.
Sincronização de dados SQL Sincronização entre bancos de dados membro e hub que são executados em um cronograma configurável ou são executados manualmente
Modificar alguns metadados do banco de dados Adicionar novas marcas de banco de dados.
Alterar o máximo de vCores, mínimo de vCores ou atraso de pausa automática.
SQL Server Management Studio (SSMS) Ao usar versões do SSMS anteriores à 18.1 e abrir uma nova janela de consulta para qualquer banco de dados no servidor, todos os bancos de dados em pausa automática no mesmo servidor serão retomados. Esse comportamento não ocorre ao usar a versão 18.1 do SSMS ou posteriores.

O monitoramento, o gerenciamento ou outras soluções que executam qualquer uma das operações listadas acima vão disparar a retomada automática. A retomada automática também é disparada durante a implantação de algumas atualizações de serviço que exigem que o banco de dados esteja online.

Conectividade

Se um banco de dados sem servidor estiver em pausa, a primeira tentativa de conexão retomará o banco de dados e gerará um erro informando que o banco de dados está indisponível, com o código de erro 40613. Depois que o banco de dados for retomado, o logon deve ser repetido para estabelecer a conectividade. Os clientes de banco de dados que seguem uma recomendações de lógica de repetição de conexão não devem ser modificados. Para obter opções e recomendações de lógica de repetição de conexão, consulte:

Latency

A latência para a retomada e a pausa automática de um banco de dados sem servidor geralmente é uma ordem de 1 minuto para retomar automaticamente e 1 a 10 minutos após a expiração do período de atraso para pausar automaticamente.

Transparent Data Encryption (BYOK) gerenciada pelo cliente

Exclusão ou revogação de chave

Se estiver usando a Transparent Data Encryption (BYOK) gerenciada pelo cliente, e o banco de dados sem servidor for pausado automaticamente quando ocorrer a exclusão ou a revogação da chave, o banco de dados permanecerá no estado de pausa automática. Nesse caso, depois que o banco de dados for retomado, o banco de dados se tornará inacessível dentro de aproximadamente 10 minutos. Quando o banco de dados se tornar inacessível, o processo de recuperação será o mesmo para bancos de dados de computação provisionados. Se o banco de dados sem servidor estiver online quando ocorrer a exclusão ou a revogação de chave, o banco de dados também se tornará inacessível dentro de aproximadamente 10 minutos da mesma forma que com os bancos de dados de computação provisionados.

Alteração de chaves

Se estiver usando a criptografia de dados transparente (BYOK) gerenciada pelo cliente e a pausa automática sem servidor estiver habilitada, o banco de dados será retomado automaticamente sempre que as chaves forem alteradas e, posteriormente, pausado automaticamente quando as condições de pausa automática forem satisfeitas.

Criar um banco de dados sem servidor

Criar um novo banco de dados ou mover um banco de dados existente para uma camada de computação sem servidor segue o mesmo padrão que criar um novo banco de dados em uma camada de computação provisionada e envolve as duas etapas a seguir:

  1. Especificar o objetivo de serviço. O objetivo de serviço prescreve a camada de serviço, a configuração de hardware e o máximo de vCores. Para obter as opções de objetivo de serviço, veja Limites de recursos sem servidor

  2. Opcionalmente, especifique o atraso de pausa automática e o mínimo de vCores para alterar seus valores padrão. A tabela a seguir mostra os valores disponíveis para esses parâmetros.

    Parâmetro Opções de valor Valor padrão
    Mínimo de vCores Depende do máximo de vCores configurado. Consulte limites de recursos. vCores de 0,5
    Atraso de pausa automática Mínimo: 15 minutos
    Máximo: 10.080 minutos (7 dias)
    Incrementos: 1 minuto
    Desabilitar pausa automática: -1    		 60 minutos

Os exemplos seguintes criam um novo banco de dados na camada de computação sem servidor.

Usar o portal do Azure

Confira Início Rápido: Criar um banco de dados individual no Banco de Dados SQL do Azure usando o portal do Azure.

Usar o PowerShell

Crie um novo banco de dados de uso geral sem servidor com o seguinte exemplo do PowerShell:

New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 0.5 -MaxVcore 2 -AutoPauseDelayInMinutes 720

Usar a CLI do Azure

Crie um banco de dados de uso geral sem servidor com o seguinte exemplo da CLI do Azure:

az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
  -e GeneralPurpose --compute-model Serverless -f Gen5 `
  --min-capacity 0.5 -c 2 --auto-pause-delay 720

Usar o Transact-SQL (T-SQL)

Quando você usa T-SQL para criar um novo banco de dados sem servidor, os valores padrão são aplicados para o mínimo de vCores e atraso de pausa automática. Seus valores podem ser alterados posteriormente no portal do Azure ou por meio da API, incluindo PowerShell, CLI do Azure e REST.

Para obter detalhes, consulte CREATE DATABASE.

Crie um novo banco de dados sem servidor de uso geral com o seguinte exemplo de T-SQL:

CREATE DATABASE testdb
( EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_S_Gen5_1' ) ;

Mover um banco de dados entre camadas de computação ou camadas de serviço

Um banco de dados pode ser movido entre a camada de computação provisionada e a camada de computação sem servidor.

Um banco de dados sem servidor também pode ser movido da camada de serviço de Uso Geral para a camada de serviço de Hiperescala. Examine Gerenciar bancos de dados de Hiperescala para saber mais.

Ao mover um banco de dados entre camadas de computação, especifique o parâmetro de modelo de computação como Serverless ou Provisioned ao usar o PowerShell ou a CLI do Azure, ou SERVICE_OBJECTIVE ao usar T-SQL. Revise os limites de recursos para identificar o objetivo de serviço apropriado.

Os exemplos a seguir movem um banco de dados existente de computação provisionada para computação sem servidor.

Usar o PowerShell

Mova um banco de dados de Uso Geral de computação provisionado para a camada de computação sem servidor com o seguinte exemplo do PowerShell:

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 1 -MaxVcore 4 -AutoPauseDelayInMinutes 1440

Usar a CLI do Azure

Mova um banco de dados de Uso Geral de computação provisionado para a camada de computação sem servidor com o seguinte exemplo de CLI do Azure:

az sql db update -g $resourceGroupName -s $serverName -n $databaseName `
  --edition GeneralPurpose --compute-model Serverless --family Gen5 `
  --min-capacity 1 --capacity 4 --auto-pause-delay 1440

Usar o Transact-SQL (T-SQL)

Quando você usa T-SQL para mover um banco de dados entre camadas de computação, os valores padrão são aplicados ao mínimo de vCores e atraso de pausa automática. Seus valores podem ser alterados posteriormente no portal do Azure ou por meio da API, incluindo PowerShell, CLI do Azure e REST. Para saber mais, confira ALTERAR BANCO DE DADOS.

Mova um banco de dados de Uso Geral de computação provisionado para a camada de computação sem servidor com o seguinte exemplo de T-SQL:

ALTER DATABASE testdb 
MODIFY ( SERVICE_OBJECTIVE = 'GP_S_Gen5_1') ;

Modificar a configuração sem servidor

Usar o PowerShell

Use Set-AzSqlDatabase para modificar os vCores máximos ou mínimos e o atraso da pausa automática. Use os argumentos MaxVcore, MinVcore e AutoPauseDelayInMinutes. A pausa automática sem servidor não tem suporte atualmente na camada de Hiperescala. Portanto, o argumento de atraso da pausa automática só é aplicável à camada de uso geral.

Usar a CLI do Azure

Use az sql db update para modificar o máximo ou mínimo de vCores e o atraso da pausa automática. Use os argumentos capacity, min-capacity e auto-pause-delay. A pausa automática sem servidor não tem suporte atualmente na camada de Hiperescala. Portanto, o argumento de atraso da pausa automática só é aplicável à camada de uso geral.

Monitor

Recursos usados e cobrados

Os recursos de um banco de dados sem servidor incluem o pacote do aplicativo, instância do SQL e entidades do pool de recursos do usuário.

Pacote do Aplicativo

O pacote do aplicativo é o limite externo de gerenciamento de recursos de um banco de dados, independentemente de se o banco de dados está em uma camada de computação sem servidor ou provisionada. O pacote do aplicativo contém a instância do SQL e os serviços externos, como pesquisa de texto completo, que, juntos, englobam todos os recursos de usuário e do sistema usados por um banco de dados no Banco de Dados SQL. Em geral, a instância do SQL domina a utilização geral de recursos no pacote do aplicativo.

Pool de recursos do usuário

O pool de recursos do usuário é um limite interno de gerenciamento de recursos de um banco de dados, independentemente de se o banco de dados está em uma camada de computação sem servidor ou provisionada. O pool de recursos do usuário engloba CPU e E/S para cargas de trabalho do usuário geradas por consultas DDL (CREATE e ALTER) e DML (INSERT, UPDATE, DELETE e MERGE e SELECT). Essas consultas geralmente representam a proporção mais substancial de utilização dentro do pacote do aplicativo.

Métricas

A tabela a seguir inclui métricas de monitoramento do uso de recursos do pacote de aplicativos e o pool de recursos do usuário de um banco de dados sem servidor, incluindo quaisquer réplicas geográficas:

Entity Métrica Descrição Unidades
Pacote do Aplicativo app_cpu_percent Percentual de vCores usados pelo aplicativo em relação ao máximo de vCores permitido para o aplicativo. Na Hiperescala sem servidor, essa métrica é exposta para todas as réplicas primárias, nomeadas e geográficas. Porcentagem
Pacote do Aplicativo app_cpu_billed A quantidade de computação cobrada para o aplicativo durante o período do relatório. O valor pago durante esse período é o produto dessa métrica e o preço unitário de vCore.

Os valores dessa métrica são determinados pela agregação do máximo de CPU usado e a memória usada por segundo. Se o valor usado for menor que a quantidade mínima provisionada conforme definido pelo mínimo de vCores e de memória, a quantidade mínima provisionada será cobrada. Para comparar CPU com memória para fins de cobrança, a memória é normalizada em unidades de vCores ao redimensionar a quantidade de memória em GB por 3 GB por vCore. Na Hiperescala sem servidor, essa métrica é exposta para a réplica primária e quaisquer réplicas nomeadas.		 Segundos de vCore
Pacote do Aplicativo app_cpu_billed_HA_replicas Aplicável somente à Hiperescala sem servidor. Soma da computação cobrada em todos os aplicativos para réplicas de alta disponibilidade durante o período do relatório. Essa soma tem como escopo as réplicas HA pertencentes à réplica primária ou as réplicas HA pertencentes a uma determinada réplica nomeada. Antes de calcular essa soma nas réplicas de HA, a quantidade de computação cobrada para uma réplica de HA individual é determinada da mesma forma que para a réplica primária ou uma réplica nomeada. Na Hiperescala sem servidor, essa métrica é exposta para todas as réplicas primárias, nomeadas e geográficas. O valor pago durante esse período do relatório é o produto dessa métrica e o preço unitário de vCore. Segundos de vCore
Pacote do Aplicativo app_memory_percent Percentual da memória usada pelo aplicativo em relação ao máximo de memória permitida para o aplicativo. Na Hiperescala sem servidor, essa métrica é exposta para todas as réplicas primárias, nomeadas e geográficas. Porcentagem
Pool de recursos do usuário cpu_percent Percentual de vCores usados pela carga de trabalho do usuário em relação ao máximo de vCores permitido para a carga de trabalho do usuário. Porcentagem
Pool de recursos do usuário data_IO_percent Percentual de IOPS de dados usados pela carga de trabalho do usuário em relação ao máximo de IOPS de dados permitido para a carga de trabalho do usuário. Porcentagem
Pool de recursos do usuário log_IO_percent Percentual de MB/s de log usados pela carga de trabalho do usuário em relação ao máximo de MB/s de log permitido para a carga de trabalho do usuário. Porcentagem
Pool de recursos do usuário workers_percent Percentual de funções de trabalho usadas pela carga de trabalho do usuário em relação ao máximo de funções de trabalho permitidas para a carga de trabalho do usuário. Porcentagem
Pool de recursos do usuário sessions_percent Percentual de sessões usadas pela carga de trabalho do usuário em relação ao máximo de sessões permitidas para a carga de trabalho do usuário. Porcentagem

Pausar e retomar status

No caso de um banco de dados sem servidor com a pausa automática habilitada, o status relatado inclui os seguintes valores:

Status Descrição
Online O banco de dados está online.
Pausando O banco de dados está em transição de online para pausado.
Pausada O banco de dados está pausado.
Retomando O banco de dados está em transição de pausado para online.

Usar o portal do Azure

No portal do Azure, o status do banco de dados é exibido na página visão geral do banco de dados e do servidor. Também no portal do Azure, o histórico de pausas e os eventos de retomada de um banco de dados sem servidor podem ser exibidos no log de atividades.

Usar o PowerShell

Exiba o status atual do banco de dados usando o seguinte exemplo do PowerShell:

Get-AzSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename `
  | Select -ExpandProperty "Status"

Usar a CLI do Azure

Exiba o status atual do banco de dados usando o seguinte exemplo da CLI do Azure:

az sql db show --name $databasename --resource-group $resourcegroupname --server $servername --query 'status' -o json

Limites de recursos

Para limites de recursos, consulte camada de computação sem servidor.

Cobrança

A quantidade de computação cobrada por um banco de dados sem servidor é o máximo de CPU e memória usados a cada segundo. Se a quantidade de CPU e memória usada for menor que a quantidade mínima provisionada para cada recurso, a quantidade provisionada será cobrada. Para comparar a CPU com a memória para fins de cobrança, a memória é normalizada em unidades de vCores redimensionando o número de GB em 3 GB por vCore.

  • Recurso cobrado: CPU e memória
  • Valor cobrado: preço unitário de vCore * máximo (mínimo de vCores, vCores usados, GB de memória mínimo * 1/3, GB de memória usados * 1/3)
  • Frequência de cobrança: Por segundo

O preço unitário de vCore é o custo por vCore por segundo.

Consulte a página de preços do Banco de Dados SQL do Azure para obter os preços unitários específicos em uma determinada região.

A quantidade de computação cobrada sem servidor para um banco de dados de uso geral ou uma réplica primária ou nomeada de Hiperescala é exposta pela seguinte métrica:

  • Métrica: app_cpu_billed (segundos de vCore)
  • Definição: máximo (mínimo de vCores, vCores usados, mínimo de memória em GB * 1/3, GB de memória usados * 1/3)
  • Frequência de relatório: por minuto com base em medidas por segundo agregadas ao longo de 1 minuto.

A quantidade de computação cobrada sem servidor para réplicas de HA em Hiperescala pertencentes à réplica primária ou a qualquer réplica nomeada é exposta pela seguinte métrica:

  • Métrica: app_cpu_billed_HA_replicas (segundos de vCore)
  • Definição: soma do máximo (mínimo de vCores, vCores usados, minínimo de memória em GB * 1/3, memória em GB usada * 1/3) para quaisquer réplicas de HA pertencentes ao recurso pai.
  • Recurso pai e ponto de extremidade de métrica: a réplica primária e qualquer réplica nomeada expõem separadamente essa métrica que mede a computação cobrada para quaisquer réplicas HA associadas.
  • Frequência de relatório: por minuto com base em medidas por segundo agregadas ao longo de 1 minuto.

Fatura de computação mínima

Se um banco de dados sem servidor for pausado, a fatura de computação será zero. Se um banco de dados sem servidor não estiver pausado, a fatura de computação mínima não será menor que a quantidade de vCores com base no máximo (vCores mínimos, mínimo de memória em GB * 1/3).

Exemplos:

  • Suponhamos que um banco de dados na camada de Uso Geral sem servidor não seja pausado e configurado com máximo de 8 vCores e mínimo de 1 vCore correspondente a 3,0 GB de memória mínima. Assim, a conta de computação mínima é baseada no máximo (1 vCore, 3,0 GB * 1 vCore/3 GB) = 1 vCore.
  • Suponha que um banco de dados sem servidor na camada de Uso Geral não esteja em pausa e esteja configurado com máximo de 4 vCores e 0,5 mínimo de vCores correspondentes a 2,1 GB de memória mínima. Assim, a conta de computação mínima é baseada no máximo (0,5 vCore, 2,1 GB * 1 vCore/3 GB) = 0,7 vCores.
  • Suponha que um banco de dados sem servidor na camada de Hiperescala tenha uma réplica primária com uma réplica de HA e uma réplica nomeada sem réplicas de HA. Suponha que cada réplica seja configurada com máximo de 8 vCores e mínimo de 1 vCore correspondente a 3 GB min de memória. Em seguida, a fatura mínima de computação para a réplica primária, de HA e nomeada são baseadas no máximo (1 vCore, 3 GB * 1 vCore / 3 GB) = 1 vCore.

A calculadora de preços do banco de dados SQL do Azure para sem servidor pode ser usada para determinar a memória mínima configurável com base no número de máximo e mínimo de vCores configurado. Como regra, se mínimo de vCores configurado for superior a 0,5 vCores, a conta de computação mínima será independente da memória mínima configurada e baseada apenas no número mínimo de vCores configurado.

Exemplos de cenário

Considere um banco de dados sem servidor na camada de Uso Geral configurado com mínimo de 1 vCore e máximo de 4 vCores. Essa configuração corresponde a cerca de 3 GB de memória mínima e 12 GB de memória máxima. Suponha que o atraso de pausa automática seja definido como 6 horas, e que a carga de trabalho do banco de dados esteja ativa durante as 2 primeiras horas de um período de 24 horas e, de outra forma, inativa.

Nesse caso, o banco de dados é cobrado por computação e armazenamento durante as primeiras 8 horas. Apesar de o banco de dados estar inativo e iniciar após a segunda hora, ele ainda é cobrado pela computação nas próximas 6 horas com base na computação mínima provisionada enquanto o banco de dados está online. Somente o armazenamento é cobrado durante o restante do período de 24 horas enquanto o banco de dados está pausado.

Mais precisamente, a fatura de computação neste exemplo é calculada da seguinte maneira:

Intervalo de tempo vCores usado por segundo GB usados por segundo Dimensão de computação cobrada Segundos de vCore cobrados no intervalo de tempo
0:00-1:00 4 9 vCores usados 4 vCores * 3600 segundos = 14400 segundos de vCore
1:00-2:00 1 12 Memória usada 12 GB * 1/3 * 3600 segundos = 14400 segundos de vCore
2:00-8:00 0 0 Mínimo de memória provisionada 3 GB * 1/3 * 21600 segundos = 21600 segundos de vCore
8:00-24:00 0 0 Nenhuma computação cobrada durante a pausa 0 segundo de vCore
Total de segundos de vCore cobrados em 24 horas 50.400 segundos de vCore

Suponha que o preço de unidade de computação seja US$ 0,000145/vCore/segundo. Em seguida, a computação cobrada para esse período de 24 horas é o produto do preço de unidade de computação e os segundos de vCore cobrados: US$ 0,000145/vCore/segundo * 50400 segundos de vCore ~ US$ 7,31.

Benefício Híbrido do Azure e capacidade reserva

O Benefício Híbrido do Azure (AHB) e os descontos de capacidade reservada não se aplicam à camada de computação sem servidor.

Regiões disponíveis

O modo sem servidor para camadas Uso Geral e de Hiperescala com suporte para até 40 vCores estão disponíveis em todo o mundo, exceto nas seguintes regiões:

  • Leste da China
  • Norte da China
  • Alemanha Central
  • Nordeste da Alemanha
  • US Gov Central (Iowa)

Regiões com suporte a no máximo 80 vCores sem zonas de disponibilidade para Uso Geral e Hiperescala

No momento, há suporte ao máximo de 80 vCores em camadas sem servidor para Uso Geral e Hiperescala nas seguintes regiões:

  • Austrália Central 1
  • Austrália Central 2
  • Leste da Austrália
  • Sudeste da Austrália
  • Brazil South
  • Sudeste do Brasil
  • Canadá Central
  • Leste do Canadá
  • Centro dos EUA
  • Leste da China 2
  • Leste da China 3
  • Norte da China 2
  • Norte da China 3
  • Leste da Ásia
  • Leste dos EUA
  • Leste dos EUA 2
  • França Central
  • Sul da França
  • Norte da Alemanha
  • Centro-Oeste da Alemanha
  • Centro da Índia
  • Sul da Índia
  • Israel Central
  • Norte da Itália
  • Leste do Japão
  • Oeste do Japão
  • Jio India Central
  • Jio Oeste da Índia
  • Coreia Central
  • Sul da Coreia
  • Maylaysia South
  • México Central
  • Centro-Norte dos EUA
  • Norte da Europa
  • Leste da Noruega
  • Oeste da Noruega
  • Polônia Central
  • Catar Central
  • Norte da África do Sul
  • Oeste da África do Sul
  • Centro-Sul dos Estados Unidos
  • Sudeste Asiático
  • Espanha Central
  • Suécia Central
  • Sul da Suécia
  • Norte da Suíça
  • Oeste da Suíça
  • Norte de Taiwan
  • Noroeste de Taiwan
  • EAU Central
  • Norte dos EAU
  • Sul do Reino Unido
  • Oeste do Reino Unido
  • US Gov East
  • US Gov Southcentral
  • US Gov Southwest
  • Europa Ocidental
  • Centro-Oeste dos EUA
  • Oeste dos EUA
  • Oeste dos EUA 2
  • Oeste dos EUA 3

Regiões com suporte a no máximo 80 vCores com zonas de disponibilidade para Uso Geral e Hiperescala

No momento, há suporte ao máximo de 80 vCores com zona de disponibilidade sem servidor para as camadas de Uso Geral e Hiperescala oferecido nas seguintes regiões (com plano de adição de mais regiões):

  • Leste da Austrália
  • Brazil South
  • Canadá Central
  • Centro dos EUA
  • Leste da Ásia
  • Leste dos EUA
  • Leste dos EUA 2
  • França Central
  • Centro-Oeste da Alemanha
  • Centro da Índia
  • Leste do Japão
  • Coreia Central
  • Norte da Europa
  • Norte da África do Sul
  • Centro-Sul dos Estados Unidos
  • Sudeste Asiático
  • Suécia Central
  • Norte dos EAU
  • Sul do Reino Unido
  • US Gov East
  • Europa Ocidental
  • Oeste dos EUA 2
  • Oeste dos EUA 3

Conteúdo relacionado