Hyperion Life Cycle Management Utility in EPM 11.2 - Logging Issue

The venerable user_projects\EPMINSTANCE\bin\utility.bat thankfully still exists in Hyperion / Oracle EPM 11.2.x.  We especially need to use this due to a bug in the user interface when we attempt to LCM export or import the Document Repository (formerly Reporting and Analysis) through the Shared Services Console.

Whether or not you hit the bug depends upon the EPM 11.2 dot release you're using, and also a roll of the dice.  The system either points the Document Repository at the correct underlying relational database, or it does not.  In the LCM graphical user interface, we get the vague EPMLCM "user not provisioned" or "not available" errors.  We'll all seen these before across multiple EPM products & releases.  So I'll skip the screenshots and dive right in.

You might not be able to export/import Document Repository through the HSS Console if the system is pointing it to the wrong database.  You can inspect this by launching the old "FRConfig" utility and examining the jdbcURL in the mBeans tab.

So when this happens, sometimes we need to use the LCM command-line utility.  The Workspace->Explore->File->Import/Export menus still work, but if you have 100s of reports you may be clicking "Overwrite" or "Skip" hundreds of times during the import process.

I noticed a problem in EPM 11.2.5.0 where the LCM export kept throwing hundreds of "user not provisioned" errors behind the scenes in the SharedServices_Security.log back-end log.  These errors are happening because the DocRep jdbcurl is pointing to the wrong database.  Coupled with this, errors relating to "cannot write to file" are also present....

Because the back-end logs are rotating faster than LCM can keep up!

Here's why, and the fix!

Examine this file on your Foundation server where you're running utility.bat from:

\Oracle\Middleware\user_projects\epmsystem1\config\FoundationServices\logging.xml

Inspect these sections:

Highlighted above is our first problem.  The log rotates once it hits 1MB in size, and only 4 backups are retained.  In my testing within a customer's environment, the SharedServices_Security_Client.log was rotating 100s of times, and LCM's back-end log started throwing fits.

Why is it writing to the log so many times?  Answer:

I've never been a fan of logging in TRACE by default, unless we're investigating an ongoing problem.

So the 2 screenshots above in combination explain what's going on.  Bump up both maxFileSize and maxLogSize for the epmcss-handler by a factor of 10, and then change the logger level for epmcss-handler from TRACE:32 to something like NOTIFICATION:1.  The latter will greatly cut down on the noise, and now LCM will be able to keep up with the logs.

Once I did these things, I stopped seeing complaints from the system about "unable to write to file SharedServices_Security.log.321" and such.  The underlying bug is still there about the Document Repository jdbcURL connection -- as far as I can tell, it is NOT getting it from the Shared Services Registry database; the HSS Registry database is correct according to the registry report.