Progettazione per flessibilità

Progettazione per riavviabilità

Alcuni processi di integrazione possono essere molto complessi e avere dipendenze con altri processi. Possono passare a una serie di stadi prima che i dati vengano caricati definitivamente nel sistema di destinazione finale. Per facilitare il riavvio, è possibile aggiungere una colonna aggiuntiva alle tabelle intermedie per tenere traccia e l'identificativo del carico corrente (load_id o load_date o qualsiasi altro elemento che identifichi in modo univoco il carico). Ciò consente una migliore tracciabilità e semplifica la progettazione delle procedure di cleanup.

Che cosa significa Oracle Data Integrator

Utilizzare le variabili per tenere traccia dell'identificativo del processo da caricare e, se possibile, aggiungere tali valori alle fasi di dati intermedi (colonne aggiuntive nelle tabelle intermedie).
Utilizzare queste variabili per impostare un nome sessione diverso (SESS_NAME) per l'esecuzione di ciascuno scenario. In questo modo gli operatori identificano immediatamente i processi che non riescono a conoscere esattamente dove cercare. Vedere Usa nomi univoci o dinamici per le sessioni scenario.
Si consideri l'esempio precedente in cui lo stesso processo viene utilizzato per caricare centinaia di file, è più pratico avere un job denominato dopo il file elaborato che ha lo stesso nome di job generico per tutti i file.

Progettazione per limitare gli impatti di indisponibilità

L'esecuzione di estrazioni notevoli in orari predefiniti ha un impatto significativo sull'intera infrastruttura.

Ad esempio:

Il sistema di origine ha un impatto negativo sulla richiesta.
La rete è interessata in quanto la larghezza di banda è inuata con il servizio della richiesta.
L'esecuzione dei job di integrazione globali richiede più tempo a causa del volume complessivo di dati da elaborare.
Un piccolo lampeggiamento o indisponibilità nella rete al momento dell'integrazione ha un impatto significativo sul task di integrazione.

I job di integrazione non devono essere in batch o in tempo reale. Spesso possono essere entrambi. Se il carico finale deve essere un'operazione batch (in quanto i dati vengono consolidati o aggregati per istanza), l'estrazione e alcuni processi preintegrazione possono essere eseguiti in modo più tempo reale. Ciò consente di ridurre il carico sull'infrastruttura globale e limitare l'impatto su quando si tenta di accedere al sistema di origine in fase di integrazione. Se i dati sono stati estratti e preparati in modalità streaming, non è necessario accedere al sistema di origine quando è previsto l'integrazione finale.

Oracle Data Integrator fornisce numerosi strumenti utilizzabili nella costruzione di package per rilevare la disponibilità di nuovi dati. Per una lista, vedere Usa strumenti basati su eventi.

Per l'integrazione con la replica in tempo reale reale, Oracle Data Integrator può creare un'infrastruttura che consentirà l'utilizzo delle modifiche, sfruttando le API sopra indicate.

Scegli tra inserimento e unione dei dati

Questo approccio può essere eseguito tra INSERT e MERGE per il caricamento dei dati. Oltre alla strategia di integrazione, è possibile considerare cosa accade quando il caricamento non riesce parzialmente.

A seconda del modo in cui si stanno caricando i dati nel sistema target, differenziando i dati caricati correttamente rispetto a quelli non riusciti o identificando gli elementi di un caricamento parziale potrebbe essere abbastanza complesso. Anche se da una prospettiva di progettazione tutti i dati in esecuzione stanno aggiungendo i dati nel sistema di destinazione, può essere utile da una prospettiva di recupero per prendere in considerazione i vantaggi dell'unione dei dati in entrata con i dati già presenti nel sistema di destinazione.

Se si sceglie questo approccio, si desidera controllare l'impatto di questa strategia sulle prestazioni dei caricamenti. Tenere tuttavia presente che un caricamento INSERT completamente ottimizzato e che non riesce più velocemente di un'unione meno efficiente.

In una prospettiva di Oracle Data Integrator, la modifica da una strategia INSERT a una strategia MERGE è un'operazione molto semplice: è necessario modificare solo la strategia di integrazione e selezionare il Knowledge Module appropriato. In questo modo, la modifica dei Knowledge Module per un numero elevato di mapping può essere un task scorporo. È possibile automatizzare questi task utilizzando l'SDK Oracle Data Integrator.

Progettazione per limitare le indisponibilità pianificate

Le indisponibilità pianificate sono in genere necessarie per l'applicazione di patch e gli aggiornamenti.

In un ambiente cloud in cui l'applicazione delle patch e gli aggiornamenti sono più semplici e completamente stabiliti dal punto di vista dell'utente finale, l'ultimo elemento che si desidera venga forzato in un'indisponibilità in quanto si applicano le patch al codice dei processi di integrazione. Ciò significa che l'applicazione delle patch deve far parte della strategia di sviluppo in avanti per garantire che le indisponibilità vengano conservate almeno.

L'unità di esecuzione per Oracle Data Integrator è uno scenario. Quando viene generato, uno scenario viene associato a un numero di versione (a partire da 001). È possibile generare di nuovo gli scenari (per sovrascrivere la versione corrente) oppure generare una nuova versione (002, 003 e così via).

Quando si richiama uno scenario, Oracle consiglia di specificare sempre il numero di versione-1. Si avranno due vantaggi:

Oracle Data Integrator utilizzerà sempre la versione più recente dello scenario. Non sarà necessario modificare il modo in cui si richiamano questi scenari durante la generazione di nuove versioni.
Dopo aver creato una nuova versione dello scenario, si tratta della versione eseguita da Oracle Data Integrator. Configura il timeout cache progetto agente descrive come controllare i possibili ritardi. Non è necessario arrestare e riavviare Oracle Data Integrator o qualsiasi strumento di orchestrazione esterno in uso per consentire a Oracle Data Integrator di utilizzare la versione più recente degli scenari di integrazione.

Nota: questo approccio è possibile solo se non si dispone di loop infiniti in Oracle Data Integrator. Un loop infinito non viene mai consigliato in Oracle Data Integrator (sono in realtà qualificati come anti-pattern):

I log costituiscono i log di Oracle Data Integrator: le rimozioni dei log non influiscono mai su un job in esecuzione. Un loop infinito è sempre in esecuzione, come tale i log corrispondenti non possono essere rimossi.
Essi impediscono l'applicazione di patch in linea agli scenari: per fare in modo che ODI selezioni la nuova versione di uno scenario, è necessario che l'utente disponga di un'opportunità di avviare lo scenario. Un loop infinito non termina mai… e pertanto non ha mai la possibilità di riavviare.
Piuttosto che avere un loop infinito, è possibile completare lo scenario richiamando lo stesso scenario in modo asincrono: l'ultimo passo dello scenario prima di terminarlo consiste nell'avviare una nuova copia di se stesso in una nuova sessione.