SQL Server Gruppi di disponibilità Always On: guida completa [2026]

1. Informazioni sui gruppi di disponibilità Always On

1.1 Cos'è e come funziona

Always On Availability Groups (AG) è un SQL Server Impresa alta disponibilità e una soluzione di disaster recovery che opera a livello di database. Un gruppo di disponibilità raggruppa uno o più database utente in un'unica unità di failover e li replica su un massimo di otto repliche secondarie tramite il trasporto continuo dei log delle transazioni. In caso di guasto della replica primaria, una replica secondaria sincrona designata subentra automaticamente, ripristinando l'accesso in pochi secondi senza storage condiviso o intervento manuale.

1.2 Gruppi di disponibilità Always On vs. istanze del cluster di failover

SQL Server Always On include due tecnologie distinte: gruppi di disponibilità (AG) e istanze del cluster di failover (FCI):

	Gruppi di disponibilità sempre attivi	Istanze del cluster di failover sempre attive
Ambito di failover	Livello di database	A livello di istanza (tutti i database eseguono il failover contemporaneamente)
Replica dei dati	Replica basata su log su ciascun secondario	Nessuno: tutti i nodi condividono lo stesso storage
Archiviazione condivisa	Non richiesto	Obbligatorio (Storage Area Network (SAN), iSCSI, S2D o SMB)
Secondari leggibili	Si	Non
Disaster recovery	Integrato (repliche asincrone tra i siti)	Non integrato senza associazione con AG

Quando utilizzare ciascuno: Utilizzate FCI quando avete bisogno di failover a livello di istanza e disponete già di un'infrastruttura di storage condivisa. Utilizzate AG quando avete bisogno di granularità a livello di database, di replicatori secondari leggibili o di disaster recovery. Per la protezione più completa, combinate entrambi: eseguite ogni replica come nodo FCI e collegatele in un AG.

1.3 Vantaggi e limitazioni

Vantaggi:

• Failover automatico con Recovery Time Objective (RTO) prossimo allo zero per repliche sincrone;
• nessuna perdita di dati (Recovery Point Objective (RPO) = 0) in modalità commit sincrono;
• non è richiesto alcun archivio condiviso: ogni replica utilizza un archivio locale indipendente;
• i secondari leggibili scaricano i carichi di lavoro di reporting e backup dal primario;
• supporta sia l'alta disponibilità locale (HA) sia il ripristino di emergenza (DR) tra siti all'interno di un'unica configurazione.

limitazioni:

• Richiede Windows Server Failover Clustering su tutte le repliche;
• Enterprise Edition per il set completo di funzionalità (Standard Edition supporta Basic AG con significative limitazioni);
• la modalità di commit sincrono aggiunge latenza alle operazioni di scrittura proporzionale al tempo di andata e ritorno della rete;
• gli accessi, i processi di SQL Agent e i server collegati non vengono sincronizzati automaticamente in SQL Server 2019 e precedenti (risolto in SQL Server 2022 conteneva gruppi di disponibilità).

2. Architettura dei gruppi di disponibilità sempre attivi

2.1 Componenti e concetti principali

2.1.1 Database di disponibilità

I database di disponibilità sono i database utente che partecipano a un gruppo di disponibilità. Questi database devono soddisfare requisiti specifici: devono utilizzare il modello di recupero completo, disporre di un backup completo ed essere presenti sulla replica primaria prima di essere aggiunti a un gruppo di disponibilità.

Quando un database si unisce a un gruppo di disponibilità, diventa parte di un set sincronizzato che esegue il failover come un'unità. Tutti i database in un gruppo di disponibilità condividono lo stesso stato di failover, il che significa che se la replica primaria fallisce, tutti i database eseguono il failover sulla stessa replica secondaria contemporaneamente. Ciò garantisce la coerenza per le applicazioni che si basano su più database correlati.

2.1.2 Repliche di disponibilità

Le repliche di disponibilità sono SQL Server Istanze che ospitano copie dei database di disponibilità. Ogni replica mantiene la propria copia fisica dei database, sincronizzata tramite la spedizione dei record del log delle transazioni. Un gruppo di disponibilità può contenere fino a nove repliche: una replica primaria e fino a otto repliche secondarie.

2.1.3 Replica primaria

La replica primaria ospita la copia di lettura e scrittura dei database di disponibilità. Tutte le modifiche ai dati (INSERIMENTO, AGGIORNAMENTO, CANCELLAZIONE) avvengono sulla replica primaria. Le applicazioni client si connettono alla replica primaria per tutte le operazioni di scrittura e, per impostazione predefinita, anche per le operazioni di lettura.

2.1.4 Repliche secondarie

Le repliche secondarie ospitano copie di sola lettura dei database di disponibilità, mantenute tramite l'applicazione continua dei record del log delle transazioni ricevuti dalla replica primaria. Ciascuna replica secondaria riceve, consolida e applica i record del log per mantenere sincronizzate le proprie copie del database con quella primaria.

2.2 Modalità di disponibilità

2.2.1 Modalità di commit sincrono

La modalità di commit sincrono garantisce una protezione contro la perdita di dati pari a zero, richiedendo alla replica primaria di attendere la conferma che i record del log delle transazioni siano stati rafforzati sulla replica secondaria prima di eseguire il commit delle transazioni. Questa modalità è essenziale per le configurazioni ad alta disponibilità in cui la perdita di dati è inaccettabile.

2.2.2 Modalità di commit asincrono

La modalità di commit asincrono dà priorità alle prestazioni della replica primaria consentendo il commit delle transazioni senza attendere che le repliche secondarie riconoscano il rafforzamento dei log. Questa modalità è adatta per le repliche di disaster recovery o quando la latenza di rete rende il commit sincrono impraticabile.

Il compromesso è la potenziale perdita di dati durante il failover. In caso di errore della replica primaria, alcune transazioni committate potrebbero non aver raggiunto la replica secondaria. L'entità della potenziale perdita di dati dipende dalla larghezza di banda della rete, dalle prestazioni della replica secondaria e dalla tempistica dell'errore. Le organizzazioni devono accettare questo rischio quando utilizzano la modalità asincrona.

2.3 Tipi di failover

2.3.1 Failover automatico

Il failover automatico consente al gruppo di disponibilità di rilevare errori nella replica primaria e di promuovere automaticamente una replica secondaria a replica primaria senza l'intervento dell'amministratore. Questa funzionalità riduce al minimo l'RTO eliminando la necessità di una risposta manuale agli errori.

Il failover automatico richiede la modalità di commit sincrono per garantire la totale assenza di perdita di dati. Se abilitato, il gruppo di disponibilità monitora costantemente lo stato della replica primaria. Se la replica primaria non risponde o si guasta, il cluster di failover di Windows Server avvia il failover automatico su una replica secondaria designata.

2.3.2 Failover manuale

Il failover manuale consente agli amministratori di trasferire intenzionalmente il ruolo di replica primaria a una replica secondaria, in genere per scopi di manutenzione pianificata o test. A differenza del failover automatico, il failover manuale richiede un'azione esplicita da parte dell'amministratore per essere avviato.

Il failover manuale senza perdita di dati è disponibile per le repliche con commit sincrono. L'amministratore avvia il failover tramite SQL Server Management Studio, Transact-SQL o PowerShell. La replica primaria termina l'elaborazione delle transazioni correnti, invia tutti i record di log rimanenti alla replica secondaria di destinazione e attende la conferma prima di trasferire il ruolo primario.

Il failover manuale può essere eseguito anche con repliche con commit asincrono, ma ciò richiede un failover forzato con potenziale perdita di dati. Gli amministratori dovrebbero utilizzare il failover manuale forzato solo in scenari di emergenza effettivi, quando la replica primaria non è disponibile e la perdita di dati è accettabile rispetto a tempi di inattività prolungati.

2.3.3 Failover forzato

Il failover forzato consente il failover su una replica secondaria asincrona o su una secondaria non completamente sincronizzata, con il riconoscimento esplicito della potenziale perdita di dati. Questa opzione è indicata come ultima risorsa quando la replica primaria non è disponibile e non esiste una replica secondaria sincronizzata.

2.4 Sincronizzazione dei dati

2.4.1 Come funziona la sincronizzazione dei dati

La sincronizzazione dei dati nei gruppi di disponibilità Always On avviene tramite l'invio continuo dei record del registro delle transazioni dalla replica primaria a tutte le repliche secondarie. Questa sincronizzazione basata sui registri garantisce la coerenza, consentendo al contempo l'archiviazione indipendente per ciascuna replica.

2.4.2 Record del registro delle transazioni e rafforzamento

Il rafforzamento dei log delle transazioni è il passaggio critico in cui i record dei log vengono scritti su un archivio durevole su repliche secondarie. Il rafforzamento garantisce che i record dei log sopravvivano ai guasti delle repliche secondarie e possano essere riprodotti durante il ripristino.

2.5 Repliche secondarie leggibili e in scala di lettura

2.5.1 Scaricamento dei carichi di lavoro di sola lettura

Le repliche secondarie leggibili consentono alle organizzazioni di scaricare i carichi di lavoro ad alta intensità di lettura dalla replica primaria, migliorando le prestazioni complessive del sistema e l'utilizzo delle risorse. Questa capacità di scalabilità in lettura è uno dei principali vantaggi dei gruppi di disponibilità rispetto alle soluzioni ad alta disponibilità più datate.

Le organizzazioni dovrebbero considerare i requisiti del carico di lavoro in sola lettura durante la progettazione delle configurazioni dei gruppi di disponibilità. Più server secondari leggibili possono distribuire il carico di reporting su più server. Gli elenchi di routing in sola lettura definiscono l'ordine in cui i server secondari ricevono connessioni con intenti di lettura, consentendo strategie di bilanciamento del carico.

2.5.2 Operazioni di backup su repliche secondarie

L'esecuzione di backup su repliche secondarie riduce il carico di input/output (I/O) e di CPU (Central Processing Unit) sulla replica primaria, consentendole di concentrarsi sui carichi di lavoro transazionali. Questa funzionalità aiuta le organizzazioni a soddisfare i requisiti di backup senza influire sulle prestazioni di produzione.

SQL Server Supporta backup completi del database, backup differenziali e backup del registro delle transazioni su repliche secondarie. Le preferenze di backup possono essere configurate per preferire repliche secondarie, primarie, solo secondarie o qualsiasi replica. Il sistema di backup seleziona automaticamente una replica appropriata in base a queste preferenze e alla disponibilità corrente.

Per ulteriori dettagli su SQL Server backup, vedere il nostro guida completa.

2.6 Ascoltatori del gruppo di disponibilità

2.6.1 Che cos'è un ascoltatore?

Un listener del gruppo di disponibilità è un nome di rete virtuale (VNN) e un indirizzo IP che le applicazioni client utilizzano per connettersi ai database del gruppo di disponibilità. Il listener reindirizza automaticamente le connessioni alla replica primaria corrente, eliminando la necessità per le applicazioni di tenere traccia di quale server sia attualmente primario.

2.6.2 Instradamento della connessione client

Il routing della connessione client tramite il listener supporta sia intenti di connessione in lettura-scrittura che in sola lettura. Il listener esamina la richiesta di connessione e la indirizza alla replica appropriata in base all'intento dell'applicazione.

3. Prerequisiti e requisiti

3.1 Clustering di failover di Windows Server per gruppi di disponibilità

3.1.1 Nozioni fondamentali sul clustering di failover di Windows Server

Windows Server Failover Clustering (WSFC) fornisce le basi per i gruppi di disponibilità Always On gestendo l'appartenenza al cluster, il monitoraggio dello stato e l'orchestrazione del failover. A differenza delle istanze del cluster di failover, i gruppi di disponibilità utilizzano WSFC solo per il coordinamento del cluster, non per la gestione dello storage condiviso.

Ogni SQL Server Ogni istanza che partecipa a un gruppo di disponibilità deve essere un nodo di un cluster WSFC. Il cluster gestisce il quorum voting, il rilevamento dello stato di integrità dei nodi e lo stato delle risorse del gruppo di disponibilità. In caso di errore della replica primaria, WSFC coordina il processo di failover e aggiorna le risorse del cluster per riflettere la nuova replica primaria.

3.1.2 Configurazione del quorum del cluster

Il quorum del cluster determina quali nodi possono operare quando si verificano problemi di connettività di rete, prevenendo scenari di "split brain" in cui più nodi si dichiarano indipendenti come primari. La configurazione del quorum definisce cosa costituisce un voto di maggioranza per le decisioni del cluster.

Sono disponibili diverse modalità di quorum per i gruppi di disponibilità:

• Node Majority utilizza solo i voti dei nodi del cluster e funziona bene per i cluster con un numero dispari di nodi.
• Node and File Share Majority aggiunge un voto di controllo sulla condivisione dei file, adatto per cluster di nodi con numero pari.
• La maggioranza dei nodi e dei dischi utilizza un testimone del disco, ma è meno comune per i gruppi di disponibilità poiché non è richiesto uno storage condiviso.

3.1.3 Clustering multi-subnet

Il clustering multi-subnet consente alle repliche dei gruppi di disponibilità di estendersi su diverse subnet di rete, supportando distribuzioni geograficamente distribuite tra data center. Questa funzionalità è essenziale per le configurazioni di disaster recovery in cui le repliche sono presenti in sedi separate.

3.2 SQL Server Requisiti dell'edizione

3.2.1 Caratteristiche dell'edizione Enterprise

SQL Server L'edizione Enterprise offre funzionalità complete di gruppi di disponibilità senza limitazioni. Supporta fino a otto repliche secondarie, secondari leggibili, seeding automatico, gruppi di disponibilità distribuiti e tutte le funzionalità avanzate.

3.2.2 Funzionalità dell'edizione standard (gruppi di disponibilità di base)

SQL Server Le versioni Standard 2016 e successive supportano i gruppi di disponibilità di base con significative limitazioni. I gruppi di disponibilità di base offrono funzionalità di alta disponibilità essenziali a un costo inferiore, risultando adatti alle organizzazioni con esigenze più semplici.

4. Configurazione dei gruppi di disponibilità Always On

4.1 Preparazione dell'ambiente

Prima di creare un gruppo di disponibilità, è necessario preparare adeguatamente l'ambiente con account Active Directory, configurazioni del server e infrastruttura di rete.

4.1.1 Configurazione del controller di dominio

Il controller di dominio Active Directory deve essere configurato per supportare il cluster del gruppo di disponibilità e SQL Server account di servizio.

1. Accedi al controller di dominio con le credenziali di amministratore di dominio.
2. Apri Server manager e vai a Strumenti -> Utenti e computer di Active Directory.
3. Creare un'unità organizzativa per SQL Server oggetti se non ne esiste uno.
4. Verificare che gli oggetti computer per tutti i nodi del cluster esistano in Active Directory.
5. Assicurarsi che i servizi DNS (Domain Name System) siano configurati correttamente e che tutti i nomi dei server vengano risolti correttamente.

4.1.2 Creazione di account di servizio

Creare account di servizio Active Directory dedicati per SQL Server servizi su ciascun nodo.

1. Apri Utenti e computer di Active Directory sul controller di dominio.
2. Fare clic con il pulsante destro del mouse sull'unità organizzativa appropriata e selezionare New -> Utente.
3. Immettere il nome dell'account di servizio (ad esempio, svc_SQLServer) e impostare Nome di accesso dell'utente.
4. Clicchi Avanti e inserisci una password complessa.
5. Seleziona L'utente non può cambiare la password and La password non ha scadenza.
6. Clicchi Avanti e poi Finitura per creare l'account.
7. Ripetere l'operazione per eventuali account di servizio aggiuntivi necessari (SQL Server Agente, SSRS, ecc.).

4.1.3 Configurazione delle autorizzazioni dell'amministratore

Account di servizio e account utilizzati per configurare SQL Server deve disporre delle autorizzazioni appropriate su tutti i nodi del cluster.

1. Accedere a ciascun server del nodo del cluster.
2. Apri Gestione computer dal Inizio menu o Server Manager.
3. Espandere Utenti e gruppi locali e seleziona Gruppi.
4. Fare clic con Gli amministratori e seleziona Proprietà a Confronto.
5. Clicchi Aggiungi e immettere il nome dell'account di servizio.
6. Clicchi Controlla i nomi per convalidare l'account, quindi fare clic OK.
7. Clicchi OK per chiudere la finestra di dialogo Proprietà amministratore.
8. Ripetere l'operazione su tutti i nodi del cluster.

4.2 Installazione e configurazione di WSFC

Prima di abilitare Always On Availability Groups, è necessario installare e configurare Windows Server Failover Clustering su tutti i nodi.

4.2.1 Installazione della funzionalità di clustering di failover

Installare la funzionalità Failover Clustering su ogni server che parteciperà al gruppo di disponibilità.

1. Apri Server manager sul primo nodo del cluster.
2. Clicchi gestire -> Aggiungi ruoli e funzionalità.
3. Clicchi Avanti attraverso le schermate introduttive.
4. Seleziona Installazione basata su ruoli o funzionalità e fare clic su Avanti.
5. Seleziona il server locale e fai clic Avanti.
6. Salta la schermata Ruoli e fai clic su Avanti.
7. Nella schermata Caratteristiche, seleziona Clustering di failover.
8. Clicchi Aggiungi funzionalità quando viene richiesto di includere strumenti di gestione.
9. Clicchi Avanti e poi Installazione.
10. Attendi il completamento dell'installazione e clicca Chiudi.
11. Ripetere l'operazione su tutti i server che parteciperanno al cluster.

4.2.2 Creazione del cluster di failover

Dopo aver installato la funzionalità Failover Clustering su tutti i nodi, creare il cluster da un nodo.

1. Apri Gestore del cluster di failover da Server manager -> Strumenti.
2. Clicchi Crea cluster nel riquadro Azioni.
3. Clicchi Avanti nella pagina Prima di iniziare.
4. Clicchi Scopri la nostra gamma di prodotti e aggiungere tutti i server che saranno nodi del cluster.
5. Clicchi Avanti dopo aver aggiunto tutti i nodi.
6. Lasciare Esegui tutti i test (consigliato) selezionato e clicca Avanti.
7. Esaminare i risultati dei test di convalida e correggere eventuali errori o avvisi.
8. Clicchi Finitura dopo che la convalida è stata completata con successo.
9. Immettere un nome per il cluster e un indirizzo IP.
10. Deseleziona Aggiungi tutto lo storage idoneo al cluster poiché non è richiesto uno spazio di archiviazione condiviso.
11. Clicchi Avanti e rivedere la conferma.
12. Clicchi Finitura per creare il cluster.

4.2.3 Convalida della configurazione del cluster

Convalidare la configurazione del cluster per garantire che tutti i nodi possano comunicare correttamente e che il cluster funzioni correttamente.

1. In Gestore del cluster di failover, fare clic con il pulsante destro del mouse sul nome del cluster.
2. Seleziona Convalida Cluster dal menu.
3. Clicchi Avanti nella pagina Prima di iniziare.
4. Seleziona Esegui tutti i test (consigliato) e fare clic su Avanti.
5. Clicchi Avanti per iniziare i test di convalida.
6. Al termine dei test, rivedere il rapporto di convalida.
7. Risolvere eventuali errori o avvisi identificati nel rapporto.
8. Clicchi Finitura per chiudere la procedura guidata.

4.3 Installazione SQL Server per gruppi di disponibilità

Installazione SQL Server su ciascun nodo che parteciperà al gruppo di disponibilità utilizzando l'opzione di installazione autonoma.

1. Corri il SQL Server supporto di installazione sul primo nodo.
2. Seleziona New SQL Server installazione autonoma.
3. Inserisci il codice Product Key o seleziona la versione di valutazione.
4. Accettare i termini della licenza e fare clic Avanti.
5. Completare i controlli dei prerequisiti e risolvere eventuali problemi.
6. Nella pagina Selezione funzionalità, seleziona Servizi del motore di database.
7. Configurare il nome dell'istanza (utilizzare lo stesso nome dell'istanza su tutti i nodi).
8. Nella pagina Configurazione server, specificare le credenziali dell'account di servizio.
9. Configura i tipi di avvio del servizio come Automatico.
10. Nella pagina Configurazione del motore di database, selezionare la modalità di autenticazione.
11. Aggiungere account amministratore.
12. Configurare le directory dei dati utilizzando percorsi coerenti in tutti i nodi.
13. Completare l'installazione e verificarne il successo.
14. Ripetere l'installazione su tutti gli altri nodi del cluster con impostazioni identiche.

4.4 Abilitazione della funzionalità Gruppi di disponibilità sempre attivi

Dopo l'installazione SQL Server su tutti i nodi, abilitare la funzionalità Gruppi di disponibilità sempre attivi su ogni istanza.

4.4.1 Abilitazione tramite SQL Server Gestore configurazione

Usa il SQL Server Configuration Manager per abilitare i gruppi di disponibilità Always On tramite l'interfaccia grafica.

1. Apri SQL Server Gestore configurazione sul primo nodo.
2. Espandere SQL Server Servizi nel riquadro di sinistra.
3. Fare clic con il tasto destro del mouse su SQL Server istanza e seleziona Proprietà a Confronto.
4. Clicca su Alta disponibilità AlwaysOn scheda.
5. Vedi Abilita gruppi di disponibilità AlwaysOn.
6. Verificare che il nome del cluster di failover di Windows sia corretto.
7. Clicchi OK per salvare le modifiche.
8. Clicchi OK sull'avviso che il servizio deve essere riavviato.
9. Fare clic con il tasto destro del mouse su SQL Server servizio e selezione Restart.
10. Attendi che il servizio si riavvii correttamente.
11. Ripetere l'operazione su tutti i nodi del cluster.

4.4.2 Abilitazione tramite PowerShell

PowerShell fornisce un metodo con script per abilitare i gruppi di disponibilità Always On su più nodi.

1. Aprire PowerShell come amministratore sul primo nodo.
2. Importa il SQL Server Modulo PowerShell:

   Import-Module SQLPS -DisableNameChecking

3. Abilita gruppi di disponibilità sempre attivi:

   Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

4. Il servizio si riavvierà automaticamente quando si utilizza il parametro Force.
5. Verificare che la funzionalità sia abilitata:

   Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

6. Ripetere l'operazione per ciascun nodo del cluster, sostituendo i nomi appropriati del server e dell'istanza.

4.4.3 Verifica dell'abilitazione della funzionalità

Verificare che Always On Availability Groups sia abilitato su tutte le istanze prima di procedere con la configurazione.

1. Connettiti a ciascuno SQL Server istanza utilizzando SQL Server Studio di gestione.
2. Apri una nuova finestra di query ed esegui:

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. Verificare che il risultato sia 1 (abilitato).
4. Controllare che il SQL Server l'istanza appare in Failover Cluster Manager nei ruoli del cluster.
5. Verificare che l'endpoint del gruppo di disponibilità esista eseguendo:

   SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'

6. Se l'endpoint non esiste, verrà creato durante la creazione del gruppo di disponibilità.

4.5 Preparazione dei database per i gruppi di disponibilità

I database devono soddisfare requisiti specifici prima di poter essere aggiunti a un gruppo di disponibilità.

4.5.1 Requisiti del modello di ripristino del database

Modificare il modello di ripristino del database su COMPLETO sulla replica primaria prima di aggiungerla a un gruppo di disponibilità.

1. Connettersi alla replica primaria utilizzando SQL Server Studio di gestione.
2. Fare clic con il pulsante destro del mouse sul database e selezionare Proprietà a Confronto.
3. Seleziona il Opzioni .
4. Cambiare Modello di recupero a Lunga.
5. Clicchi OK per salvare la modifica.
6. In alternativa, utilizzare Transact-SQL:

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 Esecuzione di backup completi del database

Eseguire un backup completo del database per stabilire la catena di backup richiesta per i gruppi di disponibilità.

1. In SQL Server Management Studio, fare clic con il pulsante destro del mouse sul database.
2. Seleziona Compiti -> Backup.
3. Verifica Tipo di backup è impostato su Lunga.
4. Seleziona una destinazione di backup o aggiungine una nuova.
5. Clicchi OK per eseguire il backup.
6. In alternativa, utilizzare Transact-SQL:

   BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

4.5.3 Esecuzione di backup del registro delle transazioni

Eseguire un backup del registro delle transazioni per garantire che la catena di registri sia stabilita e ridurre al minimo i tempi di inizializzazione.

1. In SQL Server Management Studio, fare clic con il pulsante destro del mouse sul database.
2. Seleziona Compiti -> Backup.
3. Cambiare Tipo di backup a Registro delle transazioni.
4. Selezionare una destinazione di backup.
5. Clicchi OK per eseguire il backup.
6. In alternativa, utilizzare Transact-SQL:

   BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

4.6 Creazione del gruppo di disponibilità

Crea il gruppo di disponibilità utilizzando uno dei vari metodi disponibili, a seconda delle tue preferenze e dei requisiti di automazione.

4.6.1 Utilizzo della procedura guidata Nuovo gruppo di disponibilità

La procedura guidata Nuovo gruppo di disponibilità fornisce un'interfaccia grafica per la creazione di gruppi di disponibilità.

1. In SQL Server In Management Studio, connettiti all'istanza che ospiterà la replica primaria.
2. Espandere Alta disponibilità AlwaysOn in Esplora oggetti.
3. Fare clic con Gruppi di disponibilità e seleziona Creazione guidata nuovo gruppo di disponibilità.
   
4. Clicchi Avanti nella pagina Introduzione.
5. Inserisci un nome per il gruppo di disponibilità e fai clic su Avanti.
6. Nella pagina Seleziona database, seleziona i database da includere.
7. Verificare che i database soddisfino tutti i prerequisiti e fare clic Avanti.
8. Nella pagina Specifica repliche, fare clic su Aggiungi replica.
9. Connettersi a ciascuna istanza di replica secondaria.
10. Configurare le proprietà della replica per ogni istanza (modalità di disponibilità, modalità di failover).
11. Clicca su endpoint scheda e rivedere la configurazione dell'endpoint.
12. Clicca su Preferenze di backup scheda e configurare le priorità di backup.
13. Clicca su Ascoltatore scheda e, facoltativamente, creare un listener.
14. Clicchi Avanti e seleziona il metodo di sincronizzazione dei dati.
15. Esaminare i risultati della convalida e risolvere eventuali problemi.
16. Clicchi Avanti e rivedere il riepilogo.
17. Clicchi Finitura per creare il gruppo di disponibilità.
18. Monitorare i progressi e verificare la corretta creazione.

4.6.2 Utilizzo di Transact-SQL

Crea gruppi di disponibilità utilizzando Transact-SQL per distribuzioni ripetibili e programmabili.

1. Creare il gruppo di disponibilità sulla replica primaria:

   CREATE AVAILABILITY GROUP AG_Name
   FOR DATABASE DatabaseName
   REPLICA ON
     'PrimaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
     'SecondaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

2. Unisci la replica secondaria al gruppo di disponibilità:

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. Unisciti al database secondario:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 Utilizzo di PowerShell

PowerShell fornisce funzionalità di scripting per la creazione e la gestione dei gruppi di disponibilità.

1. Creare l'oggetto gruppo di disponibilità:

   $AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

2. Aggiungi database:

   Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

3. Configurare le repliche con le proprietà desiderate utilizzando il cmdlet New-SqlAvailabilityReplica.
4. Unisci le repliche secondarie utilizzando il cmdlet Join-SqlAvailabilityGroup.

4.7 Aggiunta di repliche al gruppo di disponibilità

Configurare le proprietà specifiche della replica che controllano il modo in cui ogni istanza partecipa al gruppo di disponibilità.

4.7.1 Configurazione delle proprietà di replica

Impostare le proprietà per ogni replica per definirne il ruolo e le capacità all'interno del gruppo di disponibilità.

1. In SQL Server Management Studio, espandi Alta disponibilità AlwaysOn -> Gruppi di disponibilità.
2. Espandi il gruppo di disponibilità e quindi espandi Repliche di disponibilità.
   
3. Fare clic con il pulsante destro del mouse su una replica e selezionare Proprietà a Confronto.
4. Rivedere e modificare le impostazioni di connessione per i ruoli primari e secondari.
5. Se necessario, configurare i valori di timeout della sessione.
6. Clicchi OK per salvare le modifiche.

4.7.2 Impostazione delle modalità di disponibilità

Configurare la modalità di disponibilità per controllare il comportamento di sincronizzazione tra le repliche.

1. Fare clic con il pulsante destro del mouse sul gruppo di disponibilità e selezionare Proprietà a Confronto.
2. Nel General pagina, vai al Repliche di disponibilità .
3. Per ogni replica, seleziona Commit sincrono or Commit asincrono dal menu a discesa.
4. Utilizzare il commit sincrono per le repliche locali ad alta disponibilità.
5. Utilizzare il commit asincrono per repliche di disaster recovery geograficamente distanti.
6. Clicchi OK per salvare la configurazione.

4.7.3 Impostazione delle modalità di failover

Configurare la modalità di failover per controllare come avviene il failover per ogni replica.

1. Fare clic con il pulsante destro del mouse sul gruppo di disponibilità e selezionare Proprietà a Confronto.
2. Nel General pagina, vai al Repliche di disponibilità .
3. Per le repliche di commit sincrone, selezionare Automatico or Manuale modalità failover.
4. Il failover automatico richiede la modalità di commit sincrono e consente il failover non presidiato.
5. Per le repliche con commit asincrono è disponibile solo il failover manuale.
6. Configurare fino a tre repliche per il failover automatico (una primaria e due secondarie).
7. Clicchi OK per applicare le impostazioni.

4.7.4 Configurazione delle preferenze di backup

Imposta le preferenze di backup per controllare dove devono avvenire le operazioni di backup.

1. Fare clic con il pulsante destro del mouse sul gruppo di disponibilità e selezionare Proprietà a Confronto.
2. Seleziona Preferenze di backup nel riquadro di sinistra.
3. Scegli una delle preferenze di backup:
   • Preferisci secondario: Backup sul secondario se disponibile, altrimenti sul primario
   • Solo secondario: Backup solo su repliche secondarie
   • Primario: Backup solo sulla replica primaria
   • Qualsiasi replica: Backup su qualsiasi replica disponibile
4. Imposta i valori di priorità del backup per ogni replica (0-100).
5. Valori di priorità più elevati indicano destinazioni di backup preferite.
6. Clicchi OK per salvare le preferenze.

4.8 Configurazione dell'ascoltatore del gruppo di disponibilità

Creare un listener per fornire un singolo punto di connessione che reindirizza automaticamente alla replica primaria corrente.

4.8.1 Creazione dell'ascoltatore

Aggiungere un listener al gruppo di disponibilità per la gestione della connessione client.

1. In SQL Server Management Studio, espandere il gruppo di disponibilità.
2. Fare clic con Listener del gruppo di disponibilità e seleziona Aggiungi ascoltatore.
   
3. Immettere un nome DNS per l'ascoltatore (ad esempio, AG_Listener).
4. Immettere il numero di porta (il valore predefinito è 1433).
5. Seleziona IP statico per la modalità di rete.
6. Clicchi Aggiungi per aggiungere un indirizzo IP per ogni subnet.
7. Inserisci l'indirizzo IP e seleziona la subnet.
8. Clicchi OK per creare l'ascoltatore.
9. Verificare che l'ascoltatore sia visualizzato in Esplora oggetti e sia online.

4.8.2 Configurazione delle impostazioni DNS e IP

Verificare la registrazione DNS e la configurazione di rete per l'ascoltatore.

1. Aprire Gestione DNS sul controller di dominio.
2. Verificare che il nome dell'ascoltatore sia stato registrato con tutti gli indirizzi IP.
3. Testare la risoluzione DNS dai computer client:

   nslookup ListenerName

4. Verificare che tutti gli indirizzi IP configurati vengano restituiti.
5. In Gestione cluster di failover, espandere Ruoli e seleziona il gruppo di disponibilità.
6. Verificare che le risorse dell'indirizzo IP siano online.
7. Verificare che la risorsa del nome di rete sia online.
   

4.8.3 Test della connettività dell'ascoltatore

Verificare che le applicazioni client possano connettersi tramite il listener.

1. Da una macchina client, apri SQL Server Studio di gestione.
2. Connettersi utilizzando il nome dell'ascoltatore anziché il nome del server.
3. Eseguire una query per verificare la connessione alla replica primaria corrente:

   SELECT @@SERVERNAME;

4. Testare il routing con intento di lettura aggiungendo ApplicationIntent=ReadOnly alla stringa di connessione.
5. Verificare che la connessione reindirizzi a una replica secondaria leggibile.
6. Eseguire il failover di prova eseguendo manualmente il failover del gruppo di disponibilità e verificando la riconnessione.

4.9 Metodi di sincronizzazione dei dati

Scegliere un metodo di sincronizzazione dei dati per inizializzare le repliche secondarie con copie del database.

4.9.1 Seeding automatico

Il seeding automatico trasferisce i dati del database sulla rete senza richiedere backup e ripristini manuali.

1. Durante la creazione del gruppo di disponibilità, selezionare Semina automatica come metodo di sincronizzazione.
   
2. Garantire la connettività di rete e una larghezza di banda sufficiente tra le repliche.
3. La replica primaria trasmette automaticamente i dati del database alle repliche secondarie.
4. Monitorare l'avanzamento del seeding tramite la dashboard del gruppo di disponibilità o i DMV.
5. La semina automatica richiede SQL Server 2016 o successivo.
6. Per i database di grandi dimensioni, considerare l'impatto sulla rete e pianificare durante i periodi di basso utilizzo.

4.9.2 Seeding manuale (backup e ripristino)

Il seeding manuale prevede l'esecuzione di backup sul server primario e il loro ripristino sulle repliche secondarie.

1. Sulla replica primaria, eseguire un backup completo:

   BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';

2. Eseguire un backup del registro delle transazioni:

   BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';

3. Su ogni replica secondaria, ripristinare il backup completo:

   RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;

4. Ripristina il backup del registro:

   RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

5. Aggiungi il database al gruppo di disponibilità:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. Verificare che la sincronizzazione abbia inizio e che il database raggiunga lo stato SINCRONIZZATO.

4.9.3 File di snapshot del database

Utilizzare i file snapshot del database per inizializzare repliche secondarie dai file del database esistenti.

1. Scollegare o eseguire il backup del database sulla replica primaria.
2. Copiare i file del database in ogni replica secondaria utilizzando gli stessi percorsi dei file.
3. Nelle repliche secondarie, collegare il database o eseguire il ripristino senza recupero.
4. Assicurarsi che il database sia in stato di RIPRISTINO.
5. Aggiungere il database al gruppo di disponibilità.
6. Questo metodo è utile per database molto grandi in cui il trasferimento in rete sarebbe impraticabile.

5. FAQ

5.1 Domande generali

D: Qual è la differenza tra Always On FCI e Always On AG?

R: Le istanze Always On Failover Cluster garantiscono elevata disponibilità a livello di istanza utilizzando storage condiviso, mentre gli Always On Availability Group garantiscono elevata disponibilità a livello di database senza storage condiviso. AG offre secondari leggibili e una distribuzione geografica più flessibile.

D: Posso utilizzare Always On Availability Groups con SQL Server Edizione standard?

A: Sì, SQL Server La Standard Edition 2016 e le versioni successive supportano i Basic Availability Group con limitazioni, tra cui un database per AG, due repliche al massimo e nessun supporto secondario leggibile.

D: Ho bisogno di spazio di archiviazione condiviso per i gruppi di disponibilità Always On?

R: No, i gruppi di disponibilità non richiedono storage condiviso. Ogni replica mantiene copie indipendenti dei database su storage locale, sincronizzate tramite il transaction log shipping.

D: Qual è il numero massimo di repliche in un gruppo di disponibilità?

A: SQL Server L'edizione Enterprise supporta fino a nove repliche (una primaria e otto secondarie). I gruppi di disponibilità distribuiti possono supportare fino a un massimo di 18 repliche totali su due gruppi di disponibilità.

5.2 Domande di configurazione

D: Come faccio a scegliere tra le modalità di commit sincrone e asincrone?

R: Utilizzare il commit sincrono per esigenze di zero perdita di dati all'interno dello stesso data center o di reti a bassa latenza. Utilizzare il commit asincrono per repliche di disaster recovery distanti, in cui il commit sincrono influirebbe sulle prestazioni.

D: Posso combinare repliche sincrone e asincrone nello stesso gruppo di disponibilità?

R: Sì, i gruppi di disponibilità supportano configurazioni miste con repliche sia sincrone che asincrone. Ciò consente l'alta disponibilità locale con repliche sincrone e il disaster recovery remoto con repliche asincrone.

D: Cosa succede alle mie connessioni durante il failover?

R: Le connessioni esistenti vengono interrotte quando si verifica il failover. Le applicazioni con logica di ripetizione della connessione si riconnettono automaticamente al nuovo server primario tramite il listener. Il processo di failover si completa in genere in pochi secondi o minuti.

D: Devo sincronizzare gli accessi e i processi tra le repliche?

R: Dentro SQL Server 2019 e versioni precedenti, sì: gli accessi, i processi di SQL Agent e i server collegati devono essere sincronizzati manualmente. SQL Server Il 2022 introduce gruppi di disponibilità contenuti che includono automaticamente questi oggetti.

5.3 Domande di gestione

D: Posso eseguire backup su repliche secondarie?

R: Sì, le repliche secondarie supportano backup completi, differenziali e del registro delle transazioni. Configura le preferenze di backup per scaricare i backup dalla replica primaria e ridurne l'utilizzo delle risorse.

D: Come faccio a patchare SQL Server con tempi di inattività minimi?

R: Utilizzare gli aggiornamenti progressivi applicando prima le patch alle repliche secondarie, quindi eseguendo un failover manuale su una replica secondaria con patch e infine applicando le patch alla replica primaria precedente. In questo modo si riducono al minimo i tempi di inattività per la durata del failover.

D: Posso aggiungere database a un gruppo di disponibilità esistente?

R: Sì, i database possono essere aggiunti ai gruppi di disponibilità in esecuzione. Il database deve essere in modalità di ripristino completo con un backup completo e le repliche secondarie devono essere sottoposte a seeding automatico o a backup e ripristino manuali.

D: Cos'è la semina automatica e dovrei usarla?

R: Il seeding automatico trasferisce i dati del database in rete per inizializzare repliche secondarie senza backup manuali. Utilizzatelo per database di piccole dimensioni o quando la larghezza di banda di rete è sufficiente. Per database di grandi dimensioni, il seeding manuale potrebbe essere più rapido.

D: Dove dovrei eseguire DBCC CHECKDB in un gruppo di disponibilità?

R: È consigliabile eseguire DBCC CHECKDB sulle repliche secondarie per ridurre il carico sulla replica primaria. I controlli di coerenza del database possono essere eseguiti sui database secondari senza influire sulle prestazioni della replica primaria.

Per maggiori dettagli su DBCC CHECKDB, vedere il nostro guida completa.

5.4 Domande sulla risoluzione dei problemi

D: Perché il mio database è nello stato NON SINCRONIZZATO?

R: Le cause più comuni includono problemi di connettività di rete, sospensione dello spostamento dei dati, spazio su disco insufficiente sulle repliche secondarie o problemi agli endpoint. Verificare la descrizione dello stato di sincronizzazione e SQL Server registri degli errori per dettagli specifici. Se il database secondario ha inserito un stato di recupero o spettacoli recupero in sospesoPer soluzioni mirate, consultare le guide collegate.

D: Come posso forzare il failover quando il server primario non è disponibile?

A: Connettersi a una replica secondaria ed eseguire ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. In questo modo si riconosce la potenziale perdita di dati e si promuove immediatamente la replica secondaria a primaria.

D: Perché i client non riescono a connettersi al mio listener?

A: Verificare che l'ascoltatore sia online in Failover Cluster Manager, che la registrazione DNS sia riuscita, che tutti gli IP dell'ascoltatore siano raggiungibili dai client e che le regole del firewall consentano il traffico sulla porta dell'ascoltatore.

D: Cosa significa una coda di redo di grandi dimensioni?

R: Una coda di redo di grandi dimensioni indica che la replica secondaria non è in grado di applicare i record di log con la stessa rapidità con cui arrivano. Ciò potrebbe indicare colli di bottiglia di I/O del disco, vincoli della CPU o blocchi da query di sola lettura sulla replica secondaria.

D: Cosa devo fare se un disastro colpisce tutte le repliche e anche i miei backup risultano danneggiati?

A: Questo scenario peggiore, sebbene estremamente raro, può verificarsi a causa di attacchi ransomware, guasti di archiviazione diffusi o disastri a cascata. La tua difesa principale è la prevenzione: mantieni repliche distribuite geograficamente, archivia i backup in posizioni separate e
testare regolarmente le procedure di disaster recovery. Se tutte le opzioni di ripristino standard falliscono, un Strumento di recupero dati SQL può tentare di estrarre dati da file MDF danneggiati come misura di ultima istanza in caso di emergenza.

5.5 Domande relative a licenze e costi

D: Come vengono concessi in licenza i gruppi di disponibilità Always On?

A: SQL Server Le licenze dipendono dall'edizione e dal modello di distribuzione. I gruppi di disponibilità Enterprise Edition richiedono licenze Enterprise su tutte le repliche. Le repliche secondarie passive possono beneficiare di licenze gratuite a determinate condizioni.

D: Posso usare SQL Server Developer Edition per gruppi di disponibilità?

R: Sì, la Developer Edition include tutte le funzionalità della Enterprise Edition, incluso il supporto completo dei gruppi di disponibilità. Tuttavia, la licenza è concessa solo per lo sviluppo e il test, non per l'uso in produzione.

D: I file secondari leggibili richiedono licenze aggiuntive?

R: La licenza dipende dallo scenario. I server secondari passivi per il disaster recovery in genere non richiedono licenze. I server secondari attivi che gestiscono carichi di lavoro in sola lettura generalmente richiedono licenze, sebbene i termini specifici possano variare.

D: Esiste un modo gratuito per ottenere un'elevata disponibilità con SQL Server?

A: SQL Server Express Edition non supporta i gruppi di disponibilità. SQL Server L'edizione Standard supporta i gruppi di disponibilità di base a partire da SQL Server 2016, che offre un'elevata disponibilità di base ai costi di licenza della Standard Edition.

D: Cosa sono i gruppi di disponibilità distribuiti?

R: I gruppi di disponibilità distribuiti sono un tipo speciale di gruppo di disponibilità che si estende su due gruppi di disponibilità separati, consentendo scenari che superano le capacità dei gruppi di disponibilità tradizionali. Introdotti in SQL Server 2016, i gruppi di disponibilità distribuiti soddisfano i requisiti di scalabilità e distribuzione geografica.

6. CONCLUSIONE

6.1 Riepilogo dei punti chiave

SQL Server I Gruppi di Disponibilità Always On rappresentano la principale soluzione Microsoft per l'alta disponibilità e il disaster recovery per database mission-critical. Offrono failover a livello di database senza requisiti di storage condiviso, repliche secondarie leggibili per l'offload dei carichi di lavoro e una distribuzione geografica flessibile per una protezione completa dei dati. Per le organizzazioni che utilizzano ancora soluzioni come spedizione di tronchi or replicazione di, i gruppi di disponibilità offrono un percorso di aggiornamento più robusto e operativamente più semplice.

6.2 Quando utilizzare i gruppi di disponibilità Always On

Scegliete i gruppi di disponibilità quando è richiesta un'elevata disponibilità a livello di database con funzionalità di failover automatico. Le organizzazioni che necessitano di protezione contro la perdita di dati per i database critici traggono vantaggio dalle repliche con commit sincrono e failover automatico. Le applicazioni che richiedono funzionalità di lettura su larga scala sfruttano repliche secondarie leggibili per distribuire i carichi di lavoro delle query.

6.3 Guida introduttiva all'implementazione

Iniziare la pianificazione del gruppo di disponibilità valutando i requisiti aziendali, inclusi RTO, RPO e vincoli di budget. Documentare l'infrastruttura del database attuale, le dipendenze delle applicazioni e le lacune in termini di alta disponibilità. Progettare un'architettura del gruppo di disponibilità che soddisfi i requisiti pur rimanendo entro i vincoli di risorse.

Referenze

• Documento ufficiale Microsoft: Che cos'è un gruppo di disponibilità Always On?
• Documento ufficiale Microsoft: Guida introduttiva ai gruppi di disponibilità Always On
• Documento ufficiale Microsoft: Gruppi di disponibilità distribuiti

---

L'autore

Yuan Sheng è un amministratore di database senior (DBA) con oltre 10 anni di esperienza in SQL Server ambienti e gestione di database aziendali. Ha risolto con successo centinaia di scenari di ripristino di database in aziende di servizi finanziari, sanitari e manifatturiere.

Yuan è specializzato in SQL Server Ripristino di database, soluzioni ad alta disponibilità e ottimizzazione delle prestazioni. La sua vasta esperienza pratica include la gestione di database multi-terabyte, l'implementazione di gruppi di disponibilità Always On e lo sviluppo di strategie di backup e ripristino automatizzate per sistemi aziendali mission-critical.

Grazie alla sua competenza tecnica e al suo approccio pratico, Yuan si concentra sulla creazione di guide complete che aiutano gli amministratori di database e i professionisti IT a risolvere problemi complessi SQL Server sfide in modo efficiente. Si mantiene aggiornato con le ultime SQL Server versioni e le tecnologie di database in continua evoluzione di Microsoft, testando regolarmente gli scenari di ripristino per garantire che le sue raccomandazioni riflettano le migliori pratiche del mondo reale.

Hai domande su SQL Server recupero o hai bisogno di ulteriore assistenza per la risoluzione dei problemi del database? Yuan accoglie feedback e suggerimenti per migliorare queste risorse tecniche.