Codice per flessibilità

Definizione procedure di cleanup automatico

La definizione delle procedure di cleanup automatico facilita la resilienza del codice.

Durante lo sviluppo del codice e l'esecuzione dei test, sarà necessario reimpostare ripetutamente l'ambiente mentre si risolvono i bug, migliorando le prestazioni e ottimizzando le strategie di caricamento. La creazione anticipata di procedure di cleanup consentirà di migliorare tali procedure con l'evoluzione del codice, fino al punto in cui devono essere flessibili abbastanza per consentire la reimpostazione dell'ambiente in qualsiasi stato desiderato:

Reimposta tutto, nessun dato nel sistema di destinazione
Reimpostare lo stato dell'ambiente precedente all'ultimo caricamento. Sono incluse variabili, tabelle di stato o di audit e così via.
Reimposta l'ambiente in modo che i dati di un determinato carico (o batch_id o run_id) vengano reimpostati nell'ambiente senza alcun impatto su altri dati

L'automazione del processo di cleanup in genere garantisce un'esecuzione più efficiente del processo (non è necessario cercare una lista di tabelle da reimpostare o le query SQL da eseguire). L'automazione consente inoltre di ridurre drasticamente il rischio che una persona reimposta la parte errata dell'ambiente. In particolare, quando il debug viene eliminato, le persone non sono associate.

Poiché queste procedure di cleanup diventano più dettagliate, possono essere incluse nei processi di integrazione. Sono disponibili due modalità per utilizzare i vantaggi descritti di seguito.

Eseguire sempre un cleanup preventivo prima di caricare i dati. Se si stanno caricando dati che possono essere facilmente identificati (con un ID batch o una data specifica), sarà possibile sovrascrivere facilmente i caricamenti precedenti dello stesso data set non riuscito.
Utilizzare queste procedure di cleanup nei workflow in caso di errore. Non si desidera interrompere l'intero caricamento poiché, per un breve periodo di tempo, si perde la connessione all'ambiente di origine o di destinazione. Si supponga di caricare centinaia di file ed eseguire trasformazioni complesse su questi file. Interrompere tutti gli elementi in quanto per un frazionamento contenente un problema durante l'accesso a uno solo dei file oppure completare tutti gli elementi, riprovare il file il prima possibile e intraprendere solo misure più analitiche se il file non può essere ancora caricato? A seconda della stabilità dell'ambiente in esecuzione, è possibile scegliere di provare più volte prima di avvisi degli individui appropriati. Allo stesso modo, in base al tipo di indisponibilità riscontrati nell'ambiente in uso, è possibile forzare una pausa prima di riprovare.

Considerare tipi diversi di procedure di recupero. Per i task semplici, spesso è sufficiente provare a rieseguire l'operazione non riuscita senza altra operazione di cleanup o ripristino. Ma mentre il codice si evolve e diventa più complesso, si otterrà un aumento anche del tipo di errori. Dopo aver risolto gli errori di caricamento (il caricamento non funziona), è possibile eseguire gli errori aziendali (i dati vengono caricati, ma si stanno caricando i dati errati o alcuni calcoli sono errati). È opportuno esaminare attentamente le modalità di indirizzamento di questi tipi di correzioni. Nelle prime fasi potrebbe essere valido reimpostare tutto ciò in caso di errori business. Si supponga, tuttavia, di voler aumentare il livello di filtro in quanto il codice si evolve, in modo da renderne più bisogno di correzioni.

È possibile definire loop in Oracle Data Integrator per includere procedure di cleanup e contatori di incremento che tengono traccia del numero di tentativi. Per una migliore tracciabilità delle indisponibilità, le procedure ottimali includono una registrazione degli errori rilevati, in modo da poter eseguire le azioni appropriate qualora si verifichino errori più frequenti: non si desidera creare la resilienza in modo da nascondere i problemi di crescita. È possibile utilizzare l'approccio descritto in Recupera errori dai passi non riusciti.

Se si sa che un passo specifico dei processi è pronunciato ad errori ma, ad esempio, un sistema remoto che passa alla modalità non in linea regolarmente senza impostare una funzione di tempificazione per l'indisponibilità, è possibile usufruire della funzione incorporata di Oracle Data Integrator per tentare di nuovo un passo nei package. Usa nuovi tentativi automatici descrive come impostare nuovi tentativi automatici per un passo.

È necessario tenere presente quanto riportato di seguito.

Oracle Data Integrator non invierà una notifica all'utente che il processo non è riuscito se è impostato su Riprova. Se l'esecuzione di uno degli ulteriori tentativi riesce, il passo viene registrato come operazione riuscita nei log di Oracle Data Integrator (è comunque possibile tenere traccia dei tentativi nelle proprie tabelle di audit).
Nuovi tentativi e attesa aumentano la durata dell'esecuzione del passo. Quando si esaminano le prestazioni dei processi di integrazione, tenere presente quanto segue.

Identifica deviazione prestazioni

Le prestazioni spesso diminuiscono gradualmente i tempi. È importante monitorare le prestazioni e assicurarsi che per lo stesso volume di dati elaborati le prestazioni vengano comunque ottenute.L'elaborazione di dati più importanti richiede più tempo. L'elaborazione della stessa quantità di dati può essere un segno di avvertenza.

Si desidera comprendere i ritardi e le cause dei ritardi. Questo può essere correlato ad attività di rete aumentate che riduce la larghezza di banda disponibile, le statistiche non più valide nei database che influiscono negativamente sull'esecuzione del codice SQL o a un'entità di distribuzione dei file su un server in cui si è interessati solo ad poche.

La miglior prassi di Oracle Data Integrator consiste nel rimuovere i log (e i report degli scenari) il più possibile per migliorare le prestazioni. Ciò è particolarmente utile per archiviare i log o copiare le informazioni rilevanti sulle prestazioni in modo da poter analizzare le prestazioni nel tempo.

Quando si indagare sulle prestazioni, osservare i singoli passi in Oracle Data Integrator (non arrestare le prestazioni complessive): questa è il modo migliore per iniziare a capire da dove provengono i ritardi. Assicurarsi inoltre di disporre di un processo automatico per rimuovere i log di Oracle Data Integrator. È possibile creare un job di Oracle Data Integrator che esegue queste rimozioni, compresi i report degli scenari. Per informazioni dettagliate, vedere Rimuovi log con OdiPurgeLog.

Poiché Oracle Data Integrator consente solo di rimuovere i report degli scenari collegati alle sessioni presenti nell'operatore, la rimozione dei report degli scenari dopo la rimozione delle sessioni richiede assistenza da Oracle Support. Se si è dimenticato di rimuovere i report dello scenario prima di rimuovere le sessioni, contattare il Supporto Oracle. Oracle può guidare l'utente attraverso la procedura appropriata.

Per una lunga esecuzione, è fondamentale per monitorare continuamente le prestazioni. Il peggioramento delle prestazioni spesso è un segno di avvertenza di un peggioramento dell'ambiente. In particolare, Oracle consiglia di controllare i piani di esecuzione utilizzando SQL Plan Management (SPM). Le modifiche al piano di esecuzione in produzione possono causare errori e i caricamenti di tabelle possono causare rischi di modifica ai piani di esecuzione.

Rimuovi log con OdiPurgeLog

Se si osserva l'icona Utility dei package Oracle Data Integrator, verrà visualizzato uno strumento denominato OdiPurgeLog. È possibile utilizzare questo scenario in uno scenario progettato per rimuovere i log di Oracle Data Integrator e pianificare l'esecuzione periodica di questo scenario per assicurarsi di conservare alcuni log nel modo più possibile.

Le procedure ottimali includono:

È necessario rimuovere sempre anche i report. Sono più difficili da rimuovere se stessi rispetto a quando si rimuovono i log.
È possibile impostare un livello di latenza nella rimozione: è possibile utilizzare le variabili per memorizzare un periodo di tempo precedente o una data precedente prima della quale devono essere rimossi tutti gli elementi (se si utilizza il parametro End Date).
È possibile scegliere di rimuovere solo i log degli scenari (e i report) oppure sia i log degli scenari che i log dei piani di caricamento.

Recupera errori da passi non riusciti

L'API getPrevStepLog() viene in genere utilizzata in una procedura Oracle Data Integrator. Si rivela particolarmente utile se un passo non riesce e si desidera recuperare gli errori segnalati nel passo prima di tentare di eseguire le azioni correttive.

Questa interfaccia API viene richiamata con un nome proprietà che restituirà le informazioni appropriate. Ad esempio, se si desidera che il nome della sessione, il nome del passo non riuscito e il messaggio di errore associato, è possibile utilizzare il codice seguente per recuperare l'errore per la procedura:

Session:
        <%=odiRef.getInfo("SESS_NAME")%> encountered the following
        error at step: <%=odiRef.getPrevStepLog("STEP_NAME")%>Error Message:
        <%odiRef.getPrevStepLog("MESSAGE")%>

A questo snippet è possibile mandare a capo il codice aggiuntivo che memorizza tali informazioni in un punto qualsiasi oppure inviare tali informazioni per una corretta elaborazione.

Usa nuovi tentativi automatici

Il tempo di salvataggio automatico, in quanto il processo completo può essere completato, rispetto all'annullamento a causa di brevi o errori temporanei.

Nel package selezionare il passo in cui si desidera consentire i nuovi tentativi. Nella casella delle proprietà, fare clic sulla scheda ‘Avanzate'. Nell'area Elaborazione in seguito a errore:

Definire il numero di nuovi tentativi per il passo
Definire la durata dell'attesa tra ogni nuovo tentativo

Usa nomi univoci o dinamici per le sessioni scenario

Se lo stesso scenario viene eseguito molte volte per caricare set di dati diversi, la vista Operatore di Oracle Data Integrator non è molto utile se mostra l'elenco di molte istanze dello stesso scenario in esecuzione, ad esempio con un errore occasionale.

In questo modo, il richiamo dello scenario può trarre vantaggio dal parametro Nome sessione (SESS_NAME). Se lo stesso scenario viene eseguito più volte, probabilmente si dispone già di un parametro che comunica a questo scenario i dati da elaborare (sezione dati particolare, load_id, data e così via). È possibile utilizzare questa variabile per generare un nome univoco per ogni esecuzione dello scenario. Se si imposta il nome della sessione nella chiamata dello scenario, sessioni aggiuntive di un package danno luogo a log più leggibili nell'operatore Oracle Data Integrator. In questo modo, è più facile comprendere quale data set presenta problemi.

Usa strumenti basati su eventi

Oracle Data Integrator offre numerosi strumenti che possono essere utilizzati nei package per attendere la disponibilità di nuovi dati.

Tutti questi strumenti consentono di impostare la frequenza di polling e un periodo di timeout:

OdiFileWait attende la disponibilità del file in una directory (tenere presente che l'agente Oracle Data Integrator dovrà vedere la directory).
OdiWaitForData attende la disponibilità di nuovi dati in una tabella basata su una query fornita.
OdiWaitForTable attende la creazione di una tabella nel database.

Configura il timeout cache progetto agente

Con Oracle Data Integrator 12c, l'efficienza dell'agente è stata migliorata inserendo nella cache la definizione degli scenari eseguiti. È possibile controllare per quanto tempo gli scenari vengono inseriti nella cache nella definizione dell'agente fisico nella topologia Oracle Data Integrator.

L'inserimento nella cache dello scenario nell'agente è utile per i job in tempo reale, pertanto l'agente non deve ottenere le informazioni nel repository per ogni esecuzione. Il recupero è la distribuzione di una nuova versione di uno scenario non immediata. Il timeout predefinito finché non viene selezionata una nuova versione di uno scenario inserito nella cache è di 600 secondi (10 minuti) e 100 voci vengono inserite nella cache per impostazione predefinita.

È possibile gestire questi valori. Nella definizione dell'agente, nella scheda Definizione, utilizzare la sezione Gestione cache progetto sessione per impostare le voci della cache massima e la durata del progetto non utilizzato (sec).