The Oracle BI Application Blogs provides the latest and tips and tricks on Oracle BI Applications Product (OBIA)

BIAPPS on PAAS – Backup and Restore - Introduction (Part1)

BI Applications (BIApps) is an integrated application involving multiple components. A backup of BIApps therefore would mean a backup of the integrated application and not just the datawarehouse or the database. High level architecture of BIAPPS on PAAS is shown below:

There are four different cloud service instances involved at a minimum when using BIAPPS on PAAS. Following table shows the components/software that are installed on each:

DBCS (Database Cloud Service)

Database that has the ODI repository, BIACM
Repository, SDS schemas and the Datawarehouse Schema

BICS (BI Cloud Service)

RPD, Webcat, Jazn file

Compute Cloud

Weblogic Server
ODI Server
BIAPPS Shiphome
Customer Data stored as files (E.g. Source Files, Universal Adaptor files)

*Optionally the below if installed
Corente VPN ?
Dev tools like sql developer/browser/ODI studio and their associated files

Storage Service

backups for Compute/DB

You will need to backup all of the above instances to be able to successfully restore the BI Applications. Each of the Cloud services provides its own backup mechanism. Relevant information for backing up each of these cloud services is available in the Oracle Cloud documentation and will be detailed in subsequent blogs in this backup series. Customer may also want to look at Oracle Database Backup Cloud Service that is a separate optional cloud service that is available to take Oracle Database backups.

However is it adequate if you just backed up each of the cloud instance independently? Following section details some of the considerations related to this question by drawing on few examples.

Example 1: Database has been backed up on weekend Saturday 11th March 11pm. Compute Cloud Instance was backed up earlier at 10am the same day. Configuration that is done on weblogic (JDBC data sources, memory settings etc) is not stored in the database. So if any of the configuration was done between 10am 11thMarch and 11pm 11th March, that would be lost. And in that sense, the backup and restore does not truly reflect the state of the integrated BIAPPS environment as it would have been at 11pm 11th March.

Example2: BICS was backed up on 10 pm on Sunday 12th March. Now continuing from example1, we have the database backup from 11pm 11th  Match and BICS backup from 10 pm on Sunday 12th March. If there were any changes that were done to the database (like adding a new table/column) that was followed by a change in the RPD, then there is a chance that when we restore the database and the BICS instance, we can have a failure since they are no longer in sync.

As you can see from the above examples, backing up the cloud instances at different points in time can cause a potential problem. That said, there is a no single button that can be clicked to backup all the instances at exact same time. However with a right process in place, it is still easy enough to backup and restore the BIAPPS Application. Following are some of the best practices/guidelines that the customer can take to avoid the above issues:

  1. The most volatile of the BIAPPS components is the database. That said, the database is primarily changed when the ETL is run. So it is probably a good idea to backup the database outside the ETL window and as frequent as is possible. Configuration changes done in BIACM will also reside in the database, but these are less likely to occur once the initial configuration is done. Similarly ODI repository changes also reside in the database but in a production instance this should not be done everyday but rather during limited controlled windows.
  2. BICS RPD is tightly coupled with the database. So the customer could restrict the RPD changes to certain limited days in a month and ensure that there is proper database backup along with accompanying BICS backup outside the change period. In other words, have a quiet period for making RPD changes and ensure that the BICS and DB are backed up in that quiet period. 
  3. Most of the configuration required for Weblogic is done during the initial configuration. So after the full load, ensure there is a blackout period when you back up all the cloud instances. Subsequently similar to the BICS quiet periods, ensure that the changes to the weblogic and other domains on the Compute are done only during certain days and ensure that they are being backed up during the quiet periods. 
  4. Most of the cloud services have either an API or command line utility to backup that instance. You could consider using those to automate the backup of
    all those instances. Better still, you can have that script kicked off automatically at the end of the ETL load plan. 
  5. When restoring the system from a backup, consider the impact of any extract from Source Systems. Most of the Sources Systems have incremental
    extracts. If the last extracted date is stored in the database, then that date will also be restored as part of the database restore. However if the extract date is stored outside the BIAPPS Database (E.g. Fusion or any on Prem Sources which you are replicating via a Replication tool), then you will need to ensure that post the database restore, you reset the extract dates to match the data in the database and also clear any pending data in transit (Like in UCM). 
  6. A full reset of the SDS and the warehouse, followed by a full load will fix any issues with the SDS/warehouse. However Full loads are expensive and
    certain Source Systems have restrictions on how much data can be extracted in a day (E.g. Taleo). Further you can potentially lose any existing snapshot data if doing reset of the warehouse (and if the snapshot data is not available in the source). 
  7. When you restore a database, you will be restoring all the tables and all the schemas. It is not easy to restore a single table. Therefore it is best to keep activities that impact different schemas separate. E.g. If doing major configuration in BIACM, then do that when no ETL is running and take a adhoc backup before and after those changes. Similarly when promoting code to the ODI Production repository, do it outside the ETL window and at a time when no BIACM changes are happening and take a backup, before and after those changes. This will ensure that you can use the db backup to restore the database to the point in time before those changes are done without worrying about impact to other schemas. For the same reasons, if you are making a change to a single warehouse table, keep a backup of that table (and other dependent tables) in the warehouse schema along with the data, so that you can use those to restore the table rather than use the complete database backup.

There are other components that are also involved in the BIAPPS on PAAS Solution and need to be included in the backup strategy. These include but not limited to:

  1. Source Systems: These are the systems from which BIAPPS gets the data from. The backup of those systems is also required when considering the entire application. However those are typically taken care by the Source System administrators and hence not listed here.  
  2. Replication Tools: If you are not using VPN to connect to the On Prem Source Systems, then it is likely, you have some kind of Replication mechanism
    to transfer the data from the On Premise Source System to the SDS. So your backup strategy ought to cover those as well.
  3. Identity Domain/ Users & Roles:  These are usually maintained from the Service Admin Console (SAC). Refer to SAC documentation on how to back
    these up.
  4. Any Network/Security Rules you setup between these various instances.

The customer ought to therefore understand the entire BIAPPS archictecture and then design the backup strategy accordingly. The customer will also likely have a Dev/Test/Prod environment, each of which is a complete BIAPPS application in itself. The customer will have to ensure that the backup strategy covers all those environments. Special care should also be taken if customer has a T2P process (Test to Production) and one of the environments requires to be restored.

The subsequent blogs in this series, will attempt to drill into the relevant backup functionality that is present for the individual components that make up the BIAPPS on PAAS solution. Below are few links that point to the backup documentation for the relevant cloud services:

Backing up Deployments on Database Cloud Service

About Database Backup Cloud Service (Optional cloud service that can be used to backup Oracle databases)

Backing up and Restoring Storage Volumes - Compute

Backing up and Restoring BICS

Refer to the latest BIAPPS and Oracle Cloud Documentation as things might have changed since this blog was written.

All blogs related to BIAPPS on PAAS

BIAPPS on PAAS Backup Blog Series



Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.