Oracle JD Edwards performance stress

You’re likely familiar with the stress that arises when there are performance issues with an Oracle JD Edwards ERP system: stress for users, but especially for the IT organization.
The focus is mainly on getting systems back up and running as quickly as possible. That’s understandable, but how do you actually go about it? Turning it off and on again will get the system running, but where exactly was the problem? What does the problem analysis reveal? It’s difficult to determine afterward. Assumptions can be made, but they’re likely inaccurate.
Is Measuring Knowing?
With this in mind, people tend to be more vigilant the next time. System administration closely monitors hardware performance, measuring factors such as CPU (the central processing unit providing the system’s computing power), memory, and disk usage. This is a good start. But things get complicated when these measurements indicate no issues, yet JD Edwards system performance remains subpar. The temptation then arises to reboot the entire system. My advice: don’t!
JD Edwards System Landscape
Let’s take a closer look at the CNC concept. CNC stands for Configurable Network Computing, a term within JD Edwards that refers to how the software operates within a network of various servers. A basic JD Edwards system landscape consists of four main components: a deployment server (for installing and updating software), an enterprise server (where the application itself runs), a web server (for browser access), and a database server (for data storage). You can monitor the first three servers with JD Edwards Server Manager, a tool that provides insights into server performance. However, the database server is not visible in this tool. Since disruptions are often identified via Server Manager, it’s possible that issues in the database go unnoticed.
Database Monitoring
In many cases, monitoring the database provides valuable insights that help resolve performance issues. Monitoring can reveal “deadlocks” (situations where processes block each other), stuck tasks, missing indexes (needed for fast data storage and retrieval), complex queries, or concurrent modifications in the same table categories. All these points deserve attention before drawing conclusions.
In short, delve into the database and use the available tools for monitoring and maintenance. Often, system reboots are unnecessary, as the necessary information is already within the systems themselves.