Perguntas frequentes sobre a hiperescala do Banco de Dados SQL do Azure

Um banco de dados Hyperscale é um banco de dados no Banco de Dados SQL do Azure que é apoiado pela tecnologia de armazenamento Hyperscale scale-out. Um banco de dados Hyperscale suporta até 128 TB de dados e fornece alta taxa de transferência e desempenho, bem como escalabilidade rápida para se adaptar aos requisitos de carga de trabalho. A conectividade, o processamento de consultas, os recursos do mecanismo de banco de dados e assim por diante, funcionam como em qualquer outro banco de dados no Banco de Dados SQL do Azure.

A camada de serviço Hyperscale está disponível para bancos de dados únicos (provisionados e sem servidor) e para pools elásticos usando o modelo de compra baseado em vCore. Não está disponível no modelo de compra baseado em DTU.

Os níveis de serviço baseados em vCore são diferenciados com base na disponibilidade do banco de dados e no tipo de armazenamento, desempenho e tamanho máximo de armazenamento, conforme descrito em comparação de limite de recursos.

A camada de serviço Hyperscale destina-se a todos os clientes que procuram maior desempenho e disponibilidade, backup e restaurações rápidos, armazenamento rápido e escalabilidade de computação. Isso inclui clientes que estão começando pequenos e crescendo, aqueles que executam grandes bancos de dados de missão crítica, aqueles que estão migrando para a nuvem para modernizar seus aplicativos e clientes que já estão usando outras camadas de serviço no Banco de Dados SQL do Azure.

Com o Hyperscale, você obtém:

• Tamanho do banco de dados que pode crescer de 10 GB até 128 TB, independentemente do tamanho da computação.
• Calcule recursos vCore de 2 vCores até 128 vCores.
• 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 do log de transações, 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 descarregar cargas de trabalho somente leitura ou como bancos de dados em espera ativa.
• Escalonamento rápido da computação, em tempo constante, para ser mais poderoso para acomodar a carga de trabalho pesada e, em seguida, reduzir a escala, em 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.
• A opção de pagar pelo que você usa com computação sem servidor, onde a computação é cobrada com base no uso.

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.

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 em pool em um servidor.

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

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

• Escalar 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, aumentar e reduzir o dimensionamento não é uma operação de tamanho de dados.

  O suporte para de computação sem servidor fornece escalonamento e redução automáticos e faturamento de computação com base no uso.

• Escalonamento de entrada/saída

  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. Isto inclui:

  • Até quatro réplicas de alta disponibilidade ter 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 ter 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.

Sim, tu podes.

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. Quando seu aplicativo estiver usando o banco de dados Hyperscale, seu aplicativo poderá aproveitar recursos como réplicas secundárias.

Na réplica primária, o nível de isolamento de transação padrão é READ COMMITTED com a opção de banco de dados READ_COMMITTED_SNAPSHOT (RCSI) habilitada. Nas réplicas secundárias, o nível de isolamento é SNAPSHOT. Isso é o mesmo que em qualquer outro banco de dados SQL do Azure.

Com o novo preço simplificado em vigor desde 15 de dezembro de 2023, o preço da computação foi reduzido para bancos de dados Hyperscale recém-criados, todos os bancos de dados Hyperscale sem servidor e todos os pools elásticos Hyperscale. Com os novos preços simplificados, não há necessidade de aplicar o Benefício Híbrido do Azure (AHB) para obter economias equivalentes. O Benefício Híbrido do Azure (AHB) só pode ser aplicado a bancos de dados únicos de hiperescala mais antigos (criados antes de 15 de dezembro de 2023) com computação provisionada. Para essas bases de dados mais antigas, a AHB só é aplicável até dezembro de 2026, após o que essas bases de dados também serão faturadas de acordo com o novo preço simplificado.

Para obter mais informações, consulte blog de preços de hiperescala e Banco de Dados SQL do Azure Hyperscale - preços mais baixos e simplificados.

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).

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é 128 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), como o Azure Synapse Analytics, o Microsoft Fabric pode ser a melhor escolha.

A taxa de ingestão ou geração de logs de 150 MB/s está disponível como um recurso de visualização opcional. Para obter mais informações e optar por 150 MB/s, consulte Blog: Aprimoramentos de hiperescala de novembro de 2024.

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 sem servidor para dimensionar automaticamente a computação com base no uso.

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

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

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

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. Se a réplica de computação falhar ou estiver em manutenção, uma nova réplica será 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, em vez de segundos no caso em que uma réplica secundária HA está 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 em espera ativa esteja disponível para servir como destino de failover.

O tamanho máximo de um único banco de dados Hyperscale é atualmente de 128 TB, independentemente do tamanho da computação. O tamanho máximo de um banco de dados em um pool elástico de hiperescala é atualmente de 100 TB.

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 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 reduzida para cargas de trabalho contínuas de gravação agressiva. A taxa de geração de log sustentada de pico é de 100 MB/s.

A taxa de geração de logs de 150 MB/s está disponível como um recurso de visualização opcional. Para obter mais informações e optar por 150 MB/s, consulte Blog: Aprimoramentos de hiperescala de novembro de 2024.

Seu banco de dados tempdb 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 de tempdb para seu banco de dados, consulte Tamanhos de computação e armazenamento em hiperescala.

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

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

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

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.

Não. Os arquivos de dados são adicionados automaticamente ao grupo de arquivos PRIMARY. 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.

Não.

Sim, operações de redução de banco de dados e arquivo estão atualmente em visualização. Para obter mais informações sobre a visualização, consulte Shrink for Azure SQL Database Hyperscale.

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

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 estratégia de preenchimento proporcional para distribuir dados em arquivos de dados.

Sim. 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 é 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 o 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 é mais rápida se feita durante um período de baixa atividade de gravação. Conheça as limitações para a migração reversa.

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 é uma operação de tamanho 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 de para de migração reversa e as políticas de backup de afetadas.

Sim. Alguns recursos do Banco de Dados SQL do Azure não são suportados 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 pararão de funcionar após a migração. Para obter detalhes, consulte Limitações conhecidas.

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 odo Serviço de Migração de Banco de Dados do Azure, que oferece suporte a muitos cenários de migração.

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 de 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.

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, pela velocidade de leitura da origem, pelo tipo de carga (em massa versus linha por linha) e pelo objetivo de nível de serviço do banco de dados de destino. A taxa de geração de logs de 150 MB/s está disponível como um recurso de visualização opcional. Para obter mais informações e optar por 150 MB/s, consulte Blog: Aprimoramentos de hiperescala de novembro de 2024.

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 Azure Data Factoryou 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.

Modelos de recuperação simples ou registrados em massa não são suportados 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.

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

Sim. Serviço de Migração de Banco de Dados do Azure oferece suporte a muitos cenários de migração.

Consulte SLA do 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.

Sim.

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.

Sim. Para obter mais informações, consulte de pools elásticos de hiperescala e Blog: Os pools elásticos de hiperescala agora estão disponíveis para o público em geral.

Não há backups tradicionais completos, diferenciais e de log de transações para bancos 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 log de transações gerado é retido as-is para 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 a partir do point-in-time especificado dentro do período de retenção, sem qualquer perda de dados. Na verdade, o backup de banco de dados no Hyperscale é contínuo.

Sim.

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. Emitir uma restauração após uma alteração recente de de redundância de armazenamento pode resultar em tempos de restauração mais longos, porque a restauração pode ser uma operação de tamanho de dados nesse caso, e o tempo de restauração pode ser proporcional ao tamanho do banco de dados.

Não. 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.

Sim. A restauração geográfica é totalmente suportada se for usado armazenamento com redundância geográfica ou com redundância de zona geográfica. O armazenamento com redundância geográfica é 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 que está emparelhada com a região do banco de dados de origem.

Sim. de replicação geográfica e grupos de failover podem ser configurados para bancos de dados de hiperescala.

Não. 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, como Azure Data Factory, Azure Databricks, SSIS, etc.

Sim. A partir de 4 de maio de 2022, os backups para 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 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 de redundância de armazenamento e backups em hiperescala .

Para obter detalhes sobre como medir o tamanho do armazenamento de backup, consulte Automated Backups.

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 o Azure Monitor API REST. O faturamento de backup no de camada de computação sem servidor é o mesmo que na camada de computação provisionada.

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.

Para obter detalhes sobre como minimizar os custos de armazenamento de backup, consulte Automated Backups.

Atualmente, os backups que não são de hiperescala (Basic/Standard/Premium/General Purpose/Business Critical) não podem ser restaurados geograficamente em uma camada de serviço Hyperscale e vice-versa. Para converter um banco de dados não Hyperscale em um banco de dados Hyperscale, altere a camada de serviço após uma restauração.

O limite de taxa de transferência do log de transações é de 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. A taxa de geração de logs de 150 MB/s está disponível como um recurso de visualização opcional. Para obter mais informações e optar por 150 MB/s, consulte Blog: Aprimoramentos de hiperescala de novembro de 2024.

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 armazenamento SSD local na réplica de computação, você verá um desempenho de E/S semelhante ao das camadas de serviço Business Critical ou Premium.

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

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 é diretamente afetada pela adição de réplicas secundárias. No entanto, a taxa de log para cargas de trabalho de gravação contínuas e agressivas pode ser limitada no primário para permitir que o log seja aplicado em réplicas secundárias e servidores de página para recuperar o atraso. 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.

Sim. No entanto, assim como em outros bancos 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.

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

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. Consulte limites de recursos do Hyperscale sem servidor para obter detalhes.

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.

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

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.

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

Sim. O banco de dados tempdb e o cache SSD de computação tamanho nos nós de computação aumentam automaticamente à medida que o número de núcleos é aumentado. Para obter detalhes, consulte Tamanhos de computação e armazenamento em hiperescala.

Não. 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.

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

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

Você pode se conectar a essas réplicas de computação somente leitura adicionais definindo a propriedade ApplicationIntent 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.

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 banco de dados master.

Não. 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.

Não. Uma nova conexão com intenção somente leitura é redirecionada para uma réplica secundária de HA arbitrá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 fornecer a capacidade de dimensionar cada réplica nomeada independentemente.

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

Não. As réplicas de computação de banco de dados de hiperescala compartilham armazenamento, 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 no banco de dados tempdb. As tabelas temporárias são leitura-gravação.

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. Em um determinado momento, a latência dos 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.

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 a réplica primária para essa finalidade.

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 .

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. No entanto, se você criou uma réplica geográfica para a réplica primária em uma região diferente, poderá criar réplicas nomeadas para a réplica geográfica.

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 que reduza sua taxa de 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 primário. 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, recomenda-se ter réplicas nomeadas com pelo menos o mesmo tamanho de computação que o primário para evitar saturar a CPU nas réplicas e forçar o primário a ficar mais lento.

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

Por padrão, as réplicas nomeadas não têm réplicas de 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. Você pode adicionar réplicas HA para uma réplica nomeada no portal do Azure ou usando o parâmetro ha-replicas com AZ CLI, ou o parâmetro HighAvailabilityReplicaCount com PowerShellou a propriedade highAvailabilityReplicaCount com API REST. O número de réplicas HA pode ser definido durante a criação de uma réplica nomeada e pode ser alterado a qualquer momento após a criação da réplica nomeada. O preço das réplicas de HA para réplicas nomeadas é o mesmo das réplicas de HA para réplicas primárias.

Sim. O de Chave Mestra de Coluna é armazenado no banco de dados do usuário e pode ser validado executando a consulta . Réplicas nomeadas e réplicas secundárias de alta disponibilidade leem dados dos mesmos servidores de página/camada de armazenamento que o banco de dados Hyperscale primário. Ambos os tipos de réplicas são sincronizados com o banco de dados Hyperscale primário por meio do serviço de log. Uma alteração de chave é considerada uma transação e é replicada automaticamente para todas as réplicas secundárias.

Não quando você consulta sys.dm_database_replica_states na réplica primária. No entanto, você pode se conectar a uma réplica nomeada para determinar sua ID de réplica e outros detalhes usando a seguinte consulta de exemplo:

  SELECT replica_id,
         DB_NAME() AS named_replica_database_name,
         synchronization_state_desc,
         log_send_queue_size / 1024.0 / 1024.0 AS log_send_queue_size_gb,
         last_sent_time,
         last_received_time,
         last_commit_time,
         redo_queue_size / 1024.0 / 1024.0 AS redo_queue_size_gb,
         redo_rate,
         secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE is_local = 1
        AND
        replica_id = DATABASEPROPERTYEX(DB_NAME(), 'ReplicaID');

Conteúdo relacionado

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