An ongoing discussion about SAP infrastructure

Why SAP HANA on IBM Power Systems

This entry has been superseded by a new one:


Before you get the wrong impression, SAP has not announced the availability of HANA on Power and in no way, should you interpret this posting as any sort of pre-announcement.  This is purely a discussion about why you should care whether SAP decides to support HANA on Power .


As you may be aware, during SAP’s announcement of the availability of HANA for Business Suite DB for ramp-up customers in early January, Vishal Sikka, Chief Technology Officer and member of the Executive Board at SAP, stated “We have been working heavily with [IBM].  All the way from lifecycle management and servers to services even Cognos, Business Intelligence on top of HANA – and also evaluating the work that we have been doing on POWER.  As to see how far we can be go with POWER – the work that we have been doing jointly at HPI.  This is a true example of open co-innovation, that we have been working on.”  Ken Tsai, VP of SAP HANA product marketing, later added in an interview with IT Jungle,  “Power is something that we’re looking at very closely now.”  And from Amit Sinha, head of database and technology product marketing. “[HANA] on Power is a research project currently sponsored at Hasso Plattner Institute. We await results from that to take next meaningful steps jointly with IBM,”  Clearly, something significant is going on.  So, why should you care?


Very simply, the reasons why customers chose Power Systems (and perhaps HP Integrity and Oracle/Fujitsu SPARC/Solaris) for SAP DBs in the past, i.e. scalability, reliability, security, are just as relevant now with HANA as in the past with conventional databases, perhaps even more so.  Why more so?  Because once the promise of real time analytics on an operational database is realized, not necessarily in Version 1.0 of the product, but in the future undoubtedly, then the value obtained by this capability would result in the exact same loss of value if the system was not available or did not respond with the speed necessary for real time analytics.


A little known fact is that HANA for Business Suite DB currently is limited to a single node.  This means that scale out options, common in the BW HANA space and others, is not an option for this implementation of the product.  Until that becomes available, customers that wish to host large databases may require a larger number of cores than x86 vendors currently offer.


A second known but often overlooked fact is that parallel transactional database systems for SAP are often complex, expensive and have so many limitations that only two types of customers consider this option; those which need continuous or near continuous availability and those that want to move away from a robust UNIX solution and realize that to attain the same level of uptime as a single node UNIX system with conventional HA, an Oracle RAC or DB2 PureScale cluster is required.  Why is it so complex?  Without getting into too much detail, we need to look at the way SAP applications work and interact with the database.  As most are aware, when a user logs on to SAP, they are connecting to a unique application server and until they log off, will remain connected to that server.  Each application server is, in turn, connected to one node of a parallel DB cluster.  Each request to read or write data is sent to that node and if the data is local, i.e. in the memory of that node, the processing occurs very rapidly.  If, on the other hand, the data is on another node, that data must be moved from the remote node to the local node.  Oracle RAC and DB2 PureScale use two different approaches with Oracle RAC using their Cache Fusion to move the data across an IP network and DB2 PureScale using Remote DMA to move the data across the network without using an IP stack, thereby improving speed and reducing overhead.  Though there may be benefits of one over the other, this posting is not intended to debate this point, but instead point out that even with the fastest, lowest overhead transfer on an Infiniband network, access to remote memory is still thousands of time slower than accessing local memory.


Some applications are “cluster aware”, i.e. application servers connect to multiple DB nodes at the same time and direct traffic based on data locality which can only be possible if the DB and App servers work cooperatively to communicate what data is located where.  SAP Business Suite is not currently cluster aware meaning that without a major change in the Netweaver Stack, replacing a conventional DB with a HANA DB will not result in cluster awareness and the HANA DB for Business Suite may need to remain as a single node implementation for some time.


Reliability and Security have been the subject of previous blog posts and will be reviewed in some detail in an upcoming post.  Clearly, where some level of outages may be tolerable for application servers due to an n+1 architecture, few customers consider outages of a DB server to be acceptable unless they have implemented a parallel cluster and even then, may be mitigated, but still not considered tolerable.  Also, as mentioned above, in order to achieve this, one must deal with the complexity, cost and limitations of a parallel DB.  Since HANA for Business Suite is a single node implementation, at least for the time being, an outage or security intrusion would result in a complete outage of that SAP instance, perhaps more depending on interaction and interfaces between SAP components.  Power Systems has a proven track record among Medium and Large Enterprise SAP customers of delivering the lowest level of both planned and unplanned outages and security vulnerabilities of any open system.


Virtualization and partition mobility may also be important factors to consider.  As all Power partitions are by their very definition “virtualized”, it should be possible to dynamically resize a HANA DB partition, host multiple HANA DB partitions on the same system and even move those partitions around using Live Partition Mobility.  By comparison, an x86 environment lacking VMware or similar virtualization technology could do none of the above.  Though, in theory, SAP might support x86 virtualization at some point for production HANA Business Suites DBs, they don’t currently and there are a host of reasons why they should not which are the same reasons why any production SAP databases should not be hosted on VMware as I discussed in my blog posting:   Lacking x86 virtualization, a customer might conceivably need a DB/HA pair of physical machines for each DB instance compared to potentially a single DB/HA pair for a Power based virtualized environment.


And now a point of pure speculation; with a conventional database, basis administrators and DBAs weigh off the cost/benefit of different levels in a storage hierarchy including main memory, flash and HDDs.  Usually, main memory is sized to contain upwards of 95% of commonly accessed data with flash being used for logs and some hot data files and HDDs for everything else.  For some customers, 30% to 80% of an SAP database is utilized so infrequently that keeping aged items in memory makes little sense and would add cost without any associated benefit.  Unlike conventional DBs, with HANA, there is no choice.  100% of an SAP database must reside in memory with flash used for logs and HDDs used for a copy of the data in memory.  Not only does this mean radically larger amounts of memory must be used but as a DB grows, more memory must be added over time.  Also, more memory means more DIMMS with an associated increase in DIMM failure rates, power consumption and heat dissipation.  Here Power Systems once again shines.  First, IBM offers Power Systems with much larger memory capabilities but also offers Memory on Demand on Power 770 and above systems.  With this, customers can pay for just the memory they need today and incrementally and non-disruptively add more as they need it.  That is not speculation, but the following is.  Power Systems using AIX offers Active Memory Expansion (AME), a unique feature which allows infrequently accessed memory pages to be placed into a compress pool which occupies much less space than uncompressed pages.  AIX then transparently moves pages between uncompressed and compressed pools based on page activity using a hardware accelerator in POWER7+.  In theory, a HANA DB could take advantage of this in an unprecedented way.  Where test with DB2 have shown a 30% to 40% expansion rate (i.e. 10GB of real memory looks like 13GB to 14GB to the application), since potentially far more of a HANA DB would have low use patterns that it may be possible to size the memory of a HANA DB at a small fraction of the actual data size and consequently at a much lower cost plus associated lower rates of DIMM failures, less power and cooling.


If you feel that these potential benefits make sense and that you would like to see a HoP option, it is important that you share this desire with SAP as they are the only ones that can make the decision to support Power.  Sharing your desire does not imply that you are ready to pull the trigger or that you won’t consider all available option, simply that you would like to get informed about SAP’s plans.  In this way, SAP can gauge customer interest and you can have the opportunity to find out which of the above suggested benefits might actually be part of a HoP implementation or even get SAP to consider supporting one or more of them that you consider to be important.  Customers interested in receiving more detailed information on the HANA on Power effort should approach their local SAP Account  Executive in writing, requesting disclosure information on this platform technology effort.


March 14, 2013 - Posted by | Uncategorized | , , , , , , , ,


  1. Alfred,

    Thank you for this thoughtful blog. I do have one question regarding the potential use of AME for a HANA system. Since HANA compresses the database during its load into memory, I was assuming that AME would not add any value. Your comments suggest otherwise. Would you mind elaborating on this?

    Joe Caruso

    Comment by Joe Caruso | March 26, 2013 | Reply

    • Joe, HANA, like DB2 and Oracle, looks for repeating patterns in tables and stores those patterns once with all references to each pattern stored as a pointer to the location of the pattern. HANA, DB2 and Oracle each do this a bit differently. For example, DB2 examines entire tables and across multiple fields/columns, so if 100 different entries refer to Address field: xxx Main Street City field: Austin State field: Texas, even though the street number might be different for each entry, Main Street Austin Texas would be common. I am not as familiar with the way that Oracle accomplishes this, but believe it looks at a database page at a time instead of the full table and looks at individual fields for repeating patterns and which tables it examines depends on configuration settings and whether standard compression, included with Oracle DB EE, or the Advanced Compression module is used. The upshot is both accomplish a similar goal, albeit in different ways and perhaps to different levels of effectiveness. HANA, likewise, looks at entire tables, but a single column at a time. So, compression is the word that everyone uses to describe this function, but perhaps pattern replacement might be a more appropriate term. This replacement occurs both on disk and in memory and becomes a permanent part of the DB. AME, on the other hand, has no awareness of the data layout, the size and scope of the data or any pattern replacement that has occurred. It acts more like image compression, albeit very sophisticated and based on algorithms developed by IBM Research. In other words, it looks for repeating patterns, whether spaces, digits or characters or groups of characters within each individual memory page and stores the page in an encoded format, in a compressed pages pool, that takes up less space, often much less. It does this on the fly and applications are not aware of this compression as AIX transparently decompresses a page when needed and places a requested page back into the regular, non-compressed memory pool. With POWER7+, a hardware engine was added that does this compression/decompression resulting in both less CPU required as well as much faster response time. Testing within IBM has found that, on benchmark workloads, DB2 for SAP, was able to achieve 30% to 40% “expansion”, e.g. 10GB looks to DB2 like 13 to 14GB. Oracle workloads have also been tested, though not for SAP, and achieved anywhere from 20% to over 100% expansion depending on type of workload. In theory, AME should work just as effectively for HANA as DB2 or Oracle with one possible exception. Where it should work well is for transactional business suite DB implementations. The exception might be for analytics as HANA tends to scan entire columns in memory. For BW HANA for example, where many more scans will be routinely used, I would doubt that AME would be as effective. I don’t have a enough knowledge, yet, to speculate on how well AME would work with a single store business suite DB including real time analytics. If the DB is composed of some row based tables and some columnar based tables, AME would probably still be quite effective on the row based tables and perhaps less so for the columnar tables. The challenge would be simply setting the level of AME expansion to affect the low frequency accessed row based data instead of the high frequency and/or columnar data. AMEPAT, the AME modeling tool, will shed a lot of light on this or any other workload running on AIX as to what expansion setting will result in the optimal expansion. Of course, this all assumes that HANA is running on AIX as AME is not available for Linux on Power today. Only SAP can determine and share which Power OS they might consider and/or support.

      Comment by Alfred Freudenberger | March 27, 2013 | Reply

  2. How Does SAP HANA works when it comes to performance between two remote sites with a distance of 90km or more?

    Comment by Jihad Mallah | May 13, 2013 | Reply

  3. […] There has been a lot of talk around HANA on IBM p-Series – Ken Tsai (VP of HANA Product Marketing) talked about it earlier this year, and so did Amit Sinha (SVP of Database & Technology Product Marketing) “[HANA] on Power is a research project currently sponsored at Hasso Plattner Institute. We await results from that to take next meaningful steps jointly with IBM”. There’s even a HANA on Power blog! […]

    Pingback by The 12 days of TechEd – my wish list for TechEd Bangalore | l_salva Blog | November 14, 2013 | Reply

  4. In my opinion where some level of outages in databse may be tolerable for application servers due to an n+1 architecture, few customers consider outages of a DB server to be acceptable unless they have implemented a parallel cluster and even then, may be mitigated, but still not considered tolerable. Also in order to achieve this, one must deal with the complexity, cost and limitations of a parallel DB.

    Comment by sap-hana-experts | June 23, 2014 | Reply

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: