Historically for SAP Business Suite / ERP / OLTP Systems we have all previously used SAP (Sales and Distribution (SD) 2 Tier benchmark results for both sizing the significant majority of SAP workloads and to enable “common currency” comparisons of relative SAP server and database throughput a peak 99-98% utilisation levels.

Subsequently SAP introduced the SAP BW Enhanced Mixed Load (EML) test, which in turn has recently been replaced by the new SAP BW Advanced Mixed Load (AML) benchmark test which in my view are both aimed at OLAP orientated Business Intelligence (BI) HANA based workloads.

There has been a significant absence of published SAP SD results for the SAP HANA database platform, whilst SAP SD results continue to be published for Sybase ASE and/or DB2 10.5 etc.

In my experience when client related large Enterprise intense SAP NetWeaver / ECC transactional (OLTP) and/or batch workloads for both SAP SD order entry type transactions and/or for a representative mixture of client customised and SAP optimised OLTP transactions are executed it becomes clear very quickly that traditional, mature and optimised row orientated database platforms like DB2 10.5 offer significant performance, throughput and efficiency benefits , indeed this short youtube video from Coca Cola Bottling Co highlights very significant improvements in both SAP transactional and batch throughput whilst concurrently saving ~ $1m in TCO reduction through enhanced rates of SAP DB2 data compression.

Conversely running an identical SAP SD like workload “side by side” on both DB2 and SAP HANA with the same SAP application and database server resources simply served to highlight significant “write” (single SQL insert, update and/or delete) penalties associated with running existing customized SAP NetWeaver OLTP / transactional workloads against columnar in-memory data stores vs prior row optimized SAP NetWeaver rdbms platforms.

With the availability of SAP HANA over Linux on POWER8 (LoP) it is also possible to run a representative “side by side” set of SAP BW 7.4 OLAP queries and reports over both SAP HANA and DB2 10.5 with BLU identical fully virtualised SAP BW application server capacity.

These results are indeed very interesting and confirm the benefits of a columnar in-memory strategy for OLAP workloads, whilst also clearly demonstrating the efficiency and maturity existing DB2 query optimisers and multi-threaded and multi core workload distribution and management with DB2 BLU compared to alternatives like SAP HANA.

Indeed it was possible to observe both superior scaling and throughput as the workload concurrency and complexity increased with DB2 BLU whilst using ~ 50% of the configured memory database server capacity and identical SAP BW application server resources.

It was also clear as described in a prior section that SAP BW 7.4 “Flat InfoCubes” and/or semantically partitioned flat Infocubes provided a significant throughput gain on a in-memory columnar platform vs traditional relational row platforms (even if parallel like DB2 DPF).

Personally unless a new SAP S/4 HANA “read optimised” application template has deployed I view Suite of HANA (SoH) simply as a rather uncomfortable mismatch and “half way house” in application and platform technology terms, one that in my view should be avoided if possible.

I have produced the following chart to highlight my viewpoint in this area:

Recently I was also sent a link to this related item on LinkedIn by Shaun Snapp, this item also highlights many of the concerns and questions that I also have about the principle of a size” SAP HANA “one columnar size fits all” workloads and platform strategy.

Indeed some observers would suggest this is being driven as much by SAP SE’s commercial desire to displace existing proven SAP NetWeaver rdbms choices like DB2 10.5 and/or Oracle 12c with their own rdbms platform, irrespective of the benefits or otherwise for their major existing SAP Business Suite clients.

My input to existing large Enterprise SAP Business Suite clients with significant, intense and business critical OLTP workloads would be to ask SAP SE for guarantees that a representative set of critical SAP OLTP and/or batch transactions will perform at a similar of higher level, whilst using a similar set of SAP platform capacity, understanding significant increases in core count and memory capacity to “throw in-memory columnar iron” at a OLTP problem can have very unwelcome real TCO increase issues and really hurt prior DC efficient / Green IT strategies & KPI’s.

Disclaimer – This blog represents the authors own views vs a formal IBM point of view

The views expressed in this blog are the authors and do not represent a formal IBM point of view. They do represent an aggregate of many years (20+) of successful ERP / SAP Platform deployment and IT strategy development experience that is supplemented with many hours of reading, respective DB2 and/or SAP HANA roadmap materials and presentations at various user conferences and/or user groups, in addition to carefully reading input from a range of respected industry / database analyst sources (these sources are respected and quoted).