GRUPO DE DISPONIBILIDADE ALTER (Transact-SQL)

Aplica-se a:SQL Server

Altera um grupo de disponibilidade Always On existente no SQL Server. A maioria ALTER AVAILABILITY GROUP dos argumentos é apoiada apenas na réplica primária atual. No entanto, os JOINargumentos , FAILOVER, e FORCE_FAILOVER_ALLOW_DATA_LOSS são suportados apenas em réplicas secundárias.

Transact-SQL convenções de sintaxe

Sintaxe

ALTER AVAILABILITY GROUP group_name
  {
     SET ( <set_option_spec> )
   | ADD DATABASE database_name
   | REMOVE DATABASE database_name
   | ADD REPLICA ON <add_replica_spec>
   | MODIFY REPLICA ON <modify_replica_spec>
   | REMOVE REPLICA ON <server_instance>
   | JOIN
   | JOIN AVAILABILITY GROUP ON <add_availability_group_spec> [ , ...2 ]
   | MODIFY AVAILABILITY GROUP ON <modify_availability_group_spec> [ , ...2 ]
   | GRANT CREATE ANY DATABASE
   | DENY CREATE ANY DATABASE
   | FAILOVER
   | FORCE_FAILOVER_ALLOW_DATA_LOSS
   | ADD LISTENER 'dns_name' ( <add_listener_option> )
   | MODIFY LISTENER 'dns_name' ( <modify_listener_option> )
   | RESTART LISTENER 'dns_name'
   | REMOVE LISTENER 'dns_name'
   | OFFLINE
  }
[ ; ]

<set_option_spec> ::=
    AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY | SECONDARY | NONE }
  | FAILURE_CONDITION_LEVEL  = { 1 | 2 | 3 | 4 | 5 }
  | HEALTH_CHECK_TIMEOUT = milliseconds
  | DB_FAILOVER  = { ON | OFF }
  | DTC_SUPPORT  = { PER_DB | NONE }
  | REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = { integer }
  | ROLE = SECONDARY
  | CLUSTER_CONNECTION_OPTIONS = 'key_value_pairs> [ ;... ] '

<server_instance> ::=
 { 'system_name [ \instance_name ] ' | 'FCI_network_name [ \instance_name ] ' }

<add_replica_spec>::=
  <server_instance> WITH
    (
       ENDPOINT_URL = 'TCP://system-address:port' ,
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY } ,
       FAILOVER_MODE = { AUTOMATIC | MANUAL }
       [ , <add_replica_option> [ , ...n ] ]
    )

  <add_replica_option>::=
       SEEDING_MODE = { AUTOMATIC | MANUAL }
     | BACKUP_PRIORITY = n
     | SECONDARY_ROLE ( {
            [ ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL } ]
        [ , ] [ READ_ONLY_ROUTING_URL = 'TCP://system-address:port' ]
     } )
     | PRIMARY_ROLE ( {
            [ ALLOW_CONNECTIONS = { READ_WRITE | ALL } ]
        [ , ] [ READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ , ...n ] ) | NONE } ]
        [ , ] [ READ_WRITE_ROUTING_URL = 'TCP://system-address:port' ]
     } )
     | SESSION_TIMEOUT = integer

<modify_replica_spec>::=
  <server_instance> WITH
    (
       ENDPOINT_URL = 'TCP://system-address:port'
     | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }
     | FAILOVER_MODE = { AUTOMATIC | MANUAL }
     | SEEDING_MODE = { AUTOMATIC | MANUAL }
     | BACKUP_PRIORITY = n
     | SECONDARY_ROLE ( {
          [ ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL }  ]
        | [ READ_ONLY_ROUTING_URL = { 'TCP://system-address:port' | NONE } ]
          } )
     | PRIMARY_ROLE ( {
          [ ALLOW_CONNECTIONS = { READ_WRITE | ALL }   ]
        | [ READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ , ...n ] ) | NONE } ]
        | [ READ_WRITE_ROUTING_URL = { 'TCP://system-address:port' | NONE }  ]
          } )
     | SESSION_TIMEOUT = seconds
    )

<add_availability_group_spec>::=
 <ag_name> WITH
    (
       LISTENER_URL = 'TCP://system-address:port' ,
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT } ,
       FAILOVER_MODE = MANUAL ,
       SEEDING_MODE = { AUTOMATIC | MANUAL }
    )

<modify_availability_group_spec>::=
 <ag_name> WITH
    (
       LISTENER = 'TCP://system-address:port'
       | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }
       | SEEDING_MODE = { AUTOMATIC | MANUAL }
    )

<add_listener_option> ::=
   {
      WITH DHCP [ ON ( <network_subnet_option> ) ]
    | WITH IP ( { ( <ip_address_option> ) } [ , ...n ] ) [ , PORT = listener_port ]
   }

  <network_subnet_option> ::=
     'ipv4_address' , 'ipv4_mask'

  <ip_address_option> ::=
     {
        'four_part_ipv4_address' , 'four_part_ipv4_mask'
      | 'ipv6_address'
     }

<modify_listener_option>::=
    {
       ADD IP ( <ip_address_option> )
     | PORT = listener_port
     | REMOVE IP ( 'ipv4_address' | 'ipv6_address')
    }

Argumentos

group_name

Especifica o nome do novo grupo de disponibilidade. group_name deve ser um identificador válido do SQL Server e deve ser exclusivo em todos os grupos de disponibilidade no cluster WSFC.

AUTOMATED_BACKUP_PREFERENCE = { PRIMÁRIO | SECONDARY_ONLY| SECUNDÁRIO | NENHUM }

Especifica uma preferência sobre como um trabalho de backup avalia a réplica primária ao escolher onde realizar backups. Você pode criar um script para uma determinada tarefa de backup para levar em conta a preferência de backup automatizado. É importante entender que a preferência não é imposta pelo SQL Server, portanto, não tem efeito em backups ad hoc.

Suportado apenas na réplica primária.

Os valores são os seguintes:

PRIMÁRIO

Especifica que os backups ocorrem sempre na réplica principal. Esta opção é útil se precisar de funcionalidades de backup, como criar backups diferenciais, que não são suportadas quando o backup corre numa réplica secundária.

Importante

Se planeia usar o envio de registos para preparar quaisquer bases de dados secundárias para um grupo de disponibilidade, defina a preferência de backup automatizado até Primary que todas as bases de dados secundárias estejam preparadas e juntadas ao grupo de disponibilidade.

SECONDARY_ONLY

Especifica que nunca ocorrem backups na réplica primária. Se a réplica principal for a única online, o backup não acontece.

SECUNDÁRIO

Especifica que os backups ocorrem numa réplica secundária, exceto quando a réplica primária é a única réplica online. Nesse caso, o backup ocorre na réplica principal. Este é o comportamento padrão.

NENHUM

Especifica que você prefere que os trabalhos de backup ignorem a função das réplicas de disponibilidade ao escolher a réplica para executar backups. Observação Os trabalhos de backup podem avaliar outros fatores, como a prioridade de backup de cada réplica de disponibilidade em combinação com seu estado operacional e estado conectado.

Importante

Não há imposição do AUTOMATED_BACKUP_PREFERENCE cenário. A interpretação desta preferência depende da lógica, se existir, que se scripta em trabalhos de backup para as bases de dados num dado grupo de disponibilidade. A definição automática de preferências de backup não tem efeito em backups ad hoc. Para mais informações, consulte Configurar backups em réplicas secundárias de um grupo de disponibilidade Always On.

Observação

Para visualizar a preferência automática de backup de um grupo de disponibilidade existente, selecione a automated_backup_preference coluna ou automated_backup_preference_desc da vista de catálogo sys.availability_groups . Adicionalmente, sys.fn_hadr_backup_is_preferred_replica podem ser usados para determinar a réplica de backup preferida. Esta função retorna 1 sempre para pelo menos uma das réplicas, mesmo quando AUTOMATED_BACKUP_PREFERENCE = NONE.

FAILURE_CONDITION_LEVEL = { 1 | 2 | 3 | 4 | 5 }

Especifica quais condições de falha acionam um failover automático para esse grupo de disponibilidade. FAILURE_CONDITION_LEVEL é definido ao nível do grupo, mas é relevante apenas em réplicas de disponibilidade configuradas para o modo de disponibilidade de commit síncrono (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). Além disso, as condições de falha podem desencadear um failover automático apenas se tanto as réplicas primária como secundária estiverem configuradas para o modo de failover automático (FAILOVER_MODE = AUTOMATIC) e a réplica secundária estiver atualmente sincronizada com a réplica primária.

Suportado apenas na réplica primária.

Os níveis de condição de falha (1-5) variam do menos restritivo, nível 1, ao mais restritivo, nível 5. Um determinado nível de condição engloba todos os níveis menos restritivos. Assim, o nível de condição mais rigoroso, 5, inclui os quatro níveis de condição menos restritivos (1-4), o nível 4 inclui os níveis 1-3, e assim por diante. A tabela seguinte descreve a condição de falha que corresponde a cada nível.

Nível	Condição de falha
1	Especifica que um failover automático é iniciado quando ocorre qualquer uma das seguintes situações: O serviço do SQL Server está inativo. O arrendamento do grupo de disponibilidade para ligação ao cluster WSFC expira porque não é recebido nada `ACK` da instância do servidor. Para obter mais informações, consulte Como funciona: Tempo limite de concessão Always On do SQL Server.
2	Especifica que um failover automático é iniciado quando ocorre qualquer uma das seguintes situações: A instância do SQL Server não se liga ao cluster, e o limiar especificado `HEALTH_CHECK_TIMEOUT` pelo utilizador para o grupo de disponibilidade é ultrapassado. A réplica de disponibilidade está em estado de falha.
3	Especifica que um failover automático é iniciado em erros internos críticos do SQL Server, como spinlocks órfãos, graves violações de acesso de escrita ou dumping excessivo. Este é o comportamento padrão.
4	Especifica que um failover automático é iniciado em erros internos moderados do SQL Server, como uma condição persistente de falta de memória no pool interno de recursos do SQL Server.
5	Especifica que um failover automático é iniciado em quaisquer condições de falha qualificadas, incluindo: Exaustão de threads de trabalho do SQL Engine. Deteção de um impasse insolúvel.

Observação

A falta de resposta de uma instância do SQL Server às solicitações do cliente não é relevante para os grupos de disponibilidade.

Os FAILURE_CONDITION_LEVEL valores e HEALTH_CHECK_TIMEOUT definem uma política flexível de failover para um dado grupo. Essa política de failover flexível fornece controle granular sobre quais condições devem causar um failover automático. Para mais informações, consulte Configurar uma política de failover automático flexível para um grupo de disponibilidade Sempre Ligado.

`HEALTH_CHECK_TIMEOUT` = milissegundos

Especifica o tempo de espera, em milissegundos, para que o procedimento armazenado do sistema sp_server_diagnostics devolva informação de saúde do servidor antes de o cluster WSFC assumir que a instância do servidor está lenta ou não responde. Definido HEALTH_CHECK_TIMEOUT ao nível do grupo, mas é relevante apenas para réplicas de disponibilidade que configura para o modo de disponibilidade de commit síncrono com failover automático (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). Além disso, um timeout de verificação de saúde pode desencadear um failover automático apenas se tanto as réplicas primárias como secundárias estiverem configuradas para modo automático de failover (FAILOVER_MODE = AUTOMATIC) e a réplica secundária estiver atualmente sincronizada com a réplica primária.

O valor padrão HEALTH_CHECK_TIMEOUT é 30.000 milissegundos (30 segundos). O valor mínimo é de 15.000 milissegundos (15 segundos) e o valor máximo é de 4.294.967.295 milissegundos.

Suportado apenas na réplica primária.

Importante

sp_server_diagnostics não realiza verificações de saúde ao nível da base de dados.

DB_FAILOVER = { EM | DESLIGADO }

Especifica a resposta a ser tomada quando um banco de dados na réplica primária estiver offline. Quando definido para ON, qualquer estado que não ONLINE seja para uma base de dados no grupo de disponibilidade desencadeia um failover automático. Quando defines esta opção para OFF, apenas a saúde da instância dispara o failover automático.

Para mais informações sobre esta definição, consulte a opção de failover de deteção de saúde ao nível da base de dados do grupo de disponibilidade.

DTC_SUPPORT = { PER_DB | NENHUM }

Especifica se as transações distribuídas estão ativadas para este grupo de disponibilidade. As transações distribuídas só têm suporte para bancos de dados de grupo de disponibilidade a partir do SQL Server 2016 (13.x) e as transações entre bancos de dados só são suportadas a partir do SQL Server 2016 (13.x) SP2. PER_DB cria o grupo de disponibilidade com suporte para estas transações e promove automaticamente transações entre bases de dados envolvendo bases de dados do grupo de disponibilidade em transações distribuídas. NONE impede a promoção automática de transações entre bancos de dados para transações distribuídas e não registra o banco de dados com um RMID estável no DTC. As transações distribuídas não são impedidas quando a configuração de NONE é usada, mas o failover do banco de dados e a recuperação automática podem não ter êxito em algumas circunstâncias. Para obter mais informações, consulte Transações - grupos de disponibilidade e espelhamento de banco de dados.

Observação

O suporte para alterar a DTC_SUPPORT definição de um grupo de disponibilidade foi introduzido no SQL Server 2016 (13.x) Service Pack 2. Esta opção não pode ser usada com versões anteriores. Para alterar esta definição em versões anteriores do SQL Server, tem DROP de voltar a usar o CREATE grupo de disponibilidade.

Importante

O DTC tem um limite de 32 alistamentos por transação distribuída. Como cada banco de dados dentro de um grupo de disponibilidade se alista com o DTC separadamente, se sua transação envolver mais de 32 bancos de dados, você poderá obter o seguinte erro quando o SQL Server tentar inscrever o 33º banco de dados:

Enlist operation failed: 0x8004d101(XACT_E_TOOMANY_ENLISTMENTS). SQL Server could not register with Microsoft Distributed Transaction Coordinator (MS DTC) as a resource manager for this transaction. The transaction may have been stopped by the client or the resource manager.

Para mais detalhes sobre transações distribuídas no SQL Server, veja Transações distribuídas.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Introduzido no SQL Server 2017 (14.x). Define um número mínimo de réplicas secundárias síncronas necessárias para confirmar antes que a réplica primária confirme uma transação. Garante que as transações do SQL Server aguarde até que os logs de transações sejam atualizados no número mínimo de réplicas secundárias.

Padrão: 0. Fornece o mesmo comportamento que o SQL Server 2016 (13.x).
Mínimo: 0.
Máximo: Número de réplicas menos 1.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT relaciona-se com réplicas em modo de commit síncrono. Quando as réplicas estão no modo de confirmação síncrona, as gravações na réplica primária aguardam até que as gravações em réplicas síncronas sejam confirmadas no log de transações do banco de dados de réplica. Se um SQL Server que hospeda uma réplica síncrona secundária deixar de responder, o SQL Server que hospeda a réplica primária marca essa réplica secundária como NOT SYNCHRONIZED e avança. Quando a base de dados não responsiva volta a estar online, está num estado de "não sincronizada" e a réplica é marcada como insalubre até que o primário a consiga sincronizar novamente. Essa configuração garante que a réplica primária não prossiga até que o número mínimo de réplicas tenha confirmado cada transação. Se o número mínimo de réplicas não estiver disponível, confirmará na falha primária. Para o tipo de cluster EXTERNAL a configuração é alterada quando o grupo de disponibilidade é adicionado a um recurso de cluster. Consulte Alta disponibilidade e proteção de dados para configurações de grupo de disponibilidade.

A partir do SQL Server 2022 (16.x), pode definir REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT um grupo de disponibilidade distribuída. Esta definição não é suportada para CREATE AVAILABILITY GROUP. Podes usar ALTER AVAILABILITY GROUP para definir REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Por exemplo:

ALTER AVAILABILITY GROUP [<name>]
  SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = <integer>);

FUNÇÕES

O único parâmetro válido é SECONDARY, e esta SET opção só é válida em grupos de disponibilidade distribuída. Use-o para fazer fail sobre um grupo de disponibilidade distribuído.

CLUSTER_CONNECTION_OPTIONS

Aplica-se a: SQL Server 2025 (17.x) e versões posteriores

Use a cláusula para impor a CLUSTER_CONNECTION_OPTIONS criptografia TLS 1.3 para comunicação entre o Cluster de Failover do Windows Server e as réplicas do grupo de disponibilidade. Especifique as opções como uma lista de pares-chave-valor, separados por ponto e vírgula. Use os pares chave-valor para configurar a encriptação das strings de ligação para o grupo de disponibilidade.

Para reverter para a criptografia padrão, defina a CLUSTER_CONNECTION_OPTIONS cláusula como uma cadeia de caracteres vazia. O SQL Server 2025 (17.x) tem por defeito , Encrypt=Mandatorye TrustServerCertificate=Yes para ligações a réplicas de grupos de disponibilidade e ouvintes.

Para obter mais informações, consulte Conectar-se a um grupo de disponibilidade com criptografia estrita e TDS 8.0.

A tabela a seguir descreve os pares chave-valor que você pode usar na CLUSTER_CONNECTION_OPTIONS cláusula:

Key	Valores suportados	Description
`Encrypt`	`Mandatory`, `Strict`, `Optional`	Especifica como a criptografia para o grupo de disponibilidade é imposta. Se o servidor não suportar encriptação, a ligação falha. Se definires a encriptação para `Mandatory`, então `TrustServerCertificate` deve ser definido como sim. Se definires a encriptação para `Strict`, então `TrustServerCertificate` é ignorado. Nota: Este par chave-valor é obrigatório.
`HostNameInCertificate`	Nome da réplica ou nome do ouvinte AG	Especifica o nome da réplica ou o nome do ouvinte do grupo de disponibilidade no certificado usado para encriptação. Esse valor deve corresponder ao valor no Nome Alternativo da Entidade do certificado. Se o nome do servidor estiver listado no certificado, você poderá omitir o `HostNameInCertificate` par chave-valor. Se o nome do servidor não estiver listado no certificado, então deve especificar o `HostNameInCertificate` par chave-valor com o nome do servidor. Nota: Este par chave-valor é opcional.
`TrustServerCertificate`	`Yes`, `No`	Defina como `yes` para especificar que o driver não valida o certificado TLS/SSL do servidor. Se `no`, o driver valida o certificado. Para obter mais informações, consulte TDS 8.0. Nota: Este par chave-valor é opcional.
`ServerCertificate`	Caminho para o certificado	Se não quiseres usar `HostNameInCertificate`, podes passar o caminho para o teu certificado. A conta de serviço de cluster deve ter permissão para ler o certificado do local determinado. Nota: Este par chave-valor é opcional.
`CLUSTER_CONNECTION_OPTIONS`	String vazia (`''`)	Limpa a configuração existente e reverte para as configurações de criptografia padrão de `Encrypt=Mandatory` e `TrustServerCertificate=Yes`.

Confira os exemplos para saber como usar a CLUSTER_CONNECTION_OPTIONS cláusula.

ADICIONAR database_name DE BANCO DE DADOS

Especifica uma lista de um ou mais bancos de dados de usuário que você deseja adicionar ao grupo de disponibilidade. Esses bancos de dados devem residir na instância do SQL Server que hospeda a réplica primária atual. Você pode especificar vários bancos de dados para um grupo de disponibilidade, mas cada banco de dados pode pertencer a apenas um grupo de disponibilidade. Para informações sobre o tipo de bases de dados que um grupo de disponibilidade pode suportar, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade Sempre Ligados. Para saber quais as bases de dados locais que já pertencem a um grupo de disponibilidade, consulte a replica_id coluna na vista de catálogo sys.databases .

Suportado apenas na réplica primária.

Observação

Depois de criar o grupo de disponibilidade, precisa de se ligar a cada instância de servidor que aloja uma réplica secundária. Depois, prepare cada base de dados secundária e junte-a ao grupo de disponibilidade. Para obter mais informações, consulte Iniciar movimentação de dados em um banco de dados secundário Always On (SQL Server).

REMOVER database_name BANCO DE DADOS

Remove o banco de dados primário especificado e os bancos de dados secundários correspondentes do grupo de disponibilidade. Suportado apenas na réplica primária.

Para informações sobre os passos recomendados após a remoção de uma base de dados de disponibilidade de um grupo de disponibilidade, veja Remover uma base de dados primária de um grupo de disponibilidade Always On.

ADICIONAR RÉPLICA EM

Especifica de uma a oito instâncias do SQL Server para hospedar réplicas secundárias em um grupo de disponibilidade. Cada réplica é especificada pelo endereço da sua instância do servidor seguido de uma WITH (...) cláusula.

Suportado apenas na réplica primária.

Você precisa unir cada nova réplica secundária ao grupo de disponibilidade. Para mais informações, consulte a descrição da JOIN opção, mais adiante nesta secção.

<server_instance>

Especifica o endereço da instância do SQL Server que é o host de uma réplica. O formato de endereço depende se a instância é a instância padrão ou uma instância nomeada e se é uma instância autônoma ou uma instância de cluster de failover (FCI). A sintaxe é a seguinte:

{ 'system_name[\instance_name]' | 'FCI_network_name[\instance_name]' }

Os componentes deste endereço são os seguintes:

system_name

O nome NetBIOS do sistema de computador no qual reside a instância de destino do SQL Server. Este computador deve ser um nó WSFC.

FCI_network_name

O nome da rede que usas para aceder a um cluster de failover SQL Server. Use este nome se a instância do servidor participar como parceiro de failover do SQL Server. Executar SELECT @@SERVERNAME numa instância de servidor FCI retorna toda a sua cadeia 'FCI_network_name[\instance_name]' (que é o nome completo da réplica).

Para mais informações, consulte @@SERVERNAME.

instance_name

O nome de uma instância de um SQL Server que system_name ou FCI_network_name hospeda e que tem o Always On ativado. Para uma instância de servidor padrão, instance_name é opcional. O nome da instância não diferencia maiúsculas de minúsculas. Numa instância de servidor autónoma, este nome de valor é o mesmo que o valor devolvido ao executar SELECT @@SERVERNAME.

\

Um separador usado apenas ao especificar instance_name, a fim de separá-lo de system_name ou FCI_network_name.

Para informações sobre os pré-requisitos para nós e instâncias de servidor WSFC, veja Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On.

ENDPOINT_URL = 'TCP:// endereço:sistemaporta'

Especifica o caminho URL para o endpoint de espelhamento da base de dados na instância do SQL Server que hospeda a réplica de disponibilidade que está a adicionar ou modificar.

ENDPOINT_URL é exigido na ADD REPLICA ON cláusula e opcional na MODIFY REPLICA ON cláusula. Para mais informações, consulte Especificar URL de Endpoint - Adicionar ou Modificar Réplica de Disponibilidade.

«TCP://endereço do sistema:port»

Especifica uma URL para especificar uma URL de ponto de extremidade ou uma URL de roteamento somente leitura. Os parâmetros de URL são os seguintes:

de endereço do sistema

Uma cadeia de caracteres, como um nome de sistema, um nome de domínio totalmente qualificado ou um endereço IP, que identifica inequivocamente o sistema do computador de destino.

porto

Um número de porta associado ao endpoint de espelhamento da instância do servidor (para a ENDPOINT_URL opção) ou o número de porta usado pelo Motor de Base de Dados da instância do servidor (para a READ_ONLY_ROUTING_URL opção).

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

Especifica se a réplica primária espera que a réplica secundária reconheça o endurecimento (escrita) dos registos de registo no disco antes de a réplica primária poder comprometer a transação numa dada base de dados primária. As transações em bancos de dados diferentes na mesma réplica primária podem ser confirmadas de forma independente.

SYNCHRONOUS_COMMIT

Especifica que a réplica primária espera para confirmar transações até que estas sejam reforçadas nesta réplica secundária (modo de commit síncrono). Pode especificar SYNCHRONOUS_COMMIT até três réplicas, incluindo a réplica principal.

ASYNCHRONOUS_COMMIT

Especifica que a réplica primária confirma transações sem esperar que essa réplica secundária proteja o log (modo de disponibilidade de confirmação síncrona). Pode especificar ASYNCHRONOUS_COMMIT até cinco réplicas disponíveis, incluindo a réplica principal.

CONFIGURATION_ONLY

Especifica que a réplica primária compromete sincronizadamente os metadados de configuração do grupo de disponibilidade na master base de dados desta réplica. A réplica não contém dados do utilizador. Esta opção:

Pode ser hospedado em qualquer edição do SQL Server, incluindo o Express Edition.
Requer que o ponto final de espelhamento de dados da CONFIGURATION_ONLY réplica seja do tipo WITNESS.
Não pode ser alterado.
Não é válido quando CLUSTER_TYPE = WSFC.

Para obter mais informações, consulte Alta disponibilidade e proteção de dados para configurações de grupo de disponibilidade.

AVAILABILITY_MODE é exigido na ADD REPLICA ON cláusula e opcional na MODIFY REPLICA ON cláusula. Para obter mais informações, consulte Diferenças entre modos de disponibilidade para um grupo de disponibilidade Always On.

FAILOVER_MODE = { AUTOMÁTICO | MANUAL }

Especifica o modo de failover da réplica de disponibilidade que você está definindo.

AUTOMÁTICO

Permite failover automático. AUTOMATIC é suportado apenas se também especificar AVAILABILITY_MODE = SYNCHRONOUS_COMMIT. Pode especificar AUTOMATIC para três réplicas disponíveis, incluindo a réplica principal.

Observação

Antes do SQL Server 2016 (13.x), estavas limitado a duas réplicas automáticas de failover, incluindo a réplica principal.
As FCIs (Instâncias de Cluster de Failover) do SQL Server não oferecem suporte a failover automático por grupos de disponibilidade, portanto, qualquer réplica de disponibilidade que um host FCI só pode ser configurada para failover manual.

MANUAL

Permite failover manual ou failover manual forçado (failover forçado) pelo administrador do banco de dados.

Deve especificar FAILOVER_MODE na ADD REPLICA ON cláusula. Podes opcionalmente especificar isso na MODIFY REPLICA ON cláusula. Existem dois tipos de failover manual: failover manual sem perda de dados e failover forçado (com possível perda de dados). Diferentes condições suportam estes tipos. Para obter mais informações, consulte modos de failover e failover (grupos de disponibilidade Always On).

SEEDING_MODE = { AUTOMÁTICO | MANUAL }

Especifica como a réplica secundária é inicialmente propagada.

AUTOMÁTICO

Permite a semeadura direta. Este método semeia a réplica secundária através da rede. Esse método não requer backup e restauração de uma cópia do banco de dados primário na réplica.

Observação

Para seed direta, deve permitir a criação de bases de dados em cada réplica secundária ligando ALTER AVAILABILITY GROUP com a GRANT CREATE ANY DATABASE opção.

MANUAL

Especifica a propagação manual (padrão). Esse método requer que você crie um backup do banco de dados na réplica primária e restaure manualmente esse backup na réplica secundária.

BACKUP_PRIORITY = n

Especifica sua prioridade para executar backups nessa réplica em relação às outras réplicas no mesmo grupo de disponibilidade. O valor é um inteiro no intervalo de 0,100. Estes valores têm os seguintes significados:

1..100 indica que a réplica de disponibilidade poderia ser escolhida para realizar backups. 1 indica a prioridade mais baixa e 100 indica a prioridade mais alta. Se BACKUP_PRIORITY = 1, a réplica de disponibilidade é escolhida apenas para realizar backups se não existirem atualmente réplicas de disponibilidade de prioridade superior.
0 indica que esta réplica de disponibilidade nunca é escolhida para realizar backups. Esta opção é útil, por exemplo, para uma réplica de disponibilidade remota para a qual nunca se quer que backups façam failover.

Para obter mais informações, consulte Transferir backups suportados para réplicas secundárias de um grupo de disponibilidade.

SECONDARY_ROLE ( ... )

Especifica definições específicas do papel que entram em vigor se esta réplica de disponibilidade atualmente detiver o papel secundário (sempre que seja uma réplica secundária). Entre parênteses, especifique uma ou ambas as opções de função secundária. Se você especificar ambos, use uma lista separada por vírgula.

As opções de função secundária são as seguintes:

ALLOW_CONNECTIONS = { NÃO | READ_ONLY | TODOS }

Especifica se as bases de dados de uma dada réplica de disponibilidade que desempenha o papel secundário (atuando como réplica secundária) podem aceitar ligações de clientes, um dos seguintes:

NÃO

Nenhuma conexão de usuário é permitida para bancos de dados secundários dessa réplica. Não estão disponíveis para acesso de leitura. Este é o comportamento padrão.

READ_ONLY

Apenas são permitidas ligações às bases de dados na réplica secundária onde a propriedade Application Intent está definida como ReadOnly. Para obter mais informações sobre essa propriedade, consulte Usando palavras-chave de cadeia de conexão com o SQL Server Native Client.

TUDO

Todas as conexões são permitidas aos bancos de dados na réplica secundária para acesso somente leitura.

Para obter mais informações, consulte Transferir carga de trabalho de leitura apenas para a réplica secundária de um grupo de disponibilidade Always On.

READ_ONLY_ROUTING_URL = { 'TCP:// sistema-endereço:porta' | NENHUM }

Especifica o URL a usar para encaminhar pedidos de ligação de intenção de leitura para esta réplica de disponibilidade. Este URL é onde o Motor de Base de Dados SQL Server escuta. Normalmente, a instância padrão do Mecanismo de Banco de Dados do SQL Server escuta na porta TCP 1433.

A partir do SQL Server 2025 (17.x), pode especificar NONE como READ_ONLY_ROUTING_URL destino reverter o encaminhamento apenas de leitura especificado para a réplica de disponibilidade, e encaminhar o tráfego com base no comportamento padrão.

Para uma instância nomeada, consulte as port colunas e type_desc da vista dinâmica de gestão sys.dm_tcp_listener_states para obter o número da porta. A instância do servidor utiliza o ouvinte Transact-SQL (type_desc='TSQL').

Para obter mais informações sobre como calcular a URL de roteamento somente leitura para uma réplica de disponibilidade, consulte Calculando read_only_routing_url para Always On.

Observação

Para uma instância nomeada do SQL Server, configure o ouvinte Transact-SQL para usar uma porta específica. Para mais informações, consulte Configurar o SQL Server para escutar numa porta TCP específica.

PRIMARY_ROLE ( ... )

Especifica definições específicas de função que entram em vigor se esta réplica disponível atualmente detiver o papel principal (sempre que seja a réplica primária). Entre parênteses, especifique uma ou ambas as opções de função primária. Se você especificar ambos, use uma lista separada por vírgula.

As principais opções de função são as seguintes:

ALLOW_CONNECTIONS = { READ_WRITE | TODOS }

Especifica o tipo de ligação que as bases de dados de uma dada réplica de disponibilidade que desempenha o papel primário (atuando como réplica primária) podem aceitar dos clientes, um dos:

LEITURA_ESCRITA

Ligações onde a propriedade de ligação Application Intent está definida ReadOnly são desautorizadas. Quando a propriedade Application Intent está definida como ReadWrite ou a propriedade de ligação Application Intent não está definida, a ligação é permitida. Para obter mais informações sobre a propriedade de conexão Application Intent, consulte Usando palavras-chave de cadeia de conexão com o SQL Server Native Client.

TUDO

Todas as conexões são permitidas aos bancos de dados na réplica primária. Este é o comportamento padrão.

READ_ONLY_ROUTING_LIST = { ('<server_instance>' [ , ... n ] ) | NENHUM }

Especifica uma lista separada por vírgulas de instâncias de servidor que hospedam réplicas de disponibilidade para esse grupo de disponibilidade que atendem aos seguintes requisitos quando executadas na função secundária:

Ser configurado para permitir todas as ligações ou ligações apenas de leitura (ver o ALLOW_CONNECTIONS argumento da SECONDARY_ROLE opção, anteriormente neste artigo).
Tenha o URL de encaminhamento de apenas leitura definido (veja o READ_ONLY_ROUTING_URL argumento da SECONDARY_ROLE opção, anteriormente neste artigo).

Os READ_ONLY_ROUTING_LIST valores são os seguintes:

<server_instance>

Especifica o endereço da instância do SQL Server que é o anfitrião para uma réplica de disponibilidade que é uma réplica secundária legível quando está a correr sob o papel secundário.

Use uma lista separada por vírgulas para especificar todas as instâncias do servidor que podem hospedar uma réplica secundária legível. O roteamento somente leitura segue a ordem na qual as instâncias do servidor são especificadas na lista. Se você incluir a instância do servidor host de uma réplica na lista de roteamento somente leitura da réplica, colocar essa instância do servidor no final da lista normalmente é uma boa prática, para que as conexões de intenção de leitura vão para uma réplica secundária, se houver uma disponível.

A partir do SQL Server 2016 (13.x), você pode balancear a carga de solicitações de intenção de leitura em réplicas secundárias legíveis. Para especificar isso, coloque as réplicas em um conjunto aninhado de parênteses na lista de roteamento somente leitura. Para obter mais informações e exemplos, consulte Configurar o balanceamento de carga entre réplicas somente leitura.

NENHUM

Especifica que, quando essa réplica de disponibilidade for a réplica primária, o roteamento somente leitura não será suportado. Este é o comportamento padrão. Quando usado com MODIFY REPLICA ON, este valor desativa uma lista existente, se existir.

{ READ_WRITE_ROUTING_URL = 'TCP:// endereço-sistema:porta' | NENHUM }

Aplica-se a: SQL Server 2019 (15.x) e versões posteriores

Especifica instâncias de servidor que hospedam réplicas de disponibilidade para esse grupo de disponibilidade que atendem aos seguintes requisitos quando executadas sob a função principal:

A especificação PRIMARY_ROLE da réplica inclui READ_WRITE_ROUTING_URL.
A cadeia de conexão é ReadWrite definindo ApplicationIntent como ReadWrite ou não definindo ApplicationIntent e deixando o padrão (ReadWrite) entrar em vigor.

A partir do SQL Server 2025 (17.x), pode especificar NONE como READ_WRITE_ROUTING_URL destino reverter o encaminhamento de leitura-escrita especificado para a réplica de disponibilidade e encaminhar o tráfego com base no comportamento predefinido.

Para obter mais informações, consulte redirecionamento de conexão de leitura/gravação de réplica primária (grupos de disponibilidade Always On).

SESSION_TIMEOUT = segundos

Especifica o período de tempo limite da sessão em segundos. Se não especificares esta opção, o período de tempo padrão é 10 segundos. O valor mínimo é de 5 segundos.

Importante

Mantém o período de espera em 10 segundos ou mais.

Para mais informações sobre o período de pausa da sessão, veja O que é um grupo de disponibilidade Always On?

MODIFICAR A RÉPLICA EM

Modifica qualquer uma das réplicas do grupo de disponibilidade. A lista de réplicas a modificar contém o endereço da instância do servidor e uma WITH (...) cláusula para cada réplica.

Suportado apenas na réplica primária.

REMOVER RÉPLICA EM

Remove a réplica secundária especificada do grupo de disponibilidade. Não podes remover a réplica principal atual de um grupo de disponibilidade. Quando removes uma réplica, ela deixa de receber dados. As bases de dados secundárias da réplica são removidas do grupo de disponibilidade e entram no RESTORING estado.

Suportado apenas na réplica primária.

Observação

Se remover uma réplica enquanto está indisponível ou falhou, quando ela volta a funcionar descobre que já não pertence ao grupo de disponibilidade.

ADERIR

Faz com que a instância do servidor local hospede uma réplica secundária no grupo de disponibilidade especificado.

Suportado apenas numa réplica secundária que ainda não está ligada ao grupo de disponibilidade.

Para mais informações, consulte Juntar uma réplica secundária a um grupo de disponibilidade Sempre Ligado.

ATIVAÇÃO PÓS-FALHA

Inicia um failover manual do grupo de disponibilidade sem perda de dados para a réplica secundária à qual você está conectado. A réplica que hospeda a réplica primária é o alvo de failover. O alvo de failover assume o papel principal e recupera a sua cópia de cada base de dados, colocando-as online como as novas bases de dados primárias. A réplica primária anterior transita simultaneamente para a função secundária e seus bancos de dados se tornam bancos de dados secundários e são imediatamente suspensos. Potencialmente, estes papéis podem alternar devido a uma série de falhas.

O failover é suportado apenas para uma réplica secundária de commit síncrono que esteja atualmente sincronizada com a réplica primária. Para que uma réplica secundária seja sincronizada, a réplica primária também deve estar em execução no modo de confirmação síncrona.

Para duas instâncias do SQL Server em um grupo de disponibilidade, você pode emitir o comando failover na réplica primária ou secundária. Para as instâncias replicadas através do link da Instância Gerida, deve emitir o comando de failover na réplica principal.

Observação

Para um grupo de disponibilidade, um comando de failover retorna assim que o alvo de failover aceita o comando. No entanto, a recuperação da base de dados ocorre de forma assíncrona após o grupo de disponibilidade terminar de falhar.
Para um failover de ligação de Instância Gerida, o comando de failover retorna após um failover bem-sucedido em que a origem e o destino trocam de funções, ou se o comando failover falhar após as verificações de pré-condição de failover.
Não pode usar o comando de failover para um failover planeado de um grupo de disponibilidade distribuído entre duas instâncias SQL Server.

Para informações sobre as limitações, pré-requisitos e recomendações para realizar um failover manual planeado, veja Realizar um failover manual planeado de um grupo de disponibilidade Always On (SQL Server).

FORCE_FAILOVER_ALLOW_DATA_LOSS

Atenção

Só inicie um failover forçado como medida de recuperação de desastres, pois pode resultar em perda de dados. O failover forçado deve ser realizado apenas quando a réplica principal não estiver disponível, estiver preparado para aceitar uma possível perda de dados e deve restaurar o serviço ao grupo de disponibilidade imediatamente.

Suportado apenas numa réplica cujo papel é no SECONDARY estado de ourives RESOLVING . A réplica em que introduz um comando de failover é o alvo do failover.

Força o failover do grupo de disponibilidade, com possível perda de dados, para o destino de failover. O alvo de failover assume o papel principal e recupera a sua cópia de cada base de dados, colocando-as online como as novas bases de dados primárias. Em todas as réplicas secundárias restantes, cada banco de dados secundário é suspenso até ser retomado manualmente. Quando a antiga réplica primária fica disponível, esta passa para o papel secundário, e as suas bases de dados tornam-se bases de dados secundárias suspensas.

Para instâncias replicadas através do link de Instância Gerida, deve emitir o FORCE_FAILOVER_ALLOW_DATA_LOSS comando na réplica secundária (o alvo de failover).

Observação

Um comando de failover retorna assim que o alvo de failover aceita o comando. No entanto, a recuperação da base de dados ocorre de forma assíncrona após o grupo de disponibilidade terminar de falhar.

Para informações sobre as limitações, pré-requisitos e recomendações para forçar o failover e o efeito de um failover forçado nas antigas bases de dados primárias do grupo de disponibilidade, consulte Executar um failover manual forçado de um grupo de disponibilidade Sempre Ligado (SQL Server).

ADICIONAR OUVINTE 'dns_name' ( <add_listener_option> )

Define um novo ouvinte do grupo de disponibilidade para esse grupo de disponibilidade. Suportado apenas na réplica primária.

Importante

Antes de criares o teu primeiro ouvinte, lê Configurar um ouvinte para um grupo de disponibilidade Always On.

Depois de criar um ouvinte para um dado grupo de disponibilidade, faça os seguintes passos:

Peça ao administrador da rede para reservar o endereço IP do ouvinte para seu uso exclusivo.
Forneça o nome de host DNS do ouvinte aos desenvolvedores de aplicativos para usar em cadeias de conexão ao solicitar conexões de cliente para esse grupo de disponibilidade.

dns_name

Especifica o nome do host DNS do ouvinte do grupo de disponibilidade. O nome DNS do ouvinte deve ser exclusivo no domínio e no NetBIOS.

dns_name é um valor de cadeia de caracteres. Este nome pode conter apenas caracteres alfanuméricos, traços (-) e hífenes (_), em qualquer ordem. Os nomes de host DNS não diferenciam maiúsculas de minúsculas. O comprimento máximo é de 63 caracteres.

Especifique uma sequência significativa. Por exemplo, para um grupo de disponibilidade chamado AG1, um nome de host DNS significativo seria ag1-listener.

Importante

O NetBIOS reconhece apenas os primeiros 15 caracteres no dns_namearquivo . Se tiver dois clusters WSFC controlados pelo mesmo Active Directory e tentar criar ouvintes de grupos de disponibilidade em ambos os clusters usando nomes com mais de 15 caracteres e um prefixo idêntico de 15 caracteres, recebe um erro a informar que o recurso de Nome da Rede Virtual não pôde ser ativado. Para obter informações sobre regras de nomenclatura de prefixo para nomes DNS, consulte Atribuindo nomes de domínio.

JUNTE-SE AO GRUPO DE DISPONIBILIDADE EM

Junta-se a um grupo de disponibilidade distribuída . Quando crias um grupo de disponibilidade distribuído, o grupo de disponibilidade no cluster onde o crias é o grupo principal de disponibilidade. O grupo de disponibilidade que se junta ao grupo de disponibilidade distribuída é o grupo de disponibilidade secundário.

<ag_name>

Especifica o nome do grupo de disponibilidade que compõe metade do grupo de disponibilidade distribuída.

OUVINTE = 'TCP:// endereço:portasistema'

Especifica o caminho da URL para o ouvinte associado ao grupo de disponibilidade.

A LISTENER cláusula é obrigatória.

'TCP:// endereço:sistemaporta'

Especifica uma URL para o ouvinte associado ao grupo de disponibilidade. Os parâmetros de URL são os seguintes:

de endereço do sistema

Uma cadeia de caracteres, como um nome de sistema, um nome de domínio totalmente qualificado ou um endereço IP, que identifica inequivocamente o ouvinte.

porto

Um número de porta associado ao endpoint de espelhamento do grupo de disponibilidade. Isto não é o port do ouvinte.

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

Especifica se a réplica primária espera que o grupo de disponibilidade secundária reconheça o endurecimento (escrita) dos registos de registo no disco antes de a réplica primária poder comprometer a transação numa dada base de dados primária.

SYNCHRONOUS_COMMIT

Especifica que a réplica primária aguarda para confirmar transações até receber confirmação de que as transações estão reforçadas no grupo de disponibilidade secundário. Pode especificar SYNCHRONOUS_COMMIT até dois grupos de disponibilidade, incluindo o grupo principal de disponibilidade.

ASYNCHRONOUS_COMMIT

Especifica que a réplica primária confirma transações sem esperar que esse grupo de disponibilidade secundário proteja o log. Pode especificar ASYNCHRONOUS_COMMIT até dois grupos de disponibilidade, incluindo o grupo principal de disponibilidade.

A AVAILABILITY_MODE cláusula é obrigatória.

FAILOVER_MODE = { MANUAL }

Especifica o modo de failover do grupo de disponibilidade distribuído.

MANUAL

Permite o failover manual planejado ou o failover manual forçado (normalmente chamado de failover forçado) pelo administrador do banco de dados.

Não há suporte para failover automático para o grupo de disponibilidade secundário.

SEEDING_MODE = { AUTOMÁTICO | MANUAL }

Especifica como o grupo de disponibilidade secundário é inicialmente propagado.

AUTOMÁTICO

Permite a propagação automática. Este método semeia o grupo de disponibilidade secundária na rede. Esse método não exige que você faça backup e restaure uma cópia do banco de dados primário nas réplicas do grupo de disponibilidade secundário.

MANUAL

Especifica a propagação manual. Este método exige que crie uma cópia de segurança da base de dados na réplica principal e restaure manualmente essa cópia de segurança nas réplicas do grupo de disponibilidade secundário.

MODIFICAR O GRUPO DE DISPONIBILIDADE EM

Modifica qualquer uma das configurações do grupo de disponibilidade de um grupo de disponibilidade distribuído. A lista de grupos de disponibilidade a modificar contém o nome do grupo de disponibilidade e uma WITH (...) cláusula para cada grupo de disponibilidade.

Importante

Deve executar este comando tanto nas instâncias do grupo primário de disponibilidade como no grupo secundário de disponibilidade.

CONCEDER A CRIAÇÃO DE QUALQUER BANCO DE DADOS

Permite ao grupo de disponibilidade criar bases de dados em nome da réplica primária, o que suporta seed direta (SEEDING_MODE = AUTOMATIC). Execute este parâmetro em todas as réplicas secundárias que suportem seed direta depois de essa secundária se juntar ao grupo de disponibilidade. Requer a permissão de CREATE ANY DATABASE.

NEGAR A CRIAÇÃO DE QUALQUER BANCO DE DADOS

Remove a capacidade do grupo de disponibilidade de criar bancos de dados em nome da réplica primária.

<add_listener_option>

ADD LISTENER Escolhe uma das seguintes opções:

COM DHCP [ EM { ('four_part_ipv4_address'',four_part_ipv4_mask') } ]

Especifica que o ouvinte do grupo de disponibilidade usa o protocolo DHCP (Dynamic Host Configuration Protocol). Opcionalmente, use a ON cláusula para identificar a rede onde este ouvinte é criado. O DHCP está limitado a uma única sub-rede usada para cada instância de servidor que aloja uma réplica de disponibilidade no grupo de disponibilidade.

Importante

Não use DHCP em um ambiente de produção. Se houver tempo de inatividade e o arrendamento IP DHCP expirar, é necessário tempo extra para registar o novo endereço IP de rede DHCP associado ao nome DNS do ouvinte e que afeta a conectividade do cliente. No entanto, o DHCP é bom para configurar seu ambiente de desenvolvimento e teste para verificar funções básicas de grupos de disponibilidade e para integração com seus aplicativos.

Por exemplo:

WITH DHCP ON ('10.120.19.0','255.255.254.0')

COM IP ( { ('four_part_ipv4_address','four_part_ipv4_mask') | ('ipv6_address') } [ , ... n ] ) [ , PORTA = listener_port ]

Em vez de usar DHCP, o ouvinte do grupo de disponibilidade utiliza um ou mais endereços IP estáticos. Para criar um grupo de disponibilidade em várias sub-redes, cada sub-rede requer um endereço IP estático na configuração do ouvinte. Para uma determinada sub-rede, o endereço IP estático pode ser um endereço IPv4 ou um endereço IPv6. Contacte o seu administrador de rede para obter um endereço IP estático para cada sub-rede que aloja uma réplica de disponibilidade para o novo grupo de disponibilidade.

Por exemplo:

WITH IP ( ('10.120.19.155','255.255.254.0') )

ipv4_address

Um endereço IPv4 de quatro partes para um ouvinte de grupo de disponibilidade. Por exemplo, 10.120.19.155.

ipv4_mask

Uma máscara IPv4 de quatro partes para um ouvinte de grupo de disponibilidade. Por exemplo, 255.255.254.0.

ipv6_address

Um endereço IPv6 para um ouvinte de grupo de disponibilidade. Por exemplo, 2001::4898:23:1002:20f:1fff:feff:b3a3.

PORTA = listener_port

O número de porta (listener_port) a usar por um ouvinte de grupo de disponibilidade que a WITH IP cláusula especifica. PORT é opcional.

O número de porta padrão, 1433, é suportado. No entanto, pode escolher um número de porta diferente.

Por exemplo: WITH IP ( ('2001::4898:23:1002:20f:1fff:feff:b3a3') ) , PORT = 7777

MODIFICAR OUVINTE 'dns_name' ( <modify_listener_option> )

Modifica um ouvinte de grupo de disponibilidade existente para esse grupo de disponibilidade. Suportado apenas na réplica primária.

<modify_listener_option>

MODIFY LISTENER Escolhe uma das seguintes opções:

ADD IP { ('four_part_ipv4_address','four_part_ipv4_mask') | ('ipv6_address') }

Adiciona o endereço IP especificado ao ouvinte do grupo de disponibilidade especificado por dns_name.

PORTA = listener_port

Consulte a descrição deste argumento anteriormente nesta seção.

REMOVER IP { ('four_part_ipv4_address') | ('ipv6_address') }

Aplica-se a: SQL Server 2025 (17.x) e versões posteriores

Remove o endereço IP especificado do ouvinte do grupo de disponibilidade especificado.

REINICIAR OUVINTE 'dns_name'

Reinicia o ouvinte associado ao nome DNS especificado. Suportado apenas na réplica primária.

REMOVER OUVINTE 'dns_name'

Remove o ouvinte associado ao nome DNS especificado. Suportado apenas na réplica primária.

Offline

Coloca um grupo de disponibilidade online offline. Não há perda de dados para bancos de dados de confirmação síncrona.

Quando um grupo de disponibilidade fica offline, as suas bases de dados tornam-se indisponíveis para os clientes e não pode voltar a pôr o grupo de disponibilidade online. Por isso, use a OFFLINE opção apenas durante uma migração entre clusters de grupos de disponibilidade Always On, quando estiver a migrar recursos de grupos de disponibilidade para um novo cluster WSFC.

Para obter mais informações, consulte colocar um grupo de disponibilidade offline (SQL Server).

Pré-requisitos e restrições

Para informações sobre pré-requisitos e restrições sobre réplicas de disponibilidade e sobre as suas instâncias e computadores do servidor anfitrião, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On.

Para informações sobre restrições às AVAILABILITY GROUP instruções Transact-SQL, consulte Transact-SQL instruções para grupos de disponibilidade Always On.

Permissões

Precisas ALTER AVAILABILITY GROUP de permissão para o grupo de disponibilidade, CONTROL AVAILABILITY GROUP permissão, ALTER ANY AVAILABILITY GROUP permissão ou CONTROL SERVER permissão. Também precisas de ALTER ANY DATABASE permissão.

Exemplos

Um. Associar uma réplica secundária a um grupo de disponibilidade

O exemplo a seguir une uma réplica secundária à qual você está conectado ao grupo de disponibilidade AccountsAG.

ALTER AVAILABILITY GROUP AccountsAG JOIN;
GO

B. Forçar o failover de um grupo de disponibilidade

O exemplo a seguir força o grupo de disponibilidade AccountsAG a fazer failover para a réplica secundária à qual você está conectado.

ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
GO

C. Forçar criptografia em conexões com o grupo de disponibilidade

Os exemplos nesta secção forçam encriptação nas ligações ao AccountsAG grupo de disponibilidade.

Se o nome do servidor aparecer em cada certificado, conforme definido por qualquer um dos métodos, pode omitir a HostNameInCertificate opção:

ALTER AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict')

Se seguiu o método 1 mas não listou o nome do servidor como Nome Alternativo de Sujeito no certificado, deve especificar o valor que aparece no Nome Alternativo de Sujeito na HostNameInCertificate opção:

ALTER AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict;HostNameInCertificate=<Subject Alternative Name>')

Se seguiu o método 1 e pretende usar a ServerCertificate propriedade em vez de fornecer um valor para HostNameInCertificate:

ALTER AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict;ServerCertificate=C:\Users\admin\SqlAGCertificate.cer')

Feedback

Esta página foi útil?

Last updated on 2026-01-06

Partilhar via

GRUPO DE DISPONIBILIDADE ALTER (Transact-SQL)

Sintaxe

Argumentos

group_name

AUTOMATED_BACKUP_PREFERENCE = { PRIMÁRIO | SECONDARY_ONLY| SECUNDÁRIO | NENHUM }

PRIMÁRIO

SECONDARY_ONLY

SECUNDÁRIO

NENHUM

FAILURE_CONDITION_LEVEL = { 1 | 2 | 3 | 4 | 5 }

HEALTH_CHECK_TIMEOUT = milissegundos

DB_FAILOVER = { EM | DESLIGADO }

DTC_SUPPORT = { PER_DB | NENHUM }

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

FUNÇÕES

CLUSTER_CONNECTION_OPTIONS

ADICIONAR database_name DE BANCO DE DADOS

REMOVER database_name BANCO DE DADOS

ADICIONAR RÉPLICA EM

<server_instance>

system_name

FCI_network_name

instance_name

\

ENDPOINT_URL = '*TCP:// endereço:*sistemaporta'

«TCP://endereço do sistema:port»

de endereço do sistema

porto

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

CONFIGURATION_ONLY

FAILOVER_MODE = { AUTOMÁTICO | MANUAL }

AUTOMÁTICO

MANUAL

SEEDING_MODE = { AUTOMÁTICO | MANUAL }

AUTOMÁTICO

MANUAL

BACKUP_PRIORITY = n

SECONDARY_ROLE ( ... )

ALLOW_CONNECTIONS = { NÃO | READ_ONLY | TODOS }

NÃO

READ_ONLY

TUDO

READ_ONLY_ROUTING_URL = { '*TCP:// sistema-endereço:*porta' | NENHUM }

PRIMARY_ROLE ( ... )

ALLOW_CONNECTIONS = { READ_WRITE | TODOS }

LEITURA_ESCRITA

TUDO

READ_ONLY_ROUTING_LIST = { ('<server_instance>' [ , ... n ] ) | NENHUM }

<server_instance>

NENHUM

{ READ_WRITE_ROUTING_URL = '*TCP:// endereço-sistema:*porta' | NENHUM }

SESSION_TIMEOUT = segundos

MODIFICAR A RÉPLICA EM

REMOVER RÉPLICA EM

ADERIR

ATIVAÇÃO PÓS-FALHA

FORCE_FAILOVER_ALLOW_DATA_LOSS

ADICIONAR OUVINTE 'dns_name' ( <add_listener_option> )

dns_name

JUNTE-SE AO GRUPO DE DISPONIBILIDADE EM

<ag_name>

OUVINTE = '*TCP:// endereço:*portasistema'

'*TCP:// endereço:*sistemaporta'

de endereço do sistema

porto

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

FAILOVER_MODE = { MANUAL }

MANUAL

SEEDING_MODE = { AUTOMÁTICO | MANUAL }

AUTOMÁTICO

MANUAL

MODIFICAR O GRUPO DE DISPONIBILIDADE EM

CONCEDER A CRIAÇÃO DE QUALQUER BANCO DE DADOS

NEGAR A CRIAÇÃO DE QUALQUER BANCO DE DADOS

<add_listener_option>

`HEALTH_CHECK_TIMEOUT` = milissegundos

ENDPOINT_URL = 'TCP:// endereço:sistemaporta'

READ_ONLY_ROUTING_URL = { 'TCP:// sistema-endereço:porta' | NENHUM }

{ READ_WRITE_ROUTING_URL = 'TCP:// endereço-sistema:porta' | NENHUM }

OUVINTE = 'TCP:// endereço:portasistema'

'TCP:// endereço:sistemaporta'