• With a cloud service, customers expect an “always on” capability – “maintenance mode” and other activities should be minimised.
• Moreover, with the advent of metered services, it’s important that available uptime (burning credits) is maximised – you don’t want the server burning credits if it’s not available for use.
• On premises Essbase can easily be backed up with no downtime with some custom backup scripts – let’s get the cloud to do the same.
• OAC essbase backups are somewhat CPU intensive
• The 2x most common use cases are:
  • Restore an individual application
  • Restore the server and rebuild an application
• This post shows you how to turbocharge your backups!

The Solution

Just like any turbo tuning company (I’m a bit of a petrolhead, Turbo V8s FTW), there’s a number of stages

• Stage 1 achieves the 1.65x performance improvement without requiring any complex changes to the backup architecture, including any changes to the recovery functions.
• Stage 2 increases the backup speed further (estimated 2x) – however also requires a (simple) modification to the restore functions.
• Stage 3 is a selective backup extension to take performance to the “Nth degree”

Stage 1

This stage changes the gzip approach to simply reduce the CPU requirements of zipping, since the backup process is heavily CPU bound, but has an abundance of IO capacity.

It modifies the gzip command to use the “–fast” parameter, documented here.

Modified Files

/u01/app/oracle/tools/acss/BI/esscs_tools/backup/essbase.py

Original Line (156)

cmd = 'tar -C ' + essbase.quotefilename(self.arborpath + '/app') + ' --exclude=\'*/temp/ess*.dat\'' + ' -zcf ' + essbase.quotefilename(app_tgz) + ' ' + essbase.quotefilename(appname)

New Line

cmd = 'tar -C ' + essbase.quotefilename(self.arborpath + '/app') + ' --exclude=\'*/temp/ess*.dat\'' + ' -cf - |gzip --fast>' + essbase.quotefilename(appname)

/u01/app/oracle/tools/acss/BI/esscs_tools/backup/cloud_container.py

Original Line (75)

processTools.run_command('tar czf - '+backupDir+' -P | split -b 2000MB - '+fileName)

New Line

processTools.run_command('tar cf - '+backupDir+' -P |gzip --fast|split -b 2000MB - '+fileName)

Also note that as gzip is still used in the backup, no changes are required to the restore scripts.

Results

Based on total essbase database storage needs of 65G, this achieves a 1.65 times performance improvement with only a very minor increase in backup storage needs.

• Backup Time (Original) : 74 minutes
• Backup Time (Stage 1 Tuning) : 47 minutes  (=74/1.65)

Stage 2

Stage 1 improves backup performance, but the backup files are still being compressed twice. Further performance can be achieved by removing the 2nd gzip.

This approach does also require a minor change to the restore function however – so after patching or platform rebuild, this tweak would need to be applied before running a restore.

Modified Files

/u01/app/oracle/tools/acss/BI/esscs_tools/backup/Essbase.py  (modified as per Stage 1, plus the following)

Original (923)

cmd = 'tar -C ' + self.quotefilename(self.arborpath + '/app') + ' -zxf ' + self.quotefilename(ffull)

New

cmd = 'tar -C ' + self.quotefilename(self.arborpath + '/app') + ' -xf ' + self.quotefilename(ffull)

(We remove the “z” from the extract command)

/u01/app/oracle/tools/acss/BI/esscs_tools/backup/cloud_container.py (75)

Original

processTools.run_command('tar czf - '+backupDir+' -P | split -b 2000MB - '+fileName) 

New

processTools.run_command('tar cf - '+backupDir+' -P | split -b 2000MB - '+fileName)  

Results

Expected performance improvement – <40 minutes total time (down from 74)

Stage 3

• Stage 3 provides “optional” backup capabilities.
• A common scenario is that cubes are rebuilt daily or weekly from new source data.
• Therefore, in the event of a loss of server, the restore scenario would typically be to restore the server and then rebuild cubes to the latest version.
• This is usually done using a “shadow build” approach, meaning the the current reporting version of a cube doesn’t need to be backed up.
• In this scenario, all the “technical” artifacts still need backing up, however named applications can be excluded from the backup to improve backup & restore performance using the tar “exclude-from” parameter:

tar -C /u01/latency/app -cvzf TBC_ASO1.tgz TBC_ASO --exclude-from ~/excludes.txt

• in this scenario, any application names included in the file /u01/app/oracle/tools/home/oracle/excludes.txt will be automatically excluded.
• Limitations : ~/excludes.txt must exist otherwise tar errors out.
• This can be handled by ensuring it exists with a “null” entry that will never match an appname, or by wrapping the parameter in python to ensure it’s only included if the file exists.

Modified Files

This builds on the Stage 1 modifications:

/u01/app/oracle/tools/acss/BI/esscs_tools/backup/essbase.py

Original Line (156)

cmd = 'tar -C ' + essbase.quotefilename(self.arborpath + '/app') + ' --exclude=\'*/temp/ess*.dat\'' + ' -zcf ' + essbase.quotefilename(app_tgz) + ' ' + essbase.quotefilename(appname)

New Line

 

cmd = 'tar -C ' + essbase.quotefilename(self.arborpath + '/app') + ' --exclude-from \'~/excludes.txt\' --exclude=\'*/temp/ess*.dat\'' + ' -cf - |gzip --fast>' + essbase.quotefilename(appname)

Results

Expected performance improvement – can be massive if “active” reporting cubes don’t need to be backed up!