Sunday, June 27, 2021

What's Clobbering My Essbase Log?

Every now and then I need to educate a customer on how OPMN works.  Well, here's some knowledge I'm giving away for free.  (3 CEOs ago hated when I did this)

Here's the symptom of what's causing your on-premises Hyperion / Oracle EPM Essbase.log to keep growing 24x7, even when no end-users are logged in and no MaxL automation is running:

What's going on here?  Nobody is logged in but the log keeps getting updated once every 20 seconds or so.

This, dear reader, is OPMN.

Oracle Process Management Notification Service.

OPMN is responsible for managing active-passive Essbase clustering.  These "hits" you're seeing in the log is OPMN pinging Essbase to see if it is alive.

"But wait a moment, Dave!  I have just one Essbase server per environment and am definitely not doing Active-Passive Essbase clustering!!!  How do I turn these pings off???"

I'm glad you asked.  Let's investigate the OPMN config file, located here by default:

Make a backup copy of opmn.xml if you've never performed this exercise before!  OPMN is very particular about the XML file, and Essbase will fail to boot up if you commit a typo error in this file.

Now click Search->Find in your favorite text editor (cough cough Notepad++ cough cough) for the word "death".  It is present in the opmn.xml file exactly once:

I have comments to offer on the restart-on-death setting.  We'll get to that in a moment.  But for now, you want to insert a new line immediately after <restart retry="2" timeout="600"/>

Paste exactly this:

<ping timeout="20" interval="0"/>

Bounce the Essbase service (Windows) or use your / scripts in Linux.  Done.  Your modified file should look like this:

The line you pasted disables the 20-second ping.  Obviously, if you ARE indeed running Essbase in an Active-Passive cluster configuration, then you need to IGNORE my advice in this case.  That 20-second ping is what allows OPMN to fail over Essbase to the Passive node, if your environment is correctly setup.

Now let's briefly touch upon the restart-on-death setting.

The setting defaults to "true", which I tend not to like.  Why?  Because I prefer to use MaxL to gracefully shutdown the Essbase Agent rather than stopping the service or running  Stopping the service brings down Essbase unconditionallyAn ESSSVR process that's active - whether it is loading data, running a calc script, or restructuring - is now orphaned and cannot be restarted until the PID is killed.

How I bring down Essbase gracefully and send an alert to the system admins when it doesn't come down gracefully.... well, if you must know you may buy me off with a case of Guinness.

Happy Essbase'ing!

No comments:

Post a Comment

Thank you very much for your interest in this blog! I hope you're finding it helpful.

Please keep comments relevant to the topic in the post, as this blog is not a free-for-all substitute for Oracle Support or traditional consulting. If you have many questions unrelated to the specific topic at hand, consider contacting me on LinkedIn ( so we may discuss the possibility of consulting.

Commenting on posts older than 90 days unfortunately goes into moderation, thanks to spammers who've been hitting this blog. Please have patience, and thanks for your understanding!

Comments including URLs linking back to gambling or other things unrelated to Oracle EPM will be deleted on sight. If you're an EPM consultant and are offering me constructive criticism or a tip, go ahead and DO link back to your blog or firm's website if you so desire.

Thanks again for reading!