What is just as important as architecting the perfect Oracle Business Intelligence integration solution?
Answer: Architecting the perfect backup and recovery strategy process in order not to lose it!
Often so much focus is placed on the “Let’s get there” aspect of a Business Intelligence implementation. But all too often during the crucial requirements gathering sessions, scope building, and project plan generation there is little talk about backing up the infrastructure that the project seeks to put in place. Forget about backing up source data for a moment. That mainly will/should be handled the DBA side of the Information Technology department. Let’s talk Oracle BI metadata and environment configuration for a moment.
As we can see from Oracle BI 11g, there are simply many more moving parts to Oracle’s latest BI tool release than what was contained by its predecessors. The Fusion Middleware layer is quite robust and even experienced Oracle BI aficionados can attest to its complicated directory structures, and their lapse in memory regarding the location of key configuration and log files. So, when it comes to backing up the Oracle BI environment there needs to be a fully vetted plan in place to ensure that your Oracle BI environment’s data, metadata, and configurations are recoverable in case an unpredictable incident occurs. In Oracle BI 11g we now must be “point-in-time” aware as the MDS and BIPLATFORM database repositories are involved.
Without going into great detail by providing a full Oracle BI backup and recovery plan in this article, let’s just highlight some basic Oracle BI backup and restoration strategy topics.
Full Server Backup
This is often seen as the “killing an ant with a sledgehammer” approach but is effective in that all components of the Oracle BI Server (and everything else on the machine) are saved for storage. Clearly, there are a multitude of cons in this approach such as the ever increasing need for storage space, the cost of storage, and the larger length of time required to complete a full server backup (which may results in large download terms). Virtual Machines (VM) make this easier but VMs have their own complications, which we don’t discuss here.
Oracle’s recommended approach is to take more of a surgical backup approach, taking only the core elements of the environment into consideration for the backup plan. This is no longer the handful of core files that is used to be in previous version of Oracle BI. In fact we now must consider several different areas for the back up:
Ultimately this precision backup strategy recommends the backup of the Middleware home, the domain home, and the Oracle instance containing the Oracle BI EE components. In addition, if running a Windows Operating System one must export Oracle BI EE Registry entries. Typically an additional batch script is created to yank out this information on some frequency to prep it for backup and likewise an additional batch script for automating the environment variables recovery.
Precision backups have much fewer cons than the full server backup strategy. Though more effort is involved upfront the maintenance of this type of backup plan is substantially less of a headache.
Hyperion aficionados, particularly those involved in Essbase infrastructure, know that a backup plan is critical to recovering elements of a Hyperion Essbase system. Depending on data loads and data vulnerability some Hyperion Essbase implementations can expect backups as frequently as daily and others comfortably monthly. As it relates to Oracle BI the same considerations of data and metadata vulnerability must take place. Different components such as configuration files or the web catalog for OBIEE can be surgically backed up on a more frequent basis than the components that might not change as frequently such as the configuration files (instanceconfig.xml, etc.)
Multiple Software Lines
Each platform delivered with the Oracle BI 11g Suite has its own backup consideration. Though OBIEE, OBIP, and ORTD comprise the Oracle Business Intelligence Enterprise Edition software they have some common metadata elements and some which are sole references. Common elements would include the MDS and BIPLATFORM relational database repositories. Sole software reference elements would be such items as the OBIEE RPD or the RTD schema. Determining if some or all of these items fall under the critical backup and restoration plan is a line item to check off during initial BR planning as ultimately your restoration plan is based on what exactly you’ve chosen to backup.
As the process of creating a backup of an infrastructure usually seeks to create a “point-in-time” instance from which to recover, adding a maintenance mode to the BR plan/strategy is a great idea. Alerting users of the Oracle BI System that a maintenance mode is planned and before backup occurs is not only a good idea it is common courtesy. More to the point, Oracle recommends locking the Oracle BI Presentation (Web) Catalog before conducting a backup so that the RPD and Presentation (Web) Catalog stay in sync. That can be conducted with the following syntax:
./runcat.sh -cmd maintenanceMode -on -online BIP_URL
-login username -pwd password
Including this into any automation process would be a smart way to approach Maintenance Mode considerations.
Ultimately a formal backup and recovery plan should be created for an implementing organization. This should be done from an Oracle BI (Fusion Middleware) system perspective and not just at the developer (Just save the RPD and Web Catalog) perspective. By creating an Oracle BI backup and recovery strategy or enlisting a Systems Integrator to assist with creating one, the Oracle BI system will rank with a higher level of confidence, match corporate BR standards, and provide a structured path to getting an infrastructure back online in the worst-case scenario of loss.