Quando un job batch notturno eseguito su una tabella F0911 o F4211 da 30 a 50 milioni di righe blocca la coda batch per ore, la maggior parte dei DBADatabase Administrator, la figura professionale responsabile della gestione, sicurezza e manutenzione di un database. incolpa immediatamente l'hardware o richiede indici compositi personalizzati. Nella stragrande maggioranza degli audit sulle prestazioni dei UBEUniversal Batch Engine, il motore di JD Edwards per l'esecuzione di report e processi batch in background. che eseguo, il database non è il problema: sta semplicemente eseguendo SQLLinguaggio standard utilizzato per interrogare, gestire e aggiornare i dati all'interno di un database relazionale. nativo non ottimizzato generato dal runtime engine di JDEJD Edwards, il sistema software ERP di Oracle utilizzato per la gestione dei processi aziendali..
Comprendere gli errori di data selection nei JDE UBE che danneggiano le prestazioni è il modo più rapido per trasformare i blocchi delle code di diverse ore in routine di due minuti. Decisioni sottili degli sviluppatori, come l'omissione dei vincoli sul codice azienda, il passaggio di intervalli di date troppo ampi o l'annidamento di logiche OR errate nei version override, costringono il motore del database ad abbandonare gli efficienti index range scanUn metodo di accesso efficiente in cui il database legge solo un intervallo specifico di dati utilizzando un indice. a favore di devastanti full table scanUn'operazione in cui il database legge ogni singola riga di una tabella per trovare i record richiesti, rallentando le prestazioni.. Correggere questi criteri direttamente in EnterpriseOneLa suite software ERP di JD Edwards per la gestione integrata dei processi aziendali. richiede uno sforzo di sviluppo minimo, ma libera istantaneamente le code batch aziendali.
Filtro Azienda Mancante che Costringe a Full Table Scan
Un report di integrità finanziaria personalizzato sulla tabella del libro giornale (F0911La tabella del Libro Giornale (Account Ledger) nel database di JD Edwards.) eseguito su un database da 20 a 30 milioni di record può essere completato in pochi secondi se strutturato correttamente, ma può sovraccaricare la CPU del database per ore se manca un singolo campo. La causa principale più frequente nei UBE finanziari e di distribuzione personalizzati è l'omissione del filtro Azienda (CO o KCOO). Quando uno sviluppatore filtra esclusivamente su un Account ID (AID) o su un Object Account (OBJ), il motore del database non può isolare la specifica partizione organizzativa, costringendo a un costoso full table scanUn'operazione in cui il database legge ogni singola riga di una tabella per trovare i record richiesti, rallentando le prestazioni. su tutti i registri storici aziendali.
Su tabelle transazionali pesanti come F0911, F4211La tabella dei dettagli degli ordini di vendita (Sales Order Detail) in JD Edwards. e F0411, le colonne dell'azienda fungono da prefisso principale negli indici compositi come F0911_1 o F4211_1. L'omissione di CO o KCOO interrompe la gerarchia degli indici, rendendo inefficaci gli index range scanUn metodo di accesso efficiente in cui il database legge solo un intervallo specifico di dati utilizzando un indice. multicolonna. Anche se un utente finale seleziona un intervallo ristretto di codici articolo o alcuni conti GL specifici, il parser SQL deve comunque scorrere decine di milioni di righe di aziende non correlate relative agli anni fiscali passati solo per verificare se tali conti esistono in business unit non selezionate.
Non lasciare mai il filtro dell'azienda alla discrezione degli utenti finali solo tramite la data selection a livello di versione. Nello sviluppo di UBE personalizzati, imponi una selezione esplicita dell'azienda a livello programmatico all'interno dell'evento Initialize SectionUn evento nei report JDE che viene eseguito prima dell'elaborazione dei dati, ideale per impostare filtri e selezioni. utilizzando le Event RulesIl linguaggio di programmazione proprietario di JD Edwards utilizzato per definire la logica di business.. Chiamare Set Selection Append Flag impostato su YES seguito da Set Data Selection per associare TK Company uguale a PO Company garantisce che l'ottimizzatore del database colpisca la chiave dell'indice di livello superiore ogni volta che il motore UBE genera la sua clausola WHERE dinamica, indipendentemente da ciò che gli utenti cancellano o modificano al momento dell'invio.
Intervalli di Date Ampi che Evitano gli Index Range Scan
Nell'elaborazione batch giornaliera sulla tabella dei dettagli degli ordini di vendita F4211, gli sviluppatori tentano regolarmente di intercettare tutti i record attivi impostando limiti di data hardcoded da 01/01/1900 a 12/31/2099 o lasciando vuoto il parametro della data inferiore. Quando il motore di un database aziendale valuta un indice basato su Order Date (TRDJ) o GL Date (DGJ) su un intervallo di 200 anni, la selettività del predicato scende a zero. L'ottimizzatore delle query di Oracle valuta il costo dell'attraversamento dell'albero e abbandona completamente l'index range scanUn metodo di accesso efficiente in cui il database legge solo un intervallo specifico di dati utilizzando un indice., ripiegando su un costoso index fast full scan o su un full table scanUn'operazione in cui il database legge ogni singola riga di una tabella per trovare i record richiesti, rallentando le prestazioni. su decine di milioni di righe storiche.
La valutazione di diversi anni di record F4211 archiviati costringe il server del database aziendale a leggere gigabyte di dati di blocco non necessari nella buffer cacheUn'area della memoria RAM utilizzata dal database per memorizzare temporaneamente i blocchi di dati letti dal disco. solo per scartare la stragrande maggioranza di quelle righe in memoria. Il passaggio di questo modello di esecuzione a una finestra operativa mobile rigorosa di 30 giorni riduce l'I/OOperazioni di lettura e scrittura dei dati tra la memoria del computer e i dispositivi di archiviazione come i dischi. fisico del database dall'80% al 90%. Un UBE di contabilizzazione delle vendite che elabora da 10 a 15 milioni di righe, e che in precedenza richiedeva quasi un'ora, verrà completato in meno di un minuto una volta che il query planner si aggancia a un efficiente index range scan.
I criteri di date ampie hardcoded nelle versioni batch devono essere sostituiti con una logica dinamica di Event Rule nell'evento Initialize SectionUn evento nei report JDE che viene eseguito prima dell'elaborazione dei dati, ideale per impostare filtri e selezioni.. L'uso di business function o variabili di sistema integrate per calcolare i limiti del periodo mobile, come derivare la data di inizio del periodo corrente rispetto a SL DateToday, consente di inserire valori limite esatti prima che l'istruzione SQL venga costruita. La costruzione della data selection con chiamate a Set User Selection che specificano esplicitamente sia il limite inferiore che quello superiore garantisce che il motore di query esegua un range scan mirato anziché un attraversamento completo della tabella.
Disallineamenti degli Indici da Logica OR e Wrapping di Funzioni
Nell'elaborazione batch dell'inventario, gli sviluppatori tentano frequentemente di filtrare record multi-location combinando F41021.MCU (Business Unit) e F41021.GLPT (G/L Category Code) utilizzando condizioni OR senza parentesi. Il generatore SQL traduce questa ampia disgiunzione in un piano di esecuzione che invalida l'indice primario composito (ITM, MCU, LOCN, LOTN). Invece di un index range scanUn metodo di accesso efficiente in cui il database legge solo un intervallo specifico di dati utilizzando un indice. che si completa in pochi millisecondi, Oracle Database ripiega su un full table scanUn'operazione in cui il database legge ogni singola riga di una tabella per trovare i record richiesti, rallentando le prestazioni. o su una complessa operazione di CONCATENATION. Su una tabella F41021 da 10 a 15 milioni di righe, questo singolo errore logico fa impennare i tempi di esecuzione dei UBE basati su C da pochi minuti a diverse ore.
Il wrapping dei campi di data selection in trasformazioni di stringhe come UPPER() o SUBSTR() all'interno di business function C personalizzate o System Function Set User Selection causa esattamente la stessa soppressione dell'indice. A meno che non esista un function-based indexUn indice speciale creato sul risultato di una funzione o espressione, anziché direttamente sul valore di una colonna. personalizzato nello schema del database, l'ottimizzatore valuta ogni singolo record in modo sequenziale. L'unione di questo aspetto con una data selection di versione approssimativa crea fallimenti a catena. Quando le istruzioni AND/OR annidate mancano di un raggruppamento esplicito tra parentesi nel Version Design Assistant, JDE aggiunge i filtri obbligatori di sicurezza dell'ambiente e dell'azienda con una precedenza degli operatori errata, generando query SQL logicamente fuori controllo che scansionano l'intera tabella.
La stabilizzazione dei piani di esecuzione su join di tabelle di grandi dimensioni, come l'abbinamento dei record di saldo F41021 alle transazioni del libro giornale F4111, richiede la sostituzione completa delle selezioni OR grezze. Progetta una tabella di lavoro dinamica popolata da query distinte e completamente indicizzate, quindi guida il ciclo di elaborazione principale del UBEUniversal Batch Engine, il motore di JD Edwards per l'esecuzione di report e processi batch in background. rigorosamente dall'elenco delle chiavi di quella tabella di lavoro. In alternativa, suddividi i requisiti di selezione ampi in più passaggi di esecuzione sequenziali o cursori di database discreti nel codice C. Il refactoring della costruzione dinamica delle stringhe OR al di fuori dei UBE ad alto volume riduce regolarmente l'utilizzo della CPU del nodo del database dal 60% all'80%, garantendo al contempo percorsi di accesso agli indici prevedibili.
Logica di Append Cumulativa nelle Event Rules e nelle Versioni
La chiamata a Set Selection Append Flag con un parametro impostato su <YES> all'interno delle regole di evento Initialize SectionUn evento nei report JDE che viene eseguito prima dell'elaborazione dei dati, ideale per impostare filtri e selezioni. o Pre-Process Section costringe il motore di runtime a concatenare la data selection a livello di versione con la logica ER personalizzata utilizzando un AND implicito. Su una tabella del libro giornale F0911 da 10 a 15 milioni di righe, questo meccanismo degrada le prestazioni del batch quando il layout della versione e la logica ER sottostante operano su presupposti contrastanti. Se una versione batch filtra esplicitamente GLDGJ per i record del periodo corrente e una regola di evento aggiunge un limite di data legacy per la convalida storica, il motore del database valuta due rami di predicati che si escludono a vicenda.
Il motore del database non può interrompere anticipatamente la query senza valutare l'intero albero dei predicati. Oracle Database o SQL Server eseguiranno un index scan su milioni di righe per soddisfare i criteri della versione, solo per scartare ogni record candidato durante il controllo del predicato ER. Il UBE termina in 10-15 minuti, consuma gigabyte di buffer cacheUn'area della memoria RAM utilizzata dal database per memorizzare temporaneamente i blocchi di dati letti dal disco. e stampa una pagina di report vuota. L'SQL di runtime sottostante restituisce WHERE (GLDGJ >= 124001 AND GLDGJ <= 124031) AND (GLDGJ <= 122365)—una totale contraddizione logica che spreca enormi cicli di I/OOperazioni di lettura e scrittura dei dati tra la memoria del computer e i dispositivi di archiviazione come i dischi. per restituire zero righe.
Quando il codice personalizzato deve controllare completamente la struttura della query di runtime, imposta esplicitamente Set Selection Append Flag su <NO> prima di invocare qualsiasi system function Set Selection. Questo cancella dalla memoria tutta la selezione della versione definita dall'utente, garantendo che solo la logica programmatica costruisca la clausola WHERE SQL. Non affidarti mai all'area di disegno del UBE per prevedere la concatenazione SQL a runtime. Estrarre l'istruzione generata da una traccia mirata di jdedebug.log è l'unico modo accurato per verificare come il motore batch di EnterpriseOneLa suite software ERP di JD Edwards per la gestione integrata dei processi aziendali. unisce i criteri a livello di versione con la logica ER prima di inviare l'istruzione al database.
Ignorare la Sequenza delle Colonne Chiave nella Data Selection Dinamica
Gli sviluppatori introducono regolarmente gravi latenze del database nei UBE personalizzati eseguendo le system function Set Selection in ordine arbitrario all'interno delle Event RulesIl linguaggio di programmazione proprietario di JD Edwards utilizzato per definire la logica di business.. Quando la data selection dinamica viene costruita a livello programmatico, il middleware JDE genera clausole WHERE SQL che corrispondono all'esatta sequenza delle chiamate alle funzioni ER. Se chiami Set Selection per l'ID conto (GLAID) e il tipo di libro giornale (GLLT) prima di definire l'azienda (GLCO), l'ottimizzatore del database riceve una clausola che interrompe la gerarchia naturale delle chiavi della tabella del database sottostante.
Prendiamo l'Indice 1 di F0911La tabella del Libro Giornale (Account Ledger) nel database di JD Edwards., strutturato su Azienda (GLCO), ID conto (GLAID), Data GL (GLDGJ) e Tipo libro giornale (GLLT). Un report di contabilizzazione o di saldo del libro giornale ad alto volume che elabora da 15 a 20 milioni di record si affida al database che colpisce questo indice composito nell'esatta sequenza da sinistra a destra. Se il tuo codice ER dinamico salta GLCO o aggiunge GLDGJ prima di GLAID, il generatore SQL passa criteri che bypassano la colonna chiave principale.
Saltare le colonne principali costringe i moderni motori di database a eseguire index skip scan o full index scan invece di precisi range scan. In ambienti che eseguono Oracle Enterprise Edition o SQL Server, un index skip scanUna tecnica di scansione dell'indice che consente al database di utilizzare un indice composito anche se la colonna principale non è specificata nella query. su una selezione F0911 non allineata consuma fino al 70-80% in più di CPU e genera migliaia di letture logiche non necessarie per esecuzione. L'ottimizzatore spende cicli di clock per attraversare i rami intermedi del B-tree dell'indice per valutare gli attributi finali come GLLT o GLDGJ su ogni codice azienda non gestito.
Prima di scrivere la logica di selezione dinamica nelle Event RulesIl linguaggio di programmazione proprietario di JD Edwards utilizzato per definire la logica di business., gli sviluppatori devono ispezionare le definizioni degli indici della tabella di destinazione in Object Management Workbench. L'allineamento di ogni chiamata Set Selection con l'esatta sequenza di colonne dell'indice composito di destinazione garantisce piani di esecuzione SQL prevedibili negli ambienti di Sviluppo, QA e Produzione.
Validare i Piani di Esecuzione SQL e Misurare l'Impatto sul Runtime dei UBE
Isola l'SQL effettivamente generato estraendo l'esatta istruzione SELECT da jdedebug.log. I cicli di recupero dei record del motore, la logica delle regole di evento e le chiamate alle API C gonfiano le metriche grezze del batch, rendendo la durata complessiva del UBEUniversal Batch Engine, il motore di JD Edwards per l'esecuzione di report e processi batch in background. una diagnostica ingannevole. Su una ricostruzione del cardex di inventario in esecuzione su Oracle Database 19c, l'estrazione dell'istruzione grezza ha rivelato una scansione non indicizzata su F4111. L'esecuzione diretta di quella specifica query e l'applicazione dell'indice corretto hanno ridotto il tempo di esecuzione rilevato da 45 minuti a meno di 15 secondi.
Incolla l'SQL catturato in Oracle SQL Developer o SQL Server Management Studio per generare un piano di esecuzione del cost-based optimizerIl componente del database che analizza diverse strategie di esecuzione per una query e sceglie la più efficiente in base ai costi stimati.. Cerca in particolare i full table scanUn'operazione in cui il database legge ogni singola riga di una tabella per trovare i record richiesti, rallentando le prestazioni. su tabelle con milioni di righe come F0911 o F4211, la soppressione degli indici innescata da conversioni di tipo implicite e gli avvisi di indici mancanti generati dal motore del database. Questi piani di esecuzione evidenziano immediatamente dove le definizioni degli indici standard di JDE non riescono ad allinearsi con le tue clausole di data selection personalizzate.
Il benchmarking delle versioni UBEUniversal Batch Engine, il motore di JD Edwards per l'esecuzione di report e processi batch in background. modificate in ambienti DV o PY contenenti da 50.000 a 100.000 record produce tempi di esecuzione falsamente ottimistici che crollano quando vengono esposti ad ambienti di produzione che contengono da 50 a 100 milioni di righe. Aggiorna sempre gli ambienti di staging non di produzione con set di dati di produzione completi e sanificati prima dell'approvazione finale. I test su volumi su scala di produzione espongono i problemi di cardinalità degli indici nel tuo ambiente di staging piuttosto che durante una finestra critica di esecuzione batch.
Stabilisci obiettivi di runtime rigidi per tutti i principali job batch notturni, impostando avvisi di soglia automatizzati ogni volta che un job supera del 15% - 20% la sua finestra di esecuzione storica. Se un UBE finanziario modificato passa improvvisamente da una media di 10 minuti a oltre 30 minuti, hai la prova immediata di una regressione del piano di esecuzione. L'applicazione di una disciplina di runtime di base impedisce ai report a lunga esecuzione di violare i programmi di backup notturni e di ritardare le operazioni di magazzino il mattino successivo. Controlla le tue Event RulesIl linguaggio di programmazione proprietario di JD Edwards utilizzato per definire la logica di business. per una corretta sequenza delle colonne, elimina i flag di append ridondanti e valida i piani di esecuzione in staging prima di distribuire le modifiche dei report personalizzati in produzione.
