ALTER AVAILABILITY GROUP (Transact-SQL)

  • Articolo

Modifica un gruppo di disponibilità AlwaysOn esistente in SQL Server 2012. La maggior parte degli argomenti ALTER AVAILABILITY GROUP sono supportati solo nella replica primaria corrente. Tuttavia gli argomenti JOIN, FAILOVER e FORCE_FAILOVER_ALLOW_DATA_LOSS sono supportati solo in repliche secondarie.

Icona di collegamento a un argomento Convenzioni della 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
   | 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 

<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 },
       FAILOVER_MODE = { AUTOMATIC | MANUAL }
       [ , <add_replica_option> [ ,...n ] ]
    ) 

  <add_replica_option>::=
       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 } 
          } )
     | SESSION_TIMEOUT = seconds 


<modify_replica_spec>::=
  <server_instance> WITH
    (  
       ENDPOINT_URL = 'TCP://system-address:port' 
     | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT } 
     | FAILOVER_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 } 
          } )
     | SESSION_TIMEOUT = seconds 
    )  


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

  <network_subnet_option> ::=
     ‘four_part_ipv4_address’, ‘four_part_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
    }

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 = { PRIMARY | SECONDARY_ONLY| SECONDARY | NONE }
    Specifica le preferenze per la modalità di valutazione della replica primaria da parte di un processo di backup nella scelta della posizione in cui eseguire i backup. È possibile generare uno script affinché un processo di backup specifico prenda in considerazione le preferenze di backup automatico. È importante comprendere che le preferenze non vengono applicate da SQL Server, pertanto non incidono sui backup ad hoc.

    Supportato solo nella replica primaria.

    Sono disponibili i valori seguenti:

    • PRIMARY
      Specifica che i backup devono essere sempre eseguiti sulla replica primaria. Questa opzione è utile se sono necessarie funzionalità di backup, ad esempio la creazione di backup differenziali, che non sono supportate quando il backup viene eseguito su una replica secondaria.

      Nota importanteImportante

      Se si intende utilizzare il log shipping per preparare un qualsiasi database secondario per un gruppo di disponibilità, impostare la preferenza di backup automatico su Principale finché tutti i database secondari non saranno stati preparati e non ne sarà stato creato un join al gruppo di disponibilità.

    • SECONDARY_ONLY
      Specifica che i backup non devono mai essere eseguiti sulla replica primaria. Se la replica primaria è l'unica replica online, il backup non viene eseguito.

    • SECONDARY
      Specifica che i backup devono essere eseguiti su una replica secondaria tranne quando la replica primaria è l'unica replica online. In tal caso il backup deve essere eseguito sulla replica primaria. Si tratta del comportamento predefinito.

    • NONE
      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.

    Nota importanteImportante

    Non è prevista l'applicazione dell'impostazione AUTOMATED_BACKUP_PREFERENCE. L'interpretazione di questa preferenza dipende dalla logica, se presente, tramite cui viene generato lo script nei processi di backup per i database in un determinato gruppo di disponibilità. L'impostazione relativa alla preferenza di backup automatico non ha alcun impatto sui backup ad hoc. Per ulteriori informazioni, vedere Configurare il backup su repliche di disponibilità (SQL Server).

    [!NOTA]

    Per visualizzare le preferenze di backup automatico di un gruppo di disponibilità esistente, selezionare la colonna automated_backup_preference o automated_backup_preference_desc della vista del catalogo sys.availability_groups. Inoltre, sys.fn_hadr_backup_is_preferred_replica (Transact-SQL) può essere utilizzato per determinare la replica di backup preferita. Questa funzione restituisce sempre 1 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 viene impostato a livello di gruppo ma è rilevante solo sulle repliche di disponibilità configurate per la modalità di disponibilità con commit sincrono (AVAILIBILITY_MODE = SYNCHRONOUS_COMMIT). Inoltre, le condizioni di errore possono attivare un failover automatico solo se entrambe le repliche, primaria e secondaria, 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 che corrisponde a ciascun livello.

    Livello

    Condizione di errore

    1

    Specifica che deve essere avviato un failover automatico quando si verifica una delle condizioni seguenti:

    • Il servizio SQL Server non è attivo.

    • Il lease del gruppo di disponibilità per la connessione al cluster WSFC scade poiché non viene ricevuto alcun acknowledgement dall'istanza del server. Per ulteriori informazioni, vedere Funzionamento: timeout lease di SQL Server AlwaysOn.

    2

    Specifica che deve essere avviato un failover automatico quando si verifica una delle condizioni seguenti:

    • L'istanza di SQL Server non si connette al cluster e viene superata la soglia HEALTH_CHECK_TIMEOUT specificata dall'utente del gruppo di disponibilità.

    • La replica di disponibilità si trova in uno stato di errore.

    3

    Specifica che deve essere avviato un failover automatico in caso di errori interni di SQL Server critici, ad esempio spinlock orfani, gravi violazioni dell'accesso in scrittura o dumping eccessivo.

    Questo è il comportamento predefinito.

    4

    Specifica che deve essere avviato un failover automatico in caso di errori interni di SQL Server con gravità moderata, ad esempio una condizione persistente di memoria insufficiente nel pool di risorse interno di SQL Server.

    5

    Specifica che deve essere avviato un failover automatico in caso di qualsiasi condizione di errore qualificata, tra cui:

    • Esaurimento dei thread di lavoro del motore SQL.

    • Rilevamento di un deadlock irrisolvibile.

    [!NOTA]

    L'assenza di risposta da un'istanza di SQL Server alle richieste del client non è rilevante per i gruppi di disponibilità.

    I valori FAILURE_CONDITION_LEVEL e HEALTH_CHECK_TIMEOUT definiscono criteri di failover flessibili per un gruppo specifico, fornendo un controllo granulare sulle condizioni che devono causare un failover automatico. Per ulteriori informazioni, vedere Criteri di failover flessibili per failover automatico di un gruppo di disponibilità (SQL Server).

  • HEALTH_CHECK_TIMEOUT = milliseconds
    Specifica il tempo di attesa, in millisecondi, per la restituzione delle informazioni sull'integrità del server da parte della stored procedure di sistema sp_server_diagnostics prima che il cluster WSFC presupponga che l'istanza del server sia lenta o bloccata. HEALTH_CHECK_TIMEOUT viene impostato a livello di gruppo ma è rilevante solo sulle repliche di disponibilità configurate per la modalità di disponibilità con commit sincrono e che supportano il failover automatico (AVAILIBILITY_MODE = SYNCHRONOUS_COMMIT). Inoltre, un timeout del controllo di integrità può attivare un failover automatico solo se entrambe le repliche, primaria e secondaria, sono configurate per la modalità di failover automatico (FAILOVER_MODE = AUTOMATIC) e la replica secondaria è attualmente sincronizzata con la replica primaria.

    Il valore predefinito di HEALTH_CHECK_TIMEOUT è 30000 millisecondi (30 secondi). Il valore minimo è 15000 millisecondi (15 secondi) e il valore massimo è 4294967295 millisecondi.

    Supportato solo nella replica primaria.

    Nota importanteImportante

    In sp_server_diagnostics non vengono eseguiti controlli di integrità a livello di database.

  • ADD DATABASE database_name
    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 (SQL Server). Per individuare i database locali già appartenenti a un gruppo di disponibilità, vedere la colonna replica_id nella vista del catalogo sys.databases.

    Supportato solo nella replica primaria.

    [!NOTA]

    Dopo aver creato il gruppo di disponibilità, sarà necessario connettersi a ogni istanza del server in cui è ospitata una replica secondaria, quindi preparare ciascun database secondario e aggiungerlo al gruppo di disponibilità. Per ulteriori informazioni, vedere Avviare lo spostamento dati su un database secondario AlwaysOn (SQL Server).

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

    Per informazioni sulle attività consigliate da eseguire dopo la rimozione di un database di disponibilità da un gruppo di disponibilità, vedere Rimuovere un database primario da un gruppo di disponibilità (SQL Server).

  • ADD REPLICA ON
    Specifica da una a quattro istanze di SQL Server per ospitare le repliche secondarie in un gruppo di disponibilità. Ogni replica viene specificata dall'indirizzo della relativa istanza del server seguito da una clausola WITH (…).

    Supportato solo nella replica primaria.

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

  • <istanza_server>
    Specifica l'indirizzo dell'istanza di SQL Server in cui viene ospitata una replica. Il formato dell'indirizzo dipende dal fatto che l'istanza sia l'istanza predefinita o un'istanza denominata e se si tratti di un'istanza autonoma o un'istanza del cluster di failover (FCI). La sintassi è la seguente:

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

    I componenti di questo indirizzo sono i seguenti:

    • system_name
      Nome NetBIOS del computer in cui si trova l'istanza di destinazione di SQL Server. Il computer deve essere un nodo WSFC.

    • FCI_network_name
      Nome di rete utilizzato per accedere a un cluster di failover di SQL Server. Utilizzare questo nome se l'istanza del server partecipa come partner di failover di SQL Server. L'esecuzione di SELECT @@SERVERNAME in un'istanza del server FCI restituisce l'intera stringa 'FCI_network_name[\instance_name]', che corrisponde al nome completo della replica.

    • instance_name
      Nome di un'istanza di un server SQL Server ospitato da system_name o FCI_network_name e in cui è abilitato il servizio AlwaysOn. Per un'istanza del server predefinita, instance_name è facoltativo. Per il nome dell'istanza non viene fatta distinzione tra maiuscole e minuscole. In un'istanza del server autonoma questo nome del valore è lo stesso di quello per il valore restituito dall'esecuzione di 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 (SQL Server).

  • ENDPOINT_URL ='TCP://system-address:port'
    Specifica il percorso URL dell'endpoint del mirroring del database nell'istanza di SQL Server in cui verrà ospitata la replica di disponibilità in corso di aggiunta o modifica.

    ENDPOINT_URL è obbligatorio nella clausola ADD REPLICA ON e facoltativo nella clausola MODIFY REPLICA ON. Per ulteriori informazioni, vedere Specifica dell'URL dell'endpoint quando si aggiunge o si modifica una replica di disponibilità (SQL Server).

  • '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:

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

    • port
      Numero di porta associato all'endpoint del mirroring dell'istanza del server (per l'opzione ENDPOINT_URL) o 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 }
    Specifica se la replica primaria deve attendere la conferma della finalizzazione (scrittura) dei record del log su disco da parte della replica secondaria prima di poter eseguire il commit della transazione in un database primario specifico. Il commit delle transazioni in database diversi della stessa replica primaria può essere eseguito indipendentemente.

    • SYNCHRONOUS_COMMIT
      Specifica che la replica primaria esegue il commit delle transazioni solo dopo la finalizzazione nella replica secondaria (modalità con commit sincrono). È possibile specificare SYNCHRONOUS_COMMIT per un massimo di 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 per un massimo di cinque repliche di disponibilità, inclusa la replica primaria.

    AVAILABILITY_MODE è obbligatorio nella clausola ADD REPLICA ON e facoltativo nella clausola MODIFY REPLICA ON. Per ulteriori informazioni, vedere Modalità di disponibilità (gruppi di disponibilità AlwaysOn).

  • FAILOVER_MODE = { AUTOMATIC | MANUAL }
    Specifica la modalità di failover della replica di disponibilità che si sta definendo.

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

      [!NOTA]

      Le istanze del cluster di failover di SQL Server non supportano il failover automatico da gruppi di disponibilità, pertanto le replica di disponibilità ospitate da un'istanza del cluster di failover possono essere configurate solo per il failover manuale.

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

    FAILOVER_MODE è obbligatorio nella clausola ADD REPLICA ON e facoltativo nella clausola MODIFY REPLICA ON. Esistono due tipi di failover manuale, failover manuale senza perdita di dati e failover forzato (con possibile perdita di dati), supportati a seconda delle diverse condizioni. Per ulteriori informazioni, vedere Failover e modalità di failover (gruppi di disponibilità AlwaysOn).

  • 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 la replica di disponibilità potrebbe essere scelta per l'esecuzione dei backup. 1 indica la priorità più bassa e 100 indica la priorità più alta. Se BACKUP_PRIORITY = 1, la replica di disponibilità verrà scelta per l'esecuzione dei backup solo se non sono attualmente disponibili repliche di disponibilità con priorità più alta.

    • 0 indica che la replica di disponibilità non verrà mai scelta per l'esecuzione dei backup. Ciò si rivela utile, ad esempio, per una replica di disponibilità remota in cui non si desidera eseguire mai il failover dei backup.

    Per ulteriori informazioni, vedere Repliche secondarie attive: Backup in repliche secondarie (Gruppi di disponibilità AlwaysOn).

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

    Le opzioni per il ruolo secondario sono le seguenti:

    • ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL }
      Specifica se i database di una determinata replica di disponibilità che esegue il ruolo secondario, ovvero che funge da replica secondaria, possono accettare connessioni dai client, ovvero:

      • NO
        Non sono consentite connessioni utente ai database secondari di questa replica. I database non sono disponibili per l'accesso in lettura. Si tratta del comportamento predefinito.

      • READ_ONLY
        Sono consentite solo connessioni ai database nella replica secondaria nei casi in cui la proprietà Finalità dell'applicazione è impostata su ReadOnly. Per ulteriori informazioni su questa proprietà, vedere Utilizzo delle parole chiave delle stringhe di connessione con SQL Server Native Client.

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

      Per ulteriori informazioni, vedere Repliche secondarie attive: Repliche secondarie leggibili (Gruppi di disponibilità AlwaysOn).

    • READ_ONLY_ROUTING_URL = 'TCP://system-address:port'
      Specifica l'URL da utilizzare per il routing delle richieste di connessione con finalità di lettura a questa replica di disponibilità. Si tratta dell'URL sul quale è in ascolto il motore di database di SQL Server. In genere, l'istanza predefinita del motore di database di SQL Server è in ascolto sulla porta TCP 1433.

      Per un'istanza denominata, è possibile ottenere il numero di porta eseguendo una query sulle colonne port e type_desc della DMV sys.dm_tcp_listener_states. Nell'istanza del server viene utilizzato il listener Transact-SQL (type_desc = 'TSQL').

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

      [!NOTA]

      Per un'istanza denominata di SQL Server, il listener Transact-SQL deve essere configurato per utilizzare una porta specifica. Per ulteriori informazioni, vedere Configurazione di un server per l'attesa su una porta TCP specifica (Gestione configurazione SQL Server).

  • PRIMARY_ROLE ( … )
    Specifica le impostazioni specifiche di ruolo che verranno applicate se questa replica di disponibilità è attualmente proprietaria del ruolo primario (ovvero ogni volta che è una replica primaria). All'interno delle parentesi, specificare uno o entrambe opzioni per il ruolo primario. Se si specificano entrambe, utilizzare un elenco delimitato da virgole.

    Le opzioni per il ruolo primario sono le seguenti:

    • ALLOW_CONNECTIONS = { READ_WRITE | ALL }
      Specifica il tipo di connessione che i database di una determinata replica di disponibilità che esegue il ruolo primario, ovvero che funge da replica primaria, possono accettare dai client, tra cui:

      • READ_WRITE
        Non sono consentite le connessioni in cui la proprietà di connessione Finalità dell'applicazione è impostata su ReadOnly. Se la proprietà Finalità dell'applicazione è impostata su ReadWrite o se tale proprietà non è impostata, la connessione è consentita. Per ulteriori informazioni sulla proprietà di connessione Finalità dell'applicazione, vedere Utilizzo delle parole chiave delle stringhe di connessione con SQL Server Native Client.

      • ALL
        Sono consentite tutte le connessioni ai database nella replica primaria. Si tratta del comportamento predefinito.

    • READ_ONLY_ROUTING_LIST = { (‘<istanza_server>’ [ ,...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:

      • Sono configurate per consentire tutte le connessioni o connessioni in sola lettura (vedere l'argomento ALLOW_CONNECTIONS dell'opzione SECONDARY_ROLE, sopra).

      • Dispongono del proprio URL del routing di sola lettura (vedere l'argomento READ_ONLY_ROUTING_URL dell'opzione SECONDARY_ROLE, sopra).

      I valori di READ_ONLY_ROUTING_LIST sono i seguenti:

      • <istanza_server>
        Specifica l'indirizzo dell'istanza di SQL Server che funge da host per una replica di disponibilità che è una replica secondaria leggibile quando è in esecuzione nel ruolo secondario.

        Utilizzare un elenco delimitato da virgole per specificare tutte le istanze del server che potrebbero ospitare una replica secondaria leggibile. Il routing di sola lettura seguirà l'ordine nel quale 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.

      • NONE
        Specifica che quando questa replica di disponibilità è la replica primaria, il routing di sola lettura non è supportato. Si tratta del comportamento predefinito. In caso di utilizzo con MODIFY REPLICA ON, questo valore disabilita un elenco esistente, se presente.

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

    Nota importanteImportante

    È consigliabile utilizzare un periodo di timeout di almeno 10 secondi.

    Per ulteriori informazioni sul periodo di timeout della sessione, vedere Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server).

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

    Supportato solo nella replica primaria.

  • REMOVE REPLICA ON
    Rimuove la replica secondaria specificata dal gruppo di disponibilità. Non è possibile rimuovere la replica primaria corrente da un gruppo di disponibilità. Nel momento in cui viene rimossa, la replica non riceverà più i dati. I relativi database secondari vengono rimossi dal gruppo di disponibilità e viene attivato lo stato RESTORING.

    Supportato solo nella replica primaria.

    [!NOTA]

    Se si rimuove una replica mentre non è disponibile o si trova in stato di errore, quando torna alla modalità online rileverà di non appartenere più al gruppo di disponibilità.

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

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

    Per ulteriori informazioni, vedere Creare un join di una replica secondaria a un gruppo di disponibilità (SQL Server).

  • FAILOVER
    Avvia un failover manuale del gruppo di disponibilità senza perdita di dati nella replica secondaria a cui si è connessi. La replica in cui viene eseguito un comando di failover della destinazione di failover è nota come . La destinazione di failover subentrerà al ruolo primario e recupererà la copia di ogni database per portarli 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 alternati in successione da una serie di errori.

    Supportato solo su una replica secondaria con commit sincrono che è attualmente sincronizzata con la replica primaria. Notare che per la sincronizzazione di una replica secondaria, è necessario che anche la replica primaria sia in esecuzione in modalità con commit sincrono.

    [!NOTA]

    Un comando di failover viene eseguito non appena la destinazione di failover avrà accettato il comando. Tuttavia, il recupero del database si verifica in modo asincrono dopo che il gruppo di disponibilità ha completato il failover.

    Per informazioni su limitazioni, prerequisiti e consigli per eseguire un failover manuale pianificato, vedere Eseguire un failover manuale pianificato di un gruppo di disponibilità (SQL Server).

  • FORCE_FAILOVER_ALLOW_DATA_LOSS

    Nota di attenzioneAttenzione

    L'utilizzo forzato di un failover, che può comportare una perdita di dati, rappresenta esclusivamente un metodo di ripristino di emergenza. Pertanto, è consigliabile forzare il failover solo se la replica primaria non è più in esecuzione, si è disposti a rischiare la perdita di dati ed è necessario ripristinare immediatamente il servizio nel gruppo di disponibilità.

    Supportato solo in una replica il cui ruolo è in uno stato SECONDARY o RESOLVING. --La replica in cui viene eseguito un comando di failover è nota come destinazione di failover.

    Forza il failover del gruppo di disponibilità, con possibile perdita di dati, nella destinazione di failover. La destinazione di failover subentrerà al ruolo primario e recupererà la copia di ogni database per portarli 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, passerà al ruolo secondario e i relativi database diventeranno database secondari sospesi.

    [!NOTA]

    Un comando di failover viene eseguito non appena la destinazione di failover avrà accettato il comando. Tuttavia, il recupero del database si verifica in modo asincrono dopo che il gruppo di disponibilità ha completato il failover.

    Per informazioni su limitazioni, prerequisiti e consigli per il failover forzato e sull'effetto di un failover forzato sui database primari precedenti nel gruppo di disponibilità, vedere Eseguire un failover manuale forzato di un gruppo di disponibilità (SQL Server).

  • ADD LISTENER ‘dns_name’( <add_listener_option> )
    Definisce un nuovo listener per il gruppo di disponibilità. Supportato solo nella replica primaria.

    Nota importanteImportante

    Prima di creare il primo listener, è consigliabile leggere Creare o configurare un listener del gruppo di disponibilità (SQL Server).

    Dopo aver creato un listener per un gruppo di disponibilità specifico, è consigliabile effettuare le operazioni seguenti:

    • Chiedere all'amministratore di rete di riservare l'indirizzo IP del listener per un utilizzo esclusivo.

    • Fornire il nome host DNS del listener agli sviluppatori dell'applicazione in modo da essere utilizzato 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 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.

    È consigliabile specificare una stringa significativa. Ad esempio, per un gruppo di disponibilità denominato AG1 un nome host DNS significativo potrebbe essere ag1-listener.

    Nota importanteImportante

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

  • <add_listener_option>
    ADD LISTENER accetta una delle opzioni seguenti:

    • WITH DHCP [ ON { (‘four_part_ipv4_address’,‘four_part_ipv4_mask’) } ]
      Specifica che il listener del gruppo di disponibilità utilizzerà il protocollo DHCP (Dynamic Host Configuration Protocol). Facoltativamente, utilizzare la clausola ON per identificare la rete su cui verrà creato il listener. DHCP è limitato a una sola subnet utilizzata per ogni istanza del server nel cui gruppo di disponibilità è ospitata una replica di disponibilità.

      Nota importanteImportante

      Non è consigliabile utilizzare DHCP negli ambienti di produzione. Se si verifica un periodo di inattività e il lease IP DHCP scade, è necessario del tempo aggiuntivo per registrare il nuovo indirizzo IP della rete DHCP che è associato al nome DNS del listener e influisce sulla connettività client. DHCP può essere tranquillamente utilizzato 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.

      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 ]
      Specifica che, anziché utilizzare DHCP, nel listener del gruppo di disponibilità verranno utilizzati 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 in cui verrà ospitata una replica di disponibilità per il nuovo gruppo di disponibilità.

      Esempio:

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

  • four_part_ipv4_address
    Specifica un indirizzo IPv4 in quattro parti per un listener del gruppo di disponibilità, ad esempio 10.120.19.155.

  • four_part_ipv4_mask
    Specifica una maschera IPv4 in quattro parti per un listener del gruppo di disponibilità, ad esempio 255.255.254.0.

  • ipv6_address
    Specifica un indirizzo IPv6 per un listener del gruppo di disponibilità, ad esempio 2001::4898:23:1002:20f:1fff:feff:b3a3.

  • PORT = listener_port
    Specifica il numero di porta, listener_port, che deve essere utilizzato da un listener del gruppo di disponibilità specificato mediante una clausola WITH IP. PORT è facoltativo.

    È supportato il numero di porta predefinito, 1433. Tuttavia, per motivi di sicurezza, è consigliabile utilizzare un numero di porta diverso.

    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’) | (‘dns_nameipv6_address’) }
      Aggiunge l'indirizzo IP specificato al listener del gruppo di disponibilità specificato da dns_name.

    • PORT = listener_port
      Vedere la descrizione di questo argomento più indietro in questa sezione.

  • RESTART LISTENER ‘dns_name’
    Consente di riavviare il listener associato al nome DNS specificato. Supportato solo nella replica primaria.

  • REMOVE LISTENER ‘dns_name’
    Consente di rimuovere il listener associato al nome DNS specificato. Supportato solo nella replica primaria.

  • OFFLINE
    Porta offline un gruppo di disponibilità online. Non si verifica alcuna perdita di dati per i database con commit sincrono.

    Dopo aver portato un gruppo di disponibilità offline, i relativi database non saranno più disponibili per i client e non sarà possibile riportare nuovamente online il gruppo di disponibilità. Utilizzare pertanto l'opzione OFFLINE solo durante la migrazione tra cluster di Gruppi di disponibilità AlwaysOn, se si esegue la migrazione di risorse del gruppo di disponibilità a un nuovo cluster WSFC.

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

Icona freccia utilizzata con il collegamento Torna all'inizio[Inizio pagina]

Prerequisiti e restrizioni

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

Per informazioni sulle restrizioni relative alle istruzioni Transact-SQL AVAILABILITY GROUP, vedere Panoramica delle istruzioni Transact-SQL per i gruppi di disponibilità AlwaysOn (SQL Server).

Sicurezza

Autorizzazioni

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

Esempi

A.Creazione di un join di una replica secondaria a un gruppo di disponibilità

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

ALTER AVAILABILITY GROUP AccountsAG JOIN;
GO

B.Failover forzato di un gruppo di disponibilità

Nell'esempio seguente viene eseguito il failover forzato del gruppo di disponibilità AccountsAG alla replica secondaria a cui si è connessi.

ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
GO

Vedere anche

Riferimento

CREATE AVAILABILITY GROUP (Transact-SQL)

ALTER DATABASE SET HADR (Transact-SQL)

DROP AVAILABILITY GROUP (Transact-SQL)

sys.availability_replicas (Transact-SQL)

sys.availability_groups (Transact-SQL)

Concetti

Risolvere i problemi relativi alla configurazione di Gruppi di disponibilità AlwaysOn (SQL Server)

Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server)

Listener del gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server)