Repliche secondarie attive: Repliche secondarie leggibili (Gruppi di disponibilità AlwaysOn)

Articolo
06/25/2013

Le funzionalità secondarie attive di Gruppi di disponibilità AlwaysOn includono il supporto per l'accesso in sola lettura a una o più repliche secondarie (repliche secondarie leggibili). Una replica secondaria leggibile consente l'accesso in sola lettura a tutti i relativi database secondari. Tuttavia, i database secondari leggibili non sono impostati per la sola lettura. Sono dinamici. Un database secondario viene modificato in base ai cambiamenti apportati al database primario corrispondente. Per una replica secondaria tipica, i dati nel database secondario sono quasi in tempo reale. Inoltre, gli indici full-text sono sincronizzati con i database secondari. In molte circostanze, la latenza dei dati tra un database primario e il database secondario corrispondente è in genere solo di pochi secondi.

Le impostazioni di sicurezza nei database primari vengono rese persistenti nei database secondari. Sono inclusi utenti, ruoli del database e delle applicazioni insieme alle rispettive autorizzazioni, nonché Transparent Data Encryption (TDE), se abilitato nel database primario.

[!NOTA]

Sebbene non sia possibile scrivere dati nei database secondari, è possibile scrivere nei database in lettura/scrittura dell'istanza del server che ospita la replica secondaria, inclusi i database utente e quelli di sistema come tempdb.

Gruppi di disponibilità AlwaysOn supporta inoltre il reindirizzamento delle richieste di connessione con finalità di lettura a una replica secondaria leggibile (routing di sola lettura). Per informazioni sul routing di sola lettura, vedere Utilizzo di un listener per connettersi a una replica secondaria di sola lettura (routing di sola lettura).

Contenuto dell'argomento

Vantaggi
Prerequisiti per il gruppo di disponibilità
Limitazioni e restrizioni
Considerazioni sulle prestazioni
Considerazioni sulla pianificazione della capacità
Attività correlate
Contenuto correlato

Vantaggi

L'indirizzamento di connessioni di sola lettura a repliche secondarie leggibili offre i seguenti vantaggi:

Consente di scaricare i carichi di lavoro di sola lettura secondari dalla replica primaria, in cui sono conservate le relative risorse per i carichi di lavoro critici. In caso di carico di lavoro di lettura critico o di carico di lavoro per il quale non è possibile tollerare la latenza, si consiglia di effettuare la relativa esecuzione nella replica primaria.
Consente di migliorare il rendimento dell'investimento per i sistemi in cui sono ospitate repliche secondarie leggibili.

Inoltre, le repliche secondarie leggibili forniscono un supporto affidabile per operazioni di sola lettura, come indicato di seguito:

Le statistiche temporanee in un database secondario leggibile consentono di ottimizzare le query di sola lettura. Per ulteriori informazioni, vedere Statistiche per database con accesso di sola lettura, più avanti in questo argomento.
Nei carichi di lavoro di sola lettura viene utilizzato il controllo delle versioni delle righe per rimuovere la contesa di blocco nei database secondari. Viene eseguito automaticamente il mapping a livello di transazioni di isolamento dello snapshot di tutte le query eseguite nei database secondari, anche quando gli altri livelli di isolamento delle transazioni sono impostati in modo esplicito. Tutti gli hint di blocco vengono ignorati. In questo modo si elimina la contesa lettore/writer.

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

Prerequisiti per il gruppo di disponibilità

Repliche secondarie leggibili (obbligatorio)

L'amministratore del database deve configurare una o più repliche in modo tale da consentire tutte le connessioni (solo per l'accesso in lettura) o solo le connessioni con finalità di lettura quando vengono eseguite nel ruolo secondario.

[!NOTA]

Facoltativamente, l'amministratore del database può configurare le repliche di disponibilità per escludere le connessioni in sola lettura quando l'esecuzione avviene nel ruolo primario.

Per ulteriori informazioni, vedere Informazioni sull'accesso alla connessione client per le repliche di disponibilità (SQL Server).
Listener del gruppo di disponibilità

Per supportare il routing di sola lettura, un gruppo di disponibilità deve possedere un listener del gruppo di disponibilità. Il client in sola lettura deve indirizzare le richieste di connessione al listener e la stringa di connessione del client deve specificare la finalità dell'applicazione come in sola lettura, ovvero devono essere richieste di connessione con finalità di lettura.
Routing di sola lettura

Con Routing in sola lettura si intende la capacità di SQL Server di indirizzare le richieste di connessione in ingresso con finalità di lettura dirette a un listener del gruppo di disponibilità a una replica secondaria leggibile disponibile. I prerequisiti per il routing di sola lettura sono i seguenti:
- Per supportare il routing di sola lettura una replica secondaria leggibile richiede un URL di routing di sola lettura. L'URL viene utilizzato solo quando la replica locale viene eseguita nel ruolo secondario. L'URL di routing di sola lettura deve essere specificato per ogni singola replica in base alle esigenze. Ogni URL di routing di sola lettura viene utilizzato per il routing delle richieste di connessione con finalità di lettura a una replica secondaria leggibile specifica. In genere, a ogni replica secondaria leggibile viene assegnato un URL di routing di sola lettura.
- Ogni replica di disponibilità che deve supportare il routing di sola lettura quando viene eseguita come replica primaria richiede un elenco di routing di sola lettura. L'elenco di routing di sola lettura viene utilizzato solo quando la replica locale viene eseguita nel ruolo primario. L'elenco deve essere specificato per ogni singola replica in base alle esigenze. In genere, ciascun elenco di routing di sola lettura deve contenere tutti gli URL di routing di sola lettura, con l'URL della replica locale alla fine dell'elenco.
  
  [!NOTA]
  
  Le richieste di connessione con finalità di lettura vengono instradate alla prima replica secondaria leggibile disponibile nell'elenco di routing di sola lettura della replica primaria corrente. Non viene eseguito alcun bilanciamento del carico.
Per ulteriori informazioni, vedere Configurare il routing di sola lettura per un gruppo di disponibilità (SQL Server).

[!NOTA]

Per ulteriori informazioni sui listener del gruppo di disponibilità e sul routing di sola lettura, vedere Listener del gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server).

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

Limitazioni e restrizioni

Alcune operazioni non sono completamente supportate, come indicato di seguito:

Non appena una replica secondaria leggibile consente di creare un join del gruppo di disponibilità, la replica secondaria può iniziare ad accettare connessioni ai relativi database secondari. Tuttavia, se in un database primario sono presenti tutte le transazioni attive, le versioni di riga non saranno subito completamente disponibili nel database secondario corrispondente. Su tutte le transazioni attive disponibili nella replica primaria al momento della configurazione della replica secondaria deve essere eseguito il commit o il rollback. Fino a quando questo processo non viene completato, il mapping del livello di isolamento delle transazioni nel database secondario non è completo e le query sono temporaneamente bloccate.

[!NOTA]

La transazione a lunga esecuzione avrà un impatto sul numero di righe con versione mantenute.
Le funzionalità di rilevamento delle modifiche e Change Data Capture non sono supportate nei database secondari che appartengono a una replica secondaria leggibile:
- Il rilevamento delle modifiche è disabilitato in modo esplicito nei database secondari.
- La funzionalità Change Data Capture può essere abilitata in un database secondario, ma ciò non è supportato.
Dal momento che viene eseguito il mapping delle operazioni di lettura al livello di transazioni di isolamento dello snapshot, la pulizia di record fantasma nella replica primaria può essere bloccata dalle transazioni in una o più repliche secondarie. L'attività di pulizia di record fantasma consentirà di pulire automaticamente i record fantasma nella replica primaria se non più necessari per qualsiasi replica secondaria. Questa operazione è simile a quella che viene effettuata quando si eseguono transazioni nella replica primaria. In caso estremo, nel database secondario sarà necessario terminare una query di lettura a esecuzione prolungata nella replica secondaria tramite cui si blocca la pulizia fantasma. Si noti che la pulizia fantasma può essere bloccata se la replica secondaria è disconnessa o quando lo spostamento dati è sospeso nel database secondario. Questo stato impedisce inoltre il troncamento del log, pertanto se lo stato persiste, si consiglia di rimuovere il database secondario dal gruppo di disponibilità.
Potrebbe verificarsi un errore durante l'operazione DBCC SHRINKFILE nella replica primaria se nel file sono contenuti record fantasma ancora necessari in una replica secondaria.

[!NOTA]

Se si esegue una query sulla vista a gestione dinamica sys.dm_db_index_physical_stats in un'istanza del server che ospita una replica secondaria leggibile, è possibile che si verifichi un problema che impedisce di eseguire un'operazione di rollforward. Tale condizione si verifica perché la vista a gestione dinamica acquisisce un blocco IS nella vista o nella tabella utente specificata che può bloccare le richieste di un thread di rollforward per un blocco X presente in tale vista o tabella utente.

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

Considerazioni sulle prestazioni

In questa sezione si illustrano le diverse considerazioni sulle prestazioni relative ai database secondari leggibili.

Contenuto della sezione

Latenza dei dati
Impatto sui carichi di lavoro di sola lettura
Indicizzazione
Statistiche per i database con accesso di sola lettura

Latenza dei dati

L'implementazione dell'accesso di sola lettura alle repliche secondarie è utile qualora i carichi di lavoro di sola lettura possono tollerare una certa latenza dei dati. Nelle situazioni in cui la latenza dei dati non può essere accettata, si consideri la possibilità di eseguire i carichi di lavoro di sola lettura nella replica primaria.

I record di log delle modifiche sul database primario vengono inviati dalla replica primaria alle repliche secondarie. In ogni database secondario i record di log vengono applicati tramite un thread di rollforward dedicato. In un database secondario di accesso in lettura, una modifica ai dati specificata non viene visualizzata nei risultati della query fino a quando il record di log, in cui è contenuta la modifica, non sarà stato applicato al database secondario e non è stato eseguito il commit della transazione nel database primario.

Ciò significa che si verifica della latenza, in genere solo pochi secondi, tra la replica primaria e quella secondaria. In rari casi, tuttavia, ad esempio se problemi di rete compromettono la velocità effettiva, la latenza può diventare significativa. La latenza aumenta quando si verificano colli di bottiglia I/O e quando viene sospeso lo spostamento dati. Per monitorare lo spostamento dati sospeso, è possibile utilizzare il dashboard AlwaysOn o la DMV sys.dm_hadr_database_replica_states.

Impatto sui carichi di lavoro di sola lettura

Quando si configura una replica secondaria per l'accesso di sola lettura, nei carichi di lavoro di sola lettura dei database secondari si utilizzano le risorse di sistema, ad esempio CPU e I/O dai thread di rollforward, soprattutto se i carichi di lavoro di sola lettura prevedono l'esecuzione di molte operazioni di I/O.

Inoltre, i carichi di lavoro di sola lettura nelle repliche secondarie possono bloccare le modifiche DDL (Data Definition Language) applicate tramite record di log. Anche se nelle operazioni di lettura non si accettano i blocchi condivisi a causa del controllo delle versioni delle righe, in queste operazioni si accettano i blocchi di stabilità dello schema (Sch-S) che possono bloccare le operazioni di rollforward tramite cui si applicano le modifiche DDL.

Valutare le procedure consigliate relative alla compilazione delle query e applicarle ai database secondari. Pianificare, ad esempio, le query a lunga esecuzione come aggregazioni di dati durante i periodi di minore attività.

[!NOTA]

Se un thread di rollforward è bloccato da query in una replica secondaria, viene generato l'oggetto XEvent sqlserver.lock_redo_blocked.

Indicizzazione

Per ottimizzare i carichi di lavoro di sola lettura nelle repliche secondarie leggibili, è possibile creare indici nelle tabelle dei database secondari. Poiché non è possibile apportare modifiche allo schema o ai dati nei database secondari, creare indici nei database primari e consentire il trasferimento delle modifiche al database secondario attraverso il processo di rollforward.

Per monitorare l'attività di utilizzo dell'indice in una replica secondaria, eseguire una query sulle colonne user_seeks, user_scans e user_lookups della DMV sys.dm_db_index_usage_stats.

Statistiche per i database con accesso di sola lettura

Le statistiche sulle colonne di tabelle e viste indicizzate vengono utilizzate per ottimizzare i piani di query. Per i gruppi di disponibilità, le statistiche create e gestite nei database primari vengono rese automaticamente persistenti nei database secondari come parte dell'applicazione dei record di log delle transazioni. Tuttavia, è possibile che per il carico di lavoro di sola lettura nei database secondari siano richieste statistiche diverse rispetto a quelle create nei database primari. Ad ogni modo, poiché i database secondari sono limitati all'accesso di sola lettura, non è possibile creare statistiche nei database secondari.

Per risolvere il problema, le statistiche temporanee per i database secondari vengono create e gestite dalla replica secondaria in tempdb. Il suffisso _readonly_database_statistic viene aggiunto al nome delle statistiche temporanee per distinguerle da quelle permanenti rese persistenti dal database primario.

Solo in SQL Server è possibile creare e aggiornare le statistiche temporanee. È tuttavia possibile eliminare le statistiche temporanee e monitorare le relative proprietà utilizzando gli stessi strumenti utilizzati per le statistiche permanenti:

Eliminare le statistiche temporanee utilizzando l'istruzione DROP STATISTICS Transact-SQL.
Monitorare le statistiche utilizzando le viste del catalogo sys.stats e sys.stats_columns. In sys_stats è inclusa una colonna, is_temporary, per indicare quali statistiche sono permanenti e quali invece temporanee.

Per ulteriori informazioni sulle statistiche di SQL Server, vedere Statistiche.

Contenuto della sezione

Statistiche permanenti non aggiornate nei database secondari
Limitazioni e restrizioni

Statistiche permanenti non aggiornate nei database secondari

Tramite SQL Server è possibile rilevare situazioni in cui le statistiche permanenti in un database secondario non sono aggiornate. Tuttavia non è possibile apportare le modifiche alle statistiche permanenti se non modificando il database primario. Per l'ottimizzazione delle query, in SQL Server è possibile creare statistiche temporanee nel database secondario e utilizzarle al posto di quelle permanenti non aggiornate.

Quando le statistiche permanenti vengono aggiornate nel database primario, vengono rese automaticamente persistenti nel database secondario. In SQL Server è quindi possibile utilizzare le statistiche permanenti aggiornate che sono più recenti delle statistiche temporanee.

Se si esegue il failover del gruppo di disponibilità, le statistiche temporanee vengono eliminate in tutte le repliche secondarie.

Limitazioni e restrizioni

Poiché le statistiche temporanee sono archiviate in tempdb, un riavvio del servizio SQL Server comporta l'indisponibilità di tutte le statistiche temporanee.
Il suffisso _readonly_database_statistic è riservato alle statistiche generate da SQL Server. Non è possibile utilizzare questo suffisso quando si creano statistiche in un database primario. Per ulteriori informazioni, vedere Statistiche.

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

Considerazioni sulla pianificazione della capacità

Le repliche secondarie leggibili possono richiedere spazio in tempdb per due motivi:
- Le versioni di riga vengono copiate dal livello di isolamento dello snapshot in tempdb.
- Le statistiche temporanee per i database secondari vengono create e mantenute in tempdb. Le statistiche temporanee possono provocare un lieve aumento delle dimensioni di tempdb. Per ulteriori informazioni, vedere Statistiche per database con accesso di sola lettura, più avanti in questa sezione.

Quando si configura l'accesso in lettura per una o più repliche secondarie, nei database primari vengono aggiunti 14 byte di overhead sulle righe di dati eliminate, modificate o inserite per archiviare i puntatori alle versioni di riga nei database secondari. L'overhead di 14 byte viene trasferito ai database secondari. Poiché l'overhead di 14 byte viene aggiunto alle righe di dati, è possibile che si verifichino divisioni di pagina.

I dati della versione di riga non sono generati dai database primari. Al contrario, i database secondari generano le versioni di riga. Tuttavia, il controllo delle versioni delle righe aumenta l'archiviazione dei dati nei database primari e secondari.

L'aggiunta dei dati della versione di riga dipende dall'isolamento dello snapshot o l'impostazione del livello di isolamento dello snapshot Read committed sul database primario. Nella tabella seguente viene descritto il comportamento del controllo delle versioni in un database secondario leggibile in impostazioni diverse.

Replica secondaria leggibile?	L'isolamento dello snapshot o l'isolamento dello snapshot Read Committed è abilitato?	Database primario	Database secondario
No	No	Nessuna versione di riga né overhead di 14 byte	Nessuna versione di riga né overhead di 14 byte
No	Sì	Versioni di riga e overhead di 14 byte	Nessuna versione di riga, ma overhead di 14 byte
Sì	No	Nessuna versione di riga, ma overhead di 14 byte	Versioni di riga e overhead di 14 byte
Sì	Sì	Versioni di riga e overhead di 14 byte	Versioni di riga e overhead di 14 byte