Perguntas Frequentes sobre a Hiperescala do Banco de Dados SQL do Azure

Um banco de dados de hiperescala é um banco de dados no Banco de Dados SQL do Azure que é apoiado pela tecnologia de armazenamento de expansão hiperescala. Um banco de dados de Hiperescala dá suporte a até 128 TB de dados e oferece alta taxa de transferência e desempenho, bem como escala rápida para se adaptar aos requisitos de carga de trabalho. Conectividade, processamento de consultas, 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 hiperescala está disponível para bancos de dados individuais (provisionados e sem servidor) e para pools elásticos usando o modelo de compra baseado em vCore. Ele não está disponível no modelo de compra baseado em DTU.

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

A camada de serviço de Hiperescala é para todos os clientes que buscam maior desempenho e disponibilidade, backup e restauração rápidos, armazenamento rápido e escalabilidade de computação. Isso inclui os clientes que estão começando pequeno e crescendo, os que estão executando bancos de dados críticos para a missão, os que estão migrando para a nuvem para modernizar seus aplicativos e os que já estão usando outras camadas de serviço no Banco de Dados SQL do Azure.

Com em Hiperescala, você obtém:

• Tamanho do banco de dados que pode crescer de 10 GB até 128 TB, independentemente do tamanho da computação.
• Compute 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 do banco de dados, independentemente do tamanho do banco de dados (as restaurações são feitas a partir de instantâneos 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 descarregamento de leitura ou como bancos de dados em espera ativa.
• Escala vertical rápida de computação, de forma constante, para conseguir acomodar a carga de trabalho pesada e depois reduzir verticalmente, de forma constante. As operações de escala levam minutos de um só 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, em que a computação é cobrada de acordo com o uso.

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

Sim. Para obter mais informações e ver os limites do número de bancos de dados por servidor, confira Limites de recursos do Banco de Dados SQL para bancos de dados individuais e em pool em um servidor.

A arquitetura da Hiperescala oferece alto desempenho e taxa de transferência, dando suporte a grandes banco de dados.

A Hiperescala fornece escalabilidade rápida com base na demanda de carga de trabalho.

• Dimensionamento para cima/para baixo

  A Hiperescala permite escalar verticalmente o tamanho da computação primária em termos de recursos como CPU e memória e, em seguida, reduzir verticalmente em tempo constante. Como o armazenamento é remoto, escalar verticalmente e reduzir verticalmente não é uma operação de tamanho de dados.

  O suporte para de computação sem servidor fornece escala vertical e horizontal automática e cobrança de computação com base no uso.

• Dimensionamento In/Out

  Com a hiperescala, 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. Isso inclui:

  • Até quatro réplicas de alta disponibilidade com o mesmo tamanho da computação que as réplicas primárias. Elas servem como réplicas em espera ativa para fazer failover rapidamente da réplica primária. Você também pode usá-las para descarregar cargas de trabalho de leitura da réplica primária.
  • Até 30 réplicas nomeadas tendo um tamanho da computação igual ou diferente da réplica primária, para atender a diversos 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 habilitar a expansão de leitura geográfica.

Sim, você pode.

Não, seu modelo de programação de aplicativo permanece igual em qualquer outro banco de dados MSSQL. Você usa a cadeia de conexão como de costume e os outros modos regulares para interagir com o banco de dados da Hiperescala. Depois de usar o banco de dados de Hiperescala, seu aplicativo pode aproveitar recursos como réplicas secundárias.

Na réplica primária, o nível de isolamento da 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 ocorre 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 de Hiperescala recém-criados, para todos os bancos de dados de Hiperescala sem servidor e para todos os pools elásticos de Hiperescala. Com o novo preço simplificado, não há necessidade de aplicar o AHB (Benefício Híbrido do Azure) para obter economias equivalentes. O Benefício Híbrido do Azure (AHB) só pode ser aplicado a bancos de dados individuais de Hiperescala mais antigos (criados antes de 15 de dezembro de 2023) com computação provisionada. Para esses bancos de dados mais antigos, o AHB só é aplicável até dezembro de 2026, após o qual esses bancos de dados também serão cobrados conforme o novo preço simplificado.

Para obter mais informações, consulte blog de preços da Hiperescala e Hiperescala do Banco de Dados SQL do Azure – preços mais baixos e simplificados.

A Hiperescala funciona bem com 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 analíticas no momento usando o SQL Server como um data warehouse, a Hiperescala é uma ótima opção, pois é possível hospedar data warehouses pequenos e médios (como de alguns TB até 128 TB) a um custo menor e você pode migrar cargas de trabalho do data warehouse do SQL Server para a Hiperescala com alterações mínimas no código T-SQL.

Se você estiver executando a análise de dados em grande escala com consultas complexas e taxas de ingestão sustentadas maiores que 100 MB/s ou usando o PDW (Data Warehouse Paralelo), Teradata ou outros data warehouses de MPP (Processamento Paralelo Massivo) como o Azure Synapse Analytics, o Microsoft Fabric pode ser a melhor opção.

A taxa de ingestão ou geração de logs de 150 MB/s está disponível como uma versão prévia do recurso opcional. Para obter mais informações e optar por 150 MB/s, veja Blog: Melhorias em Hiperescala de novembro de 2024.

Não no momento. No entanto, é possível reduzir a escala de sua computação e o número de réplicas para diminuir o custo fora dos horários de pico, ou usar a tecnologia sem servidor para dimensionar automaticamente a computação com base no uso.

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

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

Você pode escalar 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. Cada réplica nomeada pode ter até 4 réplicas secundárias de HA.

Nos bancos de dados da Hiperescala, a resiliência de dados é fornecida no nível de armazenamento. Você só precisa de uma réplica (a primária) 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, poderá levar um minuto ou dois para criar uma nova réplica, versus segundos no caso em que uma réplica secundária de HA está disponível. Inicialmente, a nova réplica terá caches frios, o que pode resultar em maior latência de armazenamento e desempenho de consulta reduzido imediatamente após o failover.

Para aplicativos críticos 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 um destino de failover.

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

Em Hiperescala, 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 aumentar devido a transações com execução prolongada ou se o processamento da Captura de dados de alterações não conseguir acompanhar a taxa de alteração de dados. Evite transações desnecessariamente muito longas e grandes para você 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 com alta taxa de transferência de log. No entanto, a taxa de geração de log pode ser reduzida para cargas de trabalho de gravação contínua agressiva. A taxa de pico da geração de log sustentada é de 100 MB/s.

A taxa de geração de logs de 150 MB/s está disponível como uma versão prévia do recurso opcional. Para obter mais informações e optar por 150 MB/s, veja Blog: Melhorias em Hiperescala de novembro de 2024.

O banco de dados tempdb está localizado no armazenamento SSD local e é dimensionado proporcionalmente ao tamanho da computação (o número de núcleos) provisionada. O tamanho de tempdb não é configurável, sendo gerenciado para você. Para determinar o tamanho máximo de tempdb do banco de dados, confira Armazenamento da hiperescala e tamanhos da computação.

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

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

Cada arquivo de dados aumenta em 10 GB. É possível ter vários arquivos de dados aumentando ao mesmo tempo.

Na Hiperescala, 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 com réplicas de computação remotas. 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 nos servidores de página remotos.

Não. Os arquivos de dados são adicionados automaticamente ao grupo de arquivos PRIMARY. Os motivos comuns para a criação de grupos de arquivos adicionais não se aplicam à arquitetura de armazenamento de Hiperescala nem ao Banco de Dados SQL do Azure mais amplamente.

Não.

Sim, as operações de redução de banco de dados e arquivo estão atualmente em versão prévia. Para obter mais informações sobre a visualização, consulte Reduzir para o banco de dados SQL do Azure em hiperescala.

Sim, assim como em qualquer outro banco de dados SQL do Azure. Isso incluide compactaçã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 do MSSQL usa a estratégia de preenchimento proporcional para distribuir dados nos arquivos de dados.

Sim. Para POCs (provas de conceito), é recomendável fazer uma cópia do banco de dados e migrar a cópia para a Hiperescala.

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

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

A migração reversa para a camada de serviço de Uso 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 de Hiperescala retornem caso a Hiperescala não atenda às necessidades deles. Embora a migração reversa seja iniciada por uma alteração da camada de serviço, é essencialmente uma operação de dimensionamento dos dados entre arquiteturas diferentes. Da mesma forma que a migração para a Hiperescala, a migração reversa será mais rápida se realizada durante um período de baixa atividade de gravação. Conheça as limitações para migração reversa.

Se você já migrou um Banco de Dados SQL do Azure existente para a camada de serviço de Hiperescala, é possível reverter a migração para a camada de serviço de Uso Geral até 45 dias após a migração original para a Hiperescala. Se você quiser migrar o banco de dados para outra camada de serviço, como Comercialmente Crítico, 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 de Hiperescala não podem ser movidos para outras camadas de serviço.

Saiba como fazer a migração reversa da Hiperescala, incluindo as limitações da migração reversa e as políticas de backup.

Sim. Não há suporte para alguns recursos do Banco de Dados SQL do Azure na Hiperescala. Se alguns desses recursos estiverem habilitados para seu banco de dados, a migração para a Hiperescala poderá ser bloqueada ou esses recursos deixarão de funcionar após a migração. Para obter detalhes, confira Limitações conhecidas.

Sim. Você pode usar muitas tecnologias de migração existentes para migrar para a Hiperescala, incluindo a replicação transacional e todas as outras tecnologias de movimentação de dados (cópia em massa, Azure Data Factory, Azure Databricks, SSIS). Confira também o Serviço de Migração de Banco de Dados do Azure, que dá suporte a vários cenários de migração.

O tempo de inatividade da migração para a Hiperescala é igual ao tempo de inatividade da migração dos 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 a migração do tempo de inatividade para bancos de dados com poucos TB de tamanho. Para bancos de dados muito grandes (mais de 10 TB), considere implementar o processo de migração usando ADF, Spark ou outras tecnologias de movimentação de dados em massa.

A hiperescala é 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, o tipo de carga (em massa versus linha por linha) e o 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 uma versão prévia do recurso opcional. Para obter mais informações e optar por 150 MB/s, veja Blog: Melhorias em Hiperescala de novembro de 2024.

Você pode fazer com que um aplicativo cliente leia os dados do Armazenamento do Azure e carregue a carga de dados em um banco de dados da Hiperescala (assim como você pode fazer com qualquer outro banco de dado no Banco de Dados SQL do Azure). No momento, o Polybase não é compatível com o Banco de Dados SQL do Azure. Como alternativa para fornecer carga rápida, você pode usar o Azure data Factory ou um trabalho do Spark no Azure Databricks com o conector do Spark para SQL. O conector do Spark SQL dá suporte à inserção em massa.

Também é possível ler em massa os dados do Armazenamento de Blobs do Azure usando BULK INSERT ou OPENROWSET: exemplos de acesso em massa aos dados no Armazenamento de Blobs do Azure.

Modelos de recuperação simples ou em massa registrados em massa não têm suporte na Hiperescala. O modelo de recuperação completa é necessário para fornecer alta disponibilidade e recuperação pontual. No entanto, a arquitetura de log da Hiperescala fornece uma melhor taxa de ingestão de dados em comparação a outras camadas de serviço do Banco de Dados SQL do Azure.

Não. A Hiperescala é uma arquitetura de SMP (multiprocessamento simétrico) e não de MPP (processamento paralelo massivo) ou uma arquitetura de vários mestres. Você pode criar várias réplicas para escalar horizontalmente cargas de trabalho somente leitura.

Sim. O Serviço de Migração de Banco de Dados do Azure dá suporte a vários cenários de migração.

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

Sim.

Sim, a Hiperescala dá suporte à configuração com redundância de zona. É necessário pelo menos uma réplica secundária de HA e o uso de armazenamento com redundância de zona ou do armazenamento com redundância de zona geográfica para habilitar a configuração redundante de zona para Hiperescala.

Sim. Para obter mais informações, consulte Pools elásticos de Hiperescala e Blog: Pools Elásticos de Hiperescala agora estão em disponibilidade geral.

Não há backups tradicionais completos, diferenciais e de log de transações para bancos de dados da Hiperescala. 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 é mantido no estado em que se encontram no período de retenção configurado. No momento da restauração, os registros de log de transações relevantes são aplicados aos instantâneos de armazenamento restaurados. Independentemente da cadência do instantâneo, isso resulta em um banco de dados transacionalmente consistente a partir do ponto especificado no tempo dentro do período de retenção, sem nenhuma perda de dados. Na verdade, o backup de banco de dados na Hiperescala é contínuo.

Sim.

O RPO para restauração pontual é de 0 min. A maioria das operações de restauração pontual é concluída em 60 minutos, independentemente do tamanho do banco de dados. O tempo de restauração pode ser mais longo para bancos de dados maiores e se o banco de dados enfrentar níveis significativos de atividade de gravação antes e até o ponto de restauração no tempo. Emitir uma restauração após uma alteração recente 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 instantâneos de armazenamento. Eles não afetam as cargas de trabalho do usuário.

Sim. A restauração geográfica terá suporte total se o armazenamento com redundância geográfica ou com redundância de zona geográfica for usado. O armazenamento com redundância geográfica é o padrão para novos bancos de dados. Diferentemente da restauração pontual, a restauração geográfica requer uma operação do tamanho dos dados. Os arquivos de dados são copiados paralelamente, de modo que 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.

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 dos bancos de dados da Hiperescala é diferente de qualquer versão de lançamento do SQL Server e você não controla os backups nem tem acesso a eles. Para tirar seus dados de um banco de dados de Hiperescala, você pode extrair dados usando tecnologias de movimentação de dados, como Azure Data Factory, Azure Databricks, SSIS etc.

Sim. A partir de 4 de maio de 2022, os backups de todos os novos bancos de dados serão cobrados com base no armazenamento de backup consumido e na redundância de armazenamento selecionada, de acordo com as taxas capturadas na página de preços do Banco de Dados SQL do Azure. Para bancos de dados em Hiperescala criados antes de 4 de maio de 2022, só haverá cobrança de backups se a retenção de backup estiver definida para ser superior a 7 dias. Para saber mais, confira Backups e redundância de armazenamento de Hiperescala.

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

Para determinar sua 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 em um período de tempo, multiplique o tamanho do armazenamento de backup faturável em cada hora do período pela taxa de armazenamento de backup e adicione todos os valores por hora. Para consultar as métricas relevantes do Azure Monitor de vários intervalos por hora de modo programático, use a API REST do Azure Monitor. A cobrança de backup na camada de computação sem servidor é a mesma da camada de computação provisionada.

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

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

Atualmente, as camadas de serviço não hiperescala (Basic/Standard/Premium/General Purpose/Business Critical) não podem ser restauradas geograficamente em uma camada de serviço de Hiperescala e vice-versa. Para converter um banco de dados sem hiperescala em um banco de dados com hiperescala, 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 de Hiperescala. 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 uma capacidade de computação suficiente na réplica de computação primária para produzir o log de registro a essa taxa. A taxa de geração de logs de 150 MB/s está disponível como uma versão prévia do recurso opcional. Para obter mais informações e optar por 150 MB/s, veja Blog: Melhorias em Hiperescala de novembro de 2024.

O IOPS e a latência de E/S variam dependendo dos padrões de carga de trabalho. Se os dados acessados forem 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 ComercialMente Crítico ou Premium.

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

Como o armazenamento é compartilhado e não há nenhuma 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 se aplique a réplicas secundárias e servidores de página para atualizar. Isso evita que haja um desempenho de leitura ruim em réplicas secundárias e uma recuperação longa após o failover para uma réplica secundária de 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 anular consultas de execução longa 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 dos 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 de armazenamento, são aplicadas etapas comuns de diagnóstico e solução de problemas do MSSQL. Para diagnósticos de armazenamento específicos da Hiperescala, confira Diagnóstico de solução de problemas de desempenho da Hiperescala do SQL.

O valor máximo de memória que um banco de dados sem servidor pode escalar verticalmente é 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. Confira Limites de recursos da Hiperescala sem servidor para saber mais.

A expansão ou redução vertical na camada de computação provisionada geralmente demora até dois minutos, independentemente do tamanho dos dados. Na camada de computação sem servidor, na qual a computação é dimensionada automaticamente com base na demanda da carga de trabalho, normalmente o tempo de dimensionamento é inferior a um segundo. Ocasionalmente, pode demorar tanto quanto o dimensionamento na computação provisionada.

Não. Um banco de dados permanece online durante operações de aumento ou redução.

A expansão ou redução da computação provisionada resulta na remoção de conexões em caso de um failover no final da operação de dimensionamento. Na computação sem servidor, a escala automática normalmente não resulta na remoção de uma conexão, mas isso pode ocorrer ocasionalmente. A adição ou remoção de réplicas secundárias não resulta em quedas de conexão na primária.

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

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

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

A Hiperescala dá suporte para réplicas de HA (alta disponibilidade), réplicas nomeadas e réplicas geográficas. Confira mais detalhes em Réplicas secundárias da Hiperescala.

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

Você pode se conectar a essas réplicas de computação adicionais somente leitura configurando a propriedade ApplicationIntent na cadeia de conexão como ReadOnly. Todas as conexões marcadas com ReadOnly são roteadas automaticamente para uma das réplicas secundárias de HA, se houver. Para obter detalhes, confira 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 será 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 precisa ser definido como o nome do seu banco de dados, não como 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 a intenção somente leitura é redirecionada para uma réplica secundária de HA arbitrária.

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

Não. O banco de dados tempdb é configurado com base no tamanho da computação provisionada. As réplicas secundárias de HA são do mesmo tamanho que a computação primária, incluindo tempdb. Em réplicas nomeadas, tempdb é dimensionado de acordo com o tamanho da computação da réplica, portanto, ela pode ser menor ou maior do que tempdb na primária.

Não. As réplicas de computação de bancos 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 você quiser índices adicionais otimizados para leituras nas secundárias, deve adicioná-los na primária. 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 de leitura-gravação.

A latência de dados do momento em que uma transação é confirmada na primária até o momento em que pode ser lida em uma secundária 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 normal para transações pequenas ocorre em dezenas de milissegundos, no entanto, não há limite superior na latência de dados. Os dados de uma determinada réplica secundária têm sempre consistência transacional, portanto, transações maiores levam mais tempo para serem propagadas. 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.

Não, as réplicas nomeadas não podem ser usadas como destinos de failover para a réplica primária. Adicione réplicas de HA para a réplica primrary 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 forma interna de direcionar o tráfego somente leitura enviado às réplicas primárias 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 somente para réplicas nomeadas de 1 a 4, enquanto as cargas de trabalho analíticas do Power BI usam as réplicas nomeadas 5 e 6 e a carga de trabalho de ciência de dados usa as réplicas 7 e 8. Dependendo de qual ferramenta ou linguagem de programação você usa, as estratégias para distribuir tal carga de trabalho podem variar. Para ver um exemplo de criação de uma solução de roteamento de carga de trabalho para permitir que um back-end REST seja escalado horizontalmente, confira a amostra de expansão de OLTP.

Não, como as réplicas nomeadas usam os mesmos servidores de página da réplica primária, elas precisam 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 as réplicas nomeadas, sob circunstâncias normais, afetem o desempenho das principais, mas isso poderá acontecer se houver cargas de trabalho intensivas em execução. Assim como uma réplica de HA, uma réplica nomeada é mantida em sincronia com a primária 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 solicitar à réplica primária para reduzir sua taxa de geração de log, para que ela possa se atualizar. Embora esse comportamento não afete a disponibilidade do primário, ele pode afetar o desempenho das 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 de cabeçalho de recurso suficiente - 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 tamanho de computação que o primário para evitar saturar a CPU nas réplicas e forçar o primário a diminuir a velocidade.

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 possuem suas próprias réplicas de alta disponibilidade. Um failover de uma réplica nomeada requer primeiro a criação de uma nova réplica, o que normalmente leva cerca de 1 a 2 minutos. No entanto, as réplicas nomeadas também podem tirar proveito da maior disponibilidade e dos failovers mais curtos fornecidos pelas réplicas de alta disponibilidade. Você pode adicionar réplicas de HA para uma réplica nomeada no portal do Azure ou usando o parâmetro ha-replicas com da CLI do AZ ou o parâmetro HighAvailabilityReplicaCount com do PowerShell ou a propriedade highAvailabilityReplicaCount com a API REST. O número de réplicas de 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. A Chave Mestra da Coluna é armazenada no banco de dados de usuário e pode ser validada executando a consulta SELECT * FROM sys.column_master_keys. As réplicas nomeadas e as réplicas secundárias de alta disponibilidade leem dados da mesma camada de armazenamento/servidores de página que o banco de dados de Hiperescala primário. Ambos os tipos de réplicas são sincronizados com o banco de dados de Hiperescala 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 da Hiperescala, confira Camada de serviço da Hiperescala.