Skip to Content

On the perils of using SAP HANA

Being an advocate of SAP HANA makes me somewhat idiosyncratic. I tend to see the advantages of implementing SAP HANA for BW systems, but I am not involved in the “other side” of the BW administrators. Recently I discussed the implementation of SAP HANA for my favorite BW landscape. Speaking with the responsible BW administrators was somewhat of an eye-opener for me. Even if such issues like hardware selection/sizing and overall project funding are clarified, then there remain four obstacles or let’s better say challenges:

1. Encryption

I was asked whether the current version of SAP HANA supports data encryption. I had to say no, and this clearly violated the corporate policy. So no HANA implementation is possible right away. Life can be hard. There is this ideal landscape – THE landscape why SAP developed HANA in the first place, and it cannot be implemented due to the security policy! I was flabbergasted. I just hoped that SAP would provide encryption in a future release to alleviate this problem. Luckily the “what’s new” of HANA 1.0 SPS05 was right on the spot. This obstacle was fixed really fast, thanks SAP!

2. Resources

BW data loading can be really complicated. There are some old and obsolete BW instances which cannot easily be dumped due to some complex data loading configurations. Unfortunately, such old instances bind resources, and this can hinder the implementation of new technologies like SAP HANA. It doesn’t really matter if you have some old reference systems which cannot be shut down due to legal reasons, but using obsolete BW releases (on obsolete HW/OS/DB) for reporting is getting more and more critical. Of course this is well known among the BW administrators, but not being able to support such an obsolescence process in any way goes against my grain as being a support engineer.

3. Capacity Planning

BW systems can be very demanding and tend to be very important for a company, therefore better use good hardware. The hardware should neither be under nor over utilized. Either way you’ll get complaints. So you need a good capacity planning process. BW systems are “work in progress” with different projects running concurrently and new subprojects going live all the time. If you have finally found a working solution so that the CPU-, memory- and IO-demands can be met in an economic way, you can be pretty sure a game changer like SAP HANA will void that process. I would not call that a real obstacle because the SAP HANA scale-out solution together with the “pay-per-use” software license should reduce the pressure from capacity planning and move it to performance + resource consumption reporting. However, if I say capacity planning is no problem, that could be only marketing speak as long as there is no verification in real life.

4. Data Issues

OK, so now for the straight talk. There was one issue which I really didn’t anticipate and could cause some subsequent problems: I was told that implementing HANA would enable the end users to see all the data, because certain queries wouldn’t time-out any more. So end users could complain that in certain areas only mockup data is loaded, not the real data. This of course means some more follow-up work on the data loading side to provide the real data. You better plan such tasks as part of the migration project if you don’t want to enter reactive mode. HANA will raise the data quality because it will really make it possible to check all the data. Have you ever wondered what to do with the people who are currently struggling with performance troubleshooting? This is the answer what they will be doing after the migration to HANA.


My expressed thoughts are of course my very own opinion. Nevertheless I expect HANA to reveal some more strange intricacies which are not related to software bugs or architecture issues. HANA reminds me of Douglas Adams’ Infinite Improbability Drive reaching reality:

“probability factor of one to one…we have normality, I repeat we have normality.” She turned her microphone off — then turned it back on, with a slight smile and continued: “Anything you still can’t cope with is therefore your own problem.”

You must be Logged on to comment or reply to a post.
  • Hi Mark,

       Thanks for your observations! Under the category of “Read carefully before you buy” you’ll want to check out the help topic for the “ALTER SYSTEM PERSISTENCE ENCRYPTION <encrypt_option>” command at Being a bit of a security wonk, I noticed several gotchas.

    Data is only encrypted for the database file on disk – here is the quote

    Currently only the finally written disk data will be encrypted. The redo log is not affected by this command. For more information about the redo log please see the “Backing Up and Recovering the SAP HANA database” section in the “SAP HANA Administration guide” available from the SAP HANA Appliance page.

    This means, your log file is subject to inspection before it’s flushed to the data file. To minimize an attack, you’ll need to flush the log often by shortening the savepoint window in global.ini. It also means that your log backups are not encrypted, so you’ll need to take full backups more often. Data loaded into memory is not encrypted so this means that attaching a debugger or memory inspector can see the data.

    If you then go to section 11.2 Enabling Persistence Encryption in an Existing SAP HANA system –, you’ll find out that you’ll need to reinstall your HANA system.

    Make sure you protect your key as if it was the “crown jewels”. Lose it and you lose everything. If you’re running HANA in a data warehouse scenario, you can just reload. With an OLTP system – ouch.

    Finally, maybe someone from SAP can verify – is your backup file protected with the encryption – I couldn’t find any reference in the documentation.



    • Hello Bill,

      thanks a lot for sharing this information. It is still very difficult to collect detailed technical information on HANA. However, in my case it is sufficient if SAP says they support encryption of the data files, this will gain the tick mark from the security auditors. (With dictionary encoding the data is already much more obfuscated than with ordinary RDBMS data blocks.) We could use LTO tape encryption for the log files, just to make sure. For the encryption key I hope we can use the corporate certificate, just like with Oracle transparent data encryption. We won’t lose the corporate certificate, but thanks for highlighting that important point!