ALTER AVAILABILITY GROUP (Transact-SQL)

Si applica a:SQL Server

Modifica un gruppo di disponibilità Always On esistente in SQL Server. La maggior parte ALTER AVAILABILITY GROUP degli argomenti è supportata solo nella replica primaria corrente. Tuttavia, gli JOINargomenti , FAILOVERe FORCE_FAILOVER_ALLOW_DATA_LOSS sono supportati solo nelle repliche secondarie.

Convenzioni relative alla sintassi Transact-SQL

Sintassi

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')
    }

Argomenti

group_name

Specifica il nome del nuovo gruppo di disponibilità. group_name deve essere un identificatore di SQL Server valido e deve essere univoco in tutti i gruppi di disponibilità nel cluster WSFC.

AUTOMATED_BACKUP_PREFERENCE = { PRIMARIO | SECONDARY_ONLY| SECONDARIO | NESSUNO }

Specifica una preferenza sul modo in cui un processo di backup valuta la replica primaria quando si sceglie dove eseguire i backup. È possibile generare uno script affinché un processo di backup specifico prenda in considerazione le preferenze di backup automatico. È importante comprendere che la preferenza non viene applicata da SQL Server, di conseguenza non ha alcun impatto sui backup ad hoc.

Supportato solo nella replica primaria.

Sono disponibili i valori seguenti:

PRIMARIO

Specifica che i backup vengono sempre eseguiti nella replica primaria. Questa opzione è utile se sono necessarie funzionalità di backup, ad esempio la creazione di backup differenziali, che non sono supportate durante l'esecuzione del backup in una replica secondaria.

Importante

Se si prevede di usare il log shipping per preparare i database secondari per un gruppo di disponibilità, impostare la preferenza di backup automatizzato su Primary finché tutti i database secondari non vengono preparati e aggiunti al gruppo di disponibilità.

SECONDARY_ONLY

Specifica che i backup non vengono mai eseguiti nella replica primaria. Se la replica primaria è l'unica replica online, il backup non viene eseguito.

SECONDARIO

Specifica che i backup vengono eseguiti in una replica secondaria tranne quando la replica primaria è l'unica replica online. In tal caso, il backup viene eseguito nella replica primaria. Questo è il comportamento predefinito.

NESSUNO

Specifica che si preferisce che i processi di backup ignorino il ruolo delle repliche di disponibilità nella scelta della replica per l'esecuzione dei backup. Si noti che i processi di backup potrebbero valutare altri fattori, ad esempio la priorità di backup di ogni replica di disponibilità in combinazione con lo stato operativo e lo stato connesso.

Importante

Non esiste alcuna imposizione dell'impostazione AUTOMATED_BACKUP_PREFERENCE . L'interpretazione di questa preferenza dipende dalla logica, se presente, che si esegue lo script nei processi di backup per i database in un determinato gruppo di disponibilità. L'impostazione delle preferenze di backup automatizzato non ha alcun effetto sui backup ad hoc. Per altre informazioni, vedere Configurare i backup nelle repliche secondarie di un gruppo di disponibilità AlwaysOn.

Nota

Per visualizzare la preferenza di backup automatizzato di un gruppo di disponibilità esistente, selezionare la automated_backup_preference colonna o automated_backup_preference_desc della vista del catalogo sys.availability_groups . Inoltre, è possibile usare sys.fn_hadr_backup_is_preferred_replica per determinare la replica di backup preferita. Questa funzione restituisce 1 sempre per almeno una delle repliche, anche quando AUTOMATED_BACKUP_PREFERENCE = NONE.

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

Specifica le condizioni di errore che attivano un failover automatico per il gruppo di disponibilità. FAILURE_CONDITION_LEVEL è impostato a livello di gruppo, ma è rilevante solo nelle repliche di disponibilità configurate per la modalità di disponibilità con commit sincrono (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). Inoltre, le condizioni di errore possono attivare un failover automatico solo se entrambe le repliche primarie e secondarie sono configurate per la modalità di failover automatico (FAILOVER_MODE = AUTOMATIC) e la replica secondaria è attualmente sincronizzata con la replica primaria.

Supportato solo nella replica primaria.

I livelli delle condizioni di errore (1-5) vanno dal livello 1, meno restrittivo, al livello 5, più restrittivo. Un livello della condizione specifico include tutti i livelli meno restrittivi. Il livello della condizione più restrittivo, ovvero il livello 5, include pertanto i quattro livelli della condizione meno restrittivi (1-4), il livello 4 include i livelli 1-3 e così via. Nella tabella seguente viene descritta la condizione di errore corrispondente a ogni livello.

Livello	Condizione di errore
1	Specifica che viene avviato un failover automatico quando si verifica una delle operazioni seguenti: Indisponibilità del servizio SQL Server. Il lease del gruppo di disponibilità per la connessione al cluster WSFC scade perché non `ACK` viene ricevuto dall'istanza del server. Per altre informazioni, vedere Funzionamento: timeout lease di SQL Server Always On.
2	Specifica che viene avviato un failover automatico quando si verifica una delle operazioni seguenti: L'istanza di SQL Server non si connette al cluster e viene superata la soglia specificata `HEALTH_CHECK_TIMEOUT` dall'utente del gruppo di disponibilità. La replica di disponibilità si trova in uno stato di errore.
3	Specifica che un failover automatico viene avviato su errori interni critici di SQL Server, ad esempio spinlock orfani, gravi violazioni dell'accesso in scrittura o un dump eccessivo. Questo è il comportamento predefinito.
4	Specifica che un failover automatico viene avviato in caso di errori interni di SQL Server moderati, ad esempio una condizione persistente di memoria insufficiente nel pool di risorse interno di SQL Server.
5	Specifica che un failover automatico viene avviato in tutte le condizioni di errore qualificate, tra cui: Esaurimento dei thread di lavoro del motore SQL. Rilevamento di un deadlock irrisolvibile.

Nota

La mancanza di risposta da parte di un'istanza di SQL Server alle richieste client non è rilevante per i gruppi di disponibilità.

I FAILURE_CONDITION_LEVEL valori e HEALTH_CHECK_TIMEOUT definiscono un criterio di failover flessibile per un determinato gruppo. fornendo un controllo granulare sulle condizioni che devono causare un failover automatico. Per altre informazioni, vedere Configurare un criterio di failover automatico flessibile per un gruppo di disponibilità AlwaysOn.

`HEALTH_CHECK_TIMEOUT` = Millisecondi

Specifica il tempo di attesa, espresso in millisecondi, affinché la stored procedure di sistema sp_server_diagnostics restituisca informazioni sull'integrità del server prima del cluster WSFC presuppone che l'istanza del server sia lenta o non risponda. Impostare HEALTH_CHECK_TIMEOUT a livello di gruppo, ma è rilevante solo nelle repliche di disponibilità configurate per la modalità di disponibilità con commit sincrono con failover automatico (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). Inoltre, un timeout del controllo integrità può attivare un failover automatico solo se le repliche primarie e secondarie sono configurate per la modalità di failover automatico (FAILOVER_MODE = AUTOMATIC) e la replica secondaria è attualmente sincronizzata con la replica primaria.

Il valore predefinito HEALTH_CHECK_TIMEOUT è 30.000 millisecondi (30 secondi). Il valore minimo è 15.000 millisecondi (15 secondi) e il valore massimo è 4.294.967.295 millisecondi.

Supportato solo nella replica primaria.

Importante

sp_server_diagnostics non esegue controlli di integrità a livello di database.

DB_FAILOVER = { ACCESO | SPENTO }

Specifica la risposta da accettare quando un database nella replica primaria è offline. Se impostato su ON, qualsiasi stato diverso da ONLINE per un database nel gruppo di disponibilità attiva un failover automatico. Quando si imposta questa opzione su OFF, solo l'integrità dell'istanza attiva il failover automatico.

Per altre informazioni su questa impostazione, vedere Opzione di failover di rilevamento dell'integrità a livello di database del gruppo di disponibilità.

DTC_SUPPORT = { PER_DB | NESSUNO }

Specifica se le transazioni distribuite sono abilitate per questo gruppo di disponibilità. Le transazioni distribuite sono supportate solo per i database del gruppo di disponibilità a partire da SQL Server 2016 (13.x) e le transazioni tra database sono supportate solo a partire da SQL Server 2016 (13.x) SP2. PER_DB crea il gruppo di disponibilità con supporto per queste transazioni e promuove automaticamente transazioni tra database che coinvolgono database nel gruppo di disponibilità in transazioni distribuite. NONE impedisce la promozione automatica delle transazioni tra database alle transazioni distribuite e non registra il database con un RMID stabile in DTC. Le transazioni distribuite non vengono impedite quando viene usata l'impostazione NONE, ma il failover del database e il ripristino automatico potrebbero non riuscire in alcune circostanze. Per altre informazioni, vedere Transazioni - gruppi di disponibilità e mirroring del database.

Nota

Il supporto per la modifica dell'impostazione DTC_SUPPORT di un gruppo di disponibilità è stato introdotto in SQL Server 2016 (13.x) Service Pack 2. Questa opzione non può essere usata con le versioni precedenti. Per modificare questa impostazione nelle versioni precedenti di SQL Server, è necessario DROP e CREATE di nuovo il gruppo di disponibilità.

Importante

DTC ha un limite di 32 inserimenti per ogni transazione distribuita. Poiché ogni database all'interno di un gruppo di disponibilità si integra separatamente con DTC, se la transazione include più di 32 database, è possibile ottenere l'errore seguente quando SQL Server tenta di integrare il 33° database:

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.

Per altre informazioni sulle transazioni distribuite in SQL Server, vedere Transazioni distribuite.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Introdotto in SQL Server 2017 (14.x). Imposta un numero minimo di repliche secondarie sincrone necessarie per il commit prima del commit della replica primaria. Garantisce che le transazioni di SQL Server attendano l'aggiornamento dei log delle transazioni sul numero minimo di repliche secondarie.

Predefinito: 0. Fornisce lo stesso comportamento di SQL Server 2016 (13.x).
Minimo: 0.
Massimo: numero di repliche meno 1.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT si riferisce alle repliche in modalità commit sincrono. Quando le repliche sono in modalità commit sincrono, le scritture nella replica primaria attendono fino a quando le scritture nelle repliche sincrone eseguono il commit nel log delle transazioni del database di replica. Se un'istanza di SQL Server che ospita una replica sincrona secondaria smette di rispondere, SQL Server che ospita la replica primaria contrassegna la replica secondaria come NOT SYNCHRONIZED e procede. Quando il database non risponde torna online, si trova in uno stato "non sincronizzato" e la replica viene contrassegnata come non integra fino a quando il database primario non può eseguire di nuovo la sincronizzazione. Questa impostazione garantisce che la replica primaria non procede finché non viene eseguito il commit del numero minimo di repliche. Se il numero minimo di repliche non è disponibile, i commit nel database primario hanno esito negativo. Per il tipo di cluster EXTERNAL l'impostazione viene modificata quando il gruppo di disponibilità viene aggiunto a una risorsa cluster. Vedere Elevata disponibilità e protezione dei dati per le configurazioni di gruppo di disponibilità.

A partire da SQL Server 2022 (16.x), è possibile impostare REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT in un gruppo di disponibilità distribuito. Questa impostazione non è supportata per CREATE AVAILABILITY GROUP. È possibile usare ALTER AVAILABILITY GROUP per impostare REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Ad esempio:

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

RUOLO

L'unico parametro valido è SECONDARYe questa SET opzione è valida solo nei gruppi di disponibilità distribuiti. Usarlo per eseguire il failover di un gruppo di disponibilità distribuito.

CLUSTER_CONNECTION_OPTIONS

Si applica a: SQL Server 2025 (17.x) e versioni successive

Usare la clausola per applicare la CLUSTER_CONNECTION_OPTIONS crittografia TLS 1.3 per la comunicazione tra il cluster di failover di Windows Server e le repliche del gruppo di disponibilità. Specificare le opzioni come elenco di coppie chiave-valore, separate da punti e virgola. Usare le coppie chiave-valore per configurare la crittografia delle stringhe di connessione per il gruppo di disponibilità.

Per ripristinare la crittografia predefinita, impostare la CLUSTER_CONNECTION_OPTIONS clausola su una stringa vuota. SQL Server 2025 (17.x) predefinito su Encrypt=Mandatory, e TrustServerCertificate=Yes per le connessioni alle repliche del gruppo di disponibilità e agli ascoltatori.

Per altre informazioni, vedere Connettersi a un gruppo di disponibilità con crittografia rigorosa e TDS 8.0.

Nella tabella seguente vengono descritte le coppie chiave-valore che è possibile usare nella CLUSTER_CONNECTION_OPTIONS clausola :

Key	Valori supportati	Description
`Encrypt`	`Mandatory`, `Strict`, `Optional`	Specifica come viene applicata la crittografia per il gruppo di disponibilità. Se il server non supporta la crittografia, la connessione non riesce. Se si imposta la crittografia su `Mandatory`, è `TrustServerCertificate` necessario impostare su Sì. Se si imposta la crittografia su `Strict`, `TrustServerCertificate` viene ignorata. Nota: questa coppia chiave-valore è obbligatoria.
`HostNameInCertificate`	Nome della replica o nome del listener del gruppo di disponibilità	Specifica il nome del listener del gruppo di disponibilità o il nome del listener del gruppo di disponibilità nel certificato usato per la crittografia. Questo valore deve corrispondere al valore nel nome alternativo soggetto del certificato. Se il nome del server è elencato nel certificato, è possibile omettere la `HostNameInCertificate` coppia chiave-valore. Se il nome del server non è elencato nel certificato, è necessario specificare la `HostNameInCertificate` coppia chiave-valore con il nome del server. Nota: questa coppia di valori chiave è facoltativa.
`TrustServerCertificate`	`Yes`, `No`	Impostare su `yes` per specificare che il driver non convalida il certificato TLS/SSL del server. Se `no`, il driver convalida il certificato. Per altre informazioni, vedere TDS 8.0. Nota: questa coppia di valori chiave è facoltativa.
`ServerCertificate`	Percorso del certificato	Se non si vuole usare `HostNameInCertificate`, è possibile passare il percorso al certificato. L'account del servizio cluster deve disporre dell'autorizzazione per leggere il certificato dal percorso specificato. Nota: questa coppia di valori chiave è facoltativa.
`CLUSTER_CONNECTION_OPTIONS`	Stringa vuota (`''`)	Cancella la configurazione esistente e ripristina le impostazioni di crittografia predefinite di `Encrypt=Mandatory` e `TrustServerCertificate=Yes`.

Vedere gli esempi per informazioni su come usare la CLUSTER_CONNECTION_OPTIONS clausola .

AGGIUNGI database_name DATABASE

Specifica un elenco di uno o più database utente che si desidera aggiungere al gruppo di disponibilità. Tali database devono risiedere nell'istanza di SQL Server in cui è ospitata la replica primaria corrente. È possibile specificare più database per un gruppo di disponibilità, ma ogni database può appartenere a un solo gruppo di disponibilità. Per informazioni sul tipo di database che un gruppo di disponibilità può supportare, vedere Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn. Per scoprire quali database locali appartengono già a un gruppo di disponibilità, vedere la replica_id colonna nella vista del catalogo sys.databases .

Supportato solo nella replica primaria.

Nota

Dopo aver creato il gruppo di disponibilità, è necessario connettersi a ogni istanza del server che ospita una replica secondaria. Preparare quindi ogni database secondario e aggiungerlo al gruppo di disponibilità. Per altre informazioni, vedere Avviare lo spostamento dati su un database secondario Always On (SQL Server).

RIMUOVERE database_name DATABASE

Rimuove il database primario specificato e i database secondari corrispondenti dal gruppo di disponibilità. Supportato solo nella replica primaria.

Per informazioni sui passaggi consigliati dopo la rimozione di un database di disponibilità da un gruppo di disponibilità, vedere Rimuovere un database primario da un gruppo di disponibilità AlwaysOn.

AGGIUNGI REPLICA SU

Specifica da una a otto istanze di SQL Server per ospitare repliche secondarie in un gruppo di disponibilità. Ogni replica viene specificata dall'indirizzo dell'istanza del server seguito da una WITH (...) clausola .

Supportato solo nella replica primaria.

È necessario creare un join di ogni nuova replica secondaria al gruppo di disponibilità. Per altre informazioni, vedere la descrizione dell'opzione JOIN , più avanti in questa sezione.

<server_instance>

Specifica l'indirizzo dell'istanza di SQL Server che è l'host per una replica. Il formato dell'indirizzo dipende dal fatto che l'istanza sia l'istanza predefinita o un'istanza denominata e che si tratti di un'istanza autonoma o di un'istanza del cluster di failover. La sintassi è la seguente:

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

I componenti di questo indirizzo sono i seguenti:

_sistema

Nome NetBIOS del sistema computer in cui risiede l'istanza di destinazione di SQL Server. Il computer deve essere un nodo WSFC.

nome_rete_FCI

Nome di rete usato per accedere a un cluster di failover di SQL Server. Usare questo nome se l'istanza del server partecipa come partner di failover di SQL Server. L'esecuzione SELECT @@SERVERNAME in un'istanza del server FCI restituisce l'intera stringa "FCI_network_name[\instance_name]" (ovvero il nome completo della replica).

Per altre informazioni, vedere @@SERVERNAME.

instance_name

Nome di un'istanza di SQL Server che system_name o FCI_network_name host e che dispone di AlwaysOn abilitato. Per un'istanza del server predefinita, nome_istanza è facoltativo. Per il nome dell'istanza non viene fatta distinzione tra maiuscole e minuscole. In un'istanza del server autonoma, questo nome di valore corrisponde al valore restituito eseguendo SELECT @@SERVERNAME.

\

Separatore utilizzato solo quando si specifica instance_name, per separarlo da system_name o FCI_network_name.

Per informazioni sui prerequisiti per i nodi WSFC e le istanze del server, vedere Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn.

ENDPOINT_URL = 'TCP:// system-address:port'

Specifica il percorso URL per l'endpoint del mirroring del database nell'istanza di SQL Server che ospita la replica di disponibilità che si sta aggiungendo o modificando.

ENDPOINT_URL è obbligatorio nella ADD REPLICA ON clausola e facoltativo nella MODIFY REPLICA ON clausola . Per altre informazioni, vedere Specificare l'URL dell'endpoint - Aggiunta o modifica della replica di disponibilità.

'TCP:// system-address:port'

Specifica un URL per definire un URL di endpoint o un URL di routing di sola lettura. I parametri URL sono i seguenti:

indirizzo di sistema

Stringa, ad esempio un nome di sistema, un nome di dominio completo o un indirizzo IP, che identifica in modo univoco il sistema del computer di destinazione.

porto

Numero di porta associato all'endpoint del mirroring dell'istanza del server (per l'opzione ENDPOINT_URL ) o al numero di porta utilizzato dal motore di database dell'istanza del server (per l'opzione READ_ONLY_ROUTING_URL ).

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

Specifica se la replica primaria attende che la replica secondaria riconosca la protezione avanzata (scrittura) dei record di log su disco prima che la replica primaria possa eseguire il commit della transazione in un determinato database primario. Il commit delle transazioni in database diversi della stessa replica primaria può essere eseguito indipendentemente.

SYNCHRONOUS_COMMIT

Specifica che la replica primaria attende il commit delle transazioni fino a quando non viene avanzata in questa replica secondaria (modalità con commit sincrono). È possibile specificare SYNCHRONOUS_COMMIT fino a tre repliche, inclusa la replica primaria.

ASYNCHRONOUS_COMMIT

Specifica che la replica primaria esegue il commit delle transazioni senza attendere la finalizzazione del log da parte della replica secondaria (modalità di disponibilità con commit sincrono). È possibile specificare ASYNCHRONOUS_COMMIT fino a cinque repliche di disponibilità, inclusa la replica primaria.

CONFIGURATION_ONLY

Specifica che i metadati di configurazione del gruppo di disponibilità con commit sincrono della replica primaria nel master database in questa replica. La replica non contiene dati utente. Questa opzione:

Può essere ospitata in qualsiasi edizione di SQL Server, inclusa la versione Express Edition.
Richiede che l'endpoint del mirroring dei dati della CONFIGURATION_ONLY replica sia di tipo WITNESS.
Non può essere modificato.
Non è valido quando CLUSTER_TYPE = WSFC.

Per altre informazioni, vedi Disponibilità elevata e protezione dei dati per le configurazioni del gruppo di disponibilità.

AVAILABILITY_MODE è obbligatorio nella ADD REPLICA ON clausola e facoltativo nella MODIFY REPLICA ON clausola . Per altre informazioni, vedere Differenze tra le modalità di disponibilità per un gruppo di disponibilità Always On.

FAILOVER_MODE = { AUTOMATICO | MANUALE }

Specifica la modalità di failover della replica di disponibilità che si sta definendo.

AUTOMATICO

Abilita il failover automatico. AUTOMATIC è supportato solo se si specifica AVAILABILITY_MODE = SYNCHRONOUS_COMMITanche . È possibile specificare AUTOMATIC per tre repliche di disponibilità, inclusa la replica primaria.

Nota

Prima di SQL Server 2016 (13.x), sono limitate a due repliche di failover automatico, inclusa la replica primaria.
Le istanze del cluster di failover di SQL Server non supportano il failover automatico da parte dei gruppi di disponibilità, quindi qualsiasi replica di disponibilità ospitata da un'istanza del cluster di failover può essere configurata solo per il failover manuale.

MANUALE

Abilita il failover manuale o il failover manuale forzato (failover forzato) da parte dell'amministratore del database.

È necessario specificare FAILOVER_MODE nella ADD REPLICA ON clausola . Facoltativamente, è possibile specificarlo nella MODIFY REPLICA ON clausola . Esistono due tipi di failover manuale: failover manuale senza perdita di dati e failover forzato (con possibile perdita di dati). Le diverse condizioni supportano questi tipi. Per altre informazioni, vedere Failover e modalità di failover (Gruppi di disponibilità Always On).

SEEDING_MODE = { AUTOMATICO | MANUALE }

Specifica in che modo viene eseguito il seeding iniziale della replica secondaria.

AUTOMATICO

Abilita il seeding diretto. Questo metodo esegue il seeding della replica secondaria in rete. Questo metodo non richiede il backup e il ripristino di una copia del database primario nella replica.

Nota

Per il seeding diretto, è necessario consentire la creazione di database in ogni replica secondaria chiamando ALTER AVAILABILITY GROUP con l'opzione GRANT CREATE ANY DATABASE .

MANUALE

Specifica il seeding manuale (impostazione predefinita). Questo metodo richiede la creazione di un backup del database nella replica primaria e il ripristino manuale del backup nella replica secondaria.

BACKUP_PRIORITY = n

Specifica la priorità di esecuzione dei backup nella replica rispetto alle altre repliche nello stesso gruppo di disponibilità. Il valore è un numero intero compreso nell'intervallo 0-100. I valori hanno il significato seguente:

1..100 indica che è possibile scegliere la replica di disponibilità per l'esecuzione di backup. 1 indica la priorità più bassa e 100 indica la priorità più alta. Se BACKUP_PRIORITY = 1, la replica di disponibilità viene scelta per l'esecuzione di backup solo se non sono attualmente disponibili repliche di disponibilità con priorità più alta.
0 indica che questa replica di disponibilità non viene mai scelta per l'esecuzione di backup. Questa opzione è utile, ad esempio, per una replica di disponibilità remota in cui non si vuole mai eseguire il failover dei backup.

Per maggiori informazioni, vedere Spostamento dei backup supportati alle repliche secondarie di un gruppo di disponibilità.

SECONDARY_ROLE ( ... )

Specifica le impostazioni specifiche del ruolo che diventano effettive se questa replica di disponibilità è attualmente proprietaria del ruolo secondario (ogni volta che è una replica secondaria). All'interno delle parentesi, specificare una o entrambe opzioni per il ruolo secondario. Se si specificano entrambe, usare un elenco delimitato da virgole.

Le opzioni per il ruolo secondario sono le seguenti:

ALLOW_CONNECTIONS = { NO | READ_ONLY | TUTTI }

Specifica se i database di una determinata replica di disponibilità che esegue il ruolo secondario (che funge da replica secondaria) possono accettare connessioni dai client, uno dei seguenti:

NO

Non sono consentite connessioni utente ai database secondari di questa replica. Non sono disponibili per l'accesso in lettura. Questo è il comportamento predefinito.

SOLO_LETTURA

Solo le connessioni sono consentite ai database nella replica secondaria in cui la proprietà Finalità applicazione è impostata su ReadOnly. Per altre informazioni su questa proprietà, vedere Using Connection String Keywords with SQL Server Native Client.

Tutti

Sono consentite tutte le connessioni ai database nella replica secondaria per l'accesso in sola lettura.

Per ulteriori informazioni, vedere Spostare il carico di lavoro di sola lettura su una replica secondaria di un gruppo di disponibilità Always On.

READ_ONLY_ROUTING_URL = { 'TCP:// system-address:port' | NONE }

Specifica l'URL da usare per il routing delle richieste di connessione con finalità di lettura a questa replica di disponibilità. Questo URL è il percorso in cui il motore di database di SQL Server è in ascolto. In genere, l'istanza predefinita del motore di database di SQL Server è in ascolto sulla porta TCP 1433.

A partire da SQL Server 2025 (17.x), puoi specificare NONE come READ_ONLY_ROUTING_URL destinazione il ritorno al routing di sola lettura specificato per la replica di disponibilità e instradare il traffico in base al comportamento predefinito.

Per un'istanza denominata, eseguire una query sulle port colonne e type_desc della sys.dm_tcp_listener_states vista a gestione dinamica per ottenere il numero di porta. L'istanza del server usa il listener Transact-SQL (type_desc='TSQL').

Per altre informazioni sul calcolo dell'URL di routing di sola lettura per una replica di disponibilità, vedere Calcolo di read_only_routing_url per Always On.

Nota

Per un'istanza denominata di SQL Server, configurare il listener Transact-SQL per l'uso di una porta specifica. Per altre informazioni, vedere Configurare SQL Server per l'ascolto su una porta TCP specifica.

PRIMARY_ROLE ( ... )

Specifica le impostazioni specifiche del ruolo che diventano effettive se la replica di disponibilità è attualmente proprietaria del ruolo primario (ogni volta che è la replica primaria). All'interno delle parentesi, specificare una o entrambe opzioni per il ruolo primario. Se si specificano entrambe, usare un elenco delimitato da virgole.

Le opzioni per il ruolo primario sono le seguenti:

ALLOW_CONNECTIONS = { READ_WRITE | TUTTI }

Specifica il tipo di connessione che i database di una determinata replica di disponibilità che esegue il ruolo primario (che funge da replica primaria) possono accettare dai client, uno dei seguenti:

LETTURA_SCRITTURA

Le connessioni in cui la proprietà di connessione Finalità applicazione è impostata su ReadOnly non sono consentite. Quando la proprietà Finalità applicazione è impostata su ReadWrite o la proprietà di connessione Finalità applicazione non è impostata, la connessione è consentita. Per altre informazioni sulla proprietà di connessione Finalità dell'applicazione, vedere Using Connection String Keywords with SQL Server Native Client.

Tutti

Sono consentite tutte le connessioni ai database nella replica primaria. Questo è il comportamento predefinito.

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

Specifica un elenco delimitato da virgole di istanze del server in cui sono ospitate repliche di disponibilità per questo gruppo di disponibilità che soddisfano i requisiti seguenti quando vengono eseguite nel ruolo secondario:

Essere configurata per consentire tutte le connessioni o le connessioni di sola lettura (vedere l'argomento ALLOW_CONNECTIONS dell'opzione SECONDARY_ROLE , in precedenza in questo articolo).
Specificare l'URL di routing di sola lettura (vedere l'argomento READ_ONLY_ROUTING_URL dell'opzione SECONDARY_ROLE , in precedenza in questo articolo).

I READ_ONLY_ROUTING_LIST valori sono i seguenti:

<server_instance>

Specifica l'indirizzo dell'istanza di SQL Server che è l'host per una replica di disponibilità che è una replica secondaria leggibile durante l'esecuzione nel ruolo secondario.

Usare un elenco delimitato da virgole per specificare tutte le istanze del server che potrebbero ospitare una replica secondaria leggibile. Il routing di sola lettura segue l'ordine in cui le istanze del server vengono specificate nell'elenco. Se si include l'istanza del server host di una replica nell'elenco di routing di sola lettura della replica, il posizionamento di questa istanza del server alla fine dell'elenco costituisce in genere buona pratica, poiché le connessioni con finalità di lettura vengono indirizzate a una replica secondaria, se ne è disponibile una.

A partire da SQL Server 2016 (13.x), è possibile eseguire il bilanciamento del carico delle richieste con finalità di lettura tra le repliche secondarie leggibili. A questo scopo, inserire le repliche in un set annidato di parentesi all'interno dell'elenco di routing di sola lettura. Per altre informazioni ed esempi, vedere Configurare il bilanciamento del carico tra le repliche di sola lettura.

NESSUNO

Specifica che quando questa replica di disponibilità è la replica primaria, il routing di sola lettura non sarà supportato. Questo è il comportamento predefinito. Se usato con MODIFY REPLICA ON, questo valore disabilita un elenco esistente, se presente.

{ READ_WRITE_ROUTING_URL = 'TCP:// system-address:port' | NONE }

Si applica a: SQL Server 2019 (15.x) e versioni successive

Specifica istanze del server in cui sono ospitate repliche di disponibilità per questo gruppo di disponibilità che soddisfano i requisiti seguenti quando vengono eseguite nel ruolo principale:

La specifica PRIMARY_ROLE di replica include READ_WRITE_ROUTING_URL.
La stringa di connessione può essere impostata come ReadWrite definendo ApplicationIntent come ReadWrite o non impostando ApplicationIntent e consentendo che venga implementata l'impostazione predefinita (ReadWrite).

A partire da SQL Server 2025 (17.x), puoi specificare NONE come READ_WRITE_ROUTING_URL destinazione il ritorno al routing di lettura-scrittura specificato per la replica di disponibilità e instradare il traffico in base al comportamento predefinito.

Per altre informazioni, vedere Reindirizzamento della connessione in lettura/scrittura da replica secondaria a primaria - Gruppi di disponibilità AlwaysOn.

SESSION_TIMEOUT = secondi

Specifica il periodo di timeout della sessione in secondi. Se non si specifica questa opzione, il periodo di tempo predefinito è 10 secondi. Il valore minimo è 5 secondi.

Importante

Mantenere il periodo di timeout a 10 secondi o superiore.

Per altre informazioni sul periodo di timeout della sessione, vedere Che cos'è un gruppo di disponibilità AlwaysOn?

MODIFICA REPLICA SU

Modifica qualsiasi replica del gruppo di disponibilità. L'elenco di repliche da modificare contiene l'indirizzo dell'istanza del server e una WITH (...) clausola per ogni replica.

Supportato solo nella replica primaria.

RIMUOVI LA REPLICA SU

Rimuove la replica secondaria specificata dal gruppo di disponibilità. Non è possibile rimuovere la replica primaria corrente da un gruppo di disponibilità. Quando si rimuove una replica, la ricezione dei dati viene interrotta. I database secondari della replica vengono rimossi dal gruppo di disponibilità e immettono lo RESTORING stato.

Supportato solo nella replica primaria.

Nota

Se si rimuove una replica mentre non è disponibile o non è riuscita, quando torna online rileva che non appartiene più al gruppo di disponibilità.

PARTECIPARE

Consente all'istanza del server locale di ospitare una replica secondaria nel gruppo di disponibilità specificato.

Supportato solo in una replica secondaria non ancora unita al gruppo di disponibilità.

Per altre informazioni, vedere Aggiungere una replica secondaria a un gruppo di disponibilità AlwaysOn.

failover

Avvia un failover manuale del gruppo di disponibilità senza perdita di dati nella replica secondaria a cui si è connessi. La replica che ospita la replica primaria è la destinazione di failover. La destinazione di failover assume il ruolo primario e recupera la copia di ogni database, portandole online come nuovi database primari. La replica primaria precedente passa contemporaneamente al ruolo secondario e i relativi database diventano database secondari e vengono immediatamente sospesi. Potenzialmente, questi ruoli possono passare da una serie di errori.

Il failover è supportato solo in una replica secondaria con commit sincrono attualmente sincronizzata con la replica primaria. Per la sincronizzazione di una replica secondaria, è necessario che la replica primaria sia in esecuzione anche in modalità commit sincrono.

Per due istanze di SQL Server in un gruppo di disponibilità, è possibile usare il comando failover nella replica primaria o secondaria. Per le istanze replicate tramite il collegamento Istanza gestita, è necessario eseguire il comando di failover nella replica primaria.

Nota

Per un gruppo di disponibilità, un comando di failover viene restituito non appena la destinazione di failover accetta il comando. Tuttavia, il ripristino del database viene eseguito in modo asincrono al termine del failover del gruppo di disponibilità.
Per un failover del collegamento a Istanza gestita, il comando di failover viene restituito dopo un failover riuscito in cui i ruoli del commutatore di origine e di destinazione o se il comando di failover ha esito negativo dopo che i controlli della precondizione del failover hanno esito negativo.
Non è possibile usare il comando di failover per un failover pianificato di un gruppo di disponibilità distribuito tra due istanze di SQL Server.

Per informazioni sulle limitazioni, i prerequisiti e le raccomandazioni per l'esecuzione di un failover manuale pianificato, vedere Eseguire un failover manuale pianificato di un gruppo di disponibilità AlwaysOn (SQL Server).

FORCE_FAILOVER_ALLOW_DATA_LOSS

Attenzione

Avviare un failover forzato solo come misura di ripristino di emergenza, in quanto può comportare la perdita di dati. Il failover forzato deve essere eseguito solo quando la replica primaria non è disponibile, si è pronti ad accettare potenziali perdite di dati ed è necessario ripristinare immediatamente il servizio nel gruppo di disponibilità.

Supportato solo in una replica il SECONDARY cui ruolo è nello stato o RESOLVING . La replica in cui si immette un comando di failover è la destinazione del failover.

Forza il failover del gruppo di disponibilità, con possibile perdita di dati, nella destinazione di failover. La destinazione di failover assume il ruolo primario e recupera la copia di ogni database, portandole online come nuovi database primari. In tutte le repliche secondarie rimanenti, ogni database secondario viene sospeso finché non viene ripristinato manualmente. Quando la replica primaria precedente diventa disponibile, passa al ruolo secondario e i database diventano sospesi.

Per le istanze replicate tramite il collegamento Istanza gestita, è necessario eseguire il FORCE_FAILOVER_ALLOW_DATA_LOSS comando nella replica secondaria (destinazione di failover).

Nota

Un comando di failover viene restituito non appena la destinazione di failover accetta il comando . Tuttavia, il ripristino del database viene eseguito in modo asincrono al termine del failover del gruppo di disponibilità.

Per informazioni sulle limitazioni, i prerequisiti e le raccomandazioni per forzare il failover e l'effetto di un failover forzato nei database primari precedenti nel gruppo di disponibilità, vedere Eseguire un failover manuale forzato di un gruppo di disponibilità AlwaysOn (SQL Server).

ADD LISTENER 'dns_name' ( <add_listener_option> )

Definisce un nuovo listener per il gruppo di disponibilità. Supportato solo nella replica primaria.

Importante

Prima di creare il primo listener, leggere Configurare un listener per un gruppo di disponibilità AlwaysOn.

Dopo aver creato un listener per un determinato gruppo di disponibilità, seguire questa procedura:

Chiedere all'amministratore di rete di riservare l'indirizzo IP del listener per un uso esclusivo.
Fornire il nome host DNS del listener agli sviluppatori dell'applicazione in modo da essere usato nelle stringhe di connessione per la richiesta di connessioni client al gruppo di disponibilità.

dns_name

Specifica il nome host DNS del listener del gruppo di disponibilità. È necessario che il nome DNS del listener sia univoco nel dominio e in NetBIOS.

dns_name è un valore di stringa. Può contenere solo caratteri alfanumerici, trattini (-) e caratteri di sottolineatura (_), in qualsiasi ordine. Per i nomi host DNS non viene fatta distinzione tra maiuscole e minuscole. La lunghezza massima è di 63 caratteri.

Specificare una stringa significativa. Ad esempio, per un gruppo di disponibilità denominato AG1un nome host DNS significativo potrebbe essere ag1-listener.

Importante

NetBIOS riconosce solo i primi 15 caratteri in dns_name. Se si dispone di due cluster WSFC controllati dallo stesso Active Directory e si tenta di creare listener del gruppo di disponibilità in entrambi i cluster usando nomi con più di 15 caratteri e un prefisso di 15 caratteri identico, viene visualizzato un errore che segnala che la risorsa Nome rete virtuale non è stata portata online. Per informazioni sulle regole di denominazione dei prefissi per i nomi DNS, vedere Assegnare nomi ai domini.

PARTECIPA AL GRUPPO DISPONIBILITÀ IL

Eseguire l'associazione a un gruppo di disponibilità distribuito. Quando si crea un gruppo di disponibilità distribuito, il gruppo di disponibilità nel cluster in cui viene creato è il gruppo di disponibilità primario. Il gruppo di disponibilità associato al gruppo di disponibilità distribuito è il gruppo di disponibilità secondario.

<ag_name>

Specifica il nome del gruppo di disponibilità che costituisce una metà del gruppo di disponibilità distribuito.

LISTENER = 'TCP:// system-address:port'

Specifica il percorso URL per il listener associato al gruppo di disponibilità.

La LISTENER clausola è obbligatoria.

'TCP:// system-address:port'

Specifica un URL per il listener associato al gruppo di disponibilità. I parametri URL sono i seguenti:

indirizzo di sistema

Stringa, ad esempio un nome di sistema, un nome di dominio completo o un indirizzo IP, che identifica in modo univoco il listener.

porto

Numero di porta associato all'endpoint del mirroring del gruppo di disponibilità. Questa non è la porta del listener.

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

Specifica se la replica primaria attende che il gruppo di disponibilità secondario riconosca la protezione avanzata (scrittura) dei record di log su disco prima che la replica primaria possa eseguire il commit della transazione in un determinato database primario.

SYNCHRONOUS_COMMIT

Specifica che la replica primaria attende il commit delle transazioni finché non riceve la conferma che le transazioni vengono rafforzate nel gruppo di disponibilità secondario. È possibile specificare SYNCHRONOUS_COMMIT fino a due gruppi di disponibilità, incluso il gruppo di disponibilità primario.

ASYNCHRONOUS_COMMIT

Specifica che la replica primaria esegue il commit delle transazioni senza attendere la finalizzazione del log da parte del gruppo di disponibilità secondario. È possibile specificare ASYNCHRONOUS_COMMIT fino a due gruppi di disponibilità, incluso il gruppo di disponibilità primario.

La AVAILABILITY_MODE clausola è obbligatoria.

FAILOVER_MODE = { MANUALE }

Specifica la modalità di failover del gruppo di disponibilità distribuito.

MANUALE

Abilita il failover manuale pianificato o il failover manuale forzato (in genere denominato failover forzato) da parte dell'amministratore del database.

Il failover automatico al gruppo di disponibilità secondario non è supportato.

SEEDING_MODE = { AUTOMATICO | MANUALE }

Specifica in che modo viene eseguito il seeding iniziale del gruppo di disponibilità secondario.

AUTOMATICO

Abilita il seeding automatico. Questo metodo esegue il seeding del gruppo di disponibilità secondario in rete. Questo metodo non richiede il backup e il ripristino di una copia del database primario nelle repliche del gruppo di disponibilità secondario.

MANUALE

Specifica il seeding manuale. Questo metodo richiede la creazione di un backup del database nella replica primaria e il ripristino manuale del backup nelle repliche del gruppo di disponibilità secondario.

MODIFICA GRUPPO DISPONIBILITÀ IL

Modifica tutte le impostazioni del gruppo di disponibilità di un gruppo di disponibilità distribuito. L'elenco dei gruppi di disponibilità da modificare contiene il nome del gruppo di disponibilità e una WITH (...) clausola per ogni gruppo di disponibilità.

Importante

È necessario eseguire questo comando sia nel gruppo di disponibilità primario che nelle istanze del gruppo di disponibilità secondario.

CONCEDI CREA QUALSIASI DATABASE

Consente al gruppo di disponibilità di creare database per conto della replica primaria, che supporta il seeding diretto (SEEDING_MODE = AUTOMATIC). Eseguire questo parametro in ogni replica secondaria che supporta il seeding diretto dopo il join secondario al gruppo di disponibilità. È necessaria l'autorizzazione CREATE ANY DATABASE.

NEGA CREA QUALSIASI DATABASE

Nega al gruppo di disponibilità la possibilità di creare database per conto della replica primaria.

<add_listener_option>

ADD LISTENER accetta una delle opzioni seguenti:

CON DHCP [ ON { ('four_part_ipv4_address','four_part_ipv4_mask') } ]

Specifica che il listener del gruppo di disponibilità deve usare il protocollo DHCP (Dynamic Host Configuration Protocol). Facoltativamente, usare la ON clausola per identificare la rete in cui viene creato questo listener. DHCP è limitato a una singola subnet usata per ogni istanza del server che ospita una replica di disponibilità nel gruppo di disponibilità.

Importante

Evitare di usare DHCP in un ambiente di produzione. Se si verificano tempi di inattività e il lease IP DHCP scade, è necessario tempo aggiuntivo per registrare il nuovo indirizzo IP di rete DHCP associato al nome DNS del listener e influisce sulla connettività client. DHCP può essere tranquillamente usato per la configurazione dell'ambiente di sviluppo e test per verificare le funzioni di base di gruppi di disponibilità e per l'integrazione con le applicazioni.

Ad esempio:

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

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

Anziché usare DHCP, il listener del gruppo di disponibilità usa uno o più indirizzi IP statici. Per creare un gruppo di disponibilità tra più subnet, viene richiesto un indirizzo IP statico nella configurazione del listener per ogni subnet. Per una determinata subnet, l'indirizzo IP statico può essere un indirizzo IPv4 o IPv6. Contattare l'amministratore di rete per ottenere un indirizzo IP statico per ogni subnet che ospita una replica di disponibilità per il nuovo gruppo di disponibilità.

Ad esempio:

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

ipv4_address

Indirizzo IPv4 in quattro parti per un listener del gruppo di disponibilità. Ad esempio: 10.120.19.155.

ipv4_mask

Maschera in quattro parti IPv4 per un listener del gruppo di disponibilità. Ad esempio: 255.255.254.0.

ipv6_address

Indirizzo IPv6 per un listener del gruppo di disponibilità. Ad esempio: 2001::4898:23:1002:20f:1fff:feff:b3a3.

PORTA = listener_port

Numero di porta (listener_port) da usare da un listener del gruppo di disponibilità specificato dalla WITH IP clausola . PORT è facoltativo.

Il numero di porta predefinito, 1433, è supportato. Tuttavia, è possibile scegliere un numero di porta diverso.

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

MODIFY LISTENER 'dns_name' ( <modify_listener_option> )

Modifica un listener del gruppo di disponibilità esistente. Supportato solo nella replica primaria.

<modify_listener_option>

MODIFY LISTENER accetta una delle opzioni seguenti:

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

Aggiunge l'indirizzo IP specificato al listener del gruppo di disponibilità specificato da dns_name.

PORTA = listener_port

Vedere la descrizione di questo argomento più indietro in questa sezione.

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

Si applica a: SQL Server 2025 (17.x) e versioni successive

Rimuove l'indirizzo IP specificato dal listener del gruppo di disponibilità specificato.

RIAVVIARE IL LISTENER 'dns_name'

Riavvia il listener associato al nome DNS specificato. Supportato solo nella replica primaria.

REMOVE LISTENER 'dns_name'

Rimuove il listener associato al nome DNS specificato. Supportato solo nella replica primaria.

OFF-LINE

Porta offline un gruppo di disponibilità online. Non esiste alcuna perdita di dati per i database con commit sincrono.

Quando un gruppo di disponibilità diventa offline, i relativi database diventano non disponibili per i client e non è possibile riportare online il gruppo di disponibilità. Pertanto, usare l'opzione OFFLINE solo durante una migrazione tra cluster di gruppi di disponibilità AlwaysOn, quando si esegue la migrazione delle risorse del gruppo di disponibilità a un nuovo cluster WSFC.

Per altre informazioni, vedere Portare un gruppo di disponibilità offline (SQL Server).

Prerequisiti e restrizioni

Per informazioni sui prerequisiti e sulle restrizioni sulle repliche di disponibilità e sui relativi computer e istanze del server host, vedere Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn.

Per informazioni sulle restrizioni relative alle AVAILABILITY GROUP istruzioni Transact-SQL, vedere istruzioniTransact-SQL per i gruppi di disponibilità Always On.

Autorizzazioni

È necessaria ALTER AVAILABILITY GROUP l'autorizzazione per il gruppo di disponibilità, CONTROL AVAILABILITY GROUP l'autorizzazione, ALTER ANY AVAILABILITY GROUP l'autorizzazione o CONTROL SERVER l'autorizzazione. È necessaria ALTER ANY DATABASE anche l'autorizzazione.

Esempi

R. Creare un join di una replica secondaria a un gruppo di disponibilità

Nell'esempio seguente viene aggiunta una replica secondaria a cui si è connessi al gruppo di disponibilità AccountsAG.

ALTER AVAILABILITY GROUP AccountsAG JOIN;
GO

B. Forzare il failover di un gruppo di disponibilità

L'esempio seguente forza il failover del gruppo di disponibilità AccountsAG alla replica secondaria a cui si è connessi.

ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
GO

C. Forzare la crittografia nelle connessioni al gruppo di disponibilità

Gli esempi in questa sezione forzano la AccountsAG crittografia nelle connessioni al gruppo di disponibilità.

Se il nome del server viene visualizzato in ogni certificato come definito da uno dei metodi, è possibile omettere l'opzione HostNameInCertificate :

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

Se è stato seguito il metodo 1 ma non è stato elencato il nome del server come nome alternativo soggetto nel certificato, è necessario specificare il valore visualizzato in Nome alternativo soggetto nell'opzione HostNameInCertificate :

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

Se è stato seguito il metodo 1 e si vuole usare la ServerCertificate proprietà invece di fornire un valore per HostNameInCertificate:

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

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-01-06

Condividi tramite

ALTER AVAILABILITY GROUP (Transact-SQL)

Sintassi

Argomenti

group_name

AUTOMATED_BACKUP_PREFERENCE = { PRIMARIO | SECONDARY_ONLY| SECONDARIO | NESSUNO }

PRIMARIO

SECONDARY_ONLY

SECONDARIO

NESSUNO

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

HEALTH_CHECK_TIMEOUT = Millisecondi

DB_FAILOVER = { ACCESO | SPENTO }

DTC_SUPPORT = { PER_DB | NESSUNO }

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

RUOLO

CLUSTER_CONNECTION_OPTIONS

AGGIUNGI database_name DATABASE

RIMUOVERE database_name DATABASE

AGGIUNGI REPLICA SU

<server_instance>

_sistema

nome_rete_FCI

instance_name

\

ENDPOINT_URL = '*TCP:// system-address:*port'

'TCP:// system-address:port'

indirizzo di sistema

porto

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

CONFIGURATION_ONLY

FAILOVER_MODE = { AUTOMATICO | MANUALE }

AUTOMATICO

MANUALE

SEEDING_MODE = { AUTOMATICO | MANUALE }

AUTOMATICO

MANUALE

BACKUP_PRIORITY = n

SECONDARY_ROLE ( ... )

ALLOW_CONNECTIONS = { NO | READ_ONLY | TUTTI }

NO

SOLO_LETTURA

Tutti

READ_ONLY_ROUTING_URL = { '*TCP:// system-address:*port' | NONE }

PRIMARY_ROLE ( ... )

ALLOW_CONNECTIONS = { READ_WRITE | TUTTI }

LETTURA_SCRITTURA

Tutti

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

<server_instance>

NESSUNO

{ READ_WRITE_ROUTING_URL = '*TCP:// system-address:*port' | NONE }

SESSION_TIMEOUT = secondi

MODIFICA REPLICA SU

RIMUOVI LA REPLICA SU

PARTECIPARE

failover

FORCE_FAILOVER_ALLOW_DATA_LOSS

ADD LISTENER 'dns_name' ( <add_listener_option> )

dns_name

PARTECIPA AL GRUPPO DISPONIBILITÀ IL

<ag_name>

LISTENER = '*TCP:// system-address:*port'

'*TCP:// system-address:*port'

indirizzo di sistema

porto

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

FAILOVER_MODE = { MANUALE }

MANUALE

SEEDING_MODE = { AUTOMATICO | MANUALE }

AUTOMATICO

MANUALE

MODIFICA GRUPPO DISPONIBILITÀ IL

CONCEDI CREA QUALSIASI DATABASE

NEGA CREA QUALSIASI DATABASE

<add_listener_option>

`HEALTH_CHECK_TIMEOUT` = Millisecondi

ENDPOINT_URL = 'TCP:// system-address:port'

READ_ONLY_ROUTING_URL = { 'TCP:// system-address:port' | NONE }

{ READ_WRITE_ROUTING_URL = 'TCP:// system-address:port' | NONE }

LISTENER = 'TCP:// system-address:port'

'TCP:// system-address:port'