Prerequisiti, restrizioni e consigli per i gruppi di disponibilità Always On

Si applica a: SQL Server (tutte le versioni supportate)

Questo articolo descrive le considerazioni per la distribuzione di gruppi di disponibilità Always On, inclusi prerequisiti, restrizioni e raccomandazioni per i computer host, i cluster di failover di Windows Server (WSFC), le istanze del server e i gruppi di disponibilità. Per ognuno di questi componenti sono indicate le eventuali considerazioni sulla sicurezza e le autorizzazioni richieste.

Importante

Prima di distribuire Always On gruppi di disponibilità, è consigliabile leggere ogni sezione di questo argomento.

Hotfix di .NET che supportano i gruppi di disponibilità

A seconda dei componenti e delle funzionalità di SQL Server usati con i gruppi di disponibilità Always On, potrebbe essere necessario installare hotfix .NET aggiuntivi identificati nella tabella seguente. Gli hotfix possono essere installati in qualsiasi ordine.

Funzionalità dipendente Hotfix Collegamento
Reporting Services L'hotfix per .NET 3.5 SP1 aggiunge il supporto a SQL Client per le funzionalità AlwaysOn di Read-intent, readonly e multisubnetfailover. L'hotfix deve essere installato in ogni Reporting Services server di report. KB 2654347: Hotfix per .NET 3.5 SP1 per aggiungere supporto alle funzionalità Always On

Elenco di controllo: requisiti (sistema Windows)

Per supportare la funzionalità Always On gruppi di disponibilità, assicurarsi che ogni computer che partecipa a uno o più gruppi di disponibilità soddisfi i requisiti fondamentali seguenti:

Requisito Collegamento
Assicurarsi che il sistema non sia un controller di dominio. I gruppi di disponibilità non sono supportati nei controller di dominio.
Assicurarsi che in ogni computer sia eseguita la versione di Windows Server 2012 o successive. Requisiti hardware e software per l'installazione di SQL Server 2016
Assicurarsi che ogni computer sia un nodo in un cluster WSFC. WSFC (Windows Server Failover Clustering) con SQL Server
Assicurarsi che nel cluster WSFC siano contenuti nodi sufficienti per supportare le configurazioni dei gruppi di disponibilità. Un nodo del cluster può ospitare una sola replica per un gruppo di disponibilità. Lo stesso nodo non può ospitare due repliche dallo stesso gruppo di disponibilità. Il nodo del cluster può partecipare a più gruppi di disponibilità, con una replica da ogni gruppo.

Chiedere agli amministratori del database il numero di nodi del cluster necessario per supportare le repliche di disponibilità dei gruppi di disponibilità pianificati.

Panoramica dei gruppi di disponibilità Always On (SQL Server).

Importante

Inoltre, assicurarsi che l'ambiente sia configurato correttamente per la connessione a un gruppo di disponibilità. Per altre informazioni, vedere connettività client Always On (SQL Server).

Indicazioni per computer in cui sono ospitate repliche di disponibilità (sistema Windows)

  • Sistemi paragonabili: Per un determinato gruppo di disponibilità, tutte le repliche di disponibilità devono essere eseguite su sistemi paragonabili che possono gestire carichi di lavoro identici.

  • Schede di rete dedicate: Per ottenere prestazioni ottimali, usare una scheda di rete dedicata (scheda di interfaccia di rete) per Always On gruppi di disponibilità.

  • Spazio su disco sufficiente: Ogni computer in cui un'istanza del server ospita una replica di disponibilità deve disporre di spazio su disco sufficiente per tutti i database nel gruppo di disponibilità. Tenere presente che, con l'aumentare delle dimensioni dei database primari, i database secondari corrispondenti aumentano di conseguenza.

Autorizzazioni (sistema Windows)

Per amministrare un cluster WSFC, l'utente deve essere un amministratore di sistema in ogni nodo del cluster.

Per altre informazioni sull'account per l'amministrazione del cluster, vedere Appendice A: Requisiti di un cluster di failover.

Attività correlate (sistema Windows)

Attività Collegamento
Impostare il valore HostRecordTTL. Modificare HostRecordTTL (tramite Windows PowerShell)

Modificare HostRecordTTL (tramite Windows PowerShell)

  1. Aprire la finestra di PowerShell con Esegui come amministratore.

  2. Importare il modulo FailoverClusters.

  3. Usare il cmdlet Get-ClusterResource per cercare la risorsa nome di rete, quindi usare il cmdlet Set-ClusterParameter per impostare il valore HostRecordTTL , come segue:

    Get-ClusterResource "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL<TimeInSeconds>

    Nell'esempio di PowerShell seguente impostare HostRecordTTL su 300 secondi per una risorsa nome di rete denominata SQL Network Name (SQL35).

    Import-Module FailoverClusters  
    
    $nameResource = "SQL Network Name (SQL35)"  
    Get-ClusterResource $nameResource | Set-ClusterParameter ClusterParameter HostRecordTTL 300  
    

    Suggerimento

    Ogni volta che viene aperta una nuova finestra di PowerShell, è necessario importare il modulo FailoverClusters .

Contenuto correlato (sistema Windows)

Prerequisiti e restrizioni dell'istanza di SQL Server

Ogni gruppo di disponibilità richiede un set di partner di failover, noti come repliche di disponibilità, ospitate da istanze di SQL Server. Un'istanza del server specificata può essere un'istanza autonoma o un'istanzadel cluster SQL Server failover (FCI).

Contenuto della sezione

Elenco di controllo: prerequisiti (istanza del server)

Prerequisito Collegamenti
Il computer host deve essere un nodo WSFC. Le istanze di SQL Server che ospitano repliche di disponibilità per un determinato gruppo di disponibilità risiedono in nodi separati del cluster. Quando viene eseguita la migrazione a un cluster diverso, un gruppo di disponibilità può risiedere temporaneamente in due cluster. SQL Server 2016 introduce i gruppi di disponibilità distribuita. In un gruppo di disponibilità distribuita due gruppi di disponibilità gruppo risiedono in cluster diversi. WSFC (Windows Server Failover Clustering) con SQL Server

Clustering di failover e gruppi di disponibilità Always On (SQL Server)

Gruppi di disponibilità distribuiti (gruppi di disponibilità AlwaysOn)
Se si desidera che in un gruppo di disponibilità venga utilizzato Kerberos:

In tutte le istanze del server in cui è ospitata una replica di disponibilità per il gruppo di disponibilità deve essere utilizzato lo stesso account del servizio SQL Server.

L'amministratore di dominio deve registrare manualmente un nome dell'entità servizio (SPN, Service Principal Name) con Active Directory nell'account del servizio SQL Server per il nome di rete virtuale del listener del gruppo di disponibilità. Se il nome SPN è registrato in un account diverso da quello del servizio SQL Server, l'autenticazione non verrà completata.



** Importante ** Se si modifica l'account del servizio SQL Server, l'amministratore del dominio dovrà registrare manualmente il nome SPN.
Registrazione di un nome dell'entità servizio per le connessioni Kerberos

Breve spiegazione:

A Kerberos e ai nomi SPN viene applicata l'autenticazione reciproca. Tramite il nome SPN viene eseguito il mapping all'account di Windows mediante il quale vengono avviati i servizi SQL Server. Se la registrazione del nome SPN non viene eseguita correttamente o presenta un errore, tramite il livello di sicurezza di Windows non è possibile determinare l'account associato al nome SPN e l'autenticazione Kerberos non può essere utilizzata.



Nota: NTLM non presenta questo requisito.
Se si prevede di usare un'istanza del cluster di failover SQL Server per ospitare una replica di disponibilità, assicurarsi di comprendere le restrizioni dell'istanza dell'istanza del cluster di failover e che siano soddisfatti i requisiti dell'istanza del cluster di failover. Prerequisiti e requisiti sull'uso di un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità, più avanti in questo articolo
Per partecipare a un gruppo di disponibilità Always On, ogni istanza del server deve eseguire la stessa versione di SQL Server. Edizioni e funzionalità supportate per SQL 2014, SQL 2016, SQL 2017.
Tutte le istanze del server che ospitano repliche di disponibilità per un gruppo di disponibilità devono usare le stesse regole di confronto SQL Server. Impostazione o modifica di regole di confronto del server
Abilitare la funzionalità Always On gruppi di disponibilità in ogni istanza del server che ospiterà una replica di disponibilità per qualsiasi gruppo di disponibilità. In un determinato computer è possibile abilitare tutte le istanze del server per Always On gruppi di disponibilità supportati dall'installazione di SQL Server. Abilitare e disabilitare la funzionalità Gruppi di disponibilità Always On (SQL Server)



** Importante ** Se si elimina e si ricrea un cluster WSFC, è necessario disabilitare e riabilitare la funzionalità Always On gruppi di disponibilità in ogni istanza del server abilitata per Always On gruppi di disponibilità nel cluster originale.
Per ogni istanza del server è necessario un endpoint del mirroring del database. Si noti che questo endpoint è condiviso da tutte le repliche di disponibilità, dai partner di mirroring di database, nonché dai server di controllo nell'istanza del server.

Se un'istanza del server selezionata come host per una replica di disponibilità è in esecuzione in un account utente di dominio e non dispone ancora di un endpoint del mirroring del database, tramite la Creazione guidata Gruppo di disponibilità (o Procedura guidata Aggiungi replica a gruppo di disponibilità) è possibile creare l'endpoint e concedere l'autorizzazione CONNECT all'account del servizio dell'istanza del server. Tuttavia, se il servizio SQL Server è in esecuzione come account predefinito, ad esempio sistema locale, servizio locale o servizio di rete o un account non di dominio, è necessario usare i certificati per l'autenticazione degli endpoint e la procedura guidata non sarà in grado di creare un endpoint del mirroring del database nell'istanza del server. In tal caso, è consigliabile creare manualmente gli endpoint del mirroring del database prima di avviare la procedura guidata.



** Nota sulla sicurezza ** La sicurezza del trasporto per Always On gruppi di disponibilità è uguale a quella per il mirroring del database.
Endpoint del mirroring del database (SQL Server)

Sicurezza del trasporto per il mirroring del database e gruppi di disponibilità Always On (SQL Server)
Se tutti i database in cui è utilizzato FILESTREAM saranno aggiunti a un gruppo di disponibilità, verificare che FILESTREAM sia abilitato in ogni istanza del server in cui sarà ospitata una replica di disponibilità per il gruppo di disponibilità. Abilitare e configurare FILESTREAM
Se tutti i database indipendenti saranno aggiunti a un gruppo di disponibilità, verificare che l'opzione del server contained database authentication sia impostata su 1 in ogni istanza del server in cui sarà ospitata una replica di disponibilità per il gruppo di disponibilità. Opzione di configurazione del server contained database authentication

Opzioni di configurazione del server (SQL Server)

Utilizzo del thread da parte dei gruppi di disponibilità

Always On gruppi di disponibilità presenta i requisiti seguenti per i thread di lavoro:

  • In un'istanza inattiva di SQL Server, Always On gruppi di disponibilità usa 0 thread.

  • Il numero massimo di thread usato dai gruppi di disponibilità è dato dall'impostazione configurata per il numero massimo di thread del server ('max worker threads') meno 40.

  • Nelle repliche di disponibilità ospitate in un'istanza del server specificata viene condiviso un singolo pool di thread.

    I thread vengono condivisi su richiesta, come riportato di seguito:

    • In genere, sono presenti 3-10 thread condivisi, tuttavia questo numero può aumentare a seconda del carico di lavoro della replica primaria.

    • Se un determinato thread è inattiva per un po', viene rilasciato nuovamente nel pool di thread di SQL Server generale. In genere, un thread inattivo viene rilasciato dopo ~15 secondi di inattività. Tuttavia, a seconda dell'ultima attività, un thread inattivo potrebbe essere mantenuto più a lungo.

    • Un'istanza di SQL Server usa fino a 100 thread per la fase di rollforward parallelo per le repliche secondarie. Ogni database usa fino a metà del numero totale di core CPU, ma non più di 16 thread per ogni database. Se il numero totale di thread necessari per una singola istanza supera 100, SQL Server usa un unico thread di fase di rollforward per tutti i database rimanenti. I thread di rollforward seriale vengono rilasciati dopo ~15 secondi di inattività.

  • Inoltre, nei gruppi di disponibilità vengono utilizzati thread non condivisi, come riportato di seguito:

    • In ogni replica primaria viene utilizzato 1 thread di acquisizione del log per ogni database primario. Inoltre, viene utilizzato 1 thread di invio del log per ogni database secondario. I thread di invio del log vengono rilasciati dopo ~15 secondi di inattività.

    • Tramite un backup di una replica secondaria un thread viene mantenuto nella replica primaria per la durata dell'operazione di backup.

  • SQL Server 2019 ha introdotto la fase di rollforward parallela per i database di gruppi di disponibilità ottimizzati per la memoria. In SQL Server 2016 e 2017 le tabelle basate su disco non usano la fase di rollforward parallela se un database in un gruppo di disponibilità è anche ottimizzato per la memoria.

Per altre informazioni, vedere Always On - Serie di apprendimento HADRON: Utilizzo del pool di lavoro per i database abilitati per HADRON (blog sui tecnici del SQL Server CSS).

Autorizzazioni (istanza del server)

Attività Autorizzazioni necessarie
Creazione dell'endpoint del mirroring del database È richiesta l'autorizzazione CREATE ENDPOINT o l'appartenenza al ruolo predefinito del server sysadmin . È richiesta inoltre l'autorizzazione CONTROL ON ENDPOINT. Per altre informazioni, vedere GRANT Endpoint Permissions (Transact-SQL).For more information, see GRANT Endpoint Permissions (Transact-SQL).
Abilitazione dei gruppi di disponibilità di Always On È richiesta l'appartenenza al gruppo Administrator nel computer locale, nonché il controllo totale nel cluster WSFC.

Attività correlate (istanza del server)

Attività Articolo
Determinazione della presenza di un endpoint del mirroring del database sys.database_mirroring_endpoints (Transact-SQL)
Creazione dell'endpoint del mirroring del database (se non ancora disponibile) Creare un endpoint del mirroring del database per l'autenticazione Windows (Transact-SQL)

Utilizzare certificati per un endpoint del mirroring del database (Transact-SQL)

Creare un endpoint del mirroring del database per i gruppi di disponibilità Always On (SQL Server PowerShell)
Abilitazione dei gruppi disponibilità Abilitare e disabilitare la funzionalità Gruppi di disponibilità Always On (SQL Server)

Contenuto correlato (istanza del server)

Consigli sulla connettività di rete

Si consiglia di usare gli stessi collegamenti di rete per le comunicazioni tra nodi WSFC e le comunicazioni tra repliche di disponibilità. L'utilizzo di collegamenti di rete separati può provocare comportamenti imprevisti in caso di errore di alcuni collegamenti (anche in modo intermittente).

Ad esempio, affinché un gruppo di disponibilità supporti il failover automatico, lo stato della replica secondaria che è partner di failover automatico deve essere SYNCHRONIZED. In caso di errore di collegamento di rete a questa replica secondaria (anche in modo intermittente), lo stato della replica diventa UNSYNCHRONIZED e non sarà possibile cominciare la risincronizzazione fino a quando non viene ripristinato il collegamento. Se per il cluster WSFC è richiesto un failover automatico mentre la replica secondaria non è sincronizzata, il failover automatico non si verificherà.

Supporto della connettività client

Per informazioni sul supporto dei gruppi di disponibilità Always On per la connettività client, vedere connettività client Always On (SQL Server).For information about Always On availability groups support for client connectivity, see Always On Client Connectivity (SQL Server).

Prerequisiti e restrizioni per l'utilizzo di un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità

Contenuto della sezione

Restrizioni (istanze del cluster di failover)

Nota

Le istanze del cluster di failover supportano i volumi condivisi cluster. Per ulteriori informazioni sui volumi condivisi cluster, vedere Informazioni sui volumi condivisi del cluster in un cluster di failover.

  • I nodi del cluster di un'istanza del cluster di failover possono ospitare una sola replica per un determinato gruppo di disponibilità: Se si aggiunge una replica di disponibilità in un'istanza del cluster di failover, i nodi WSFC possibili non possono ospitare un'altra replica per lo stesso gruppo di disponibilità. Per evitare possibili conflitti è consigliabile configurare i proprietari possibili per l'istanza del cluster di failover. In tal modo si evita la possibilità che un singolo WSFC tenti l'hosting di due repliche di disponibilità per lo stesso gruppo di disponibilità.

    Inoltre tutte le altre repliche devono essere ospitate da un'istanza di SQL Server 2016 che risiede in un nodo del cluster diverso nello stesso cluster WSFC. L'unica eccezione è che quando viene eseguita la migrazione a un altro cluster, un gruppo di disponibilità può risiedere temporaneamente in due cluster.

Avviso

L'uso di Gestione cluster di failover per lo spostamento di un'istanza di cluster di failover che ospita un gruppo di disponibilità in un nodo che ospita già una replica dello stesso gruppo di disponibilità può causare la perdita della replica del gruppo di disponibilità, impedendo che venga portato online sul nodo di destinazione. Un singolo nodo di un cluster di failover non può ospitare più di una replica dello stesso gruppo di disponibilità. Per altre informazioni su come si verifica questa situazione e su come eseguire il ripristino, vedere il blog Replica eliminata in modo imprevisto nel gruppo di disponibilità.

  • Le istanze del cluster di failover non supportano il failover automatico da parte dei gruppi di disponibilità: Le istanze del cluster di failover non supportano il failover automatico da parte dei gruppi di disponibilità, pertanto qualsiasi replica di disponibilità ospitata da un'istanza del cluster di failover può essere configurata solo per il failover manuale.

  • Modifica del nome di rete dell'istanza del cluster di failover: Se è necessario modificare il nome di rete di un'istanza del cluster di failover che ospita una replica di disponibilità, è necessario rimuovere la replica dal gruppo di disponibilità e quindi aggiungere nuovamente la replica al gruppo di disponibilità. Non è possibile rimuovere la replica primaria, pertanto se si rinomina un'istanza del cluster di failover in cui è ospitata la replica primaria, è consigliabile eseguire il failover in una replica secondaria e successivamente rimuovere e poi riaggiungere la prima replica primaria. Si noti che la ridenominazione di un'istanza del cluster di failover può comportare la modifica dell'URL del relativo endpoint del mirroring del database. Quando si aggiunge la replica assicurarsi di specificare l'URL dell'endpoint corrente.

Elenco di controllo: prerequisiti (istanze del cluster di failover)

Prerequisito Collegamento
Assicurarsi che in ogni istanza del cluster di failover di SQL Server sia disponibile l'archiviazione condivisa necessaria in base all'installazione dell'istanza del cluster di failover di SQL Server standard.

Attività correlate (istanze del cluster di failover)

Attività Articolo
Installazione di un cluster di failover di SQL Server Creare un nuovo cluster di failover di SQL Server (programma di installazione)
Aggiornamento sul posto del cluster di failover di SQL Server esistente Eseguire l'aggiornamento di un'istanza del cluster di failover di SQL Server (installazione)
Gestione del cluster di failover di SQL Server esistente Aggiungere o rimuovere nodi in un cluster di failover di SQL Server (programma di installazione)

Contenuto correlato (istanze del cluster di failover)

Prerequisiti e restrizioni dei gruppi di disponibilità

Contenuto della sezione

Restrizioni (gruppi di disponibilità)

  • Le repliche di disponibilità devono essere ospitate da nodi diversi di un cluster WSFC: Per un determinato gruppo di disponibilità, le repliche di disponibilità devono essere ospitate da istanze del server in esecuzione in nodi diversi dello stesso cluster WSFC. L'unica eccezione è che quando viene eseguita la migrazione a un altro cluster, un gruppo di disponibilità può risiedere temporaneamente in due cluster.

    Nota

    In ogni macchina virtuale presente nello stesso computer fisico può essere ospitata una replica di disponibilità per lo stesso gruppo di disponibilità, in quanto ogni macchina virtuale costituisce un computer distinto.

  • Nome del gruppo di disponibilità univoco: Ogni nome del gruppo di disponibilità deve essere univoco nel cluster WSFC. La lunghezza massima consentita per il nome del gruppo di disponibilità è 128 caratteri.

  • Repliche di disponibilità: Ogni gruppo di disponibilità supporta una replica primaria e fino a otto repliche secondarie. Tutte le repliche possono essere eseguite in modalità con commit asincrono oppure fino a cinque repliche possono essere eseguite in modalità commit sincrono (una replica primaria con due repliche secondarie sincrone). Ogni replica deve avere un nome server univoco sia in Windows che in SQL Server. I nomi dei server tra Windows e SQL Server devono corrispondere.

  • Numero massimo di gruppi di disponibilità e database di disponibilità per computer: il numero effettivo di database e gruppi di disponibilità che è possibile creare in un computer (macchina virtuale o computer fisico) dipende dall'hardware e dal carico di lavoro, tuttavia non esiste un limite imposto. Microsoft ha testato un massimo di 10 gruppi di disponibilità e 100 database per computer fisico, ma non si tratta di un limite vincolante. A seconda delle specifiche hardware del server e del carico di lavoro, è possibile inserire un numero maggiore di database e di gruppi di disponibilità in un'istanza di SQL Server. I segnali di sistemi di overload possono includere, a titolo esemplificativo, l'esaurimento del thread di lavoro, tempi di risposta lenti per visualizzazioni di sistema del gruppo di disponibilità e DMV e/o dump del sistema dispatcher bloccati. Assicurarsi di testare completamente l'ambiente con un carico di lavoro simile a quello di produzione per assicurare che possa gestire capacità di carico di lavoro di picco all'interno del contratto sul livello di servizio dell'applicazione. Per i contratti sul livello di servizio occorre considerare il carico in condizioni di errore e i tempi di risposta previsti.

  • Non usare Gestione cluster di failover per modificare i gruppi di disponibilità. Lo stato di un'istanza del cluster di failover di SQL Server viene condiviso tra SQL Server e il cluster di failover di Windows (WSFC), con SQL Server che mantiene più informazioni dettagliate sullo stato delle istanze rispetto a quelle richieste dal cluster. Il modello di gestione prevede che SQL Server guidi le transazioni e sia responsabile di mantenere la visualizzazione dello stato del cluster sincronizzata con la visualizzazione dello stato di SQL Server. Se lo stato del cluster viene modificato all'esterno di SQL Server è possibile che lo stato non sia più sincronizzato tra WSFC e SQL Server e ciò potrebbe causare un comportamento imprevedibile.

    Ad esempio:

    • Non modificare le proprietà del gruppo di disponibilità, ad esempio i possibili proprietari.

    • Non utilizzare Gestione cluster di failover per eseguire il failover dei gruppi di disponibilità. È necessario usare Transact-SQL o SQL Server Management Studio.

Prerequisiti (gruppi di disponibilità)

Quando si crea o riconfigura una configurazione del gruppo di disponibilità, assicurarsi che si soddisfino i requisiti seguenti.

Prerequisito Descrizione
Se si prevede di usare un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità, assicurarsi di comprendere le restrizioni dell'istanza del cluster di failover e che vengano soddisfatti i requisiti dell'istanza del cluster di failover. Prerequisiti e restrizioni per l'uso di un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità, precedentemente in questo articolo.

Sicurezza (gruppi di disponibilità)

  • La sicurezza viene ereditata dal cluster WSFC. Windows Server Failover Clustering fornisce due livelli di sicurezza utente a livello di granularità dell'intero cluster:

    • Accesso di sola lettura

    • Controllo completo

      Always On i gruppi di disponibilità richiedono il controllo completo e l'abilitazione di gruppi di disponibilità Always On in un'istanza di SQL Server offre il controllo completo del cluster (tramite SID del servizio).

      Non è possibile aggiungere o rimuovere direttamente la sicurezza per un'istanza del server in Gestione cluster. Per gestire le sessioni di sicurezza del cluster, usare il Gestione configurazione SQL Server o l'equivalente WMI da SQL Server.

  • Ogni istanza di SQL Server deve avere le autorizzazioni per accedere al Registro di sistema, al cluster e così via.

  • È consigliabile usare la crittografia per le connessioni tra istanze del server che ospitano Always On repliche di disponibilità dei gruppi di disponibilità.

Autorizzazioni (gruppi di disponibilità)

Attività Autorizzazioni necessarie
Creazione di un gruppo di disponibilità Sono necessarie l'appartenenza al ruolo predefinito del server sysadmin e l'autorizzazione server CREATE AVAILABILITY GROUP oppure l'autorizzazione ALTER ANY AVAILABILITY GROUP o CONTROL SERVER.
Modifica di un gruppo di disponibilità È necessaria l'autorizzazione ALTER AVAILABILITY GROUP nel gruppo di disponibilità, l'autorizzazione CONTROL AVAILABILITY GROUP, l'autorizzazione ALTER ANY AVAILABILITY GROUP o l'autorizzazione CONTROL SERVER.

Inoltre, per la creazione di un join di un database a un gruppo di disponibilità è richiesta l'appartenenza al ruolo predefinito del database db_owner .
Rimozione/eliminazione di un gruppo di disponibilità È necessaria l'autorizzazione ALTER AVAILABILITY GROUP nel gruppo di disponibilità, l'autorizzazione CONTROL AVAILABILITY GROUP, l'autorizzazione ALTER ANY AVAILABILITY GROUP o l'autorizzazione CONTROL SERVER. Per rimuovere un gruppo di disponibilità non ospitato nel percorso della replica locale, è necessaria l'autorizzazione CONTROL SERVER o CONTROL per questo gruppo di disponibilità.

Attività correlate (gruppi di disponibilità)

Attività Articolo
Creazione di un gruppo di disponibilità Utilizzare il gruppo di disponibilità (Creazione guidata Gruppo di disponibilità)

Creare un gruppo di disponibilità (Transact-SQL)

Creare un gruppo di disponibilità (SQL Server PowerShell)

Specifica dell'URL dell'endpoint quando si aggiunge o si modifica una replica di disponibilità (SQL Server)
Modifica del numero di repliche di disponibilità Aggiungere una replica secondaria a un gruppo di disponibilità (SQL Server)

Creare un join di una replica secondaria a un gruppo di disponibilità (SQL Server)

Rimuovere una replica secondaria da un gruppo di disponibilità (SQL Server)
Creazione di un listener del gruppo di disponibilità Creare o configurare un listener del gruppo di disponibilità (SQL Server)
Eliminazione di un gruppo di disponibilità Rimuovere un gruppo di disponibilità (SQL Server)

Prerequisiti e restrizioni dei database di disponibilità

Per essere idoneo a essere aggiunto a un gruppo di disponibilità, un database deve soddisfare i prerequisiti e le restrizioni riportate di seguito.

Contenuto della sezione

Elenco di controllo: requisiti (database di disponibilità)

Per essere idoneo a essere aggiunto a un gruppo di disponibilità, un database deve soddisfare i requisiti seguenti:

Requisiti Collegamento
Deve trattarsi di un database utente. I database di sistema non possono appartenere a un gruppo di disponibilità.
Risiedere nell'istanza di SQL Server in cui si crea il gruppo di disponibilità ed essere accessibile all'istanza del server.
Deve trattarsi di un database di lettura/scrittura. I database di sola lettura non possono essere aggiunti a un gruppo di disponibilità. sys.databases (is_read_only = 0)
Deve trattarsi di un database multiutente. sys.databases (user_access = 0)
Non deve essere utilizzato AUTO_CLOSE. sys.databases (is_auto_close_on = 0)
Utilizzare il modello di recupero con registrazione completa (noto anche come modalità di recupero con registrazione completa). sys.databases (recovery_model = 1)
Deve disporre di almeno un backup completo del database.

Nota: Dopo aver impostato un database sulla modalità di recupero con registrazione completa, è necessario un backup completo per iniziare la catena di log del recupero con registrazione completa.
Creare un backup completo del database (SQL Server)
Non deve appartenere ad alcun gruppo di disponibilità esistente. sys.databases (group_database_id = NULL)
Non deve essere configurato per il mirroring del database. sys.database_mirroring Se il database non fa parte del mirroring, tutte le colonne con prefisso "mirroring_" sono NULL.
Prima di aggiungere un database in cui è utilizzato FILESTREAM a un gruppo di disponibilità, verificare che FILESTREAM sia abilitato in ogni istanza del server in cui è o sarà ospitata una replica di disponibilità per il gruppo di disponibilità. Abilitare e configurare FILESTREAM
Prima di aggiungere un database indipendente a un gruppo di disponibilità, verificare che l'opzione del server contained database authentication sia impostata su 1 in ogni istanza del server in cui è o sarà ospitata una replica di disponibilità per il gruppo di disponibilità. Opzione di configurazione del server contained database authentication

Opzioni di configurazione del server (SQL Server)

Nota

Always On gruppi di disponibilità funziona con qualsiasi livello di compatibilità del database supportato.

Restrizioni (database di disponibilità)

  • Se il percorso del file, inclusa la lettera di unità, di un database secondario differisce da quello del database primario corrispondente, si applicano le restrizioni seguenti:

    • Creazione guidata gruppo di disponibilità/Aggiunta guidata database a gruppo di disponibilità: L'opzione Full non è supportata (nella paginaSeleziona sincronizzazione dati iniziale )

    • RESTORE WITH MOVE: Per creare i database secondari, i file di database devono essere RIPRISTINATI WITH MOVE in ogni istanza di SQL Server che ospita una replica secondaria.

    • Impatto sulle operazioni sui file aggiuntivi: Un'operazione successiva sui file aggiuntivi nella replica primaria potrebbe non riuscire nei database secondari. Questo errore può causare la sospensione dei database secondari. Questa situazione, a sua volta, può causare l'attivazione dello stato NON IN SINCRONIZZAZIONE delle repliche secondarie.

      Nota

      Per informazioni sulla risposta a un'operazione di file pubblicitario non riuscita, vedere Risolvere i problemi di un'operazione di Add-File non riuscita (Always On gruppi di disponibilità).For information about responding to a failed ad-file operation, see Troubleshoot a Failed Add-File Operation (Always On Availability Groups).

  • Non è possibile eliminare un database che attualmente appartiene a un gruppo di disponibilità.

Completamento per database protetti tramite crittografia TDE

Se si utilizza TDE (Transparent Data Encryption), la chiave asimmetrica o il certificato per la creazione e la decrittografia di altre chiavi deve essere identico in ogni istanza del server in cui viene ospitata una replica di disponibilità per il gruppo di disponibilità. Per altre informazioni, vedere Spostare un database protetto da TDE in un'altra istanza di SQL Server.

Autorizzazioni (database di disponibilità)

È richiesta l'autorizzazione ALTER per il database.

Attività correlate (database di disponibilità)

Attività Articolo
Preparazione di un database secondario (manuale) Preparare manualmente un database secondario per un gruppo di disponibilità (SQL Server)
Creazione di un join di un database secondario a un gruppo di disponibilità (manuale) Creare un join di un database secondario a un gruppo di disponibilità (SQL Server)
Modifica del numero di database di disponibilità Aggiungere un database a un gruppo di disponibilità (SQL Server)

Rimuovere un database secondario da un gruppo di disponibilità (SQL Server)

Rimuovere un database primario da un gruppo di disponibilità (SQL Server)

Contenuto correlato

Vedere anche

Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server)
Clustering di failover e gruppi di disponibilità Always On (SQL Server)
Connettività client Always On (SQL Server)