• Articolo

Integrazione di dati da più siti (server)

Numerose aziende hanno filiali o entità che raccolgono ed elaborano dati che devono essere inviati a una posizione centrale. Ad esempio:

  • È possibile eseguire il rollup o consolidare i dati di inventario provenienti da vari server di magazzini locali nel server principale della sede centrale.

  • È possibile inviare a un server centrale informazioni provenienti da divisioni aziendali autonome all'interno della stessa azienda.

  • È possibile consolidare informazioni relative all'elaborazione degli ordini provenienti da ubicazioni diverse.

In alcuni casi è inoltre possibile inviare dati dal sito centrale a siti remoti. In genere, questi dati sono destinati alla sola lettura presso il sito remoto, ad esempio un set di tabelle di inventario dei prodotti che viene aggiornato solo sul sito centrale.

Nella figura seguente viene illustrato uno scenario tipico, in cui viene eseguito il rollup di dati da siti remoti. I dati di sola lettura vengono inoltre inviati a ogni sito remoto.

Replica dei dati nelle filiali

Esempio Adventure Works Cycles

Adventure Works Cycles è un'azienda manifatturiera fittizia utilizzata per esemplificare concetti e scenari relativi ai database. Per ulteriori informazioni, vedere Database di esempio AdventureWorks.

Adventure Works Cycles ha vari uffici vendite dislocati negli Stati Uniti. Ogni ufficio utilizza la replica in due modi:

  • Per offrire informazioni necessarie ai fini dell'evasione degli ordini e della creazione di report. I dati vengono raccolti ed elaborati in ogni ufficio vendite e successivamente replicati nella sede centrale.

  • Per fornire dati e funzionalità per l'elaborazione degli ordini al personale mobile addetto alle vendite. Questo scenario viene descritto nell'argomento Scambio di dati con utenti mobili.

Requisiti comuni per questo scenario

In genere, le applicazioni delle filiali presentano i requisiti seguenti, che devono essere risolti con una soluzione di replica appropriata:

  • È necessario che nel sistema venga mantenuta la consistenza delle transazioni.

  • La latenza del sistema deve essere bassa perché gli aggiornamenti eseguiti sui siti remoti devono raggiungere rapidamente il sito centrale.

  • La velocità effettiva del sistema deve essere elevata perché il sistema deve essere in grado di gestire la replica di un numero elevato di transazioni.

  • L'elaborazione delle repliche deve richiedere un overhead minimo sui siti remoti.

  • Il flusso delle modifiche apportate ai dati deve poter essere bidirezionale perché in alcuni casi i dati di sola lettura vengono inviati ai siti remoti in aggiunta ai dati consolidati dai siti remoti nel sito centrale.

  • I dati necessari nel sito centrale potrebbero essere un subset dei dati disponibili su ogni sito remoto.

Tipo di replica da utilizzare per questo scenario

Microsoft In SQL Server viene utilizzata una metafora basata sul settore dell'editoria per la descrizione dei componenti del sistema di replica. I componenti includono il server di pubblicazione, Sottoscrittori, pubblicazioni, articoli e sottoscrizioni.

  • Nella figura sopra riportata ogni sito remoto è un server di pubblicazione. Alcuni o tutti i dati del sito remoto sono inclusi nella pubblicazione e ogni tabella di dati rappresenta un articolo (gli articoli possono essere altri oggetti di database, ad esempio stored procedure). Il sito centrale è un Sottoscrittore di queste pubblicazioni, che riceve schema e dati in forma di sottoscrizioni.

  • Il sito centrale funge inoltre da server di pubblicazione dei dati inviati ai siti remoti. Ogni sito remoto esegue la sottoscrizione della pubblicazione dal sito centrale.

Per ulteriori informazioni sui componenti del sistema, vedere Panoramica del modello di pubblicazione della replica.

SQL Server supporta diversi tipi di replica per soddisfare differenti esigenze applicative, ovvero la replica snapshot, transazionale e di tipo merge. Per ottenere i migliori risultati, per l'implementazione di questo scenario è consigliabile utilizzare la replica transazionale, essendo la più appropriata per la gestione dei requisiti descritti nella sezione precedente. Per ulteriori informazioni sulla replica transazionale, vedere Panoramica della replica transazionale e Funzionamento della replica transazionale.

Le caratteristiche di progettazione tipiche della replica transazionale la rendono il tipo di replica ideale per soddisfare i requisiti principali di questo scenario:

  • Consistenza delle transazioni

  • Bassa latenza

  • Velocità effettiva elevata

  • Overhead minimo

[!NOTA]

È possibile implementare uno scenario simile nel caso della replica di tipo merge. Se è necessario utilizzare criteri di risoluzione dei conflitti o filtri che inviano a ogni sito remoto set univoci di dati, utilizzare la replica di tipo merge. Per ulteriori informazioni, vedere Integrazione di dati da più siti (Client).

Passaggi per l'implementazione dello scenario

Per l'implementazione di questo scenario, è innanzitutto necessario creare una pubblicazione e le sottoscrizioni, quindi inizializzare ogni sottoscrizione. Fare clic sui collegamenti seguenti per ulteriori informazioni su ogni passaggio:

Dopo l'inizializzazione della sottoscrizione e l'attivazione del flusso di dati tra il server di pubblicazione e i Sottoscrittori, potrebbe essere utile consultare gli argomenti seguenti per raccogliere ulteriori informazioni sulle attività più comuni di amministrazione e monitoraggio: