Brook Preloader

Blog

Creating Custom Essbase Application Level Backup in Oracle Analytics Cloud (OAC Classic)

Introduction

Having application backups from production is critical for every organization. Manually taking backup requires effort depending on the number of applications. It is time consuming and is much prone to manual errors. Having a script eliminates the manual intervention and provides the flexibility for scheduling to run the backups at a desired time.

Need for Backup Script:

Essbase applications are backed up at least once a day. The backup includes all the artifacts viz. scripts, rules, report scripts, outline and data. In on-premise environment, this activity is automated by using a MaxL script. For OAC hosted on Unix, a shell script can be developed, which can be scheduled through a cron job.

Need for Custom Script:

The default script from Oracle takes the backup of all Essbase applications sequentially and places all of them in a single zip file. The size of the zip file becomes very big, since it contains all the application’s backup including data and the size keeps increasing as data increases or if any new application is created.

Restoring any application from backup in case of emergency becomes very difficult due to the size of a single backup file and unzipping it multiple times can be time consuming. There is no flexibility of scheduling the individual backups at different times. As the number of applications increase, the overall time for backup will also increase, as they run one after the other. The increase in the overall run time will conflict with any scheduled jobs resulting in job failures.

Required Utility:

Download the tools Command Line Interface (CLI) tools from the web console.

Script Development:

Create a “cli” folder on the Essbase Unix server in the path where the script will be placed. The script and backups are stored on the u01/data folder. The cli folder will have esscs.sh script, which is the utility to be used in the backup script for taking backup.

Remember to update JAVA_HOME path in esscs.sh. The path can be found under root/usr/java folder. This is required as the utility uses it and needs the exact path.

Create a shell script using Putty. Below is an example

Sample script:
export ESSCLI_ID=whoami_$PPID /u01/data/cli/esscs.sh login -user username -url http://xxx/essbase /u01/data/cli/esscs.sh lcmExport -v -a appname -z “date +%Y_%m_%d_%H:%M:%S_appname.zip -ld /u01/data/backup/essbak -o -gal -isl

Get URL information by logging in to Putty and typing hostname.

Create a separate script for each application and mention the folder where the backups have to be stored. In this sample, it is the essbak folder. The user is usually the admin, as he/she will have admin
rights on all the Essbase applications. Set the password to avoid specifying it in each script explicitly.

  • Log in to Putty
  • sudo su oracle
  • Go to cli folder path cd / u01/data/cli
  • Type ./esscs.sh setpassword – user admin URL

Scheduling Using Cron Job:

Use the crontab -e command to open user account’s crontab file. Commands in this file will run with user account’s permissions.

Pros:

  • Built in OS and no third party client needs.
  • Runs the commands and is automatically scheduled (Scripting is not needed).
  • Easy to implement, no other group is needed.

Cons:

  • Not centrally managed, it has to go to each and every server to be maintained.
  • Not too flexible, it is just a simple scheduling tool which kicks off the job as scheduled.
  • Commands are as per jobs.
  • Maintenance/change is tedious.
  • No visibility to make sure that the scheduled jobs going through other scheduling tools do not conflict.

Example of Cron syntax:
1 2 3 4 5 /path/backupscriptname.sh
where,
1: Minutes (0-59)
2: Hours (0-23)
3: Days (0-31)
4: Months (0-12 [12 = December])
5: Day of the week (0-7 [7 or 0 = Sunday])

Benefits of the Script:

  • Using the custom script, a separate backup job can be created for each application and scheduled separately.
  • Flexibility of scheduling them to run in parallel, as there is no dependency on each other.
  • Flexibility to schedule the backup jobs at different times based on other scheduled jobs, in case we don’t require all of them to run at the same time.
  • Separate backup files for each application makes it easier to use them when needed (Example: When we need to migrate an application in lower environment with production backup).

Contact for further details

Sudarshan Dundrapu
Sr. Technology Specialist – Analytics BW HANA
sudarshandu.in@mouritech.com
MOURI Tech

0 0 vote
Rating
guest
0 Comments
Inline Feedbacks
View all comments