Perguntas frequentes sobre a Base de Dados SQL do Azure Hyperscale

Aplica-se a:Banco de Dados SQL do Azure

Este artigo fornece respostas a perguntas frequentes para clientes que consideram um banco de dados na camada de serviço Hiperescala do Banco de Dados SQL do Azure, referida como apenas Hyperscale no restante destas Perguntas frequentes. Este artigo descreve os cenários suportados pelo Hyperscale e os recursos compatíveis com o Hyperscale.

  • Este FAQ destina-se a leitores que têm uma breve compreensão da camada de serviço Hyperscale e estão procurando ter suas perguntas e preocupações específicas respondidas.
  • Este FAQ não se destina a ser um guia ou responder a perguntas sobre como usar um banco de dados Hyperscale. Para obter uma introdução ao Hyperscale, recomendamos que consulte a documentação do Azure SQL Database Hyperscale .

Perguntas gerais

O que é um banco de dados Hyperscale?

Um banco de dados Hyperscale é um banco de dados no Banco de dados SQL que é apoiado pela tecnologia de armazenamento scale-out Hyperscale. A base de dados Hyperscale suporta até 100 TB de dados e proporciona um débito e desempenho elevados, assim como dimensionamento rápido para se adaptar aos requisitos da carga de trabalho. A conectividade, o processamento de consultas, os recursos do mecanismo de banco de dados e assim por diante, funcionam como qualquer outro banco de dados no Banco de Dados SQL do Azure.

Que tipos de recursos e modelos de compra suportam o Hyperscale?

O escalão de serviço Hyperscale só está disponível para bases de dados individuais com o modelo de compra baseado em vCore na Base de Dados SQL do Azure. Não está disponível no modelo de compra baseado em DTU.

Qual é a diferença entre a camada de serviço Hyperscale e as camadas de serviço Uso Geral e Críticas para os Negócios?

As camadas de serviço baseadas em vCore são diferenciadas com base na disponibilidade do banco de dados e no tipo de armazenamento, desempenho e tamanho máximo de armazenamento, conforme descrito na comparação de limites de recursos.

Quem deve usar a camada de serviço Hyperscale?

O escalão de serviço Hyperscale é para todos os clientes que precisam de mais desempenho e disponibilidade, cópias de segurança e restauro rápidos e/ou rapidez no armazenamento e escalabilidade computacional. Tal inclui clientes que estão a mudar para a cloud para modernizarem as aplicações e clientes que já estão a utilizar outros escalões de serviço na Base de Dados SQL do Azure. Com o Hyperscale, obtém:

  • Tamanho do banco de dados de até 100 TB.
  • Backups rápidos de banco de dados, independentemente do tamanho do banco de dados (os backups são baseados em instantâneos de armazenamento).
  • Restaurações rápidas de banco de dados, independentemente do tamanho do banco de dados (as restaurações são de snapshots de armazenamento).
  • Maior taxa de transferência de log, independentemente do tamanho do banco de dados e do número de vCores.
  • Expansão de leitura usando uma ou mais réplicas somente leitura, usadas para descarregamento de leitura ou como bancos de dados em espera ativa.
  • Um aumento vertical rápido da computação, com tempo constante, para um acomodamento mais potente da carga de trabalho elevada e, em seguida, uma redução vertical, com tempo constante. As operações de dimensionamento levam minutos de um dígito para computação provisionada e menos de um segundo para computação sem servidor, independentemente do tamanho do banco de dados.

Quais regiões suportam atualmente o Hyperscale?

A camada de serviço Hyperscale está disponível em todas as regiões onde o Banco de Dados SQL do Azure está disponível.

Posso criar vários bancos de dados Hyperscale por servidor?

Sim. Para obter mais informações e limites sobre o número de bancos de dados por servidor, consulte Limites de recursos do Banco de dados SQL para bancos de dados únicos e agrupados em um servidor.

Quais são as características de desempenho de um banco de dados Hyperscale?

A arquitetura Hyperscale oferece alto desempenho e taxa de transferência, ao mesmo tempo em que suporta grandes tamanhos de banco de dados.

Qual é a escalabilidade de um banco de dados Hyperscale?

O Hyperscale fornece escalabilidade rápida com base na sua demanda de carga de trabalho.

  • Escalando para cima/para baixo

    Com o Hyperscale, você pode aumentar o tamanho da computação primária em termos de recursos como CPU e memória e, em seguida, reduzir a escala em tempo constante. Como o armazenamento é remoto, o dimensionamento e a redução não são um tamanho de operação de dados.

    O suporte para computação sem servidor fornece escalonamento e redução automáticos, e a computação é cobrada com base no uso.

  • Entrada e saída de escala

    Com o Hyperscale, você pode usar três tipos de réplicas secundárias para atender aos requisitos de expansão de leitura, alta disponibilidade e replicação geográfica. O que está incluído:

    • Até quatro réplicas de alta disponibilidade com o mesmo tamanho de computação que a principal. Eles servem como réplicas em espera quente para fazer failover rápido do primário. Você também pode usá-los para descarregar cargas de trabalho de leitura do primário.
    • Até 30 réplicas nomeadas com o mesmo tamanho de computação ou tamanho diferente do principal, para atender a vários cenários de expansão de leitura.
    • Uma réplica geográfica em uma região diferente do Azure para proteger contra interrupções regionais e permitir a expansão de leitura geográfica.

Perguntas aprofundadas

Posso misturar Hyperscale e bancos de dados únicos em um único servidor?

Sim, pode.

O Hyperscale requer que meu modelo de programação de aplicativos seja alterado?

Não, seu modelo de programação de aplicativo permanece o mesmo que para qualquer outro banco de dados MSSQL. Você usa sua cadeia de conexão como de costume e as outras maneiras regulares de interagir com seu banco de dados Hyperscale. Depois de usar o Hyperscale, seu aplicativo pode aproveitar recursos como réplicas secundárias.

Qual nível de isolamento de transação é o padrão em um banco de dados Hyperscale?

Na réplica primária, o nível de isolamento de transação padrão é RCSI (Read Committed Snapshot Isolation). Nas réplicas secundárias de Expansão de Leitura, o nível de isolamento padrão é Instantâneo. Isso é o mesmo que em qualquer outro banco de dados SQL do Azure.

Posso trazer minha licença local ou IaaS SQL Server para o Hyperscale?

Sim, o Benefício Híbrido do Azure está disponível para Hyperscale apenas na camada de computação provisionada. Cada núcleo do SQL Server Standard pode ser mapeado para um vCores Hyperscale. Cada núcleo do SQL Server Enterprise pode ser mapeado para quatro vCores de hiperescala. Você não precisa de uma licença SQL para réplicas secundárias. O preço do Benefício Híbrido do Azure é aplicado automaticamente a réplicas de Expansão de Leitura (secundárias). Consulte computação sem servidor para obter uma opção de cobrança alternativa com base no uso. Nota: Preços simplificados para o SQL Database Hyperscale em breve. Consulte o blog de preços do Hyperscale para obter detalhes.

Para que tipo de cargas de trabalho o Hyperscale foi projetado?

A hiperescala funciona bem para todos os tipos de carga de trabalho, incluindo cargas de trabalho OLTP, híbridas (HTAP) e analíticas (data mart).

Como posso escolher entre o Azure Synapse Analytics e o Azure SQL Database Hyperscale?

Se você estiver executando consultas de análise interativas usando o SQL Server como um data warehouse, o Hyperscale é uma ótima opção porque você pode hospedar armazéns de dados de pequeno e médio porte (como alguns TB até 100 TB) a um custo mais baixo e pode migrar suas cargas de trabalho de data warehouse do SQL Server para o Hyperscale com alterações mínimas no código T-SQL.

Se você estiver executando análises de dados em grande escala com consultas complexas e taxas de ingestão sustentadas superiores a 100 MB/s ou usando PDW (Parallel Data Warehouse), Teradata ou outros armazéns de dados MPP (Massively Parallel Processing), o Azure Synapse Analytics pode ser a melhor escolha.

Perguntas sobre computação em hiperescala

Posso pausar minha computação a qualquer momento?

Neste momento, não. No entanto, você pode dimensionar sua computação e o número de réplicas para reduzir o custo fora dos horários de pico, ou usar serverless para dimensionar automaticamente a computação com base no uso.

Posso provisionar uma réplica de computação com RAM extra para minha carga de trabalho que consome muita memória?

Para cargas de trabalho de leitura, você pode criar uma réplica nomeada com um tamanho de computação maior (mais núcleos e memória) do que a principal. Para obter mais informações sobre tamanhos de computação disponíveis, consulte Armazenamento em hiperescala e tamanhos de computação.

Posso provisionar várias réplicas de computação de tamanhos diferentes?

Para cargas de trabalho de leitura, isso pode ser feito usando réplicas nomeadas.

Quantas réplicas de expansão de leitura são suportadas?

Você pode dimensionar o número de réplicas secundárias de HA entre 0 e 4 usando o portal do Azure ou a API REST. Além disso, você pode criar até 30 réplicas nomeadas para muitos cenários de expansão de leitura.

Para alta disponibilidade, preciso provisionar réplicas de computação adicionais?

Em bancos de dados Hyperscale, a resiliência de dados é fornecida no nível de armazenamento. Você só precisa de uma réplica (a principal) para fornecer resiliência. Quando a réplica de computação está inativa, uma nova réplica é criada automaticamente sem perda de dados.

No entanto, se houver apenas a réplica primária, pode levar um ou dois minutos para criar uma nova réplica após o failover, em vez de segundos no caso em que uma réplica secundária HA estiver disponível. A nova réplica terá caches frios inicialmente, o que pode resultar em maior latência de armazenamento e desempenho de consulta reduzido imediatamente após o failover.

Para aplicativos de missão crítica que exigem alta disponibilidade com impacto mínimo de failover, você deve provisionar pelo menos uma réplica secundária de HA para garantir que uma réplica de espera ativa esteja disponível para servir como destino de failover.

Perguntas sobre tamanho e armazenamento de dados

Qual é o tamanho máximo do banco de dados suportado com o Hyperscale?

100 TB.

Qual é o tamanho do log de transações com o Hyperscale?

No Hyperscale, o log de transações é praticamente infinito, com uma restrição de que a parte ativa do log não pode exceder 1 TB. A parte ativa do log pode crescer devido a transações de longa duração ou devido ao processamento do Change Data Capture não acompanhar a taxa de alteração de dados. Evite transações desnecessariamente longas e grandes para ficar abaixo desse limite. Além dessa restrição, você não precisa se preocupar em ficar sem espaço de log em um sistema que tenha alta taxa de transferência de log. No entanto, a taxa de geração de logs pode ser limitada para cargas de trabalho contínuas de gravação agressiva. A taxa de geração de log sustentada de pico é de 100 MB/s.

O meu 'tempdb' é dimensionado à medida que a minha base de dados cresce?

Seu tempdb banco de dados está localizado no armazenamento SSD local e é dimensionado proporcionalmente ao tamanho de computação (o número de núcleos) que você provisiona. O tamanho do tempdb não é configurável e é gerenciado para você. Para determinar o tamanho máximo tempdb do banco de dados, consulte Tamanhos de computação e armazenamento em hiperescala.

O tamanho do meu banco de dados aumenta automaticamente ou tenho que gerenciar o tamanho dos arquivos de dados?

O tamanho do banco de dados aumenta automaticamente à medida que você insere/ingere mais dados.

Qual é o menor tamanho de banco de dados suportado pelo Hyperscale?

10 GB. Um banco de dados Hyperscale é criado com um tamanho inicial de 10 GB e cresce conforme necessário em blocos de 10 GB.

Em que incrementos o tamanho do meu banco de dados cresce?

Cada arquivo de dados cresce 10 GB. Vários arquivos de dados podem crescer ao mesmo tempo.

O armazenamento em Hyperscale é local ou remoto?

No Hyperscale, os arquivos de dados são armazenados no armazenamento padrão do Azure. Os dados são totalmente armazenados em cache no armazenamento SSD local, em servidores de página remotos para réplicas de computação. Além disso, as réplicas de computação têm caches de dados no SSD local e na memória, para reduzir a frequência de busca de dados de servidores de página remotos.

Posso gerenciar ou definir arquivos ou grupos de arquivos com o Hyperscale?

N.º Os arquivos de dados são adicionados automaticamente ao PRIMARY grupo de arquivos. Os motivos comuns para criar grupos de arquivos adicionais não se aplicam na arquitetura de armazenamento de hiperescala ou no Banco de Dados SQL do Azure de forma mais ampla.

Posso provisionar um limite rígido no crescimento de dados para meu banco de dados?

N.º

Há suporte para redução de banco de dados?

Neste momento, não.

A compressão de dados é suportada?

Sim, assim como em qualquer outro banco de dados do Banco de Dados SQL do Azure. Isso inclui a compactação de linha, página e columnstore.

Se eu tiver uma tabela enorme, os dados da tabela estão espalhados por vários arquivos de dados?

Sim. As páginas de dados associadas a uma determinada tabela podem acabar em vários arquivos de dados, que fazem parte do mesmo grupo de arquivos. O mecanismo de banco de dados MSSQL usa a estratégia de preenchimento proporcional para distribuir dados em arquivos de dados.

Perguntas sobre migração de dados

Posso mover meus bancos de dados existentes no Banco de Dados SQL do Azure para a camada de serviço Hyperscale?

Sim. Você pode mover seus bancos de dados existentes no Banco de Dados SQL do Azure para o Hyperscale. Para provas de conceito (POCs), recomendamos que você faça uma cópia do seu banco de dados e migre a cópia para o Hyperscale.

O tempo necessário para mover um banco de dados existente para o Hyperscale consiste no tempo para copiar dados e o tempo para reproduzir as alterações feitas no banco de dados de origem durante a cópia de dados. O tempo de cópia dos dados é proporcional ao tamanho dos dados. O tempo para reproduzir as alterações será menor se a mudança for feita durante um período de baixa atividade de gravação.

Obtenha código de exemplo para migrar Bancos de Dados SQL do Azure existentes para Hyperscale no portal do Azure, CLI do Azure, PowerShell e Transact-SQL em Migrar um banco de dados existente para Hyperscale.

A migração reversa para a camada de serviço de Propósito Geral permite que os clientes que migraram recentemente um banco de dados existente no Banco de Dados SQL do Azure para a camada de serviço Hyperscale voltem, caso o Hyperscale não atenda às suas necessidades. Embora a migração reversa seja iniciada por uma alteração na camada de serviço, ela é essencialmente uma operação de tamanho de dados entre diferentes arquiteturas. Da mesma forma que a migração para o Hyperscale, a migração reversa será mais rápida se feita durante um período de baixa atividade de gravação. Conheça as limitações da migração inversa.

Posso mover meus bancos de dados Hyperscale para outras camadas de serviço?

Se você tiver migrado anteriormente um Banco de Dados SQL do Azure existente para a camada de serviço Hyperscale, poderá revertê-lo para a camada de serviço de Propósito Geral dentro de 45 dias da migração original para Hyperscale. Se desejar migrar o banco de dados para outra camada de serviço, como Business Critical, primeiro faça a migração reversa para a camada de serviço de uso geral e, em seguida, modifique a camada de serviço. A migração reversa é um tamanho de operação de dados.

Os bancos de dados criados na camada de serviço Hyperscale não podem ser movidos para outras camadas de serviço.

Saiba como reverter a migração do Hyperscale, incluindo as limitações da migração reversa e as políticas de backup afetadas.

Perco alguma funcionalidade ou capacidade após a migração para a camada de serviço Hyperscale?

Sim. Alguns recursos do Banco de Dados SQL do Azure ainda não têm suporte no Hyperscale. Se alguns desses recursos estiverem habilitados para seu banco de dados, a migração para o Hyperscale poderá ser bloqueada ou esses recursos deixarão de funcionar após a migração. Esperamos que estas limitações sejam temporárias. Para obter detalhes, consulte Limitações conhecidas.

Posso mover meu banco de dados SQL Server local ou meu banco de dados SQL Server em uma máquina virtual em nuvem para o Hyperscale?

Sim. Você pode usar muitas tecnologias de migração existentes para migrar para o Hyperscale, incluindo replicação transacional e quaisquer outras tecnologias de movimentação de dados (Bulk Copy, Azure Data Factory, Azure Databricks, SSIS). Consulte também o Serviço de Migração de Banco de Dados do Azure, que dá suporte a muitos cenários de migração.

Qual é o meu tempo de inatividade durante a migração de um ambiente local ou de máquina virtual para o Hyperscale e como posso minimizá-lo?

O tempo de inatividade para a migração para o Hyperscale é o mesmo que o tempo de inatividade quando você migra seus bancos de dados para outras camadas de serviço do Banco de Dados SQL do Azure. Você pode usar a replicação transacional para minimizar o tempo de inatividade da migração para bancos de dados de até alguns TB de tamanho. Para bancos de dados muito grandes (10+ TB), você pode considerar a implementação do processo de migração usando ADF, Spark ou outras tecnologias de movimentação de dados em massa.

Quanto tempo levaria para trazer X quantidade de dados para o Hyperscale?

O Hyperscale é capaz de consumir 100 MB/s de dados novos/alterados, mas o tempo necessário para mover dados para bancos de dados no Banco de Dados SQL do Azure também é afetado pela taxa de transferência de rede disponível, velocidade de leitura de origem e o objetivo de nível de serviço do banco de dados de destino.

Posso ler dados do armazenamento de blob e fazer um carregamento rápido (como o Polybase no Azure Synapse Analytics)?

Você pode fazer com que um aplicativo cliente leia dados do Armazenamento do Azure e carregue a carga de dados em um banco de dados Hyperscale (assim como você pode fazer com qualquer outro banco de dados no Banco de Dados SQL do Azure). Atualmente, não há suporte para o Polybase no Banco de Dados SQL do Azure. Como alternativa para fornecer carregamento rápido, você pode usar o Azure Data Factory ou usar um trabalho do Spark no Azure Databricks com o conector Spark para SQL. O conector Spark para SQL suporta inserção em massa.

Também é possível ler dados em massa do repositório de Blobs do Azure usando BULK INSERT ou OPENROWSET: Exemplos de acesso em massa a dados no Armazenamento de Blobs do Azure.

Não há suporte para recuperação simples ou modelo de log em massa no Hyperscale. O modelo de recuperação completa é necessário para fornecer alta disponibilidade e recuperação point-in-time. No entanto, a arquitetura de log do Hyperscale fornece uma melhor taxa de ingestão de dados em comparação com outras camadas de serviço do Banco de Dados SQL do Azure.

O Hyperscale permite o provisionamento de vários nós para ingestão paralela de grandes quantidades de dados?

N.º A hiperescala é uma arquitetura simétrica de multiprocessamento (SMP) e não é um processamento paralelo maciço (MPP) ou uma arquitetura multimestre. Você só pode criar várias réplicas para expandir cargas de trabalho somente leitura.

O Hyperscale suporta migração de outras fontes de dados, como Amazon Aurora, MySQL, PostgreSQL, Oracle, DB2 e outras plataformas de banco de dados?

Perguntas sobre continuidade de negócios e recuperação de desastres

Quais SLAs são fornecidos para um banco de dados Hyperscale?

Consulte SLA para o Banco de Dados SQL do Azure. Recomendamos adicionar réplicas secundárias de HA para cargas de trabalho críticas. Isso proporciona failover mais rápido e reduz o impacto potencial no desempenho imediatamente após o failover.

Os backups de banco de dados são gerenciados para mim pelo Banco de Dados SQL do Azure?

Sim.

O Hyperscale suporta zonas de disponibilidade?

Sim, o Hyperscale suporta configuração redundante de zona. Pelo menos uma réplica secundária de HA e o uso de armazenamento com redundância de zona ou geozona são necessários para habilitar a configuração redundante de zona para Hyperscale.

Com que frequência são feitos backups de banco de dados?

Não existem cópias de segurança tradicionais completas, diferenciais e de registos de transações para bases de dados Hyperscale. Em vez disso, há instantâneos de armazenamento regulares de arquivos de dados, com uma cadência de instantâneo separada para cada arquivo. O registo de transações gerado é mantido tal como está durante o período de retenção configurado. No momento da restauração, os registros de log de transações relevantes são aplicados aos snapshots de armazenamento restaurados. Independentemente da cadência do snapshot, isso resulta em um banco de dados transacionalmente consistente sem qualquer perda de dados a partir do point-in-time especificado dentro do período de retenção. Na verdade, o backup de banco de dados no Hyperscale é contínuo.

O Hyperscale suporta restauração point-in-time?

Sim.

O que é o RPO (Recovery Point Objetive, objetivo de ponto de recuperação)/RTO (Recovery Time Objetive, objetivo de tempo de recuperação) para restauração de banco de dados em Hyperscale?

O RPO para restauração point-in-time é de 0 min. A maioria das operações de restauração point-in-time é concluída em 60 minutos, independentemente do tamanho do banco de dados. O tempo de restauração pode ser maior para bancos de dados maiores e se o banco de dados tiver tido uma atividade de gravação significativa antes e até o ponto de restauração. Alterar a redundância de armazenamento ao emitir uma restauração pode resultar em tempos de restauração mais longos, pois a restauração é o tamanho dos dados e, portanto, o tempo será proporcional ao tamanho do banco de dados.

O backup de banco de dados afeta o desempenho de computação em minhas réplicas primárias ou secundárias?

N.º Os backups são gerenciados pelo subsistema de armazenamento e usam snapshots de armazenamento. Eles não afetam as cargas de trabalho do usuário.

Posso executar a restauração geográfica com um banco de dados Hyperscale?

Sim. A restauração geográfica é totalmente suportada se o armazenamento com redundância geográfica for usado. Este é o padrão para novos bancos de dados. Ao contrário da restauração point-in-time, a restauração geográfica requer uma operação de tamanho de dados. Os arquivos de dados são copiados em paralelo, portanto, a duração dessa operação depende principalmente do tamanho do maior arquivo no banco de dados, em vez do tamanho total do banco de dados. O tempo de restauração geográfica será significativamente menor se o banco de dados for restaurado na região do Azure emparelhada com a região do banco de dados de origem.

Posso configurar a replicação geográfica com um banco de dados Hyperscale?

Sim. A replicação geográfica pode ser configurada para bancos de dados Hyperscale.

Posso fazer um backup de banco de dados Hyperscale e restaurá-lo no meu servidor local ou no SQL Server em uma VM?

N.º O formato de armazenamento para bancos de dados Hyperscale é diferente de qualquer versão lançada do SQL Server e você não controla backups nem tem acesso a eles. Para retirar seus dados de um banco de dados Hyperscale, você pode extrair dados usando qualquer tecnologia de movimentação de dados, ou seja, Azure Data Factory, Azure Databricks, SSIS, etc.

Serei cobrado pelos custos de armazenamento de backup no Hyperscale?

Sim. A partir de 4 de maio de 2022, os backups de todos os novos bancos de dados são cobrados com base no armazenamento de backup consumido e na redundância de armazenamento selecionada com taxas capturadas na página de preços do Banco de Dados SQL do Azure. Para bancos de dados Hyperscale criados antes de 4 de maio de 2022, os backups serão cobrados somente se a retenção de backup estiver definida como superior a sete dias. Para saber mais, consulte Backups em hiperescala e redundância de armazenamento.

Como posso medir o tamanho do armazenamento de backup no meu banco de dados Hyperscale?

Os detalhes sobre como medir o tamanho do armazenamento de backup são capturados em Backups automatizados.

Como sei qual será a minha fatura de backup?

Para determinar a fatura de armazenamento de backup, o tamanho do armazenamento de backup é calculado periodicamente e multiplicado pela taxa de armazenamento de backup e pelo número de horas desde o último cálculo. Para estimar sua fatura de backup para um período de tempo, multiplique o tamanho de armazenamento de backup faturável para cada hora do período pela taxa de armazenamento de backup e adicione todos os valores por hora. Para consultar métricas relevantes do Azure Monitor para vários intervalos horários programaticamente, use a API REST do Azure Monitor. O faturamento de backup na camada de computação sem servidor é o mesmo que na camada de computação provisionada.

Como minha carga de trabalho influenciará meus custos de armazenamento de backup?

Os custos de backup serão maiores para cargas de trabalho que adicionam, modificam ou excluem grandes volumes de dados no banco de dados. Por outro lado, cargas de trabalho que são principalmente somente leitura podem ter custos de backup menores.

Como posso minimizar os custos de armazenamento de backup?

Os detalhes sobre como minimizar os custos de armazenamento de backup são capturados em backups automatizados.

Perguntas sobre desempenho

Quanta taxa de transferência de gravação posso enviar por push em um banco de dados Hyperscale?

O limite de taxa de transferência do log de transações é definido como 100 MB/s para qualquer tamanho de computação Hyperscale. A capacidade de atingir essa taxa depende de vários fatores, incluindo, entre outros, o tipo de carga de trabalho, a configuração e o desempenho do cliente, e ter capacidade de computação suficiente na réplica de computação primária para produzir registros de log nessa taxa.

Quantas IOPS obtenho no maior computador?

A latência de IOPS e IO variará dependendo dos padrões de carga de trabalho. Se os dados acessados estiverem armazenados em cache no RBPEX na réplica de computação, você verá um desempenho de E/S semelhante ao das camadas de serviço Business Critical ou Premium.

Minha taxa de transferência é afetada por backups?

N.º A computação é dissociada da camada de armazenamento. Isso elimina o impacto no desempenho do backup.

Minha taxa de transferência é afetada à medida que provisiono réplicas de computação adicionais?

Como o armazenamento é compartilhado e não há replicação física direta acontecendo entre réplicas de computação primárias e secundárias, a taxa de transferência na réplica primária não será diretamente afetada pela adição de réplicas secundárias. No entanto, cargas de trabalho de gravação contínuas e agressivas podem ser limitadas no primário para permitir que a aplicação de log em réplicas secundárias e servidores de página se atualizem. Isso evita um desempenho de leitura ruim em réplicas secundárias e recuperação longa após o failover para uma réplica secundária HA.

O Hyperscale é adequado para consultas e transações que consomem muitos recursos e são de longa duração?

Sim. No entanto, assim como em outros bancos de dados do Banco de Dados SQL do Azure, as conexões podem ser encerradas por erros transitórios muito pouco frequentes, que podem abortar consultas de longa execução e reverter transações. Uma causa de erros transitórios é quando o sistema muda rapidamente o banco de dados para um nó de computação diferente para garantir a disponibilidade contínua de recursos de computação e armazenamento ou para executar a manutenção planejada. A maioria desses eventos de reconfiguração termina em menos de 10 segundos. Os aplicativos que se conectam ao seu banco de dados devem ser criados para esperar e tolerar esses erros transitórios pouco frequentes implementando a lógica de repetição. Além disso, considere configurar uma janela de manutenção que corresponda à sua agenda de carga de trabalho para evitar erros transitórios devido à manutenção planejada.

Como faço para diagnosticar e solucionar problemas de desempenho em um banco de dados Hyperscale?

Para a maioria dos problemas de desempenho, particularmente aqueles que não estão enraizados no desempenho do armazenamento, aplicam-se etapas comuns de diagnóstico e solução de problemas do SQL. Para diagnósticos de armazenamento específicos do Hyperscale, consulte SQL Hyperscale performance troubleshooting diagnostics.

Como o limite máximo de memória no serverless se compara à computação provisionada?

A quantidade máxima de memória que um banco de dados sem servidor pode escalar é de 3 GB/vCore vezes o número máximo de vCores configurados, em comparação com mais de 5 GB/vCore vezes o mesmo número de vCores na computação provisionada. Analise os limites de recursos do Hyperscale sem servidor para obter detalhes.

Perguntas sobre escalabilidade

Quanto tempo levaria para aumentar e diminuir a escala de uma réplica de computação?

O dimensionamento para cima ou para baixo na camada de computação provisionada normalmente leva até 2 minutos, independentemente do tamanho dos dados. Na camada de computação sem servidor, onde a computação é dimensionada automaticamente com base na demanda de carga de trabalho, o tempo de dimensionamento normalmente é de subsegundo, mas ocasionalmente pode levar tanto tempo quanto ao dimensionamento da computação provisionada.

Meu banco de dados está offline enquanto a operação de dimensionamento para cima/para baixo está em andamento?

N.º Um banco de dados permanece on-line durante operações de aumento ou redução de escala.

Devo esperar uma queda de conexão quando as operações de dimensionamento estiverem em andamento?

O dimensionamento da computação provisionada para cima ou para baixo resulta na desativação de conexões quando ocorre um failover no final da operação de dimensionamento. Na computação sem servidor, o dimensionamento automático normalmente não resulta na queda de uma conexão, mas pode ocorrer ocasionalmente. Adicionar ou remover réplicas secundárias não resulta em quedas de conexão na principal.

A expansão para cima e para baixo das réplicas de computação é automática ou a operação acionada pelo usuário final?

O dimensionamento na computação provisionada é realizado pelo usuário final. O dimensionamento automático na computação sem servidor é realizado pelo serviço.

O tamanho do meu banco de dados 'tempdb' e do cache RBPEX também cresce à medida que a computação é ampliada?

Sim. O tamanho do banco de dados e do tempdb cache RBPEX nos nós de computação aumenta automaticamente à medida que o número de núcleos é aumentado. Para obter detalhes, consulte Armazenamento em hiperescala e tamanhos de computação.

Posso provisionar várias réplicas de computação primárias, como um sistema multimestre, onde várias cabeças de computação primárias podem gerar um nível mais alto de simultaneidade?

N.º Somente a réplica de computação primária aceita solicitações de leitura/gravação. As réplicas de computação secundárias só aceitam solicitações somente leitura.

Ler perguntas de expansão

Que tipos de réplicas secundárias (leitura em expansão) estão disponíveis no Hyperscale?

O Hyperscale oferece suporte a réplicas de alta disponibilidade (HA), réplicas nomeadas e réplicas geográficas. Consulte Réplicas secundárias de hiperescala para obter detalhes.

Quantas réplicas secundárias de HA posso provisionar?

Entre 0 e 4. Se quiser ajustar o número de réplicas, você pode fazer isso usando o portal do Azure ou a API REST.

Como faço para me conectar a uma réplica secundária de HA?

Você pode se conectar a essas réplicas de computação somente leitura adicionais definindo a ApplicationIntent propriedade em sua cadeia de conexão como ReadOnly. Todas as conexões marcadas com ReadOnly são automaticamente roteadas para uma das réplicas secundárias de HA, se houver. Para obter detalhes, consulte Usar réplicas somente leitura para descarregar cargas de trabalho de consulta somente leitura.

Como valido se me conectei com êxito a uma réplica de computação secundária usando o SQL Server Management Studio (SSMS) ou outras ferramentas de cliente?

Você pode executar a seguinte consulta T-SQL: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). O resultado é READ_ONLY se você estiver conectado a uma réplica secundária somente leitura e READ_WRITE se estiver conectado à réplica primária. O contexto do banco de dados deve ser definido como o nome do seu banco de dados, não para o master banco de dados.

Posso criar um ponto de extremidade dedicado para uma réplica secundária de HA?

N.º Você só pode se conectar a réplicas secundárias de HA especificando ApplicationIntent=ReadOnly. No entanto, você pode usar pontos de extremidade dedicados para réplicas nomeadas.

O sistema faz o balanceamento de carga inteligente da carga de trabalho de leitura em réplicas secundárias de HA?

N.º Uma nova conexão com intenção somente leitura é redirecionada para uma réplica secundária de HA arbitrária.

Posso aumentar ou reduzir a escala de réplicas secundárias de HA independentemente da réplica primária?

Não na camada de computação provisionada. As réplicas secundárias de HA são usadas como destinos de failover de alta disponibilidade, portanto, precisam ter a mesma configuração que a principal para fornecer o desempenho esperado após o failover. No serverless, a computação é dimensionada automaticamente para cada réplica de HA com base em sua demanda de carga de trabalho individual. Cada HA secundária ainda pode ser dimensionada automaticamente para os núcleos máximos configurados para acomodar sua função pós-failover. As réplicas nomeadas oferecem a capacidade de dimensionar cada réplica de forma independente.

Obtenho tamanhos 'tempdb' diferentes para minha computação primária e minhas réplicas secundárias de HA?

N.º Seu tempdb banco de dados é configurado com base no tamanho de computação provisionado, suas réplicas secundárias de HA têm o mesmo tamanho, incluindo tempdb, como a computação primária. Em réplicas nomeadas, é dimensionado de acordo com o tamanho de computação da réplica, portanto, tempdb pode ser menor ou maior do que tempdb na primária.

Posso adicionar índices e visualizações em minhas réplicas de computação secundárias?

N.º Os bancos de dados de hiperescala têm armazenamento compartilhado, o que significa que todas as réplicas de computação veem as mesmas tabelas, índices e outros objetos de banco de dados. Se quiser índices adicionais otimizados para leituras no secundário, você deve adicioná-los no primário. Você ainda pode criar tabelas temporárias (nomes de tabela prefixados com # ou ##) em cada réplica secundária para armazenar dados temporários. As tabelas temporárias são leitura-gravação.

Quanto atraso haverá entre as réplicas de computação primária e secundária?

A latência de dados desde o momento em que uma transação é confirmada no primário até o momento em que é legível em um secundário depende da taxa de geração de log atual, do tamanho da transação, da carga na réplica e de outros fatores. A latência de dados típica para pequenas transações é de dezenas de milissegundos, no entanto, não há limite superior para a latência de dados. Os dados em uma determinada réplica secundária são sempre transacionalmente consistentes, portanto, transações maiores levam mais tempo para se propagar. No entanto, em um determinado momento, a latência de dados e o estado do banco de dados podem ser diferentes para réplicas secundárias diferentes. As cargas de trabalho que precisam ler dados confirmados imediatamente devem ser executadas na réplica primária.

Uma réplica nomeada pode ser usada como destino de failover?

Não, as réplicas nomeadas não podem ser usadas como destinos de failover para a réplica primária. Adicione réplicas HA para essa finalidade.

Como posso distribuir uma carga de trabalho somente leitura entre minhas réplicas nomeadas?

Como cada réplica nomeada pode ter um objetivo de nível de serviço diferente e, portanto, ser usada para diferentes casos de uso, não há uma maneira interna de direcionar o tráfego somente leitura enviado para o primário para um conjunto de réplicas nomeadas. Por exemplo, você pode ter oito réplicas nomeadas e talvez queira direcionar a carga de trabalho OLTP apenas para réplicas nomeadas de 1 a 4, enquanto as cargas de trabalho analíticas do Power BI usam réplicas nomeadas 5 e 6 e a carga de trabalho de ciência de dados usa réplicas 7 e 8. Dependendo da ferramenta ou linguagem de programação usada, as estratégias para distribuir essa carga de trabalho podem variar. Para obter um exemplo de criação de uma solução de roteamento de carga de trabalho para permitir que um back-end REST seja dimensionado, revise o exemplo de expansão OLTP.

Uma réplica nomeada pode estar em uma região diferente da região da réplica primária?

Não, como as réplicas nomeadas usam os mesmos servidores de página da réplica primária, elas devem estar na mesma região.

Uma réplica nomeada pode afetar a disponibilidade ou o desempenho da réplica principal?

Uma réplica nomeada não pode afetar a disponibilidade da réplica primária. É improvável que réplicas nomeadas, em circunstâncias normais, afetem o desempenho do primário, mas isso pode acontecer se houver cargas de trabalho intensivas em execução. Assim como uma réplica HA, uma réplica nomeada é mantida em sincronia com a principal por meio do serviço de log de transações. Se uma réplica nomeada, por qualquer motivo, não for capaz de consumir o log de transações com rapidez suficiente, ela começará a pedir à réplica primária para diminuir (acelerar) sua geração de log, para que possa recuperar o atraso. Embora esse comportamento não afete a disponibilidade do primário, ele pode afetar o desempenho de cargas de trabalho de gravação no principal. Para evitar essa situação, certifique-se de que suas réplicas nomeadas tenham espaço suficiente para recursos – principalmente CPU – para processar o log de transações sem demora. Por exemplo, se o primário estiver processando várias alterações de dados, é recomendável ter réplicas nomeadas com pelo menos o mesmo Objetivo de Nível de Serviço que o principal, para evitar saturar a CPU nas réplicas e, assim, forçar o primário a ficar mais lento.

O que acontece com réplicas nomeadas se a réplica primária não estiver disponível, por exemplo, devido à manutenção planejada?

As réplicas nomeadas ainda estarão disponíveis para acesso somente leitura, como de costume.

Como posso melhorar a disponibilidade de réplicas nomeadas?

Por padrão, as réplicas nomeadas não têm réplicas HA próprias. Um failover de uma réplica nomeada requer a criação de uma nova réplica primeiro, o que normalmente leva cerca de 1 a 2 minutos. No entanto, as réplicas nomeadas também podem se beneficiar de maior disponibilidade e failovers mais curtos fornecidos pelas réplicas HA. Para adicionar réplicas HA para uma réplica nomeada, você pode usar o parâmetro com AZ CLI ou o parâmetro ha-replicas HighAvailabilityReplicaCount com PowerShell ou a propriedade com API highAvailabilityReplicaCount REST. O número de réplicas HA pode ser definido durante a criação de uma réplica nomeada e pode ser alterado – somente por meio da AZ CLI, PowerShell ou API REST – a qualquer momento após a réplica nomeada ter sido criada. O preço das réplicas HA para réplicas nomeadas é o mesmo das réplicas HA para bancos de dados Hyperscale regulares.

Para obter mais informações sobre a camada de serviço Hyperscale, consulte Hyperscale service tier.