Integrazione di dati eterogenei

Data aggiornamento: 14 aprile 2006

In molte aziende e organizzazioni i dati vengono archiviati nei database da più fornitori. L'integrazione di tali dati rappresenta spesso un aspetto fondamentale per l'interazione dei sistemi in un'organizzazione. La replica consente di integrare dati eterogenei in due modi:

• Utilizzando Oracle come origine dei dati che possono essere replicati nei database Microsoft SQL Server, IBM e Oracle.
• Utilizzando SQL Server come origine dei dati che possono essere replicati nei database IBM e Oracle.

Il tipo di configurazione della replica utilizzato per integrare dati eterogenei dipende dall'origine e dalle destinazioni dei dati:

• Nella figura seguente viene illustrata la replica di dati da SQL Server in IBM DB2 e Oracle.
  
• Nella figura seguente viene illustrata la replica di dati da un database Oracle in altri database. I dati vengono prima replicati in un database SQL Server e possono quindi essere replicati in altri database inclusi SQL Server, IBM DB2 e Oracle.
  

Esempio Adventure Works Cycles

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

Adventure Works Cycles ha recentemente acquisito l'azienda messicana Importadores Neptuno nel tentativo di espandere la propria infrastruttura per supportare la crescita prevista dell'azienda. Importadores Neptuno utilizza un database Oracle per la gestione dei dati finanziari e di produzione. È tuttavia necessario condividere gli elementi principali di tali dati per poter garantire l'accuratezza dei dati di pianificazione e inventario nell'applicazione Manufacturing Resource Planning (MRP) di Adventure Works Cycles.

Sebbene non sia stata pianificata la migrazione dei database di Importadores Neptuno, non è necessario che Adventure Works Cycles trasmetta e riceva dati su base quotidiana e trasferisca tali informazioni nei database esistenti OLTP (Online Transaction Processing, elaborazione delle transazioni in linea) e OLAP (Online Analytical Processing, elaborazione analitica in linea) di SQL Server. Adventure Works Cycles replicherà i dati dal database Oracle nei database SQL Server nella sede centrale.

Requisiti comuni per questo scenario

Le applicazioni che comportano l'integrazione di dati eterogenei generalmente presentano i requisiti riportati di seguito, che una soluzione per l'esecuzione delle repliche appropriata deve essere in grado di soddisfare:

• È necessario che il sistema consenta la replica dei dati tra database di fornitori differenti.
• È necessario che nel sistema venga mantenuta la consistenza delle transazioni.
• L'elaborazione della replica deve richiedere un overhead minimo sul server di origine.
• Se è richiesta la replica delle modifiche incrementali, è necessario che il sistema abbia una latenza bassa.
• Se è richiesta la replica delle modifiche incrementali, è necessario che il sistema abbia un'elevata velocità effettiva, in quanto deve essere in grado di gestire la replica di un numero elevato di transazioni.
• I dati richiesti nei server di destinazione possono essere un subset dei dati disponibili nel server di origine.

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, il server di distribuzione, Sottoscrittori, pubblicazioni, articoli e sottoscrizioni.

• Nella prima figura riportata sopra il database Oracle è il server di pubblicazione. Alcuni o tutti i dati del database Oracle sono inclusi nella pubblicazione e ogni tabella di dati rappresenta un articolo. I dati vengono replicati nel primo computer SQL Server, configurato come server di distribuzione, e quindi distribuiti all'altro computer SQL Server e ai database IBM e Oracle. Ognuno di questi database è un Sottoscrittore della pubblicazione che riceve schema e dati come sottoscrizione.
• Nella seconda figura riportata sopra il database SQL Server è il server di pubblicazione e i database IBM e Oracle sono i Sottoscrittori.

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. Il modo migliore per implementare questo scenario è utilizzando le funzionalità di replica eterogenee della replica snapshot e/o transazionale, che sono particolarmente adatte a soddisfare i requisiti descritti nella sezione precedente:

• Se l'applicazione richiede la replica delle modifiche incrementali in tempo reale, utilizzare la replica transazionale.
  Per il server di pubblicazione Oracle, la replica transazionale rileva le modifiche sul server di pubblicazione mediante i trigger e le tabelle di rilevamento delle modifiche. Per ulteriori informazioni sulla replica transazionale, vedere Panoramica della replica transazionale, Funzionamento della replica transazionale e Flusso di lavoro della replica transazionale per i server di pubblicazione Oracle.
• Se l'applicazione richiede che i dati vengano replicati una sola volta, ad esempio quando vengono migrati, o che vengano aggiornati periodicamente anziché in modo incrementale, utilizzare la replica snapshot.
  Dal momento che la replica snapshot non rileva le modifiche incrementali né le recapita, i trigger non vengono utilizzati sulle tabelle pubblicate. Per ulteriori informazioni sulla replica snapshot, vedere Panoramica della replica transazionale e Funzionamento della replica transazionale.

Le caratteristiche di progettazione tipiche della replica transazionale e di quella snapshot le rendono i tipi di replica ideali per soddisfare i requisiti principali di questo scenario:

• Replica tra database di fornitori differenti
• Consistenza delle transazioni
• Overhead minimo

La replica transazionale soddisfa ulteriori requisiti per i sistemi che richiedono aggiornamenti incrementali:

• Bassa latenza
• Velocità effettiva elevata

La principale opzione da valutare per questo scenario è il filtraggio dei dati. I tipi di replica snapshot e transazionale consentono di filtrare colonne e righe, in modo che le tabelle dei Sottoscrittori contengano solo i dati richiesti dall'applicazione. Per ulteriori informazioni, vedere Applicazione di filtri ai dati pubblicati.

Passaggi per l'implementazione dello scenario

Per l'implementazione di questi scenari, è innanzitutto necessario creare una pubblicazione e le sottoscrizioni, quindi inizializzare ogni sottoscrizione. Per ulteriori informazioni, fare clic sui collegamenti seguenti.

• Pubblicazione Oracle:
  • Panoramica della pubblicazione Oracle
  • Configurazione di un server di pubblicazione Oracle
• Sottoscrittori Oracle e IBM DB2:
  • Sottoscrittori non SQL Server
  • Sottoscrittori Oracle
  • Sottoscrittori IBM DB2

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:

• Monitoraggio della replica
• Strategie per il backup e il ripristino della replica snapshot e della replica transazionale
• Backup e ripristino di server di pubblicazione Oracle
• Risoluzione dei problemi relativi alla replica
• Risoluzione dei problemi dei server di pubblicazione Oracle
• Rimozione della replica

Vedere anche

Altre risorse

Replica di dati in un ambiente da server a server

Guida in linea e informazioni

Assistenza su SQL Server 2005