Why HANA Has Problems with Transaction Processing

Executive Summary

  • HANA has performance problems when supporting transaction processing applications like S/4HANA.
  • We cover one possible reason for this.

Introduction

SAP proposed that HANA is optimal for processing either OLAP or OLTP. And SAP had a specific design which SAP claimed allowed for this to happen.

This is explained by the following quotation from Rolf Paulsen.

HANA’s Design with Respect to Column Oriented Tables

The common quotation.

HANA combines OLTP and OLAP capabilities, with row store and columnar store in the same box” –

..is misleading at least because it suggests row store belongs to OLTP and columnar store to OLAP in HANA. Unlike products of other vendors, HANA does not provide “hybrid” tables that combine row store and columnar store in parallel. A HANA table is either columnar or row stored but row store tables are the exception for very volatile and fast-changing data. E.g. the size of all row store tables together has a hard limit of 1,945 GB per instance. The sophisticated issue are the transactional operations on the many columnar tables. The price for having data in the columnar form convenient for fast analysis has to be paid on data manipulation. No “row” of a columnar table gets updated, there are only inserts and complex “delta merges” on a short-lived row representation of the columnar data.

How HANA’s Design Has Changed Over Time (and How the Explanation of HANA Has Changed Even More)

It is important to remember that when HANA was first introduced, it was introduced as a 100% column-oriented table database. Obviously, with this design, HANA ran into major problems in transaction processing. This was one of the many indications that SAP did not understand what it was doing when it first designed HANA, and our view is that HANA was overly “boxed in” but the original design objectives of Hasso Plattner. This is explained in the following quotation from John Appleby.

With ERP on HANA, we, of course, don’t need separate row and column stores for transactional and operational reporting data. Plus as Hasso Plattner says, we can use the DR instance for read-only queries for operational reporting.

That is what SAP thought at this time, but then in SPS08, suddenly SAP added rows oriented tables to HANA. Yes running an entirely column-oriented database for a transaction processing system never made any sense. Appleby himself describes this change in our critique of his article in How Accurate Was John Appleby on HANA SPS08? This article is written in November 2014, and in June of 2014, or seven months later SAP already had to change its design.

Therefore, what Appleby states here is reversed. HANA’s performance for ERP systems must have been absolutely atrocious before they added row oriented stores.

More analysis of this quote can be found in the article John Appleby, Beaten by Chris Eaton in Debate and Required Saving by Hasso Plattner.

Later versions of HANA decreased the percentage of column-oriented tables to roughly 1/3 of the total tables in the database for S/4HANA. 

The Oracle Database Design

Oracle’s design is different which is covered in part by this quote from Oracle.

“The IM column store encodes data in a columnar format: each column is a separate structure. The columns are stored contiguously, which optimizes them for analytic queries. The database buffer cache can modify objects that are also populated in the IM column store. However, the buffer cache stores data in the traditional row format. Data blocks store the rows contiguously, optimizing them for transactions.”

The Issue in the Interaction Between Transaction Processing and Columnar Tables

This quote on Rolf’s part is compelling.

“The sophisticated issue is the transactional operations on the many columnar tables.

The price for having data in the columnar form convenient for fast analysis has to be paid on data manipulation.

No “row” of a columnar table gets updated, there are only inserts and complex “delta merges” on a short-lived row representation of the columnar data.”

The CPU Consumption Issues of HANA

If we can restate this the following can be said about Rolf Paulsen’s quotation.

  • Rolf proposes that the columnar tables are updated by a transaction (let us say HANA is supporting a transaction processing system rather than BW).
  • Therefore this update is problematic from transactions being processed to the database.

Results from the Field

Results from the field indicate HANA still has problems with both transaction and running CPU intensive processes like MRP/DRP as we covered in the article HANA as a Mismatch for S/4HANA and ERP.

The CPU issue is clearly because of the overload of data into memory, causes major CPU consumption, often requiring a HANA reboot as we covered in the article How to Understand HANA’s High CPU Consumption. However, the continued transaction processing performance issues could be in part related to the exact problem you bring up here in Rolf’s quote above.

Removing Duplicate Data by Porting an Analytics Database Design to the Non-Analytics Application?

John Appleby and others repeatedly proposed that HANA would eliminate duplicate data (that is the data that is redundant between the ERP system and the data warehouse). Analysis of this claim performed in this article How Accurate Was John Appleby on HANA Replacing BW? 

But the “solution” meant turning the ERP system database into something like the database for a data warehouse (if one does not want to use star schemas). The row-oriented databases supported data warehouses quite well but used an intermediary structure called the star schema. As a point of comparison, Brightwork Research & Analysis uses an application that creates star schemas in the background without the user seeing anything, and easily beats the performance of SAP BW. SAP BW requires the configuration of star schemas when BW sits on top of a row-oriented DB. That is creating star schemas does not need to be as onerous as it is in SAP’s BW. It can be made to create the schemas in the background from just loading a flat-file which contains the relationships (as one example). 

How SAP Has Been Hiding HANA’s Transaction Processing Performance

John Appleby stated that SAP no longer would use the SD benchmark as we covered in the article The Hidden Issue with the SD HANA Benchmark, because it no longer fit with how companies used SD (that is the sales and distribution module of ECC, a transaction processing system). And in fact, even in 2019, there is still no SD benchmark for HANA published by SAP. Instead, SAP created an analytics benchmark called the BW-EML which we covered in The Four Hidden Issues with SAP’s BW-EML Benchmark.

All of this is strongly indicative that the SAP has run the SD benchmark internally, but choose not to publish the benchmark because the performance would match what has been reported to us from the field, that HANA simply performs poorly for transaction processing. However, this never stopped SAP from claiming HANA had far better performance than any other database, including Bill McDermott’s claim that HANA performed 100,000x faster than any other database. SAP needs its customers to replace their current database with HANA to meet their revenue objectives and to further increase account control. Once HANA is installed, SAP will apply indirect access rules to HANA, which will include requiring second HANA instances and licenses to copy any data out of HANA as we covered in the article The HANA Police and Indirect Access Charges.

Conclusion

As far as adding columnar capabilities to a row-oriented database, all of the major database vendors were able to do the same thing. Sybase IQ was around for at least 15 years before HANA and had a similar design to HANA, but it was just never very popular.

Oracle, IBM, SQL Server all added column stores to their databases after SAP did (and all of these vendors had superior knowledge of memory optimization versus SAP).

But it is not a question of if one can, its a question of “why would you?” SAP essentially proposed that an analytics database is a fantastic database for a transaction processing system — and that furthermore, they were the only one to figure this out.

SAP’s Inaccurate Messaging on HANA as Communicated in SAP Videos

Fact-Checking SAP’s HANA Information

This video is filled with extensive falsehoods. We will address them in the sequence they are stated in this video.

SAP Video Accuracy Measurement

SAP's Statement
Accuracy
Brightwork Fact Check
Link to Analysis Article
HANA is a Platform
0%
HANA is not a platform, it is a database.How to Deflect You Were Wrong About HANA
HANA runs more "in-memory" than other databases.
10%
HANA uses a lot of memory, but the entire database is not loaded into memory.How to Understand the In-Memory Myth
S/4HANA Simplifies the Data Model
0%
HANA does not simplify the data model from ECC. There are significant questions as to the benefit of the S/4HANA data model over ECC.Does HANA Have a Simplified Data Model?
Databases that are not HANA are legacy.
0%
There is zero basis for SAP to call all databases that are not HANA legacy.SAP Calling All Non-HANA DBs Legacy.
Aggregates should be removed and replaced with real time recalculation.
0%
Aggregates are very valuable, and all RDBMS have them (including HANA) and they should not be removed or minimized in importance.Is Hasso Plattner Correct on Database Aggregates?
Reducing the number of tables reduces database complexity.
0%
Reducing the number of tables does not necessarily decrease the complexity of a database. The fewer tables in HANA are more complicated than the larger number of tables pre-HANA.Why Pressure SAP to Port S/4HANA to AnyDB?
HANA is 100% columnar tables.
0%
HANA does not run entirely with columnar tables. HANA has many row-oriented tables, as much as 1/3 of the database.Why Pressure SAP to Port S/4HANA to AnyDB?
S/4HANA eliminates reconciliation.
0%
S/4HANA does not eliminate reconciliation or reduce the time to perform reconciliation to any significant degree.Does HANA Have a Simplified Data Model and Faster Reconciliation?
HANA outperforms all other databases.
0%
Our research shows that not only can competing databases do more than HANA, but they are also a better fit for ERP systems.How to Understand the Mismatch Between HANA and S/4HANA and ECC.

The Problem: A Lack of Fact-Checking of HANA

There are two fundamental problems around HANA. The first is the exaggeration of HANA, which means that companies that purchased HANA end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.

Being Part of the Solution: What to Do About HANA

We can provide feedback from multiple HANA accounts that provide realistic information around HANA — and this reduces the dependence on biased entities like SAP and all of the large SAP consulting firms that parrot what SAP says. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. This is how companies end up paying for a database which is exorbitantly priced, exorbitantly expensive to implement and exorbitantly expensive to maintain. When SAP or their consulting firm are asked to explain these discrepancies, we have found that they further lie to the customer/client and often turn the issue around on the account, as we covered in the article How SAP Will Gaslight You When Their Software Does Not Work as Promised.

If you need independent advice and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.

This was incorrect from multiple dimensions. SAP receives a 1 out of 10 score for accuracy in this area. 

Inaccurate Messaging on HANA as Communicated in SAP Consulting Firm Videos

For those interested in the accuracy level of information communicated by consulting firms on HANA, see our analysis of the following video by IBM. SAP consulting firms are unreliable sources of information about SAP and primarily serve to simply repeat what SAP says, without any concern for accuracy. The lying in this video is brazen and shows that as a matter of normal course, the consulting firms are happy to provide false information around SAP.

SAP Video Accuracy Measurement

SAP's Statement
Accuracy
Brightwork Fact Check
Link to Analysis Article
HANA runs more "in-memory" than other databases.
10%
HANA uses a lot of memory, but the entire database is not loaded into memory.How to Understand the In-Memory Myth
HANA is orders of magnitude faster than other databases.
0%
Our research shows that not only can competing databases do more than HANA, but they are also a better fit for ERP systems.How to Understand the Mismatch Between HANA and S/4HANA and ECC.
HANA runs faster because it does not use disks like other databases.
0%
Other databases also use SSDs in addition to disk.Why Did SAP Pivot the Explanation of HANA In Memory?
HANA holds "business data" and "UX data" and "mobile data" and "machine learning data" and "IoT data."
0%
HANA is not a unifying database. HANA is only a database that supports a particular application, it is not for supporting data lakes.
SRM and CRM are part of S/4HANA.
0%
SRM and CRM are not part of S/4HANA. They are separate and separately sold applications. SAP C/4HANA is not yet ready for sale. How Accurate Was Bluefin Solutions on C-4HANA?
Netweaver is critical as a platform and is related to HANA.
0%
Netweaver is not relevant for this discussion. Secondly Netweaver is not an efficient environment from which to develop.
HANA works with Business Objects
10%
It is very rare to even hear about HANA and Business Objects. There are few Buisness Objects implementations that use HANA.SAP Business Objects Rating
Leonardo is an important application on SAP accounts.
0%
Leonardo is dead, therefore its discussion here is both misleading and irrelevant.Our 2019 Observation: SAP Leonardo is Dead
IBM Watson is an important application on SAP accounts.
0%
Watson is dead, therefore its discussion here is both misleading and irrelevant.How IBM is Distracting from the Watson Failure to Sell More AI and Machine Learning
Digital Boardroom is an important application on SAP accounts.
0%
SAP Digital Boardroom is another SAP item that has never been implemented many places.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

Search Our Other HANA Content

References

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/inmem/in-memory-column-store-architecture.html#GUID-EEA265EE-8FBA-4457-8C3F-315B9EEA2224

TCO Book

 

TCO3

Enterprise Software TCO: Calculating and Using Total Cost of Ownership for Decision Making

Getting to the Detail of TCO

One aspect of making a software purchasing decision is to compare the Total Cost of Ownership, or TCO, of the applications under consideration: what will the software cost you over its lifespan? But most companies don’t understand what dollar amounts to include in the TCO analysis or where to source these figures, or, if using TCO studies produced by consulting and IT analyst firms, how the TCO amounts were calculated and how to compare TCO across applications.

The Mechanics of TCO

Not only will this book help you appreciate the mechanics of TCO, but you will also gain insight as to the importance of TCO and understand how to strip away the biases and outside influences to make a real TCO comparison between applications.
By reading this book you will:
  • Understand why you need to look at TCO and not just ROI when making your purchasing decision.
  • Discover how an application, which at first glance may seem inexpensive when compared to its competition, could end up being more costly in the long run.
  • Gain an in-depth understanding of the cost, categories to include in an accurate and complete TCO analysis.
  • Learn why ERP systems are not a significant investment, based on their TCO.
  • Find out how to recognize and avoid superficial, incomplete or incorrect TCO analyses that could negatively impact your software purchase decision.
  • Appreciate the importance and cost-effectiveness of a TCO audit.
  • Learn how SCM Focus can provide you with unbiased and well-researched TCO analyses to assist you in your software selection.
Chapters
  • Chapter 1:  Introduction
  • Chapter 2:  The Basics of TCO
  • Chapter 3:  The State of Enterprise TCO
  • Chapter 4:  ERP: The Multi-Billion Dollar TCO Analysis Failure
  • Chapter 5:  The TCO Method Used by Software Decisions
  • Chapter 6:  Using TCO for Better Decision Making