Compartilhar via

Confiabilidade na Instância Gerenciada de SQL do Azure

A Instância Gerenciada de SQL do Azure é um mecanismo de banco de dados PaaS (plataforma como serviço) totalmente gerenciada. Ele fornece quase 100% compatibilidade de recursos com o SQL Server. A Instância Gerenciada de SQL do Azure manipula a maioria das funções de gerenciamento de banco de dados, como atualização, aplicação de patch, backups e monitoramento sem envolvimento do usuário. Ele é executado na versão estável mais recente do mecanismo de banco de dados do SQL Server e em um sistema operacional corrigido com alta disponibilidade interna.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar a Instância Gerenciada de SQL do Azure resiliente a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade e interrupções de região. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas, como lidar com a manutenção do serviço e realça algumas informações importantes sobre o SLA (contrato de nível de serviço) da Instância Gerenciada de SQL do Azure.

Recomendações de implantação de produção para confiabilidade

Para a maioria das implantações de produção da Instância Gerenciada de SQL, considere as seguintes recomendações:

Visão geral da arquitetura de confiabilidade

As instâncias gerenciadas de SQL de Uso Geral são executadas em um único nó gerenciado pelo Azure Service Fabric . Sempre que o mecanismo de banco de dados ou o sistema operacional é atualizado ou uma falha é detectada, a Instância Gerenciada de SQL funciona com o Service Fabric para mover o processo do mecanismo de banco de dados sem estado para outro nó de computação sem estado que tenha capacidade livre suficiente. Os arquivos de banco de dados são armazenados no Armazenamento de Blobs do Azure, que tem recursos de redundância internos. Os arquivos de dados e de log são desanexados do nó de computação original e anexados ao processo do mecanismo de banco de dados recém-inicializado.

As instâncias gerenciadas de SQL Comercialmente Críticas usam várias réplicas em um cluster. O cluster inclui dois tipos de réplicas:

  • Uma réplica primária individual que pode ser acessada para cargas de trabalho de cliente de leitura/gravação

  • Até cinco réplicas secundárias (computação e armazenamento) que contêm cópias de dados

A réplica primária envia alterações contínua e sequencialmente para as réplicas secundárias, que garantem que os dados sejam persistidos em um número suficiente de réplicas secundárias antes de confirmar cada transação. Esse processo garante que, se a réplica primária ou uma réplica secundária para leitura ficar indisponível, uma réplica totalmente sincronizada estará sempre disponível para failover.

A Instância Gerenciada de SQL e o Service Fabric iniciam o failover entre réplicas. Depois que uma réplica secundária se torna a nova réplica primária, outra réplica secundária é criada para garantir que o cluster tenha um número suficiente de réplicas para manter o quorum. Após a conclusão do failover, as conexões SQL do Azure são redirecionadas automaticamente para a nova réplica primária ou para a réplica secundária legível, com base na cadeia de conexão.

Redundancy

Por padrão, a Instância Gerenciada de SQL obtém redundância espalhando nós de computação e dados em um único datacenter na região primária. Essa abordagem protege seus dados durante os seguintes tempos de inatividade esperados e inesperados:

  • Operações de gerenciamento iniciadas pelo cliente que resultam em um breve tempo de inatividade

  • Operações de manutenção de serviços

  • Falhas de rede ou energia em pequena escala

  • Problemas e interrupções de datacenter que envolvem os seguintes componentes:

    • O rack onde as máquinas que alimentam seu serviço estão operando

    • A máquina física que hospeda a VM (máquina virtual) que executa o Mecanismo de Banco de Dados SQL.

    • A VM que executa o Mecanismo de Banco de Dados SQL

  • Problemas com o Mecanismo de Banco de Dados SQL

  • Possíveis interrupções localizadas não planejadas

Para obter mais informações sobre como a Instância Gerenciada de SQL fornece redundância, consulte Disponibilidade por meio da redundância local e de zona.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

A Instância Gerenciada de SQL lida automaticamente com tarefas de manutenção críticas, como aplicação de patch, backups e atualizações do Mecanismo de Banco de Dados SQL e Windows. Ele também lida com eventos não planejados, como hardware subjacente, software ou falhas de rede. A Instância Gerenciada de SQL pode se recuperar rapidamente mesmo nas circunstâncias mais críticas, o que garante que seus dados estejam sempre disponíveis. A maioria dos usuários não percebe que as atualizações são executadas continuamente.

Ao aplicar patch ou fazer failover de uma instância, o tempo de inatividade terá efeito mínimo se você empregar a lógica de repetição no aplicativo. Você pode testar a resiliência do aplicativo para falhas transitórias.

Resiliência a falhas de zona de disponibilidade

Observação

No momento, a redundância de zona não está disponível para a camada de serviço Uso Geral de próxima geração.

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Ao habilitar uma configuração com redundância de zona, você pode garantir que a sua instância gerenciada de SQL seja resiliente a um grande conjunto de falhas, incluindo interrupções catastróficas do datacenter, sem alterações na lógica do aplicativo.

A Instância Gerenciada de SQL obtém redundância de zona colocando nós de computação sem estado em zonas de disponibilidade diferentes. Ela depende do ZRS com estado que é anexado a qualquer nó que atualmente contenha o processo ativo do Mecanismo de Banco de Dados SQL. Se ocorrer uma falha, o processo do Mecanismo de Banco de Dados SQL ficará ativo em um dos nós de computação sem estado, que então acessa os dados no armazenamento com estado.

A Instância Gerenciada de SQL obtém redundância de zona colocando réplicas da instância gerenciada de SQL em várias zonas de disponibilidade. Para eliminar um ponto único de falha, o anel de controle também é duplicado entre várias zonas. O tráfego do painel de controle é roteado para um balanceador de carga que também é implantado nas zonas de disponibilidade. O Gerenciador de Tráfego do Azure controla o roteamento de tráfego do plano de controle para o balanceador de carga.

Requirements

  • Suporte à região: Há suporte para redundância de zona para a Instância Gerenciada de SQL em regiões selecionadas. Para obter mais informações, confira Regiões com suporte.

  • Redundância de armazenamento de backup: Para habilitar a redundância de zona para sua instância gerenciada de SQL, defina a redundância de armazenamento de backup como ZRS ou GZRS ( armazenamento com redundância de zona geográfica).

Custo

Quando você habilita a redundância de zona, há um custo extra para sua instância gerenciada de SQL e para backups com redundância de zona. Para saber mais, consulte Preços.

Você pode economizar dinheiro comprometendo-se a usar recursos de computação a uma taxa com desconto por um período, o que inclui instâncias com redundância de zona na camada de serviço Comercialmente Crítico. Para obter mais informações, consulte Reservas para a Instância Gerenciada de SQL.

Configurar o suporte à zona de disponibilidade

Esta seção explica como configurar o suporte à zona de disponibilidade para suas instâncias gerenciadas de SQL:

  • Habilitar redundância de zona: Para saber como configurar a redundância de zona em instâncias novas e existentes, consulte Configurar redundância de zona.

    Todas as operações de dimensionamento para a Instância Gerenciada de SQL, incluindo a habilitação da redundância de zona, são operações online e exigem um tempo de inatividade mínimo ou nenhum. Para obter mais informações, consulte Duração das operações de gerenciamento.

  • Desabilitar a redundância de zona: você pode desabilitar a redundância de zona seguindo as mesmas etapas para habilitar a redundância de zona. Esse processo é uma operação online semelhante a uma atualização do objetivo da camada de serviço normal. No final do processo, a instância é migrada da infraestrutura com redundância de zona para a infraestrutura de zona única.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando sua instância gerenciada de SQL está configurada como com redundância de zona e todas as zonas de disponibilidade estão operacionais:

  • Roteamento de tráfego entre zonas: durante operações normais, as solicitações são roteadas para o nó que executa sua camada de computação da Instância Gerenciada de SQL.

  • Replicação de dados entre zonas: Os arquivos de banco de dados são armazenados no Armazenamento do Azure usando o ZRS, que está anexado a qualquer nó que contenha atualmente o processo ativo do Mecanismo de Banco de Dados SQL.

    As operações de gravação são síncronas e não são consideradas concluídas até que os dados sejam replicados com êxito em todas as zonas de disponibilidade. Essa replicação síncrona garante consistência forte e perda de dados zero durante falhas de zona. No entanto, isso pode resultar em latência de gravação ligeiramente maior em comparação com o armazenamento com redundância local.

  • Roteamento de tráfego entre zonas: durante operações normais, as solicitações são roteadas para a réplica primária da Instância Gerenciada de SQL.

  • Replicação de dados entre zonas: a réplica primária envia alterações contínua e sequencialmente para as réplicas secundárias em diferentes zonas de disponibilidade. Esse processo garante que os dados sejam mantidos em um número suficiente de réplicas secundárias antes de confirmar cada transação. Essas réplicas estão localizadas em diferentes zonas de disponibilidade. Esse processo garante que, se a réplica primária ou uma réplica secundária para leitura ficar indisponível por qualquer motivo, uma réplica totalmente sincronizada estará sempre disponível para failover.

    Como as instâncias com redundância de zona têm réplicas em datacenters diferentes com alguma distância entre elas, o aumento da latência de rede pode aumentar o tempo de confirmação da transação. Esse aumento pode afetar o desempenho de algumas cargas de trabalho OLTP (Processamento de Transações Online). A maioria dos aplicativos não é sensível a essa latência extra.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando sua instância gerenciada de SQL está configurada como com redundância de zona e uma ou mais zonas de disponibilidade não estão disponíveis:

  • Detecção e resposta: A Instância Gerenciada de SQL é responsável por detectar e responder a uma falha em uma zona de disponibilidade. Você não precisa fazer nada para iniciar um failover de zona.
  • Solicitações ativas: quando uma zona de disponibilidade não está disponível, todas as solicitações que estão sendo processadas na zona de disponibilidade com falha são encerradas e precisam ser repetidas. Para tornar seus aplicativos resilientes a esses tipos de problemas, consulte As diretrizes de resiliência a falhas transitórias .

  • Redirecionamento de tráfego: A Instância Gerenciada de SQL funciona com o Service Fabric para mover o mecanismo de banco de dados para um nó de computação sem estado adequado que esteja em uma zona de disponibilidade diferente e tenha capacidade livre suficiente. Após a conclusão do failover, as novas conexões serão redirecionadas automaticamente para o novo nó de computação primário.

    Uma carga de trabalho pesada pode enfrentar alguma degradação de desempenho durante a transição de um nó de computação para o outro nó de computação porque o novo processo do mecanismo de banco de dados começa com um cache frio.

  • Redirecionamento de tráfego: A Instância Gerenciada de SQL funciona com o Service Fabric para selecionar uma réplica adequada em outra zona de disponibilidade para se tornar a réplica primária. Depois que uma réplica secundária se torna a nova réplica primária, outra réplica secundária é criada para garantir que o cluster tenha um número suficiente de réplicas para manter o quorum. Após a conclusão do failover, novas conexões são redirecionadas automaticamente para a nova réplica primária ou para a réplica secundária legível, com base na cadeia de conexão.

  • Tempo de inatividade esperado: pode haver um pequeno tempo de inatividade durante um failover de zona de disponibilidade. O tempo de inatividade normalmente é inferior a 30 segundos, o que seu aplicativo deve tolerar se seguir as diretrizes de Resiliência a falhas transitórias .

  • Perda de dados esperada: não há nenhuma perda de dados esperada para transações confirmadas durante um failover de zona de disponibilidade. As transações em andamento precisam ser tentadas novamente.

Recuperação de zona

Quando a zona de disponibilidade é recuperada, a Instância Gerenciada de SQL funciona com o Service Fabric para restaurar operações na zona recuperada. Nenhuma intervenção do cliente é necessária.

Testar falhas em zonas

A plataforma SQL Managed Instance gerencia o roteamento de tráfego, o failover e o failback para instâncias redundantes a nível de zona. Como esse recurso é totalmente gerenciado, você não precisa iniciar nem validar processos de falha da zona de disponibilidade. No entanto, você pode validar o tratamento de falhas do aplicativo.

Resiliência a falhas em toda a região

Uma Instância Gerenciada de SQL individual é implantada em uma única região. No entanto, você pode implantar uma instância gerenciada de SQL secundária em uma região separada do Azure e configurar um grupo de failover.

Grupos de failover

Os grupos de failover replicam automaticamente os dados e podem fazer failover automaticamente ou manualmente se ocorrer uma falha regional, com base na política de failover.

Esta seção resume as principais informações sobre grupos de failover, mas é importante examinar a visão geral e as práticas recomendadas dos grupos de failover para saber mais sobre como eles funcionam e como configurá-los.

Política de failover

Ao criar um grupo de failover, você seleciona a política de failover, que especifica quem é responsável por detectar uma interrupção e executar um failover. Você pode configurar dois tipos de políticas de failover:

  • Failover gerenciado pelo cliente (recomendado): Ao usar uma política de failover gerenciada pelo cliente, você pode decidir se deseja executar um failover, que não incorre em perda de dados ou um failover forçado, o que pode incorrer em perda de dados. O failover forçado é usado como um método de recuperação durante interrupções quando a instância primária não pode ser acessada.

  • Failover gerenciado pela Microsoft: O failover gerenciado pela Microsoft só é usado em situações excepcionais para disparar um failover forçado.

Importante

Use as opções de failover gerenciadas pelo cliente para desenvolver, testar e implementar seus planos de recuperação de desastre. Não confie no failover gerenciado pela Microsoft, que só pode ser usado em circunstâncias extremas. Um failover gerenciado pela Microsoft provavelmente é iniciado para uma região inteira. Ele não pode ser iniciado para grupos de failover individuais, instâncias gerenciadas de SQL, assinaturas ou clientes. O failover pode ocorrer em horários diferentes para diferentes serviços do Azure. É recomendável usar o failover gerenciado pelo cliente.

Suporte de regiões

Você pode selecionar qualquer região do Azure para as instâncias gerenciadas de SQL no grupo de failover. Devido à alta latência de redes de ampla área, a replicação geográfica usa um mecanismo de replicação assíncrono. Para reduzir os atrasos de rede, selecione regiões com conexões de baixa latência. Para obter mais informações sobre latência entre regiões do Azure, consulte as estatísticas de latência de ida e volta da rede do Azure.

Custo

Ao criar várias instâncias gerenciadas de SQL em regiões diferentes, você recebe uma cobrança para cada instância gerenciada de SQL.

No entanto, se a sua instância secundária não tiver nenhuma carga de trabalho de leitura ou aplicativos conectados a ela, você poderá economizar nos custos de licenciamento designando a réplica como uma instância em espera. Para obter mais informações, consulte Configurar uma réplica em espera sem licença para a Instância Gerenciada de SQL.

Para obter mais informações sobre os preços da Instância Gerenciada de SQL, consulte as informações de preços do serviço.

Configurar o suporte a várias regiões

Para saber como configurar um grupo de failover, consulte Configurar um grupo de failover para a Instância Gerenciada de SQL.

Planejamento e gerenciamento de capacidade

Durante um failover, o tráfego é redirecionado para uma instância gerenciada de SQL secundária. É importante que sua instância gerenciada de SQL secundária esteja pronta para receber o tráfego. Crie uma instância gerenciada de SQL secundária com a mesma camada de serviço, geração de hardware e tamanho da computação que a instância primária.

Para obter mais informações sobre como dimensionar instâncias gerenciadas de SQL em um grupo de failover, consulte Instâncias de escala.

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando as instâncias gerenciadas de SQL são configuradas para usar grupos de failover de várias regiões e todas as regiões estão operacionais:

  • Roteamento de tráfego entre regiões: durante as operações normais, as solicitações de leitura e gravação vão para a única instância primária na região primária.

    Os grupos de failover também fornecem um ponto de extremidade de ouvinte somente leitura separado. Durante operações normais, esse ponto de extremidade se conecta à instância secundária para rotear o tráfego somente leitura especificado na cadeia de conexão.

    Para obter mais informações sobre como os grupos de transição enviam o tráfego para cada instância e como você pode direcionar o tráfego para um ponto de extremidade de escuta somente leitura, veja Visão geral e melhores práticas dos grupos de failover.

  • Replicação de dados entre regiões: por padrão, os dados são replicados de maneira assíncrona da instância primária para a instância gerenciada de SQL secundária.

    Como a replicação geográfica é assíncrona, se você executar um failover forçado, é possível experimentar a perda de dados. Você pode monitorar o atraso de replicação para entender a possível perda de dados durante um failover forçado. Para obter mais informações, consulte a lista de verificação de DR.

    Se você precisar eliminar a perda de dados decorrente da replicação assíncrona durante os failovers, configure seu aplicativo para bloquear o thread de execução até que seja confirmada a transmissão e a persistência da última transação confirmada no registro de transações do banco de dados secundário. Essa abordagem requer desenvolvimento personalizado e degrada o desempenho do seu aplicativo. Para obter mais informações, consulte Evitar a perda de dados críticos.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando as instâncias gerenciadas de SQL são configuradas para usar grupos de failover de várias regiões e há uma interrupção na região primária:

  • Detecção e resposta: a responsabilidade pela detecção e resposta depende da política de failover usada pelo grupo de failover.

    • Política de failover gerenciada pelo cliente: você é responsável por detectar a falha em uma região e disparar um failover ou um failover forçado para a instância secundária no grupo de failover.

      Se você executar um failover, a Instância Gerenciada de SQL aguardará que os dados sejam sincronizados com a instância secundária antes de executar o procedimento de failover.

      Se você executar um failover forçado, a Instância Gerenciada de SQL alterna imediatamente a instância secundária para a função primária sem esperar que as alterações recentes sejam propagadas da primária. Esse tipo de failover pode gerar perda de dados.

    • Política de failover gerenciada pela Microsoft: os failovers gerenciados pela Microsoft são executados em circunstâncias excepcionais. Quando a Microsoft dispara um failover, o grupo de failover executa automaticamente um failover forçado para a instância secundária no grupo de failover. No entanto, é recomendável usar uma política de failover gerenciada pelo cliente para cargas de trabalho de produção para que você possa controlar quando o failover ocorrer.

  • Solicitações ativas: Quando ocorre um failover, todas as solicitações que estão sendo processadas são encerradas e devem ser repetidas. Para tornar seus aplicativos resilientes a esses tipos de problemas, consulte Resiliência a falhas transitórias.

  • Perda de dados esperada: A quantidade de perda de dados depende de como você configura seu aplicativo. Para obter mais informações, consulte a visão geral e as práticas recomendadas dos grupos de failover.

  • Tempo de inatividade esperado: pode haver um pequeno período de inatividade durante um failover de grupo de failover. O tempo de inatividade normalmente é inferior a 60 segundos.

  • Redirecionamento de tráfego: Depois que o grupo de failover concluir o processo de failover, o tráfego de leitura/gravação será roteado automaticamente para a nova instância primária. Se os aplicativos usarem os pontos de extremidade do grupo de failover nas cadeias de conexão, eles não precisarão modificar as cadeias de conexão após o failover.

Recuperação de região

Os grupos de failover não fazem failback automaticamente para a região primária quando ela é restaurada, portanto, é sua responsabilidade iniciar um failback.

Teste de falhas na região

Você pode testar o failover de um grupo de failover.

Testar um grupo de failover é apenas uma parte da execução de uma análise de DR. Para obter mais informações, veja Executar simulações de DR.

Backup e restauração

Faça backups de seus bancos de dados para proteger contra vários riscos, incluindo perda de dados. Os backups podem ser restaurados para se recuperar de perda acidental de dados, corrupção ou outros problemas. Os backups não são a mesma coisa que a replicação geográfica e têm propósitos diferentes e reduzem riscos diferentes.

A Instância Gerenciada de SQL realiza automaticamente backups completos, diferenciais e de log de transações de seus bancos de dados. Para obter mais informações sobre os tipos de backups, sua frequência, recursos de restauração, custos de armazenamento e criptografia de backup, consulte backups automatizados na Instância Gerenciada de SQL.

A Instância Gerenciada de SQL fornece backups automatizados internos e também dá suporte a backups do tipo copy-only iniciados pelo usuário para bancos de dados do usuário. Para obter mais informações, veja Backups somente cópia.

Replicação de backup

Ao configurar backups automatizados para sua instância gerenciada de SQL, você pode especificar como os backups devem ser replicados. Os backups configurados para serem armazenados no ZRS têm um nível mais alto de resiliência. Recomendamos que você configure seus backups para usar um dos seguintes tipos de armazenamento:

  • ZRS para resiliência dentro da região, se a região tiver zonas de disponibilidade

  • GZRS para melhorar a resiliência de seus backups entre regiões se a região tiver zonas de disponibilidade e estiver emparelhada com outra região

  • GRS se sua região não dá suporte a zonas de disponibilidade, mas tem uma região pareada

Para obter mais informações sobre diferentes tipos de armazenamento e suas funcionalidades, consulte Redundância de armazenamento de backup.

Restauração geográfica

A funcionalidade de restauração geográfica é uma solução básica de recuperação de desastre que permite restaurar cópias de backup para uma região diferente do Azure. Normalmente, o backup geográfico exige um tempo de inatividade significativo e perda de dados. Para obter níveis mais altos de capacidade de recuperação se ocorrer uma interrupção regional, você deve configurar grupos de failover.

Se você usar a restauração geográfica, precisará considerar como disponibilizar seus backups em sua região secundária:

  • Se a região primária estiver emparelhada, use o armazenamento de backup GZRS ou GRS para dar suporte à restauração geográfica para a região emparelhada.

  • Se a região primária não estiver emparelhada, você poderá criar uma solução personalizada para replicar seus backups para outra região. Considere o uso de backups somente cópia iniciados pelo usuário e armazená-los em uma conta de armazenamento que usa a replicação de objeto de blob para replicação para uma conta de armazenamento em outra região.

Resiliência à manutenção do serviço

Quando a Instância Gerenciada de SQL executa a manutenção em sua instância, a instância gerenciada de SQL permanece totalmente disponível, mas pode estar sujeita a reconfigurações curtas. Os aplicativos cliente podem observar breves interrupções de conectividade durante um evento de manutenção. Os aplicativos cliente devem seguir as diretrizes de Resiliência a falhas transitórias para minimizar os efeitos.

A Instância Gerenciada de SQL permite que você especifique uma janela de manutenção geralmente usada para atualizações de serviço e outras operações de manutenção. Configurar uma janela de manutenção pode ajudar a minimizar qualquer efeitos colaterais, como failovers automáticos, durante o horário comercial. Você também pode receber uma notificação antecipada da manutenção planejada.

Para obter mais informações, consulte a janela Manutenção na Instância Gerenciada de SQL.

Contrato de nível de serviço

O acordo de nível de serviço (SLA) dos serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para alcançar essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

Para a Instância Gerenciada de SQL, o SLA de disponibilidade só se aplica quando sua rede virtual do Azure está configurada corretamente para que ela não impeça o tráfego de gerenciamento. Essa configuração inclui tamanho de sub-rede, NSGs (grupos de segurança de rede), UDRs (rotas definidas pelo usuário), configuração de DNS e outros recursos que afetam o gerenciamento e o uso de recursos de rede. Para obter mais informações sobre a configuração de rede necessária para a Instância Gerenciada de SQL, consulte os requisitos de rede.

Conteúdo relacionado

  • Last updated on