| # Ottimizzazione delle prestazioni per l'elaborazione parallela Nell'appendice C è illustrata l'ottimizzazione delle prestazioni che potrebbe essere necessaria per eseguire la sessione Processo Inizializzazione valuta (CI) (tccri7203m000) con l'elaborazione parallela. Le prestazioni della sessione Processo Inizializzazione valuta (CI) (tccri7203m000) dipendono da diversi fattori, tra cui il numero di CPU disponibili e la configurazione di server applicazioni e database. Un altro fattore rilevante è la quantità di dati contenuti nelle tabelle. In generale, le seguenti tabelle contengono grandi quantità di dati: Transazioni di integrazione (tfgld482) Dati di riconciliazione (tfgld495) Transazioni finalizzate (tfgld106) Transazioni semilavorati e scorte (SFC) (ticst300) Transazioni semilavorati e scorte PCS (tipcs300) Storico ordini di vendita (tdsls450, tdsls451, and tdsls456) In Infor LN FP5 e nelle versioni successive è disponibile una funzionalità che consente di aggiornare le tabelle direttamente tramite RDBMS. Questa funzionalità è implementata nel porting set 8.7a.03 e versioni successive. Gli aggiornamenti diretti tramite RDBMS sono più efficienti rispetto a quelli tramite bshell. La differenza consiste nel fatto che al sistema RDBMS viene trasmessa l'intera transazione. Questo tipo di aggiornamento riguarda soltanto le tabelle o i dati per i quali non è necessario ricalcolare importi in valuta locale e/o tassi di cambio. Ad esempio, nel caso in cui importi espressi in una valuta di reportistica vengano convertiti in importi espressi in valuta locale. Un altro esempio può essere la rimozione di importi in valuta locale, ad esempio nel caso in cui vengano eliminate valute di reportistica, o nel caso in cui il sistema valutario delle tabelle logistiche venga convertito in un sistema valutario standard. Nella sessione Processo Inizializzazione valuta (CI) (tccri7203m000) viene verificato se è possibile applicare gli aggiornamenti direttamente tramite RDBMS. Se ciò non è possibile, vengono utilizzati gli aggiornamenti convenzionali (più lenti). L'utilizzo degli aggiornamenti RDBMS dipende dai seguenti fattori: Nella sessione Tassi Inizializzazione valuta (CI) (tccri7100m000) il valore del campo Esprimi in valuta base deve corrispondere a quello del campo corrispondente incluso nella sessione Tassi di cambio (tcmcs0108m000). Ad esempio, nelle società EURO i tassi di cambio per la conversione da EUR (valuta locale) alle valute di transazione possono rimanere invariati se durante la conversione l'impostazione del campo Esprimi in valuta locale non cambia. Nota: questa regola è valida per tutti i tipi di tasso di cambio di qualsiasi valuta base inclusa nella sessione Tassi di cambio. Limiti tecnici Si applicano le seguenti restrizioni: Il driver di database deve essere un driver di livello 2. Le seguenti tabelle sono sottoposte a controllo e non a mirroring: tfgld495, tfgld482, tdsls451 e tdsls456. È necessario utilizzare un porting set 8.7a.03 o versione successiva. Il livello TIV del porting set deve essere 1744 o successivo. Per verificarlo, eseguire $BSE/bin/bshell6.2 –V dalla riga di comando (in Windows utilizzare %BSE\bin\ntbshell –V). Se il processo di inizializzazione della valuta viene avviato dalla sessione Processo Inizializzazione valuta (CI) (tccri7203m000), da quest'ultima verrà eseguito l'accesso al gruppo di conversione e alle relative società e verrà determinato quindi il tipo di conversione richiesto. Se è possibile utilizzare gli aggiornamenti diretti tramite RDBMS, in Tabelle di conversione CI per Società gruppo (tccri725) e Tabelle conversione gruppi Inizial. valuta (CI) - Gruppi aggiornamento (tccri726) verranno creati alcuni dati. Nota Le Tabelle conversione gruppi Inizial. valuta (CI) - Gruppi aggiornamento (tccri726) vengono generate soltanto per le voci Transazioni di integrazione (tfgld482) incluse nella sessione Tabelle di conversione CI per Società gruppo (tccri7125m000). Se una tabella viene aggiornata direttamente tramite RDBMS, nella sessione Tabelle di conversione CI per Società gruppo (tccri7125m000) viene selezionato il campo Aggiornamenti cumulativi. La tabella Transazioni di integrazione (tfgld482) può includere transazioni di più società finanziarie. Le transazioni di integrazione aggiornabili direttamente tramite RDBMS vengono raggruppate in gruppi di aggiornamento. Tutte le transazioni incluse in un gruppo di aggiornamento possono essere convertite in un unico aggiornamento RDBMS. Se alcune transazioni della tabella Transazioni di integrazione (tfgld482) devono essere convertite senza aggiornamenti diretti tramite RDBMS, la conversione può essere suddivisa. In questo modo l'aggiornamento convenzionale della tabella verrà eseguito tramite processi paralleli. La conversione della tabella Dati di riconciliazione (tfgld495) deve essere suddivisa soltanto se non è possibile utilizzare gli aggiornamenti diretti tramite RDBMS, ad esempio nel caso in cui sia necessario ricalcolare gli importi in valuta locale o i tassi di cambio. Nota Se la conversione della tabella Dati di riconciliazione (tfgld495) viene suddivisa, la tabella non verrà aggiornata direttamente tramite RDBMS. La tabella Transazioni finalizzate (tfgld106) può essere convertita tramite processi paralleli. Gli aggiornamenti effettuati direttamente tramite RDBMS non sono supportati. Esempio di ottimizzazione L'esempio riportato di seguito riguarda conversioni gestite senza aggiornamenti diretti tramite RDBMS, che possono essere suddivise in Tabelle di conversione CI per Società gruppo (tccri7125m000). Una conversione interna con elaborazione parallela può includere conversioni con o senza aggiornamenti diretti tramite RDBMS, a seconda dell'impostazione della valuta della società. Si supponga che sia necessario convertire i dati di tre società utilizzando nove elaborazioni bshell parallele. Nell'immagine precedente le tre società sono rappresentate da colori diversi. La tabella convertita con l'attività di conversione 1.1 è di grandi dimensioni. Contemporaneamente vengono convertite altre tre tabelle di grandi dimensioni (2.1, 2.2 e 3.1). Se l'attività di conversione 1.1 è divisibile, è possibile ottenere sei bshell che elaborano le attività 1.1 e tre bshell che elaborano le attività 2.1, 2.2 e 3.1. Dopo aver suddiviso l'attività 1.1, le sei attività più grandi che elaborano questa attività verranno gestite prima delle attività più piccole (di colore rosa). Lo stesso approccio può essere utilizzato, ad esempio, se le conversioni delle tabelle 2.3 e 2.4 sono suddivisibili. Se la tabella 2.3 viene elaborata da due bshell in parallelo e la tabella 2.4 da tre bshell in parallelo, le restanti bshell parallele avranno capacità sufficiente per elaborare contemporaneamente le attività più piccole (di colore verde). Dopo la suddivisione delle attività, il carico dei processi paralleli è più bilanciato. Il tempo totale trascorso si riduce da 28 a 17 unità di tempo. Processo Inizializzazione valuta (CI) (tccri7203m000): conversione di prova e conversione effettiva In modalità di simulazione, vengono eseguite prove di transazioni di database relative ad aggiornamenti diretti tramite RDBMS. È possibile utilizzare questo tipo di aggiornamenti nell'ambito della conversione delle tabelle Dati di riconciliazione (tfgld495), Transazioni di integrazione (tfgld482), Storico righe ordine di vendita (tdsls451) e Storico righe consegna effettiva ordine di vendita (tdsls456). In modalità di prova viene eseguito il rollback delle transazioni. Questa operazione può richiedere un tempo notevolmente superiore rispetto a quello necessario nella conversione effettiva. Nella logica di conversione tradizionale, durante la conversione di prova i dati delle tabelle non vengono aggiornati. Si tenga dunque presente che nella conversione di prova l'elaborazione delle tabelle richiede un tempo inferiore rispetto a quello richiesto dalla conversione effettiva. Importante! Durante l'inizializzazione della valuta, nelle società del gruppo di conversione non devono essere attivi altri utenti o processi, anche se per eseguire la conversione di prova si utilizza la sessione Processo Inizializzazione valuta (CI) (tccri7203m000). Per evitare problemi causati da blocchi di tabella o lettura di transazioni non confermate, prestare attenzione a quanto indicato di seguito: Gli aggiornamenti diretti tramite RDBMS sono transazioni di grandi dimensioni che nella conversione di prova vengono testate ma non confermate (commit). Questo può provocare blocchi nelle tabelle Dati di riconciliazione (tfgld495), Transazioni di integrazione (tfgld482), Storico righe ordine di vendita (tdsls451) e Storico righe consegna effettiva ordine di vendita (tdsls456). SQL Server: per impostazione predefinita, il driver di database utilizza il livello di isolamento "Read uncommitted" per impedire blocchi condivisi e il blocco esclusivo per azioni di aggiornamento ed eliminazione. Ne consegue che, durante la conversione (di prova), altri utenti o processi potranno leggere transazioni non confermate nelle tabelle Dati di riconciliazione (tfgld495), Transazioni di integrazione (tfgld482), Storico righe ordine di vendita (tdsls451) e Storico righe consegna effettiva ordine di vendita (tdsls456). Per ulteriori informazioni, consultare Infor Enterprise Server Technical Reference Guide for SQL Server Database Driver (U8173 US). Impostazioni Oracle Gli aggiornamenti diretti tramite RDBMS sono transazioni di grandi dimensioni che richiedono un tablespace di UNDO di grandi dimensioni. LN viene testato con un tablespace di UNDO pari a 32 GB. Si consiglia di configurare il tablespace di UNDO in modo da estendere automaticamente i file di dati, ad esempio, di 8 GB alla volta. Ciò consente di evitare la restituzione di errori ORA-1555 (Snapshot too old). Tenere presente le dimensioni massime dei file di dati. Non è facile prevedere se le dimensioni del tablespace di UNDO saranno sufficienti. Quando si esegue il Processo Inizializzazione valuta (CI) (tccri7203m000), si consiglia di controllare eventuali errori ORA-1555 nei registri del visualizzatore eventi di LN. In generale, perché le query vengano eseguite correttamente, è necessario che il database Oracle sia configurato in modo appropriato. LN è stato testato con le seguenti impostazioni applicate all'ambiente LN tramite il file $BSE/lib/default/db_resource: `ora_init:0101000` `ora_max_array_fetch:100` `ora_max_array_insert:100` `ora_alter_session`: set " `_optim_peek_user_binds` "= `false` Per la conversione può essere utile unire le righe precedenti alla risorsa del database basata su batch. In alcune implementazioni ai parametri nascosti di Oracle (i cosiddetti parametri underscore) vengono applicati valori non predefiniti. Queste impostazioni possono influenzare i piani di esecuzione delle query. Può essere pertanto opportuno reimpostarne i valori predefiniti aggiungendoli alla proprietà `ora_alter_session` del file $BSE//lib/defaults/db_resource. Impostazioni SQL Server Durante l'inizializzazione della valuta può essere opportuno impostare su Semplice la registrazione nel database di LN, quindi creare un backup completo al termine dell'inizializzazione. Impostare il file $BSE/lib/default/db_resource per consentire il recupero di array, quindi impostare la dimensione di recupero su 100. Impostazioni DB2 Impostare il file $BSE/lib/default/db_resource per consentire il recupero di array, quindi impostare la dimensione di recupero su 100. |