Art of BI: Hyperion OpenLDAP and Shared Services Won’t Start – Error 1068
Author: Christian Screen | 2 min read | July 21, 2009
The Oracle/Hyperion EPM System 9x or 11x is crazy robust due to its suite offerings. However, as any administrators will tell you it is highly dependent on the correct start and stop order of its windows services. The database has to be up before shared services and OpenLDap then workspace can be started, blah, blah, blah. Often when the inappropriate stop/shutdown of these services takes place they can become “corrupted” for a lack of a better word.
In particular, a common annoyance is when the OpenLDAP windows service has a problem started. And, thus the shared services windows service will not kick off properly. You may get hit with prompts like this when this occurs.
OpenLDap uses a nice database called Berkeley. I won’t go into details but if you read the wikipedia on Berkeley you will see how it could get out of sync since there is no real structured storage to it. I won’t go any further on that topic in this post.
Solution
First, navigate to the core directory, %HYPERION_HOME%productsFoundationopenLDAPvaropenldap-data, and make a back-up of this folder. Save it using your favorite compressor (rar, zip) and store it in a safe location.
Second, navigate to the following directory on the machine hosting OpenLDAP, %HYPERION_HOME%productsFoundationopenLDAPbdbbin. Copy the file called db_recover.exe
Third, navigate back to the core directory, %HYPERION_HOME%productsFoundationopenLDAPvaropenldap-data, and paste the db_recover.exe file in there.
Fourth, double-click/execute the db_recover.exe in the folder. It runs quickly so you will miss the command window execute if you blink.
Fifth, at this point the db_recover.exe execution has resync’d your OpenLDAP database to its last save setting before the “corruption”. You should be able to start your OpenLDAP and Shared Services window services now.
Recommendations & Further Discussion
I offer this solution to a development environment situation. Surely, in a production environment, you are backing up the core OpenLDAP directory on a daily basis. Also, there is a lot more detail on the db_recover.exe file that you can find by running it from the command prompt and looking at the help menu (i.e.: db_recover.exe ?). When we run it as outlined in the steps above we are simply recovering the last backup of the OpenLDAP directory. With the command prompt, you can actually recover to a explicitly previous data in time.
