Back Up and Restore an Essbase Instance

Essbase instance backups are used to restore all applications on your instance to a common point in time. Instance backups are used primarily for disaster recovery, but are appropriate when you want to migrate or restore all applications at once.

Consider your pre-restore Essbase instance as a source (from which the backup is taken) and the post-restore Essbase instance as a target. After finishing the restore tasks, your applications in the target instance will reflect the source instance as of some point in time.

Note:

The target instance does not need to be the same version of Essbase as the source. However, the target version must be patchable compared to the source.

You will be told several times in these topics to stop your Essbase services. See Stop, Start, and Check Servers. After disabling user connections and before you stop the services, allow adequate time for existing user request to finish.

Back Up an Essbase Instance

Instance backups are a mandatory pre-requisite to restoring an Essbase instance, and you must examine backup consistency for Essbase 21c.

In addition to the disk artifacts used by Essbase 11g, Essbase 21c introduces the use of a relational database schema for managing Essbase application metadata. Modify your existing backup routines to ensure that you capture all relevant information in a consistent state.

To ensure that Essbase backups are consistent, stop all services before you take your backup. Although you can take steps to minimize this downtime, Oracle does not recommend taking instance backups while users are active. Before stopping Essbase, you may want to gracefully bring users off the system. See Alter Application (especially enable/disable) and Alter System (especially logoff/ kill). If you use disable commands, you must reverse them with enable commands after you restart the system.

Consistent backups include:

Contents of the <Application Directory>
Relational database source schema: <schemaprefix>_Essbase
EPM Shared Services “assigned roles” (if using EPM Shared Services with Essbase)

To minimize user downtime, consider mounting separate disk volumes for your <Domain Root>/<Domain Name> and your <Application Directory>. This will allow you to take snapshots or clones more quickly than compressing folders from the disk. Also, consider removing redundant or outdated text files used for loading data and building dimensions, as these can be quite large and will lengthen compression times.

Restore an Essbase Instance

Production Essbase instances use either WebLogic security plus an identity provider or EPM security (with or without an Identity Provider). In either case, users and groups are managed external to Essbase.

Note:

Embedded WebLogic LDAP is supported only for test environments and has significant backup and restore restrictions.

Generally speaking, your identity provider will not run on the same physical hardware as your Essbase instance, so you are protected from recovering the identity provider when you recover Essbase. You will only need to configure a new Essbase target instance and configure it to use your existing identity provider.