SAP HANA MCOD – What I really want for my data center

The real SAP game changer will be when I have one (1) HANA DB for all my production applications.  I want single, giant in-memory DB where my ECC, BW, CRM, PLM, SCM, BOBJ, etc. all consume the same data.  I want a row  view for the OLTP ECC-like applications and column view for OLAP BW-like applications.  It would look like the picture below.

sap hana mcod system
What we really need from SAP! The SAP HANA MCOD system.

Right now, I can’t really recommend using HANA on anything but OLAP based applications.  In the future, when we can do the analytic transformations in memory without silly exports, extractors, DSO’s and the like, we will really have a very* different scenario.  For now, the cost of the HANA license and risk of losing transactions only committed to memory is not justifiable.

In this new vision with MCOD, there will be two (2) key issues.  First, how do we support MCOD.  I’ve seen MCOD come and go since 1993 several times. Each time, it was easy to build and impossible to support.  The overlapping requirements became overwhelming. Second, HANA will need a data aging architecture which can age data out of main memory to some slightly slower memory or device.

IBM is working on some important technology, Phase Change Memory, that will be of great value (   It may provide the near DRAM speeds while being cost effective and non-volatile.  Maybe IBM will build out series of servers specifically designed to run in-memory databases such as HANA with massive DRAM and massive PCM capacities.  PCM could then provide the roll-back logs and more at near DRAM speeds. PCM won’t solve the MCOD and data aging problems, but at least the risk of running rapidly transacting OLTP systems would go to near zero and certainly lower than that of even today’s highly cached disk writing databases.

It is going to be a fun watching HANA make it from infancy to toddler-hood.  I wonder how fast she’ll mature.

* Mark Twain said every time a writer was tempted to use “very” in a sentence, they should use the word “damn” and then the editor would strike the word and the sentence would read as it should.


Author: cloudubq

Shaving solutions with Occam's razor while seeking simple elegant synergies. Scientist working as an engineer by architecting systems to improve the world and support my family.

6 thoughts on “SAP HANA MCOD – What I really want for my data center”

  1. Nice and simple.I like your blog and I deal somewhat with HANA in a day to day life. But why do you say “risk of losing transactions only committed to memory”. No committed transaction are actually lost in HANA.

    1. Thanks. If ECC on HANA is running and someone enters an order via VA01 and it is committed to the DB followed by an immediate crash of the system, how is that order not lost? It is in main memory.

      1. For every committed transaction in HANA a log is immediately persisted. It uses concepts of MaxDB persistency layer. So I would say, if the physical log area is corrupted then chances of committed transaction being lost is a possibility, but not in a general crash and restart of the system.

      2. Rahul,

        You are correct. HANA uses rolling log process that is consistent with all other DB roll forward/backward schemas – not just MaxDB. To do this, they require /hana/data/ partition must be able to write at least 800 MB/s and /hana/log/ partition must have a bandwidth of at least 100,000 I/O ops. As I start putting HANA under fortune 100 clients, is this enough? Is it rock solid enough? HANA is still having growing pains in the field.

        I’m confident we will not be having this debate in a few years. Massive SSD development is coming. IBM recently announced a $1B investment. HANA will mature and more transactions will be optimized for it. Newer technology around Phase Change Memory (PCM) will provide near RAM speeds, low cost persistent memory.

        For now, my guidance is to use HANA where the speed makes the business case and the processes are in place to use it. Build it and they will come has never worked in IT. As HANA continues to mature, more is optimized for it, price comes down, skills are more readily available, and we see more MCOD type of capabilities, HANA will become almost the automatic answer. I think that is ~3 years away.

        Again, Rahul, thank you for reading, commenting, and time.

  2. Hi,
    Thanks for the post, it’s a great piece of article. Really saved my day.

    I referred the tutorial , and created a module as described and tried to deploy the mtar in the XSA on premise.
    I get the error as ,
    Error merging descriptors: Unsupported module type “html5” for platform type “XSA” Unsupported module type “html5” for platform type “XSA” ERR Error merging descriptors: Unsupported module type “html5” for platform type “XSA” Unsupported module type “html5” for platform type “XSA”
    The mtad.yml file looked like this,
    _schema-version: “2.0.0” ID: version: “1.1.1” modules: – name: html5only type: html5 path: web
    whereas the same packaging structure works for a node js application when bundled with node js libraries and using
    _schema-version: “2.0.0” ID: version: “1.1.1” modules: – name: html5only type: javascript.nodejs path: web
    I wish to know, why this error occurs and what is the correct way to deploy a html5 module in XSA.

    Appreciate your effort for making such useful blogs and helping the community.
    Thank you,
    Martilye Kevin

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 )

Google photo

You are commenting using your Google 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