Ein benutzerdefinierter Batch-Bericht, der über 100.000 F0911Die zentrale Tabelle für Hauptbuchtransaktionen in JD Edwards.-Datensätze verarbeitet, sollte nicht vier bis sechs Stunden laufen. Wenn dies der Fall ist, liegt die Ursache selten an der Datenbankindizierung oder an Hardwarebeschränkungen, sondern an einer mangelhaften Konstruktion der Event Rules (ER)Die proprietäre Skriptsprache von JD Edwards zur Definition von Geschäftslogik.. Ein systematisches JD Edwards UBEUniversal Batch Engine; das Werkzeug in JD Edwards zur Erstellung von Berichten und zur Stapelverarbeitung von Daten. Performance-Tuning zur Reduzierung von Tabellenzugriffen erfordert die Abkehr von der zeilenweisen Verarbeitung. Häufig platzieren Entwickler Fetch SingleEin Befehl in den Event Rules, der gezielt einen einzelnen Datensatz aus einer Datenbanktabelle abruft. oder Select/Fetch Next Statements innerhalb der Do Section oder Do Loop Events eines UBEs, was den Enterprise Server dazu zwingt, Hunderttausende redundante SQL-SELECT-Statements gegen die Datenbank auszuführen. Durch die Analyse von JDEDEBUG-LogsProtokolldateien, die detaillierte technische Informationen über die internen Abläufe eines JD Edwards-Prozesses aufzeichnen. können wir diese Schleifen isolieren, die Datenselektion der Driver Section präzisieren und die ER-Logik so umgestalten, dass JDE Memory Cache oder benutzerdefinierte C Business FunctionsIn C geschriebene Programme, die komplexe Logik schneller ausführen als Standard-Event-Rules. verwendet werden, anstatt ständige Datenbank-Roundtrips zu verursachen.
Die Kosten von zeilenbasiertem Table IO in Event Rules
Eine einzige Zeile Event-Rules-Code kann einen Batch-Prozess unbemerkt lähmen. Jedes Standard-"Fetch Single"- oder "Select/Fetch Next"-Statement, das innerhalb eines Do Section Events platziert wird, wird nicht isoliert ausgeführt; es wird direkt in ein unabhängiges Round-Trip-SQL-SELECT-StatementsDatenbankabfragen, die verwendet werden, um spezifische Daten aus einer oder mehreren Tabellen abzurufen. übersetzt, das an die Datenbank-Engine gesendet wird. In einer typischen Oracle- oder SQL-Server-Umgebung fällt der Overhead für Netzwerklatenz, Statement-Parsing und die Auswertung des AusführungsplansEine von der Datenbank berechnete Strategie, um eine SQL-Abfrage auf dem effizientesten Weg auszuführen. bei jedem einzelnen Aufruf an, unabhängig davon, wie klein die Datenmenge ist.
Betrachten wir einen standardmäßigen Financial Integrity Report, bei dem die Driver Section 50.000 bis 100.000 Journalbuchungszeilen aus der Tabelle F0911 verarbeitet. Wenn ein Entwickler ein verschachteltes Fetch Single auf den Address Book Master (F0101Die zentrale Stammdatentabelle für Adressen, Kunden und Lieferanten (Address Book) in JD Edwards.) innerhalb dieser Schleife platziert, um einen Alpha-Namen abzurufen, initiiert die EnterpriseOne Batch-Engine Zehntausende einzelner Netzwerk-Roundtrips zur Datenbank. Selbst wenn die Datenbank jede Abfrage in scheinbar vernachlässigbaren ein bis zwei Millisekunden auflöst, summiert sich die Netzwerk- und Datenbankverarbeitungszeit zu einer erheblichen Latenz für einen einzigen Event-Loop.
Entwickler übersehen diese kumulative Latenz oft, da einzelne Event-Rules-Statements in der Object Management Workbench (OMW)Die integrierte Entwicklungsumgebung in JD Edwards zur Verwaltung von Objekten und Code. harmlos aussehen. In der Realität machen diese repetitiven Datenbankaufrufe häufig den Großteil der gesamten UBE-Laufzeit aus – oft über 80 %. Dabei bleibt die CPU des Enterprise Servers im Leerlauf, während sie auf die Antwort der Datenbank wartet.
Das Ersetzen dieser zeilenweisen Abrufe durch Datenbank-Views, Table Joins oder speicherbasierte Caching-Mechanismen kann die Laufzeit eines UBEs sofort von mehreren Stunden auf wenige Minuten senken. Indem Sie die rechenintensive Datenaggregation auf die Datenbankebene verlagern oder die internen Cache-APIsSchnittstellen, die es verschiedenen Softwarekomponenten ermöglichen, kontrolliert miteinander zu kommunizieren. von JDE nutzen, eliminieren Sie das geschwätzige Netzwerkverhalten, das die Batch-Queues während des Monatsabschlusses verstopft.
Diagnose von Tabellenzugriffen mit JDEDEBUG-Logs und SQL
Um nicht länger raten zu müssen, warum ein benutzerdefinierter UBE langsam ist, müssen Sie das rohe SQL analysieren, das von der JDB-Datenbank-MiddlewareEine Softwareebene, die Datenbankbefehle von JD Edwards in das Format des spezifischen Datenbanksystems übersetzt. generiert wird. Setzen Sie Output=FILE im Abschnitt [DEBUG] der lokalen oder Enterprise Server jde.iniDie zentrale Konfigurationsdatei für JD Edwards, die Laufzeitparameter für Server und Clients festlegt., um EnterpriseOne zu zwingen, jede einzelne Datenbankinteraktion zu erfassen. Dies erzeugt eine jdedebug.log-Datei, die den Table I/O der Event Rules direkt nativen SQL-Statements wie SELECT, UPDATE und INSERT zuordnet.
Eine mehrere Gigabyte große Log-Datei in einen Standard-Texteditor zu laden, ist ein Anfängerfehler, der Ihre Workstation zum Absturz bringt. Verwenden Sie stattdessen die Performance WorkbenchEin Analyse-Werkzeug von Oracle, das Log-Dateien auswertet, um Performance-Engpässe zu identifizieren., ein von Oracle bereitgestelltes Dienstprogramm, das die Trace-Datei analysiert und SQL-Statements nach Ausführungshäufigkeit und Dauer aggregiert. Diese Analyse zeigt sofort die exakte Frequenz von SELECT-Statements auf Tabellen mit hohem Volumen wie F0911 oder F4211 auf und deckt versteckte Schleifen auf, die tausendfach für eine einzige PDF-Seite ausgeführt werden.
Ein hocheffizienter UBE behält ein Verhältnis von Datenbank-Reads zu verarbeiteten Datensätzen von nahezu 1:1 bei, was bedeutet, dass jeder Fetch aus der Driver Section einem einzigen, gezielten Datenbank-Lookup entspricht. In schlecht optimierten Berichten steigt dieses Verhältnis häufig auf 50:1 oder höher an, was darauf hindeutet, dass die Engine die Datenbank mit Dutzenden redundanter Abfragen bombardiert, um eine einzige Transaktion zu verarbeiten.
Wenn das Log hohe Ausführungszahlen bei schlechten Antwortzeiten zeigt, müssen Sie prüfen, ob die Datenbank Ihre Indizes tatsächlich nutzt. Verwenden Sie den SQL Server Profiler oder fragen Sie Oracles v$sql_plan ab, um die Ausführungspläne der in Ihrem Log identifizierten Abfragen zu inspizieren. Dieser Schritt zeigt auf, ob der Datenbank-Optimizer Ihren benutzerdefinierten Index auf F41021 ignoriert oder aufgrund einer fehlenden Join-Bedingung in Ihrem Table I/O einen kostspieligen Full Table ScanEin ineffizienter Suchvorgang, bei dem die Datenbank jede Zeile einer Tabelle prüfen muss. durchführt.
Optimierung der Datenselektion in der Driver Section
Kürzlich habe ich einen benutzerdefinierten Sales Analysis UBE refactored, bei dem der Entwickler zuließ, dass die primäre Driver Section jeden Datensatz aus der Tabelle F4211 für das aktuelle Geschäftsjahr abrief, nur um die überwiegende Mehrheit davon (nach unserer Erfahrung etwa 80 % bis 90 %) mittels eines If-Statements innerhalb der Do Section zu verwerfen. Diese breite Datenselektion zwingt die UBE-Engine dazu, Hunderttausende unnötiger Zeilen aus der Datenbank in den Speicher des Enterprise Servers zu laden. Die Datenbank verbraucht Zyklen für die Ausführung von Select-Statements und die Übertragung von Paketen über das Netzwerk, nur damit die Runtime-Engine die Daten sofort wieder verwirft.
Sie müssen die Filterarbeit dorthin zurückverlagern, wo sie hingehört: auf die Datenbankebene. Die programmatische Manipulation der SQL-WHERE-KlauselDer Teil eines SQL-Befehls, der Filterkriterien definiert, um die Ergebnismenge einzuschränken. mit der Systemfunktion Set User Selection in der Initialize Section ist exponentiell schneller als die Auswertung von Bedingungen innerhalb der Do Section. Wenn Sie beispielsweise F4211-Datensätze nach Next Status (NXTR) und Line Type (LNTY) filtern müssen, beschränkt der explizite Aufruf dieser Systemfunktion das initiale Öffnen des Cursors auf den passenden Datensatz und verhindert, dass die Middleware unnötigen Ballast verarbeitet.
Damit diese programmatische Selektion effektiv ist, müssen die Zielfelder mit einem vorhandenen Datenbankindex übereinstimmen. Eine Abfrage gegen F4211 oder F0911 auf einem nicht indizierten Feld wie dem Transaction Date (TRDJ) löst einen Full Table Scan aus, was die Datenbank-Performance zerstört. Zudem ist das Weglassen der Business Unit (MCU) oder der Company (CO) in den Selektionskriterien auf partitionierten Datenbanken ein häufiger Fehler, der die Tabellenlesezeiten oft um das Drei- bis Vierfache erhöht, da die Datenbank-Engine keine PartitionenUnterteilungen großer Datenbanktabellen in kleinere Segmente zur Steigerung der Abfragegeschwindigkeit. ausschließen kann und gezwungen ist, jede Partition im Schema zu scannen.
Refactoring von verschachtelten Loops und Table IO
Das Platzieren einer Select- und Fetch-Next-Schleife innerhalb der Do Section eines UBEs ist der schnellste Weg, um die Batch-Performance von Minuten auf Stunden zu verschlechtern. Wenn die Driver Section 50.000 bis 100.000 Datensätze verarbeitet und die innere Schleife eine Sekundärtabelle wie die F4211 ohne enge Grenzen abfragt, führt der Enterprise Server Hunderttausende redundante Datenbank-Roundtrips aus. Dieses geometrische Wachstum der Tabellenzugriffe drosselt die Datenbank-Engine, insbesondere wenn Entwickler es versäumen, die inneren Select-Keys exakt auf einen zusammengesetzten Index abzustimmen, was Full Table Scans anstelle von schnellen Index-Lookups erzwingt.
Diese verschachtelten Strukturen hinterlassen häufig eine Spur von nicht geschlossenen Datenbank-Cursorn. Jeder offene Tabellen-Pointer, dem ein entsprechendes explizites Close-Statement in den Event Rules fehlt, verursacht Memory LeaksFehler, bei denen Arbeitsspeicher reserviert, aber nicht wieder freigegeben wird, was das System verlangsamt. und hält CursorEin Datenbank-Objekt, das als Zeiger fungiert, um durch die Ergebnismenge einer Abfrage zu navigieren.-Handles auf dem Enterprise Server offen. Über einen Lauf von Zehntausenden von Iterationen verbraucht dieses Versäumnis Systemressourcen, bis die Datenbank limits erreicht sind, was zu einem plötzlichen, unerklärlichen UBE-Fehler führt. Das explizite Schließen jedes Tabellen-Handles am Ende des bedingten Blocks ist für eine stabile Batch-Verarbeitung nicht verhandelbar.
Repetitive Abfragen für statische Konfigurationsdaten, wie das Abrufen von UDC-WerteUser Defined Codes; anpassbare Listen in JD Edwards zur Validierung von Datenfeldern.n aus der F0005, sollten niemals innerhalb dieser Schleifen erfolgen. Anstatt Tausende einzelner F0005-Reads für dieselben Dokumenttypen auszuführen, laden Sie diese Referenzdaten einmal in einen JDE-Cache unter Verwendung der jdeCache APIProgrammierschnittstellen in JD Edwards, um Daten für schnellen Zugriff im Arbeitsspeicher statt in der Datenbank zu speichern. innerhalb einer benutzerdefinierten C Business Function während der Initialize Section des UBEs. Das Abrufen aus dem Speicher anstatt von der Datenbank reduziert die I/O-Ausführungszeit auf nahezu Null. Für einfachere Anforderungen erzielt das Laden von Key-Value-Paaren in ein Memory-Array beim Start die gleiche Reduzierung des Overheads ohne Datenbank-Penalty.
Nutzung von JDE Cache und Business Functions
Event Rules Table I/O verursacht Performance-Einbußen, da der Interpreter des Toolsets jedes Statement sequenziell mit erheblichem Laufzeit-Overhead verarbeitet. Wenn ein UBE ein einfaches F0014.FetchSingle innerhalb einer Schleife von 100.000 oder mehr Datensätzen ausführt, verhandelt die ER-Engine wiederholt Datenbankverbindungen und parst SQL-Statements. Die Verlagerung dieser Lookup-Logik in eine kompilierte C Business Function umgeht diesen Interpreter-Overhead vollständig und erfolgt mit nativer Maschinencode-Geschwindigkeit.
Durch die Entwicklung einer benutzerdefinierten C Business Function wie B550001 unter Verwendung von JDECACHE APIsProgrammierschnittstellen in JD Edwards, um Daten für schnellen Zugriff im Arbeitsspeicher statt in der Datenbank zu speichern. initialisieren Sie während des Initialize Section Events des UBEs einen benannten In-Memory-Cache auf dem Enterprise Server. Der erste Datenbankzugriff lädt den erforderlichen Datensatz in den Speicher; nachfolgende Anfragen werden über Speicher-Pointer anstatt über Datenbank-Roundtrips aufgelöst. Dieser Ansatz eliminiert SQL-Reads für statische Stammdaten, indem Keys und Values in einem strukturierten Speicher block gespeichert werden, der nur für die Dauer des UBE-Laufs existiert.
Für UBEs mit hohem Volumen, die 100.000 oder mehr Datensätze verarbeiten, reduziert das Caching von Stammdaten wie Zahlungsbedingungen (F0014) oder Steuersätzen (F4008) die Datenbankaufrufe um 90 % oder mehr. Anstatt Zehntausende Male auf die Datenbank zuzugreifen, um dieselben zehn Zahlungsbedingungen aufzulösen, fragt der UBE die Datenbank nur einige Male ab, um den Cache zu füllen, und führt dann blitzschnelle Speicher-Lookups für die verbleibenden Datensätze durch.
Eine benutzerdefinierte C Business Function verarbeitet komplexe Speicherstrukturen und binäre Suchen weitaus schneller, als ER durch Datenbanktabellen iterieren kann. Die Verwendung der jdeCacheFetchPosition API ermöglicht es dem System, Hochgeschwindigkeits-Binärsuchen auf indizierten Cache-Keys durchzuführen und Daten in Mikrosekunden zurückzugeben. Dies verlagert den Verarbeitungsengpass von der Datenbankebene in den RAM des Applikationsservers, wo Speicherzugriffszeiten in Nanosekunden gemessen werden, im Gegensatz zu den Millisekunden, die für physischen Disk-I/O erforderlich sind.
Messung von Performance-Gewinnen nach dem Refactoring
Sie können sich nicht auf subjektives Benutzerfeedback verlassen, um eine Refactoring-Maßnahme zu validieren; Sie benötigen harte Zahlen aus der Tabelle Job Control Status Master (F986110Die Systemtabelle in JD Edwards, die Status und Laufzeiten aller Batch-Jobs speichert.). Durch Abfrage der Felder JCSTRTTIME (Startzeit) und JCENDTIME (Endzeit), wo der Jobstatus (JCST) 'D' (Done) ist, können Sie die exakte Ausführungsdauer in Sekunden berechnen. Vergleichen Sie diese Baseline nach der Optimierung mit mindestens drei historischen Läufen des unveränderten UBEs, um Schwankungen in der Netzwerk- oder Datenbanklast zu berücksichtigen.
Isolieren Sie als Nächstes die Auswirkungen auf die Datenbank, indem Sie die Gesamtzahl der SQL-Statement-Ausführungen vor und nach den Codeänderungen vergleichen. Das Erzeugen eines jdedebug.log für eine repräsentative Stichprobe von mehreren tausend Datensätzen zeigt den exakten Rückgang der physischen Tabellenzugriffe. In einem kürzlich durchgeführten Projekt mit einem stark angepassten R42565 (Invoice Print) reduzierte das Refactoring von verschachteltem F41021 Table I/O in einen speicherresidenten Fetch die Datenbank-Roundtrips von über einer Million auf weniger als 15.000 für einen einzigen Batch-Lauf.
Geschwindigkeit darf nicht auf Kosten der Stabilität gehen, insbesondere wenn Disk-I/O gegen JDE-Cache oder große Speicherstrukturen getauscht wird. Überwachen Sie die CPU-Auslastung und den Speicherbedarf des Enterprise Servers während der Ausführung via top unter Linux oder Task-Manager unter Windows. Ein schlecht verwalteter JDE-Cache, der deallocateUserCache nicht aufruft oder Pointer in benutzerdefinierten C Business Functions nicht freigibt, äußert sich als Memory Leak und bringt schließlich den jdenet_k Kernel-Prozess zum Absturz.
Wenn diese Metriken übereinstimmen – reduzierte Datenbank-Statements, stabile Speicherallokation und saubere C-Code-Ausführung – führt eine erfolgreiche Optimierung in der Regel zu einer Reduzierung der Gesamtlaufzeit um 70 % bis 90 % bei Batch-Läufen mit hohem Volumen. Entscheidend ist, dass Sie einen vollständigen PDF- und Tabellenvergleich mit einem Tool wie PDF Diff durchführen, um zu garantieren, dass die optimierte Logik identische finanzielle und operative Ergebnisse wie die Legacy-Version liefert.
Wenn die Reduzierung von Table IO in Ihren High-Volume-UBEs weitere Engpässe in Ihrem benutzerdefinierten Code aufgezeigt hat, bieten die technischen Artikel zu C BSFNBusiness Function; eine wiederverwendbare Logikeinheit in JD Edwards für komplexe Prozesse. Memory Management und SQL View Integration tiefergehende architektonische Anleitungen zur Optimierung der ERP-Performance.
