A Possible Disaster Recovery Strategy for an EPM System

The client was already utilizing EMC’s SRDFA (Symmetric Remote Data Facility -Asynchronous) to replicate the EPMS Production DB files and logs to their QA environment, which doubles as their DR environment. The DR plan makes use of the HFM, Planning and FDM replicated DB files to recover the applications associated with those components. The only additional requirement was for the applications to exist in the QA environment with the same names as Production. This will ensure the Production applications are recognized by all other QA components in the event DR is triggered.
The client had also already established LCM migrations for Security and their EPMA components. The migrations were being used to push updates from QA to Production. Similar LCM migrations were created to reverse the process for DR. New LCM migrations were created for migrating Financial Reporting, Calc Mgr, and Essbase objects (Substitution Variables, etc). All of the LCM migration definitions will be scripted and automated to run nightly. The artifacts are exported to a NAS device, which is also being replicated to QA through SRDFA. In the event DR is triggered, the LCM migration objects will use LCM from the QA environment to import the Production Security, EPMA, Financial Reporting, Calc Mgr, and Essbase objects into QA.
The final piece to account for was Essbase. Their Production Essbase applications also exist in their QA environment with the same names. Similar to Planning and HFM, it’s critical that the applications exist in the QA environment with the same names. This ensures proper registration of the applications with Shared Services, and in the case of Essbase with the Essbase.SEC file. The Production Essbase applications are backed up nightly through a list of exports scripted in MaxL. They also take a weekly file system backup which is also replicated to QA through SRDFA. In a DR scenario, the Production Essbase objects (outline files, report scripts, etc) will be restored into the QA Essbase application folder structure, over-writing the QA objects. Level 0 data will then be loaded and aggregated.
Following these steps, along with additional steps for backing up QA, finalizing the Security and EPMA migrations and some minor tuning, the QA environment should be fully functional as their Disaster Recovery EPMS site.
Every EPMS DR implementation is unique and customized to meet a client’s specific needs and appetite for cost. We made good use for the effort and cost this client had already made in technology to create a fairly straight forward and easy to manage Disaster Recovery process for their Oracle EPMS implementation.
Let us help you with your DR Strategy!