Selezione del tipo di replica appropriato

MicrosoftSQL Server offre tre tipi di replica, ognuno dei quali è in grado di soddisfare diverse esigenze applicative. A seconda dei requisiti dell'applicazione, è possibile utilizzare uno o più tipi di replica in una topologia:

• Replica snapshot

• Replica transazionale

• Replica di tipo merge

Per facilitare la selezione del tipo di replica appropriato, in questo argomento vengono fornite informazioni relative a:

• Scenari di replica

  In questa sezione viene offerta una breve descrizione di alcuni casi comuni di utilizzo della replica, con collegamenti a descrizioni più dettagliate.

• Tipi di replica

  In questa sezione vengono descritte le esigenze applicative soddisfatte da ogni tipo di replica.

• Aggiornamento di dati nei Sottoscrittori

  In questa sezione vengono descritte le opzioni disponibili per le applicazioni che richiedono aggiornamenti dei dati nel Sottoscrittore.

È consigliabile consultare innanzitutto le descrizioni degli scenari per individuare lo scenario che corrisponde maggiormente alle specifiche esigenze applicative, quindi fare clic sul collegamento per ulteriori informazioni. Se non si riesce a individuare una stretta corrispondenza con le esigenze aziendali o si desidera ottenere informazioni aggiuntive sui tipi di replica, vedere "Tipi di replica". Se l'applicazione richiede aggiornamenti in uno o più Sottoscrittori, vedere "Aggiornamento di dati nei Sottoscrittori" per determinare la tecnologia appropriata da utilizzare.

Scenari di replica

Gli scenari di replica possono essere suddivisi in due categorie generali: la replica di dati in un ambiente server-server e la replica di dati tra server e client. Gli scenari server-server vengono implementati utilizzando la replica transazionale e talvolta la replica snapshot, mentre gli scenari con server e client vengono implementati utilizzando la replica di tipo merge.

Scenari server-server

La replica di dati tra server viene in genere eseguita per supportare le applicazioni e le esigenze descritte di seguito.

Scenario	Descrizione
Incremento di scalabilità e disponibilità	Il mantenimento di copie di dati continuamente aggiornate consente la scalabilità dell'attività di lettura su più server. La ridondanza garantita dal mantenimento di più copie degli stessi dati è essenziale in caso di manutenzione pianificata e non pianificata dei sistemi. Per ulteriori informazioni, vedere Incremento di scalabilità e disponibilità.
Data warehousing e report	I server di report e data warehouse utilizzano spesso i dati di server di elaborazione delle transazioni in linea (OLTP). Utilizzare la replica per trasferire dati tra server OLTP e sistemi di report e supporto decisionale. Per ulteriori informazioni, vedere Applicazioni di data warehousing e creazione di report.
Integrazione di dati da più siti	I dati vengono spesso raccolti da sedi remote e consolidati presso una sede centrale. Analogamente, i dati possono essere distribuiti tramite replica alle sedi remote. Per ulteriori informazioni, vedere Integrazione di dati da più siti (server).
Integrazione di dati eterogenei	Alcune applicazioni dipendono dall'invio di dati da e verso database diversi da MicrosoftSQL Server. Utilizzare la replica per integrare dati di database non SQL Server. Per ulteriori informazioni, vedere Integrazione di dati eterogenei.
Ripartizione del carico di lavoro dell'elaborazione batch	Le operazioni batch utilizzano in genere una quantità di risorse eccessiva per l'esecuzione in un server OLTP. Utilizzare la replica per ripartire il carico di lavoro dell'elaborazione in un server di elaborazione batch dedicato. Per ulteriori informazioni, vedere Ripartizione del carico di lavoro dell'elaborazione batch.

Scenari con server e client

La replica di dati tra server e client (come workstation, computer portatili, Tablet PC e dispositivi) viene in genere eseguita per supportare le applicazioni descritte di seguito.

Scenario	Descrizione
Scambio di dati con utenti mobili	Numerose applicazioni richiedono la disponibilità dei dati per utenti remoti, ad esempio rappresentanti di vendita, personale addetto ai recapiti e così via. Tali applicazioni includono le applicazioni CRM (Customer Relationship Management), SFA (Sales Force Automation) e FFA (Field Force Automation). Per ulteriori informazioni, vedere Scambio di dati con utenti mobili.
Applicazioni POS (Point Of Sale) consumer	Le applicazioni POS, ad esempio terminali di pagamento e sportelli bancomat, richiedono la replica dei dati dai siti remoti a un sito centrale. Per ulteriori informazioni, vedere Applicazioni POS (Point of Sale) consumer.
Integrazione di dati da più siti	Le applicazioni spesso integrano dati da più siti. Un'applicazione che supporta sedi regionali, ad esempio, potrebbe richiedere il flusso unidirezionale o bidirezionale dei dati tra le sedi regionali e una sede centrale. Per ulteriori informazioni, vedere Integrazione di dati da più siti (Client).

Tipi di replica

Replica snapshot

Il processo snapshot viene comunemente utilizzato per creare il set iniziale di dati e oggetti di database per le pubblicazioni transazionali e di tipo merge. La replica snapshot può tuttavia essere utilizzata anche autonomamente. L'utilizzo della replica snapshot in modo autonomo si rivela maggiormente appropriato in presenza di una o più delle condizioni seguenti:

• I dati vengono modificati raramente.

• L'utilizzo temporaneo di copie di dati non aggiornate rispetto al server di pubblicazione è accettabile.

• Vengono replicati volumi ridotti di dati.

• Viene apportato un ingente volume di modifiche in un breve periodo di tempo.

La replica snapshot è maggiormente appropriata in caso di modifiche di dati sostanziali ma non frequenti. Se un'organizzazione di vendita gestisce un listino prezzi dei prodotti e i prezzi sono aggiornati in blocco una o due volte all'anno, ad esempio, è consigliabile eseguire la replica dell'intero snapshot di dati dopo la modifica.

Replica transazionale

La replica transazionale viene in genere utilizzata in ambienti server-server e si rivela appropriata in ognuno dei casi seguenti:

• Si desidera propagare modifiche incrementali ai Sottoscrittori appena vengono apportate.

• L'applicazione richiede una bassa latenza tra il momento in cui le modifiche vengono apportate nel server di pubblicazione e il momento in cui raggiungono il Sottoscrittore.

• L'applicazione richiede l'accesso a stati dei dati intermedi. Se una riga viene modificata cinque volte, ad esempio, la replica transazionale consente a un'applicazione di rispondere a ogni modifica, ad esempio attivando un trigger, anziché soltanto alla modifica di dati netta apportata alla riga.

• Il server di pubblicazione è caratterizzato da un'intensa attività di inserimento, aggiornamento ed eliminazione.

• Il server di pubblicazione e il Sottoscrittore sono database non SQL Server, ad esempio Oracle.

Per impostazione predefinita, i Sottoscrittori di una pubblicazione transazionale devono essere considerati come di sola lettura, poiché le modifiche non vengono nuovamente propagate al server di pubblicazione. La replica transazionale offre tuttavia opzioni che consentono aggiornamenti nel Sottoscrittore. Per ulteriori informazioni, vedere la sezione "Aggiornamento di dati nei Sottoscrittori" in questo argomento.

Replica di tipo merge

La replica di tipo merge viene in genere utilizzata in ambienti server-client e si rivela appropriata nelle situazioni seguenti:

• Più Sottoscrittori potrebbero aggiornare gli stessi dati in diversi momenti e propagare tali modifiche al server di pubblicazione e ad altri Sottoscrittori.

• I Sottoscrittori devono ricevere dati, apportare modifiche non in linea e sincronizzarle successivamente con il server di pubblicazione e altri Sottoscrittori.

• Ogni Sottoscrittore richiede una diversa partizione di dati.

• Potrebbero verificarsi conflitti e in questo caso è necessario essere in grado di rilevarli e risolverli.

• L'applicazione richiede la modifica di dati netta, anziché l'accesso a stati dei dati intermedi. Se una riga viene modificata cinque volte nel Sottoscrittore prima della sincronizzazione con un server di pubblicazione, ad esempio, la riga viene modificata una sola volta nel server di pubblicazione in modo da riflettere la modifica di dati netta, ovvero il quinto valore.

La replica di tipo merge consente a diversi siti di operare in modo autonomo e di unire successivamente gli aggiornamenti in un unico risultato uniforme. Poiché gli aggiornamenti vengono eseguiti in più nodi, è possibile che gli stessi dati vengano aggiornati dal server di pubblicazione e da più Sottoscrittori. Al momento dell'unione degli aggiornamenti potrebbero pertanto verificarsi conflitti, per i quali la replica di tipo merge offre alcune modalità di gestione.

Aggiornamento di dati nei Sottoscrittori

I tipi di replica e le opzioni di replica descritti di seguito consentono di apportare modifiche in un Sottoscrittore e trasferire tali modifiche al server di pubblicazione.

Tipo di replica	Casi di utilizzo
Replica di tipo merge	È presente un numero elevato di Sottoscrittori. I dati vengono replicati per utenti mobili. I dati replicati vengono aggiornati frequentemente nel Sottoscrittore. È necessario filtrare i dati affinché i Sottoscrittori ricevano partizioni di dati diverse. Per ulteriori informazioni, vedere Panoramica della replica di tipo merge e Funzionamento della replica di tipo merge.
Replica transazionale peer-to-peer	La replica viene utilizzata per incrementare la scalabilità e la disponibilità. È necessaria una latenza minima. I dati non sono partizionati tra i Sottoscrittori. Non si verificano in genere conflitti, che tuttavia devono essere rilevati se presenti. Per ulteriori informazioni, vedere Replica transazionale peer-to-peer.
Replica transazionale con sottoscrizioni aggiornabili	È presente un numero ridotto di Sottoscrittori. I dati replicati sono prevalentemente di sola lettura nel Sottoscrittore. Sottoscrittore, server di distribuzione e server di pubblicazione sono quasi sempre connessi (per sottoscrizioni ad aggiornamento immediato). Per ulteriori informazioni, vedere Sottoscrizioni aggiornabili per la replica transazionale.

Vedere anche

Altre risorse

Progettazione e implementazione (Replica)

Considerazioni sulla progettazione di soluzioni (Replica)