Wednesday, July 5, 2017

Financial Reporting 11.1.2.4.700+ Logging Bug

If you're on EPM 11.1.2.4 and have applied any of the recent patches for Hyperion Financial Reporting 11.1.2.4.700 or higher, this post is for you!

Hop onto your Financial Reporting host server and inspect this folder:

\Oracle\Middleware\user_projects\domains\EPMSystem\servers\FinancialReporting0\logs\

Look for a file here named FRLogging.log.  How large has it grown?

In all versions older than HFR 11.1.2.4.700, FRLogging.log would rotate automatically.  Starting in 11.1.2.4.700, however, this behavior broke and the log grows indefinitely.

This log in particular contains the details about the reports your users are running.  By default, each report generates 3-5 pages of log entries.  If your users heavily rely upon Hyperion Financial Reporting during month-end and/or quarter-end close, this log file can grow very quickly!


Root Cause and Workaround!
 
Edit this file:

\Oracle\Middleware\user_projects\domains\EPMSystem\config\fmwconfig\servers\FinancialReporting0\logging.xml

Find this section within the file:







The above block of XML is entirely missing the rotation-related settings. Here's a corrected version you can use to replace the above:












The above is what I prefer to use. This will cause your logging.xml file to rotate daily, with a maximum retention of 7 days' worth of files.

One thing to bear in mind: This logging.xml file resides both on your Hyperion Financial Reporting host machine and also the WebLogic Admin Server's machine. Whenever WebLogic Admin Server is running, and Financial Reporting is restarted, the logging.xml file on the WAS server is pushed to the HFR server. Also, if you have HFR clustered across multiple instances/machines, you'll need to edit logging.xml within FinancialReporting1, FinancialReporting2, etc., as appropriate.

Update: I've submitted an Oracle SR to issue a BUG about this issue, as I've encountered this in every single 11.1.2.4 implementation I've done across multiple Oracle customers.

6 comments:

  1. Thanks Dave for the tip. It was really helpful. Any news from Oracle about it?
    Regarding logging.xml, is that the only way to tune this up? wondering if weblogic admin console have the details of that file accessible somewhere around.
    kr,
    elraff

    ReplyDelete
  2. Hi Elraff, sorry for the delay in responding. This appears to be fixed in the very latest patch (11.1.2.4.706 as of this writing). At least, that's what I discovered during my regression test. Your mileage may vary!

    Editing the logging.xml file is, for me, the quickest way to resolve the issue. My WebLogic Admin Server is usually shut down so as to conserve memory.

    ReplyDelete
  3. Apologies if this question is remedial but, should the logging.xml file be edited on both servers then? (FR and WAS).

    ReplyDelete
    Replies
    1. ..btw we are on FR708 and it is still a bug from what I can see.

      Delete
  4. we still have that bug as well - our log.html exists on our Base01 and our RPT01 server. we changed a value in both and the result was Base01 file was still being pushed.
    another question: we changed our rotation frequency to DAILY and notice that the files all end around 4:50(ish) pst and they start at 5:00 pm (ish) pst. so today, all log info until 5:00 pm is going to log that started 5:00 pm yesterday. we thought DAILY would help the size issue, but we have GIGANTIC unusable logs. we are implementing a max size property tonight on production.

    ReplyDelete
  5. Sadly, I need to lock this thread now due to the overseas gambling website spammers.

    ReplyDelete