For many years, the conventional wisdom was that if your Essbase server was failing to start, you should run it in the foreground to see any messages that might be displayed to the console, but not logged into the Essbase.log file. With the pre-11.1.2.x versions, this was usually quite simple. In fact, if you had your environment variables set right, all you needed to do is type in ‘essbase’ at a command prompt regardless of what directory and your Essbase server would start before your eyes.
According to the Essbase Database Administrator’s Guide (dbag), it states that the ability to run Essbase in the foreground is no longer supported as of version 188.8.131.52.100. With the 11.1.2.x versions and their more complicated directory structure (some static files stored in …Oracle/Middleware/EPMSystem11R1/products…. and some files stored in …Oracle/Middleware/user_projects/epmsystem1/…); starting Essbase in the foreground can be challenging if you don’t use this simple hack.
If we open a command prompt and navigate to the …/Oracle/Middleware/EPMSystem11R1/products/Essbase/EssbaseServer/bin directory and type in ‘essbase’, you will likely see a message about an improper ESSBASEPATH, or maybe a message about the Locale.
In later versions, Essbase needs to reference files from different folders. We have two options, we can either set up the proper environment variables or we can do what Oracle has done with their ESSCMD and ESSMSH executables. I like to hijack the “startEsscmd.cmd” script that is installed with the Essbase Client in …/Oracle/Middleware/EPMSystem11R1/products/Essbase/EssbaseClient/bin directory.
Simply save a copy of the “startEsscmd.cmd” script as “startEssbase.cmd”. Edit the new “startEssbase.cmd” script and change the “%ARBORPATH%\bin\ESSCMD.exe %*” line to “%ARBORPATH%\bin\ESSBASE.exe %*”. Then, save the startEssbase.cmd file and when you double-click it in Windows, Essbase will run in that window. Now you can use those old school Essbase commands in the foreground and rebuild the Essbase.sec file if absolutely necessary.
Of course, this is unsupported and with the advances in Essbase, it’s probably not even necessary since Essbase runs much better now than it did in the 9.3.x and early 11.1.1.x days. The only time I have had to do this is when the Essbase.sec is corrupted beyond repair, but starting in version 184.108.40.206, I believe, Essbase tries to create a new Essbase.sec file automatically if it’s missing. It’s not very often that these steps are needed, but I wanted to document them just in case anyone is running on an old version out there. If you are on EPM version 220.127.116.11 or older, please consider an upgrade. I know a guy that can help with that.