There’s JDE pain, damned JDE pain and then there’s Analytics

Posted by Pete Joslin | Apr 05, 2018

Take out some JD Edwards “Data Insurance”

Go on, admit it. The only time you really think about your JD Edwards data is when it starts causing you pain. Proactively managing your JDE data is a bit like having the right insurance, it gives you peace of mind. Just like having insurance, regularly managing your JDE data helps to avoid potentially painful and expensive incidents in the future.


Time to see your ERP data Doctor?

Pain, especially when it comes to Oracle JD Edwards data, can vary from mild to severe. It often begins slowly with the little things, like slow running reports or strange errors, and eventually rises to frozen sessions, login failures and potentially a partial or total ERP system failure.

JD Edwards data archiving is like an overdue doctor’s appointment. Too many of us only visit when the pain becomes so great we can no longer ignore it. In Oracle data archiving terms, we live with all the small niggles and if the “usual” processes are running, the backups are completing, and the application is secure, then everything is good, right?

Err, possibly.

When multiple tickets get raised that mention Oracle JDE performance, or that an operation is taking longer than expected, a heavy sigh can be heard echoing around the IT office. There is a realisation that software performance is becoming an issue and actions can’t be put off any longer!

The challenge is then “How can we tell what is wrong?”, “How do we identify the root cause?”, and “How do we make the pain go away?”

Houston, we have a problem

At that point, the ticket gets escalated and the “investigation” begins. Servers are connected to, JD Edwards health is checked, CPU reviewed, RAM scrutinised, logged in user counts perused, database log files checked, disk space considered, all the usual, generically suspicious things worked through and conclusions are drawn that it’s data related.

If this is the route that leads to you seeing that volumes of JD Edwards data lie at the root of your ERP issues, that’s good. You caught it early. But pain is pain and the need for JD Edwards data archiving solutions urgently brings with it its own questions, like “How do I maintain my JDE data integrity?”, or “How can I be sure that the data I archive won’t cause problems in my application?”.

The good news is you’re thinking about your Oracle data management, considering your data insurance policies, or thinking you may need to visit the JD Edwards data management doctor. Now it’s time to Eat a Frog.


Eat That Frog – It will make you feel better

Eat that Frog” is a concept introduced for efficient time management by Brian Tracy. Tracy writes that to be more efficient, you should complete the worst, most horrible tasks that you have first. Say you have two tasks you don’t want to do, do the worst of the two first! No, it’s not pleasant.

Just like having to visit the doctor for a check-up, very often the things that we put off the most are the things that come back to bite us in the, um, end. Eating this frog by dealing with your JD Edwards data challenges and running some analysis to understand how your JDE application uses data, what volumes you have and for how long you need to keep your data in your production environment(s), could be the check-up your production environment needs.


< Back to Blog