Data Backup and Recovery

Issue faced during restoring Oracle Fusion Middleware - Hyperion at DR site


We are using Netapp SnapManager for replicating the Oracle Fusion Middleware (OFM)
environments along with other components.

We are facing a typical issue with Hyperion-Essbase while Restoring/Recovering Hyperion at DR,we are facing Essbase corruption issue.

it seems snapshot is not quiesceing the Hyperion Essbase files to a consistent state and hence
resulting in file corruption at DR.

I have checked in white papers for Oracle Fusion Middleware conveying special treatment for
Essbase backup to maintain consistency but haven't
found any note from Netapps on DR synchronization for the same.

Could you kindly suggest if there are any work arounds for the same.



How many volumes host this database? Just one or multiple volumes?



Its a single volume.


I can’t think of any explanation for this. Any software configuration that can survive a power failure without corruption should also work with a snapshot. This applies to any vendor technology. Restoring a snapshot is essentially the same as starting up a database after a power failure. Even if you had something like EMC SRDF replication, your recovery procedure would be the same because if you lost the primary site you’d be left with a copy of the data on the remote site. That copy would be frozen at a moment in time with no special preparation of the filesystem or database.

Can you supply the exact procedures used to create the backup and then perform the restoration? I can’t believe that Essbase becomes corrupt simply because of a power failure.


I think that is exactly the reason why Oracle in fusion middleware doumentation have provided the following note:-


Oracle® Fusion Middleware

Administrator's Guide 11g Release 1 (11.1.1)


17.4.2 Considerations for Backing Up Oracle Essbase

You cannot back up Oracle Essbase online. You can back it up in the following modes:

Offline backup

Backup in quiesce mode, in which no new requests are serviced, by using MaxL


This implies online backup at any point in time might not work.

Which is similar to what happens during Snapmanager synch,where no quiescing is introduced.

It just takes a snapshot at regular intervals,compares the changes based on the baseline snapshot and transfers over the change to DR site.

Now,if online backup of Essbase would not be supported unless quiesced,Similarl some quiescing has to be integrated in Snapmanager to get this work