Applicazioni di data warehousing e creazione di report
La replica viene spesso utilizzata nelle applicazioni di data warehousing e creazione di report per:
Consolidare i dati per poterli trasformare e spostare nell'ambiente di data warehousing.
Distribuire i dati a database di sola lettura per la creazione di report.
Distribuire i dati a un database di elaborazione analitica in linea (OLAP, Online Analytical Processing).
Sebbene tramite la replica non vengano replicati gli oggetti di Microsoft SQL Server 2008 Analysis Services (SSAS), ad esempio dimensioni o cubi, essa viene spesso utilizzata per distribuire i dati da database di elaborazione delle transazioni in linea (OLTP) a database dell'area di gestione temporanea e a database utilizzati per creazione di report, supporto decisionale e analisi.
Nella figura seguente viene illustrato uno scenario tipico, con i dati replicati da un server di elaborazione in linea a un server di report e a un server dell'area di gestione temporanea per l'analisi OLAP e ROLAP.
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 AdventureWorks2008R2.
In Adventure Works Cycles le funzionalità di data warehousing e creazione di report vengono utilizzate in diversi reparti, tra cui quello di produzione e delle risorse umane.
Nel reparto di produzione vengono archiviati i dati cronologici sui difetti di produzione e diverse altre metriche relative a qualità e a prestazioni. I dati vengono replicati dai server nella struttura di produzione a un server dell'area di gestione temporanea nella sede centrale della società, da dove i dati vengono trasformati e caricati in cubi OLAP per l'analisi.
Il reparto delle risorse umane crea attualmente i report tramite un'applicazione di terze parti. Si sta pianificando di sostituire questa applicazione con Reporting Services. Si desidera inoltre espandere le funzionalità di creazione dei report e aggiungere la possibilità di eseguire i tipi di analisi seguenti:
Analisi delle indennità e dei profitti, inclusa l'analisi dell'impatto dei tassi di cambio valutari internazionali.
Pianificazione del numero di dipendenti.
Simulazioni e previsioni dei costi delle retribuzioni.
Verrà aggiunto alla rete un nuovo server per gestire le accresciute esigenze della società per quanto riguarda i report. I dati verranno replicati dal reparto delle risorse umane e dagli altri reparti a questo server di report centrale di sola lettura.
Requisiti comuni per questo scenario
Le applicazioni di data warehousing e creazione di report presentano in genere i requisiti seguenti, che possono essere soddisfatti da una soluzione di replica appropriata:
È necessario che nel sistema venga mantenuta la consistenza delle transazioni.
La latenza del sistema deve essere bassa, in modo che gli aggiornamenti nel server di elaborazione in linea raggiungano rapidamente i server dell'area di gestione temporanea e di report.
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 della replica deve richiedere un overhead minimo nel server di elaborazione in linea.
Il flusso delle modifiche ai dati deve essere in una sola direzione, dal server di elaborazione in linea ai server dell'area di gestione temporanea e di report.
I dati necessari nei server dell'area di gestione temporanea e di report possono essere un subset dei dati disponibili nel server di elaborazione in linea.
Tipo di replica da utilizzare per questo scenario
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 riportata sopra il server di elaborazione in linea è il server di pubblicazione. Alcuni o tutti i dati nel server di elaborazione in linea vengono inclusi in due pubblicazioni, una per l'area di gestione temporanea e una per i report, con ogni tabella di dati che costituisce un articolo. Gli articoli possono inoltre essere costituiti da altri oggetti di database, ad esempio stored procedure. Il server dell'area di gestione temporanea e il server di report sono i Sottoscrittori di una delle pubblicazioni. Ogni server riceve lo schema e i dati come sottoscrizione. Per ulteriori informazioni sui componenti del sistema, vedere Panoramica del modello di pubblicazione della replica.
SQL Server supporta diversi tipi di replica per soddisfare diversi requisiti delle applicazioni, 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, che è 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
La principale opzione da valutare per questo scenario è il filtro dei dati. Poiché la replica transazionale consente di filtrare colonne e righe, le tabelle nei server dell'area di gestione temporanea e di report contengono solo i dati necessari per l'applicazione. Per ulteriori informazioni, vedere Applicazione di filtri ai dati pubblicati.
Passaggi per l'implementazione dello scenario
Per l'implementazione di questo scenario, è innanzitutto necessario creare una pubblicazione e le sottoscrizioni e 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: